Terminal authentication method, function and device, terminal, storage medium and product

Abstract

The invention discloses a terminal authentication method. The method comprises the steps that a first function receives a first message sent by first equipment providing service for a first terminal; wherein the first message comprises one or more of the following items: a first token; a first characteristic parameter of the first terminal; the first token is generated by the first terminal based on a preset first secret key and / or random parameters; the first function authenticates the first terminal based on the first token and / or the first feature parameter. The invention further discloses a first function, first equipment, a first terminal, a computer readable storage medium and a computer program product.

Description

Technical Field

[0001] This application relates to, but is not limited to, the field of communications, and particularly to a terminal authentication method, a first function, a first device, a first terminal, a computer-readable storage medium, and a computer program product. Background Technology

[0002] Currently, passive tags, such as Radio Frequency Identification (RFID), are used for local area services via handheld readers or Wireless Fidelity (Wi-Fi). The 3rd Generation Partnership Project (3GPP) Release 19 (R19) began exploring Ambient Internet of Things (AIoT) topics, including combining AIoT tags with 5G networks to achieve wide-area IoT services.

[0003] However, AIoT tags are limited by their own capabilities and cannot afford reliable encryption algorithms. They are not suitable for 5G authentication methods based on Subscriber Identity Module (SIM) cards as defined by 3GPP in related technologies, as well as complex wireless physical layer authentication methods. Therefore, user data stored inside AIoT tags can be easily obtained by attackers. Attackers can write this data into their own counterfeit tags. These counterfeit tags have the exact same data as the real tags and are difficult to detect, which will cause serious security risks to the network. Summary of the Invention

[0004] This application provides a terminal authentication method, a first function, a first device, a first terminal, a computer-readable storage medium, and a computer program product, ensuring the security of user data inside the tag.

[0005] In a first aspect, embodiments of this application provide a terminal authentication method applied to a first function, including:

[0006] Receive a first message sent by a first device that provides services to a first terminal; wherein the first message includes one or more of the following: a first token; a first characteristic parameter of the first terminal; the first token is generated by the first terminal based on a preset first key and / or random parameters;

[0007] The first terminal is authenticated based on the first token and / or the first feature parameter.

[0008] Secondly, embodiments of this application provide a terminal authentication method, applied to a first device, comprising:

[0009] Receives a second message sent by the first terminal; the second message includes a first token generated by the first terminal based on a preset first key and / or random parameters; the first device is a device that provides services to the first terminal;

[0010] Determine the first characteristic parameter of the first terminal;

[0011] Send a first message to the first function; wherein the first message includes one or more of the following: a first token; a first characteristic parameter of the first terminal.

[0012] Thirdly, embodiments of this application provide a terminal authentication method, applied to a first terminal, comprising:

[0013] Send a second message to the first device; wherein the second message includes a first token generated by the first terminal based on a preset first key and / or random parameters; the first device is a device that provides services to the first terminal.

[0014] Fourthly, embodiments of this application provide a first function, the first function including:

[0015] The first receiving module is configured to receive a first message sent by a first device providing services to the first terminal; wherein the first message includes one or more of the following: a first token; a first characteristic parameter of the first terminal; the first token is generated by the first terminal based on a preset first key and / or random parameters;

[0016] The first processing module is used to authenticate the first terminal based on the first token and / or the first feature parameter.

[0017] Fifthly, embodiments of this application provide a first device, the first device comprising:

[0018] The second receiving module is used to receive a second message sent by the first terminal; the second message includes a first token generated by the first terminal based on a preset first key and / or random parameters; the first device is a device that provides services to the first terminal;

[0019] The second processing module is used to determine the first characteristic parameter of the first terminal;

[0020] The second sending module is used to send a first message to the first function; wherein the first message includes one or more of the following: a first token; a first characteristic parameter of the first terminal.

[0021] Sixthly, embodiments of this application provide a first terminal, the first terminal comprising:

[0022] The third sending module is used to send a second message to the first device; wherein the second message includes a first token generated by the first terminal based on a preset first key and / or random parameters; the first device is a device that provides services to the first terminal.

[0023] Seventhly, embodiments of this application provide a first function, the first function including:

[0024] The first memory is used to store executable instructions;

[0025] The first processor, when executing executable instructions stored in the first memory, implements the aforementioned terminal authentication method.

[0026] Eighthly, embodiments of this application provide a first device, the first device comprising:

[0027] The second memory is used to store executable instructions;

[0028] The second processor, when executing executable instructions stored in the second memory, implements the aforementioned terminal authentication method.

[0029] Ninthly, embodiments of this application provide a first terminal, the first terminal comprising:

[0030] The third memory is used to store executable instructions;

[0031] The third processor, when executing executable instructions stored in the third memory, implements the aforementioned terminal authentication method.

[0032] In a tenth aspect, embodiments of this application provide a computer-readable storage medium storing one or more programs that can be executed by one or more processors to implement the aforementioned terminal authentication method.

[0033] Eleventhly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the aforementioned terminal authentication method.

[0034] This application provides a method for authenticating low-power, low-storage-capability terminals in a network using a first function. The first function receives terminal-related parameters, namely a first token and a first feature parameter, and authenticates the terminal based on these parameters. Furthermore, the first message can be a business message, thus embedding the authentication process into the business message flow. This achieves network-based terminal authentication, protecting data security, and reduces the number of communication interactions with the terminal, thereby reducing power consumption. Moreover, the dual authentication using a token and the first feature parameter ensures authentication accuracy. Since the feature parameter is independent of environmental factors, the authentication process is highly robust to environmental changes and has strong practicality. Attached Figure Description

[0035] Figure 1 This is a schematic diagram of a communication system according to an embodiment of this application;

[0036] Figure 2 A flowchart illustrating the terminal authentication method provided in this application embodiment. Figure 1 ;

[0037] Figure 3 A flowchart illustrating the terminal authentication method provided in this application embodiment. Figure 2 ;

[0038] Figure 4 A flowchart illustrating the terminal authentication method provided in this application embodiment. Figure 3 ;

[0039] Figure 5 A flowchart illustrating the terminal authentication method provided in this application embodiment. Figure 4 ;

[0040] Figure 6 A flowchart illustrating the terminal authentication method provided in this application embodiment. Figure 5 ;

[0041] Figure 7 This application provides a schematic diagram of security domain partitioning as an embodiment.

[0042] Figure 8 This application provides a schematic diagram of a security gateway isolation system.

[0043] Figure 9 A flowchart corresponding to an inventory counting operation provided in related technologies;

[0044] Figure 10 A flowchart corresponding to an inventory counting operation is provided in an embodiment of this application;

[0045] Figure 11 A flowchart corresponding to a command-type business function provided in related technologies;

[0046] Figure 12 A flowchart corresponding to a command-type service provided in an embodiment of this application;

[0047] Figure 13 A flowchart corresponding to a combination of command-type and inventory-type business logic provided in related technologies;

[0048] Figure 14 This application provides a flowchart of a method for verifying tag identity using tag fingerprints for inventory-related business, as provided in this embodiment.

[0049] Figure 15 A schematic block diagram illustrating a first function provided in an embodiment of this application;

[0050] Figure 16 A schematic block diagram of a first device provided in an embodiment of this application;

[0051] Figure 17 A schematic block diagram of a first terminal provided for an embodiment of this application;

[0052] Figure 18 This is a schematic structural diagram of a communication device provided in an embodiment of this application. Detailed Implementation

[0053] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0054] The embodiments of this application can be applied to various communication systems, such as: Global System of Mobile communication (GSM) system, Code Division Multiple Access (CDMA) system, Wideband Code Division Multiple Access (WCDMA) system, General Packet Radio Service (GPRS), Long Term Evolution (LTE) system, Advanced Long Term Evolution (LTE-A) system, New Radio (NR) system, evolution of NR system, Universal Mobile Telecommunication System (UMTS), Wireless Local Area Networks (WLAN), Wireless Fidelity (WiFi), next-generation communication systems, or other communication systems, etc.

[0055] Figure 1 This is a schematic diagram of a communication system according to an embodiment of this application.

[0056] like Figure 1 As shown, the communication system 100 may include a terminal device 110 and a network device 120. The network device 120 can communicate with the terminal device 110 via an air interface. Multi-service transmission is supported between the terminal device 110 and the network device 120.

[0057] exist Figure 1 In the communication system 100 shown, network device 120 can be an access network device that communicates with terminal device 110. The access network device can provide communication coverage for a specific geographical area and can communicate with terminal device 110 located within that coverage area.

[0058] Network device 120 may be an evolved Node B (eNB or eNodeB) in a Long Term Evolution (LTE) system, or a Next Generation Radio Access Network (NG RAN) device, or a base station (gNB or gNodeB) in an NR system, or a radio controller in a Cloud Radio Access Network (CRAN), or the network device 120 may be a relay station, access point, vehicle-mounted equipment, wearable device, hub, switch, bridge, router, or network equipment in a future evolved Public Land Mobile Network (PLMN), etc.

[0059] Terminal equipment 110 can also be referred to as UE, tag, access terminal, user unit, user station, mobile station, mobile station, remote station, remote terminal, mobile device, user terminal, terminal, wireless communication equipment, user agent, or user device, etc. Terminal equipment can be a station (STAION, ST) in a WLAN, a cellular phone, cordless phone, Session Initiation Protocol (SIP) phone, Wireless Local Loop (WLL) station, Personal Digital Assistant (PDA) device, handheld device with wireless communication capabilities, computing device or other processing device connected to a wireless modem, in-vehicle equipment, wearable device, and next-generation communication systems, such as terminal equipment in NR networks or terminal equipment in future evolved Public Land Mobile Network (PLMN) networks, etc.

[0060] The communication system 100 may further include core network equipment 130, which includes, but is not limited to, Access and Mobility Management Function (AMF), Authentication Server Function (AUSF), User Plane Function (UPF), and Session Management Function (SMF). During network evolution, the names of the aforementioned core network equipment may change, or new network entities may be formed by dividing the core network functions; this embodiment does not impose any limitations on this.

[0061] Figure 1 An exemplary embodiment shows a base station, a core network device, and two UEs. Optionally, the communication system 100 may include multiple base stations, and the coverage area of ​​each base station may include other numbers of UEs. This application embodiment does not limit this.

[0062] It should be noted that, Figure 1This application merely illustrates the system to which this application applies; of course, the methods shown in the embodiments of this application can also be applied to other systems. Furthermore, the terms "system" and "network" are often used interchangeably herein. The term "and / or" in this application merely describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this application generally indicates that the preceding and following related objects have an "or" relationship. It should also be understood that "instruction" mentioned in the embodiments of this application can be a direct instruction, an indirect instruction, or an indication of a related relationship. For example, A instructing B can mean that A directly instructs B, for example, B can be obtained through A; it can also mean that A indirectly instructs B, for example, A instructs C, B can be obtained through C; or it can mean that there is a related relationship between A and B. It should also be understood that "correspondence" mentioned in the embodiments of this application can indicate a direct or indirect correspondence between two things, or an related relationship between two things, or a relationship of instruction and being instructed, configuration and being configured, etc. It should also be understood that the "predefined" or "predefined rules" mentioned in the embodiments of this application can be implemented by pre-storing corresponding codes, tables, or other means that can be used to indicate relevant information in the device (e.g., including terminal devices and network devices), and this application does not limit the specific implementation method. For example, predefined can refer to those defined in a protocol. It should also be understood that in the embodiments of this application, the "protocol" can refer to standard protocols in the field of communication, such as LTE protocol, NR protocol, and related protocols applied to future communication systems, and this application does not limit this.

[0063] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and they all fall within the protection scope of the embodiments of this application.

[0064] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0065] Figure 2 A flowchart illustrating a terminal authentication method provided in this application embodiment is shown below. Figure 2 As shown, this method is applied to the first function, and the method includes:

[0066] Step 201: Receive the first message sent by the first device that provides services to the first terminal.

[0067] The first message includes one or more of the following: a first token; a first characteristic parameter of the first terminal; the first token is generated by the first terminal based on a preset first key and / or random parameters.

[0068] In this embodiment, the first terminal and the network side will pre-configure a shared key. After the first terminal receives a relevant request forwarded by the first function through the first device, the first terminal will send the first token to the first function through the first device based on the pre-configured shared key (i.e., the first key) and / or random parameters.

[0069] Here, the shared key can be a quantum key or a regular key generated by a pseudo-random number generator / physical noise source generator. If the first key is a quantum key, it can be generated by a quantum random number generator or by negotiating with the peer through a quantum key distribution (QKD) network, and then provided to the terminal and the network through QKD network nodes or a quantum key security service center.

[0070] In the embodiments of this application, the random parameters are generated by the first function, or by the second function, or by the first terminal, or by the first device. This application does not specifically limit the subject that generates the random parameters.

[0071] If the random parameters are generated by the first terminal or the first device, and the first token is generated based on at least the random parameters, then the first message also includes the random parameters. If the random parameters are generated by the first function or the second function, then the random parameters need to be sent to the first terminal before the first terminal generates the first token.

[0072] Here, the random parameter can be a random value generated based on a random function, and its lifespan can be one authentication process. If the terminal successfully authenticates with the network, or the network successfully authenticates the terminal, and the communication between the network and the terminal ends, the random parameter becomes invalid. Of course, the lifespan of the random parameter can also be one day, one month, or one week. In that case, once the random parameter is generated during the initial authentication between the network and the terminal, subsequent authentications of the terminal by the network can directly use this initial authentication random parameter within its lifespan. Therefore, this application does not specifically limit the lifespan of the random parameter.

[0073] In this embodiment of the application, the first characteristic parameter of the first terminal is a unique parameter of the first terminal, which is a parameter that can uniquely identify the first terminal in addition to its own identifier. For example, the first characteristic parameter can be the power-off time when the first terminal is powered off after charging is completed, the power-off maintenance time during the discharge process of the first terminal, or the sum of the charging time and the power-off maintenance time, or the characteristic parameter of the RC circuit corresponding to the first terminal.

[0074] In this embodiment, the first function is a network function with authentication tag / device capabilities. The network function can be a functional entity such as a network element, controller, or server. Here, a network element can be a network component implemented on dedicated hardware, a software instance running on dedicated hardware, or an instance of virtualized functionality on an appropriate platform.

[0075] Here, the primary function can be a standalone function or it can be integrated into the network functions of related technologies.

[0076] In this embodiment of the application, the first terminal includes a terminal that is difficult to authenticate or has insufficient authentication capabilities. For example, the first terminal is... Figure 1 The terminal device 110 can be a carrier of Radio Frequency Identification (RFID) technology, such as a tag, electronic tag, radio frequency tag, transponder, or data carrier.

[0077] In this embodiment, the first device is a service provider for the first terminal, assisting the first terminal in network authentication or being authenticated by the network. Furthermore, the relevant data and parameters of the first terminal need to be sent through the first device, and relevant instructions for operating the first terminal (such as inventory instructions or command-type instructions) need to be forwarded by the first device. For example, the first device and the first terminal achieve spatial coupling of radio frequency signals through a coupling element. Within the coupling channel, energy transfer and data exchange are realized according to timing relationships. Therefore, the first device can be a reader, also known as a reading device, scanner, read head, communicator, or reader / writer.

[0078] In this embodiment, the first message is sent in various ways, including in-band, out-of-band, media, signaling, data, message, control plane, and user plane. Among these, sending the first message via a media channel, as described in related technologies, offers better compatibility with existing systems and reduces the cost of system modification.

[0079] In this embodiment, the first message is a business-related message, such as a business request, business response, business instruction, or business reply. As can be seen, this application embeds the authentication process into the business message process, which can solve the problem of easy acquisition of terminal data and save the number of communication interactions with the terminal, thereby reducing power consumption.

[0080] In this embodiment of the application, the first message may further include the identifier of the first terminal, a session identifier, a timestamp, or a serial number. If the first message is a message sent in response to an inventory request, then the first message includes the identifier of the first terminal (e.g., a device identifier (Device ID)).

[0081] Step 202: Authenticate the first terminal based on the first token and / or the first feature parameter.

[0082] In this embodiment of the application, the first function can authenticate the first terminal based on a single parameter, namely the first token or the first feature parameter, or it can authenticate the first terminal based on two parameters, namely the first token and the first feature parameter. When using two parameters for authentication, the accuracy of identity verification can be improved. When using one parameter for authentication, the number of communication interactions and terminal power consumption can be reduced while authenticating.

[0083] This application provides a terminal authentication method applied to a first function. The method includes: receiving a first message sent by a first device providing services to a first terminal; wherein the first message includes one or more of the following: a first token; a first characteristic parameter of the first terminal; the first token being generated by the first terminal based on a preset first key and / or random parameters; and authenticating the first terminal based on the first token and / or the first characteristic parameter. In other words, this application provides a method for authenticating a low-power, low-storage-capability terminal in a network's first function. The first function, upon receiving terminal-related parameters, namely the first token and the first characteristic parameter, authenticates the terminal based on the received parameters. Furthermore, the first message can be a business message, thus embedding the authentication process into the business message flow. This achieves network authentication of the terminal, protects data security, and reduces the number of communication interactions with the terminal, thereby reducing power consumption. Moreover, the dual authentication using the token and the first characteristic parameter ensures authentication accuracy. Since the characteristic parameter is independent of environmental factors, the authentication process is highly robust to environmental changes and has strong practicality.

[0084] In some embodiments, step 202, authenticating the first terminal based on the first token and / or the first feature parameter, includes the following steps:

[0085] Step A1: Obtain the second token.

[0086] The second token is generated by the first function or the second function based on the second key and / or random parameters; the second key is preset in the first function or the second function and is the same as the first key.

[0087] In this embodiment of the application, the first key and the second key are a pair of shared keys located in different positions.

[0088] It should be noted that if the second token is generated based on the second key and random parameters, then the first token is generated based on the first key and random parameters; if the second token is generated based on the second key, then the first token is generated based on the first key; if the second token is generated based on random parameters, then the first token is generated based on random parameters. In other words, the first and second tokens are generated based on the same type and the same number of parameters.

[0089] In this embodiment of the application, the second function includes the function of managing related data in the network, such as passive IoT data management (ADM).

[0090] In this embodiment of the application, if the second key and / or random parameters are stored in the second function, the first function needs to obtain the second key and / or random parameters from the second function, and then generate the second token based on the second key and / or random parameters; if the second key and / or random parameters are stored in the first function, the first function directly generates the second token based on the second key and / or random parameters.

[0091] In this embodiment, if the second key and / or random parameters are stored in the second function, the second function generates a second token based on the second key and / or random parameters and sends the second token to the first function. If the second key and / or random parameters are stored in the first function, the first function sends the second key and / or random parameters to the second function, and the second function generates a second token based on the second key and / or random parameters and sends the second token to the first function.

[0092] In this embodiment of the application, the second token can be generated before or after the first token.

[0093] If the first token is generated after the second token, and the second token is generated based on at least random parameters, then the first function needs to send the random parameters to the first terminal before the first message. This enables the first terminal to obtain the random parameters and generate the first token based on at least the random parameters. The terminal can then verify the network based on the first and second tokens.

[0094] If the first token is generated before the second token, and the first token is generated based on at least random parameters, then the first terminal needs to send the random parameters to the first function after the first message. This enables the first function to obtain the random parameters and generate the second token based on at least the random parameters, so that the first function can verify the terminal by the network based on the first and second tokens.

[0095] Step A2: Obtain the second feature parameters of the first terminal.

[0096] The second characteristic parameter is preset in the first function or preset in the second function.

[0097] In this embodiment of the application, the second feature parameter and the first feature parameter represent the same feature parameter of the first terminal. The first feature parameter is the parameter of the first terminal obtained by the first device, and the second feature parameter is the parameter of the first terminal obtained by the first function.

[0098] Step A3: Compare the first token and the second token.

[0099] Step A4: Compare the first feature parameter and the second feature parameter.

[0100] Step A5: If the first token and the second token are the same, and / or the first feature parameter and the second feature parameter are the same, then the first terminal authentication is confirmed to be successful.

[0101] In this embodiment of the application, if the first token and the second token are different, or only the token is used for authentication, then there is no need to execute steps A2 and A4. If the first token and the second token are the same, and authentication is required using both the token and the feature parameter, then steps A2 and A4 are executed, and then it is determined that the first feature parameter is the same as the second feature parameter in order to confirm that the first terminal has passed authentication.

[0102] For example, if the first token and the second token are the same, and the first feature parameter and the second feature parameter are the same, the tag corresponding to the first terminal is determined to be a real tag; otherwise, if the results are inconsistent, the tag is determined to be a fake tag.

[0103] Figure 3 A flowchart illustrating a terminal authentication method provided in this application embodiment is shown below. Figure 3 As shown, the method is applied to a first device, and the method includes:

[0104] Step 301: Receive the second message sent by the first terminal.

[0105] The second message includes a first token generated by the first terminal based on a preset first key and / or random parameters; and a device that provides services to the first terminal.

[0106] In this embodiment, the first terminal and the network side will pre-configure a shared key. After the first terminal receives the relevant request forwarded by the first function through the first device, the first terminal will send the first token to the first device based on the pre-configured shared key (i.e., the first key) and / or random parameters.

[0107] Here, the shared key can be a quantum key or a regular key generated by a pseudo-random number generator / physical noise source generator. If the first key is a quantum key, it can be generated by a quantum random number generator or by negotiating with the peer through a quantum key distribution (QKD) network, and then provided to the terminal and the network through QKD network nodes or a quantum key security service center.

[0108] In the embodiments of this application, the random parameters are generated by the first function, the second function, the first terminal, or the first device. This application does not specifically limit the subject that generates the random parameters.

[0109] If the random parameters are generated by the first terminal or the first device, and the first token is generated based on at least the random parameters, then the first message and the second message also include the random parameters. If the random parameters are generated by the first function or the second function, then the random parameters need to be sent to the first terminal before the first terminal generates the first token.

[0110] Here, the random parameter can be a random value generated based on a random function, and its lifespan can be one authentication process. If the terminal successfully authenticates with the network, or the network successfully authenticates the terminal, and the communication between the network and the terminal ends, the random parameter becomes invalid. Of course, the lifespan of the random parameter can also be one day, one month, or one week. In that case, once the random parameter is generated during the initial authentication between the network and the terminal, subsequent authentications of the terminal by the network can directly use this initial authentication random parameter within its lifespan. Therefore, this application does not specifically limit the lifespan of the random parameter.

[0111] In this embodiment, the second message is sent via various methods, including in-band, out-of-band, media, signaling, data, message, control plane, and user plane. Specifically, the first message is sent via a media channel, a technique employed in related technologies, to better ensure compatibility with existing systems and reduce the cost of system modification.

[0112] In this embodiment, the second message is a business-related message, such as the first message being a business request, business response, business instruction, business reply, etc. It can be seen that this application embeds the authentication process into the business message process, which can solve the problem of easy acquisition of terminal data and save the number of communication interactions with the terminal, thereby reducing power consumption.

[0113] In this embodiment, the second message may further include the identifier of the first terminal. If the second message is sent in response to an inventory request, then the second message includes a Device ID.

[0114] Step 302: Determine the first characteristic parameter of the first terminal.

[0115] In this embodiment of the application, the first characteristic parameter of the first terminal is a unique parameter of the first terminal, which is a parameter that can uniquely identify the first terminal in addition to its own identifier. For example, the first characteristic parameter can be the power-off time when the first terminal is powered off after charging is completed, the power-off maintenance time during the discharge process of the first terminal, or the sum of the charging time and the power-off maintenance time, or the characteristic parameter of the RC circuit corresponding to the first terminal.

[0116] Step 303: Send the first message to the first function.

[0117] The first message includes one or more of the following: a first token; a first characteristic parameter of the first terminal.

[0118] In this embodiment, the first message is sent in various ways, including in-band, out-of-band, media, signaling, data, message, control plane, and user plane. Among these, sending the first message via a media channel, as described in related technologies, offers better compatibility with existing systems and reduces the cost of system modification.

[0119] In this embodiment, the first message is a business-related message, such as a business request, business response, business instruction, or business reply. As can be seen, this application embeds the authentication process into the business message process, which can solve the problem of easy acquisition of terminal data and save the number of communication interactions with the terminal, thereby reducing power consumption.

[0120] In this embodiment of the application, the first message may further include the identifier of the first terminal, a session identifier, a timestamp, or a sequence number. If the first message is sent in response to an inventory request, then the first message includes the identifier of the first terminal (e.g., Device ID).

[0121] This application provides a terminal authentication method applied to a first device. The method includes: receiving a second message sent by a first terminal; wherein the second message includes a first token generated by the first terminal based on a preset first key and / or random parameters; the first device is a device that provides services to the first terminal; determining a first characteristic parameter of the first terminal; and sending a first message to a first function; wherein the first message includes one or more of the following: a first token; the first characteristic parameter of the first terminal; that is, this application provides a method for a first function in a network to authenticate a terminal with low power consumption and limited storage capacity. The first device receives the first token sent by the first terminal through the second message and forwards it to the first function through the first message. The first function authenticates the terminal through the received first token. The first message and the second message can be business messages. In this way, the authentication process is embedded in the business message process, which can realize the network's authentication of the terminal, protect data security, and save the number of communication interactions with the terminal, thereby reducing power consumption. At the same time, the first device can also collect the feature parameters of the first terminal and send them to the first function along with the first token through the first message. The first function can perform dual authentication based on the first token and the first feature parameters, which can ensure the authentication accuracy. The feature parameters are independent of environmental factors, so the authentication process has strong robustness to environmental changes and strong practicality.

[0122] Figure 4 A flowchart illustrating a terminal authentication method provided in this application embodiment is shown below. Figure 4 As shown, this method is applied to a first terminal, and the method includes:

[0123] Step 401: Send the second message to the first device.

[0124] The second message includes a first token generated by the first terminal based on a preset first key and / or random parameters; and a device that provides services to the first terminal.

[0125] In this embodiment, the first terminal and the network side will pre-configure a shared key. After the first terminal receives the relevant request forwarded by the first function through the first device, the first terminal issues a first token based on the pre-configured shared key (i.e., the first key) and / or random parameters.

[0126] Here, the shared key can be a quantum key or a regular key generated by a pseudo-random number generator / physical noise source generator. If the first key is a quantum key, it can be generated by a quantum random number generator or by negotiating with the peer through a QKD network, and then provided to the terminal and the network through QKD network nodes or a quantum key security service center.

[0127] In the embodiments of this application, the random parameters are generated by the first function, the second function, the first terminal, or the first device. This application does not specifically limit the subject that generates the random parameters.

[0128] If the random parameters are generated by the first terminal or the first device, and the first token is generated based on at least the random parameters, then the first message and the second message also include the random parameters. If the random parameters are generated by the first function or the second function, then the random parameters need to be sent to the first terminal before the first terminal generates the first token.

[0129] Here, the random parameter can be a random value generated based on a random function, and its lifespan can be one authentication process. If the terminal successfully authenticates with the network, or the network successfully authenticates the terminal, and the communication between the network and the terminal ends, the random parameter becomes invalid. Of course, the lifespan of the random parameter can also be one day, one month, or one week. In that case, once the random parameter is generated during the initial authentication between the network and the terminal, subsequent authentications of the terminal by the network can directly use this initial authentication random parameter within its lifespan. Therefore, this application does not specifically limit the lifespan of the random parameter.

[0130] In this embodiment, the second message is sent via various methods, including in-band, out-of-band, media, signaling, data, message, control plane, and user plane. Specifically, the first message is sent via a media channel, a technique employed in related technologies, to better ensure compatibility with existing systems and reduce the cost of system modification.

[0131] In this embodiment, the second message is a business-related message, such as the first message being a business request, business response, business instruction, business reply, etc. It can be seen that this application embeds the authentication process into the business message process, which can solve the problem of easy acquisition of terminal data and save the number of communication interactions with the terminal, thereby reducing power consumption.

[0132] In this embodiment, the second message may further include the identifier of the first terminal. If the second message is sent in response to an inventory request, then the second message includes a Device ID.

[0133] This application provides a terminal authentication method applied to a first terminal. The method includes: sending a second message to a first device; wherein the second message includes a first token generated by the first terminal based on a preset first key and / or random parameters; the first device is a device that provides services to the first terminal; that is, this application provides a method for a first function in a network to authenticate a terminal, namely, the first terminal first generates a first token and sends the token to a first function through the first device, and the first function authenticates the terminal by receiving the first token. The second message can be a business message. In this way, the authentication process is embedded in the business message process, which can realize the network's authentication of the terminal, protect data security, and save the number of communication interactions with the terminal, thereby reducing power consumption. Moreover, this authentication method can be well adapted to the limited capabilities of terminals such as low power consumption and low storage.

[0134] Figure 5 A flowchart illustrating a terminal authentication method provided in this application embodiment is shown below. Figure 5 As shown, this method is applied to Figure 1 In the communication system 100 shown, the method includes:

[0135] Step 501: The first terminal sends a second message to the first device.

[0136] The second message includes a first token generated by the first terminal based on a preset first key and / or random parameters; and a device that provides services to the first terminal.

[0137] In this embodiment, the first terminal and the network side will pre-configure a shared key. After the first terminal receives the relevant request forwarded by the first function through the first device, the first terminal will send the first token to the first device based on the pre-configured shared key (i.e., the first key) and / or random parameters.

[0138] Here, the shared key can be a quantum key or a regular key generated by a pseudo-random number generator / physical noise source generator. If the first key is a quantum key, it can be generated by a quantum random number generator or by negotiating with the peer through a QKD network, and then provided to the terminal and the network through QKD network nodes or a quantum key security service center.

[0139] In the embodiments of this application, the random parameters are generated by the first function, the second function, the first terminal, or the first device. This application does not specifically limit the subject that generates the random parameters.

[0140] If the random parameters are generated by the first terminal or the first device, and the first token is generated based on at least the random parameters, then the first message and the second message also include the random parameters. If the random parameters are generated by the first function or the second function, then the random parameters need to be sent to the first terminal before the first terminal generates the first token.

[0141] Here, the random parameter can be a random value generated based on a random function, and its lifespan can be one authentication process. If the terminal successfully authenticates with the network, or the network successfully authenticates the terminal, and the communication between the network and the terminal ends, the random parameter becomes invalid. Of course, the lifespan of the random parameter can also be one day, one month, or one week. In that case, once the random parameter is generated during the initial authentication between the network and the terminal, subsequent authentications of the terminal by the network can directly use this initial authentication random parameter within its lifespan. Therefore, this application does not specifically limit the lifespan of the random parameter.

[0142] In this embodiment, the second message is sent via various methods, including in-band, out-of-band, media, signaling, data, message, control plane, and user plane. Specifically, the first message is sent via a media channel, a technique employed in related technologies, to better ensure compatibility with existing systems and reduce the cost of system modification.

[0143] In this embodiment, the second message is a business-related message, such as the first message being a business request, business response, business instruction, business reply, etc. It can be seen that this application embeds the authentication process into the business message process, which can solve the problem of easy acquisition of terminal data and save the number of communication interactions with the terminal, thereby reducing power consumption.

[0144] In this embodiment, the second message may further include the identifier of the first terminal. If the second message is sent in response to an inventory request, then the second message includes a Device ID.

[0145] Step 502: The first device receives the second message and determines the first characteristic parameter of the first terminal.

[0146] In this embodiment of the application, the first characteristic parameter of the first terminal is a unique parameter of the first terminal, which is a parameter that can uniquely identify the first terminal in addition to its own identifier. For example, the first characteristic parameter can be the power-off time when the first terminal is powered off after charging is completed, the power-off maintenance time during the discharge process of the first terminal, or the sum of the charging time and the power-off maintenance time, or the characteristic parameter of the RC circuit corresponding to the first terminal.

[0147] Step 503: The first device sends a first message to the first function.

[0148] The first message includes one or more of the following: a first token; a first characteristic parameter of the first terminal.

[0149] In this embodiment, the first message is sent in various ways, including in-band, out-of-band, media, signaling, data, message, control plane, and user plane. Among these, sending the first message via a media channel, as described in related technologies, offers better compatibility with existing systems and reduces the cost of system modification.

[0150] In this embodiment, the first message is a business-related message, such as a business request, business response, business instruction, or business reply. As can be seen, this application embeds the authentication process into the business message process, which can solve the problem of easy acquisition of terminal data and save the number of communication interactions with the terminal, thereby reducing power consumption.

[0151] In this embodiment of the application, the first message may further include the identifier of the first terminal, a session identifier, a timestamp, or a sequence number. If the first message is sent in response to an inventory request, then the first message includes the identifier of the first terminal (e.g., Device ID).

[0152] Step 504: The first function receives the first message and authenticates the first terminal based on the first token and / or the first feature parameter.

[0153] In this embodiment of the application, the first function can authenticate the first terminal based on a single parameter, namely the first token or the first feature parameter, or it can authenticate the first terminal based on two parameters, namely the first token and the first feature parameter. When using two parameters for authentication, the accuracy of identity verification can be improved. When using one parameter for authentication, the number of communication interactions and terminal power consumption can be reduced while authenticating.

[0154] This application provides a terminal authentication method, which includes: a first terminal sending a second message to a first device; wherein the second message includes a first token generated by the first terminal based on a preset first key and / or random parameters; the first device is a device that provides services to the first terminal; the first device receives the second message, determines a first characteristic parameter of the first terminal, and sends a first message to a first function; wherein the first message includes one or more of the following: a first token; the first characteristic parameter of the first terminal; and the first function receiving the first message. In other words, this application provides a method for a first function in a network to authenticate a terminal with low power consumption and limited storage capabilities. The terminal sends the generated first token to the first function through the first device, and the first function authenticates the terminal using the received first token. The first device can also collect the characteristic parameters of the first terminal and send them to the first function. The first function can perform dual authentication based on the first token and the first characteristic parameter, ensuring authentication accuracy. Since the characteristic parameter is independent of environmental factors, the authentication process is highly robust to environmental changes and has strong practicality. Furthermore, the message that sends the first token and the first feature parameter can be a business message. In this way, the authentication process is embedded into the business message process, which can not only realize the network's authentication of the terminal and protect data security, but also save the number of communication interactions with the terminal, thereby reducing power consumption.

[0155] Figure 6 A flowchart illustrating a terminal authentication method provided in this application embodiment is shown below. Figure 6 As shown, this method is applied to Figure 1 In the communication system 100 shown, the method includes:

[0156] Step 601: The first function receives the first request sent by the third function through the fourth function.

[0157] The first request includes the first identifier of the first terminal, or the area identifier corresponding to the location where the first terminal is stationed.

[0158] In this embodiment of the application, the first request may be a command request, an inventory request, or a control request.

[0159] In this embodiment, the third function includes, but is not limited to, Figure 1 The core network equipment 130 includes the application functions (AFs).

[0160] In this embodiment, the fourth function includes, but is not limited to, Figure 1 The core network equipment in the system includes NEF, which comprises 130 devices.

[0161] In this embodiment of the application, if the first request is for a single terminal, the first request includes the first identifier of the first terminal; if the first request is for multiple terminals, the first request includes the region identifier of the region where the multiple terminals are located.

[0162] Step 602: The first function selects a first device to provide services to the first terminal based on the first identifier or the area identifier.

[0163] In this embodiment of the application, before the first function forwards the first request to the first device, the first function may obtain a second key and / or random parameters, wherein the second key is preset by the first function or obtained from the second function; and generate a second token based on the second key and / or random parameters.

[0164] In this embodiment of the application, before the first function forwards the first request to the first device, the first function may encrypt the first identifier of the first terminal based on the second key or the second token to obtain the encrypted identifier.

[0165] In this embodiment of the application, before the first function forwards the first request to the first device, the first function may determine a Security Policy Indicator (SPI). The Security Policy Indicator is used to instruct the first device to perform feature-based authentication on the first terminal.

[0166] Step 603: The first function forwards the first request to the first device.

[0167] The first request may include a second token, or the first request may include a random parameter and a second token, or the first request may include a random parameter, a second token, and a first identifier, or the first request may include a second token and a first identifier, or the first request may include a random parameter, a second token, and an encrypted identifier, or the first request may include a second token and an encrypted identifier, or the first request may include a second token and a security policy indication parameter, or the first request may include a random parameter, a second token, and a security policy indication parameter, or the first request may include a random parameter, a second token, a first identifier, and a security policy indication parameter, or the first request may include a second token, a first identifier, and a security policy indication parameter, or the first request may include a random parameter, a second token, an encrypted identifier, and a security policy indication parameter, or the first request may include a second token, an encrypted identifier, and a security policy indication parameter.

[0168] Here, if the first request is for a single terminal, then the first request may include the first identifier or an encrypted identifier. If the first request is for multiple terminals, then the first request may not include the first identifier or the encrypted identifier.

[0169] Step 604: The first device receives the first request and sends the second request to the first terminal.

[0170] The second request may include a second token, or the second request may include a random parameter and a second token, or the second request may include a random parameter, a second token and a first identifier, or the second request may include a second token and a first identifier, or the second request may include a random parameter, a second token and an encrypted identifier, or the second request may include a second token and an encrypted identifier.

[0171] In this embodiment, the second request and the first request are of the same type. If the first request does not include security policy indication parameters, the first device directly forwards the first request. In this case, the first request and the second request are the same request. If the first request includes security policy indication parameters, the first device removes the security policy indication parameters from the first request, generates a second request that does not include the security policy indication parameters, and sends the second request to the first terminal. In this case, the second request is the processed first request and is different from the first request.

[0172] Step 605: The first terminal receives the second request, obtains the first key, and generates the first token based on the first key and / or random parameters.

[0173] In this embodiment of the application, if the first request includes random parameters, then the first token is generated based on the first key and the random parameters, or the random parameters; if the first request does not include random parameters, then the first token is generated based on the first key.

[0174] In this embodiment of the application, if the first request includes a second token, the first token and the second token are compared; if the first token and the second token are the same, it is determined that the first terminal has successfully authenticated the network.

[0175] In this embodiment of the application, if the second request includes an encrypted identifier, the encrypted identifier is decrypted based on the first key or the first token; if the decryption is successful and the first identifier is obtained, it is determined that the first terminal has successfully authenticated the network.

[0176] In this embodiment of the application, if the second request is a disk storage request and the first terminal has successfully authenticated the network, the identity indicator parameter is cached in the storage device of the first terminal; wherein, the identity indicator parameter indicates that the first terminal has successfully authenticated the network.

[0177] In this embodiment of the application, if the second request is a command request and an identity indication parameter exists in the storage device of the first terminal, it is determined that no network authentication is required.

[0178] Step 606: The first terminal sends a second message to the first device.

[0179] The second message includes the first token.

[0180] Step 607: The first device receives the second message.

[0181] Step 608: If the first request includes security policy indication parameters, the first device determines the first feature parameters based on the security policy indication parameters.

[0182] Step 609: The first device sends the first message to the first function.

[0183] The first message includes one or more of the following: a first token; a first characteristic parameter of the first terminal.

[0184] Step 610: The first function receives the first message and authenticates the first terminal based on the first token and / or the first feature parameter.

[0185] It should be noted that if the first function does not generate the second token, the first function may request the second function to generate the second token. The second function responds to the request and obtains the second key and / or random parameters, wherein the second key is preset by the second function or obtained from the first function; and generates the second token based on the second key and / or random parameters. Furthermore, the second function sends the second token to the first function to assist in the authentication of the terminal.

[0186] It should be noted that the first function communicates directly with the first device, or the first function communicates with the first device through the fifth function.

[0187] It should be noted that the first function, the first device, and the second function belong to the first security domain; the fourth function and the fifth function belong to the second security domain; the first security domain and the second security domain are isolated and protected by a security gateway.

[0188] Here, the fifth function includes AMF.

[0189] It should be noted that the descriptions of the same steps and contents as in other embodiments in this embodiment can be found in the descriptions in other embodiments, and will not be repeated here.

[0190] The following describes an exemplary application of the embodiments of this application in the practical application scenario of passive IoT, taking as an example the first terminal being a passive IoT device (AIoT Device), the first device being a passive IoT reader (AIoT Reader) or a passive IoT radio access network reader (AIoT RAN Reader), the first function being a passive IoT function (AIoTF) and passive IoT data management (AIoT data management (ADM), the third function being AIoT AF, and the fourth function being NEF:

[0191] Passive IoT is a contactless automatic identification technology. Passive IoT tags have no built-in power supply. Their working principle is as follows: the passive IoT reader communicates with tags within a certain range by releasing a carrier wave through an antenna. The passive IoT tag draws energy from the carrier wave released by the passive IoT reader. Passive IoT tags have gained market favor due to their low cost, long lifespan, and simple maintenance. Currently, this technology is widely used in various fields, such as logistics and warehousing.

[0192] Passive IoT: Passive IoT tags combined with cellular mobile networks can enable automated inventory management of warehouse goods and wide-area logistics tracking. Passive IoT readers can be integrated into base stations of cellular mobile networks or dedicated passive IoT readers, such as UEs and repeaters, which transmit passive IoT data and / or signaling between base stations and passive IoT devices, and access the core network through the base station.

[0193] Passive IoT tags being studied in 3GPP Release 19 have power consumption of approximately 1 microwatt or several hundred microwatts and a cost of less than 1 RMB. The ultra-low power consumption and low cost of passive IoT tags limit their capabilities, including security capabilities, such as the inability to support USIM cards like normal UEs.

[0194] Currently, based on the deployment requirements of operators, passive IoT may have two networking modes: direct connection and non-direct connection. In the direct connection networking, the AIoTF communicates directly with the AIoT Reader. In the non-direct connection networking, the AIoTF communicates with the AIoT Reader through the AMF.

[0195] The AIoT RAN Reader communicates with tags (AIoT Devices) within a certain range by releasing a carrier wave through its antenna. The AIoT Devices draw power from the carrier wave released by the AIoT RAN Reader.

[0196] Given the security limitations of passive IoT devices (the inability to achieve strong authentication capabilities based on 5G-AKA), passive IoT should be networked independently as much as possible, isolated from the core network of related technologies, to prevent security risks from spreading to the core network. This application proposes an isolation method based on security domains, as follows: Figure 7As shown, AIoT RAN Reader, AIoTF, and ADM are classified as AIoT domain(s) within the operator domain(s), while 5G core network (5GC) elements (such as AMF, Network Repository Function (NRF), and NEF) are classified as 5G core network domain within the operator domain(s). Physical isolation can be used for security protection between different security domains. AIoT RAN Reader communicates with tags (such as AIoT Devices) within a certain range by releasing a carrier wave through its antenna.

[0197] For scenarios involving cross-domain interface interactions, security gateways can be used for interface isolation and protection. Examples include the interaction interfaces between the ADM of the AIoT domain(s) and network elements such as NEF and NRF in the 5G core network domain; the interaction interfaces between the AIoTF of the AIoT domain(s) and network elements such as AMF, NEF, and NRF in the 5G core network domain; and the interaction interfaces between the AIoT RAN Reader of the AIoT domain(s) and network elements such as AMF in the 5G core network domain. Figure 8 As shown, the above-mentioned interaction interface includes the SEG interface. This networking scheme can effectively isolate the passive IoT and the core network of the main network, ensuring the security of the main network.

[0198] Limited by the capabilities of passive IoT tags, this application is based on Figure 7 or Figure 8 The isolation method described herein proposes a lightweight passive IoT authentication method and an embedded authentication process. The parameters pre-configured on both the passive IoT device and network sides can include: a long-term root key, a device ID, and the mapping between the long-term root key and the device ID. An authentication token is calculated using the root key. The device and network sides authenticate each other by comparing the token calculated using their respective stored keys with the expected token Xtoken. The authentication process provided in this application differs from the independent authentication processes of 5G-AKA or EAP-AKA in related technologies; instead, it is embedded within the passive IoT service message flow. This reduces the number of communication interactions with the passive tag, thereby reducing the tag's power consumption.

[0199] Passive IoT mainly has two types of services: inventory-type services and command-type services.

[0200] Inventory is a typical business of passive IoT. For example, a large supermarket needs to automatically count the quantity of goods in its warehouse. By attaching a label to each item, when the user application actively triggers the inventory operation, the passive IoT reader can automatically scan all matching labels within its target range to quickly realize the inventory count.

[0201] Command services are another typical service in passive IoT, where tags can perform corresponding read and write operations based on the commands sent by the user application.

[0202] The authentication process provided in this application includes the following, depending on the specific business process:

[0203] First, let's explain the inventory counting process:

[0204] Figure 9 This is a flowchart provided in related technologies corresponding to inventory counting operations, such as... Figure 9 As shown:

[0205] Step 901: The AIoT AF sends an inventory request to the network (e.g., to the AIoT F via NEF);

[0206] The inventory request may or may not include the tag's Device ID; when AIoT AF is inventorying multiple tags simultaneously, it does not include the Device ID.

[0207] Step 902: After receiving the inventory request, AIoTF selects an AIoT Reader and forwards the inventory request to the selected AIoT Reader.

[0208] Step 903: The AIoT Reader sends an inventory request to the AIoT Device.

[0209] Step 904: After receiving the inventory request, the AIoT Device reports its Device ID to the network through the inventory response.

[0210] Here, the inventory response sent by the AIoT Device is sent to AIoTAF sequentially through AIoT Reader, AIoTF, and NEF.

[0211] Figure 10This is a flowchart of an inventory counting process provided in an embodiment of this application, such as... Figure 10 As shown:

[0212] Step 1001: AIoT AF sends an inventory request to NEF.

[0213] The inventory request may or may not include the tag's Device ID; when AIoT AF inventories multiple tags simultaneously, it does not include the Device ID.

[0214] Step 1002: NEF forwards the inventory request to AIoTF.

[0215] Step 1003: AIoTF or ADM generates a random number RAND_n and obtains the preset key Key1.

[0216] In this embodiment of the application, RAND_n can be a random number generated by AIoTF or ADM based on a random function.

[0217] Step 1004: AIoTF calculates the expected token 1 (XToken1).

[0218] In this embodiment of the application, if the tag needs to authenticate the network, step 1004 needs to be executed; if the tag does not need to authenticate the network, step 1004 is not executed.

[0219] Here, XToken1 can be calculated based on Key1; if Key1 is stored in ADM, AIoTF obtains Key1 from ADM and calculates XToken1 based on Key1; if Key1 is stored in AIoTF, AIoTF directly calculates XToken1 based on Key1.

[0220] Here, XToken1 can also be calculated based on Key1 and RAND_n. XToken1 can be calculated using a Key Derivation Function (KDF) or a Hash-based Message Authentication Code (HMAC) function. The inputs to the KDF and the HMAC function are Key1 and RAND_n.

[0221] It should be noted that if RAND_n is generated by ADM, AIoTF obtains RAND_n from ADM.

[0222] Step 1005: AIoTF selects AIoT Reader and sends the inventory request to AIoT Reader.

[0223] The inventory request includes the Device ID (optional) of the tag and the RAND_n generated by the network side (AIoTF or ADM).

[0224] If the tag needs to authenticate the network, the inventory request should include the Device ID (optional), RAND_n, and XToken1.

[0225] If an implicit tag authentication network method is adopted, AIoTF uses a key (Key1) or a derived XToken1 to encrypt the Device ID to obtain an Encrypted ID. Then, the inventory request carries the Encrypted ID and RAND_n, or Encrypted ID, RAND_n and XToken1.

[0226] Here, encryption can be performed using the AES algorithm, with input parameters Key1, RAND_n, and Device ID.

[0227] Step 1006: The AIoT Reader sends the inventory request to the AIoT Device.

[0228] The inventory request includes the label Device ID (optional) and RAND_n.

[0229] If the tag needs to authenticate the network, the inventory request should include the Device ID (optional), RAND_n, and XToken1.

[0230] If an implicit label authentication network method is used, the inventory request carries the Encrypted ID and RAND_n, or the Encrypted ID, RAND_n and XToken1.

[0231] Step 1007: AIoT Device Computation Token.

[0232] In this embodiment of the application, the AIoT Device calculates the Token based on the locally stored key (Key2) and the received RAND_n.

[0233] In this embodiment of the application, the AIoT Device may generate a random number RAND_d and calculate the Token based on Key2, the received RAND_n, and the generated random number RAND_d.

[0234] In this embodiment of the application, if an implicit tag authentication network method is used, the tag is authenticated by the network if the EncryptedID is decrypted based on Key2 and the decryption is successful; or the expected token is calculated based on Key2 and RAND_n, and then the EncryptedID is decrypted based on the calculated expected token. If the decryption is successful, the tag is authenticated by the network.

[0235] Here, the token can be computed using KDF; where the inputs of KDF are Key2 and RAND_n.

[0236] Step 1008: The AIoT Device is authenticated based on the Token and XToken1.

[0237] In this embodiment, if the tag needs to authenticate with the network, the AIoT Device executes step 1008, which involves comparing the received XToken1 and Token. If the comparison results are equal, the tag's authentication with the network is successful; otherwise, the tag's authentication with the network fails. If the tag does not need to authenticate with the network, the AIoT Device does not execute step 1008.

[0238] Step 1009: The AIoT Device responds to the inventory request and sends the inventory response to the AIoT Reader.

[0239] The inventory response includes the actual identifier (Device ID) reported by the tag, the locally calculated Token, and / or RAND_d.

[0240] Step 1010: The AIoT Reader sends the inventory response to the AIoTF.

[0241] The inventory response includes the actual identifier, token, and / or RAND_d reported by the AIoT Device.

[0242] Step 1011: AIoTF sends authentication information to ADM.

[0243] If Key1 is stored in ADM and RAND_n is generated by ADM, then AIoTF sends authentication information to ADM, which is used to request ADM to generate the desired token 2 (XToken2) based on Key1 and RAND_n.

[0244] If Key1 is stored in AIoTF and RAND_n is generated by AIoTF, then the authentication information sent by AIoTF to ADM may also include Key1 and RAND_n.

[0245] If the token is generated based on Key2, RAND_n, and RAND_d, then the authentication information sent by AIoTF to ADM may also include RAND_d.

[0246] Step 1012: ADM calculates the expected XToken2.

[0247] In this embodiment of the application, ADM calculates XToken2 based on Key1 and RAND_n, or calculates XToken2 based on Key1, RAND_d and RAND_n.

[0248] Step 1013: ADM returns the calculated XToken2 to AIoTF.

[0249] Step 1014: AIoTF authenticates the tag based on the XToken and the received Token.

[0250] Here, XToken can be XToken1 calculated locally by AIoTF, or XToken2 calculated by ADM received by AIoTF.

[0251] In this embodiment of the application, XToken and Token are compared. If the comparison result is equal, the tag passes the network authentication, i.e., the authentication is successful. If the comparison result is not equal, the tag fails the network authentication, i.e., the authentication fails.

[0252] Step 1015: If authentication is successful, AIoTF will send the real identifier reported by the AIoT Device to AIoT AF via NEF.

[0253] Based on the above, this application pre-configures shared keys on both the network and tag sides. The authentication token is calculated separately by the network's AIoTF and AIoTDevice, or ADM and AIoT Device. Before forwarding the inventory request, the AIoTF calculates XToken1 based on the network-side key. The AIoT Device calculates the actual token based on its local key. The tag can also authenticate itself to the network by comparing the received XToken1 with its local token. After receiving the inventory response from the AIoT Device, the AIoTF compares the received token with XToken1, or the received token with XToken2, thereby authenticating the AIoT Device.

[0254] Meanwhile, this application also proposes an implicit tag authentication network method, in which the network encrypts the Device ID, and the tag side successfully decrypts it with a local key to authenticate the network and protect the transmission of the Device ID.

[0255] Next, we will explain the command-type business logic:

[0256] Figure 11 It is a flowchart corresponding to a command-type business function provided in related technologies, such as Figure 11 As shown:

[0257] Step 1101: The AIoT AF sends a command request to the network (e.g., from NEF to AIoTF);

[0258] The command request can include the tag's Device ID or not; when AIoT AF is inventorying multiple tags at the same time, it does not include the Device ID.

[0259] Step 1102: After receiving the command request, AIoTF selects an AIoT Reader and forwards the command request to the selected AIoT Reader.

[0260] Step 1103: The AIoT Reader sends the command request to the AIoT Device.

[0261] Step 1104: The AIoT Device receives the command request, executes the command-type operation, and returns a command response to the network.

[0262] Here, the command response sent by the AIoT Device is sent to the AIoT AF in sequence through the AIoT Reader, AIoTF, and NEF.

[0263] Figure 12 This is a flowchart of a command-type service provided in an embodiment of this application, such as... Figure 12 As shown:

[0264] Step 1201: AIoT AF sends a command-type request to NEF.

[0265] The command request may or may not include the tag's Device ID; when the AIoT AF commands multiple tags simultaneously, it does not include the Device ID.

[0266] Step 1202: NEF forwards the command request to AIoTF.

[0267] Step 1203: AIoTF or ADM generates a random number RAND_n and obtains the preset key Key1.

[0268] In this embodiment of the application, RAND_n can be a random number generated by AIoTF or ADM based on a random function.

[0269] Step 1204: AIoTF calculates XToken1.

[0270] Here, XToken1 can be calculated based on Key1; if Key1 is stored in ADM, AIoTF obtains Key1 from ADM and calculates XToken1 based on Key1; if Key1 is stored in AIoTF, AIoTF directly calculates XToken1 based on Key1.

[0271] Here, XToken1 can also be calculated based on Key1 and RAND_n; XToken1 can be calculated using KDF or HMAC functions based on Key1 and RAND_n; where the inputs of KDF are Key1 and RAND_n, and the inputs of HMAC functions are Key1 and RAND_n.

[0272] It should be noted that if RAND_n is generated by ADM, AIoTF obtains RAND_n from ADM.

[0273] Step 1205: AIoTF selects an AIoT Reader and sends command requests to the AIoT Reader;

[0274] The command-type request carries the Device ID (for single-tag scenarios), RAND_n generated by the network side, and XToken1.

[0275] If an implicit tag authentication network method is adopted, AIoTF uses Key1 or the derived XToken1 to encrypt the DeviceID to obtain the Encrypted ID. Then, the command-type request carries the Encrypted ID and RAND_n, or the Encrypted ID, RAND_n and XToken1.

[0276] Here, encryption can use the AES algorithm, where the input parameters are Key1, RAND_n, and Device ID.

[0277] Step 1206: The AIoT Reader sends a command request to the AIoT Device.

[0278] The command-type request carries the label Device ID (for single-label scenarios), RAND_n, and XToken1.

[0279] If an implicit label authentication network method is used, the command request carries the Encrypted ID and RAND_n, or the Encrypted ID, RAND_n and XToken1.

[0280] Step 1207: AIoT Device Computation Token.

[0281] In this embodiment of the application, the AIoT Device calculates the Token based on the locally stored key (Key2) and the received RAND_n.

[0282] In this embodiment of the application, the AIoT Device may generate a random number RAND_d and calculate the Token based on Key2, the received RAND_n, and the generated random number RAND_d.

[0283] In this embodiment of the application, if an implicit tag authentication network method is used, the EncryptedID is decrypted based on Key2. If the decryption is successful, the tag is authenticated by the network. Alternatively, the expected token is calculated based on Key2 and RAND_n, and then the EncryptedID is decrypted based on the calculated expected token. If the decryption is successful, the tag is authenticated by the network.

[0284] Here, the token can be computed using KDF; where the inputs of KDF are Key2 and RAND_n.

[0285] Step 1208: The AIoT Device is authenticated based on the Token and XToken1.

[0286] In this embodiment of the application, XToken1 and Token are compared. If the comparison result is equal, the tag's authentication with the network is successful; if the comparison result is not equal, the tag's authentication with the network is unsuccessful.

[0287] Step 1209: If authentication is successful, the AIoT Device responds to the command request, executes the command operation, and sends the command response to the network.

[0288] Here, the command-type responses sent by the AIoT Device are sequentially sent to the AIoT AF via the AIoT Reader, AIoTF, and NEF.

[0289] As can be seen from the above, this application pre-configures a shared key on the network side and the tag side. The AIoTF and AIoTDevice of the network calculate the authentication token respectively. Before forwarding command-type requests, the AIoTF calculates the expected token 1 (XToken1) based on the network-side key and sends XToken1 to the AIoT Device along with the command-type request message. The AIoT Device calculates the actual token (Token) based on the local key and compares the Token with XToken1, thereby realizing the authentication of the network.

[0290] Meanwhile, this application also proposes an implicit tag authentication network method, in which the network encrypts the Device ID, and the tag side successfully decrypts it with a local key to authenticate the network and protect the transmission of the Device ID.

[0291] Next, we will explain the combined business logic of command-based and inventory-based operations:

[0292] Figure 13 This is a flowchart of a combined command-type and inventory-type business process provided in related technologies, such as... Figure 13 As shown:

[0293] Step 1301: The AIoT AF sends an inventory request to the network (e.g., via NEF to AIoTF);

[0294] The inventory request may or may not include the tag's Device ID; when AIoT AF is inventorying multiple tags simultaneously, it does not include the Device ID.

[0295] Step 1302: After receiving the inventory request, AIoTF selects an AIoT Reader and forwards the inventory request to the selected AIoT Reader.

[0296] Step 1303: The AIoT Reader sends an inventory request to the AIoT Device.

[0297] Step 1304: After receiving the inventory request, the AIoT Device reports its Device ID to the AIoTF through the inventory response.

[0298] Here, the inventory response sent by the AIoT Device is sequentially sent to the AIoTF via the AIoT Reader.

[0299] Step 1305: After receiving the Device ID, AIoTF sends the command request to the specific AIoT Device through AIoT Reader.

[0300] Step 1306: The AIoT Device receives the command request, executes the command operation, and returns the execution result to the network.

[0301] Here, the execution results sent by the AIoT Device are sequentially sent to AIoTAF via AIoT Reader, AIoTF, and NEF.

[0302] For business processes involving a combination of command and inventory operations, the authentication process is a combination of inventory and command authentication processes. The difference lies in the following: During the inventory phase, the tag first authenticates with the network. If the tag's capabilities allow, it stores this authentication result, which can be cached as an Auth indicator through the tag register. During the command phase, the tag checks the status of the Auth indicator. If it is already authenticated, the step of the tag authenticating with the network again is omitted.

[0303] It should be noted that for inventory management services, if a tag is hijacked, an attacker can copy the tag's key and use it to deceive the authentication process, thereby attacking the network. For example, an attacker who hijacks a tag, copies the key, or even the Device ID, can successfully pass authentication. If the attacker is using a non-passive IoT tag, such as a resource-unrestricted device, this device could launch a malicious attack on the network after connecting, with very serious consequences, especially for private networks with high security requirements. Therefore, to further ensure network security, this application introduces a device fingerprint-based authentication method on top of the aforementioned authentication methods, namely, a tag fingerprint-based dual authentication method. During the network's tag authentication process, the extracted tag fingerprint is compared with the tag fingerprint pre-stored in the network. If the results match, the tag is determined to be genuine; otherwise, if the results do not match, the tag is determined to be counterfeit. This verification step can be performed after the network has completed lightweight tag authentication, enabling re-verification of the tag's identity and thus improving the accuracy of identity verification.

[0304] This application uses the tag fingerprint to measure the power-off duration during which a passive IoT tag can function normally after being fully charged and then powered off. Passive IoT tags do not have a built-in power supply. The reader communicates with tags within a certain range by releasing a carrier wave through its antenna. The passive tag continuously draws energy from the carrier wave released by the reader. To ensure reliable and continuous operation, the tag needs to store some electrical energy in its chip, which is equivalent to a resistive-capacitor (RC) charging circuit. Two tags cannot have exactly the same RC circuit. By detecting this difference, fingerprint identification of each tag can be performed from the perspective of the physical layer circuit. This application uses the power-off duration T as an indicator to reflect the characteristics of the RC circuit. The power-off duration refers to the time span from when the RC circuit is fully charged and then powered off, decaying from a fully charged state to a low level (the lowest voltage state for the tag to operate normally). This parameter depends on the RC circuit itself. Based on the different power-off duration T, counterfeit tags and genuine tags can be distinguished by measuring the tag's power-off duration T. Specifically, the state of the tag's flag can be used as a reference for the tag's battery level. The tag's flag is a type of volatile memory that requires power to maintain the stored information. Once the power is cut off or the supply voltage falls below a threshold, the stored data will be quickly lost. Utilizing this characteristic, the state transition of the tag's Inventory Flag or Select Flag can be used as the basis for tag fingerprint identification.

[0305] Figure 14 This application provides a flowchart illustrating how tag fingerprints are used for tag authentication in inventory management operations. Figure 14 As shown:

[0306] Step 1401: AIoT AF sends an inventory request to NEF.

[0307] The inventory request may or may not include the tag's Device ID; when AIoT AF inventories multiple tags simultaneously, it does not include the Device ID.

[0308] Step 1402: NEF forwards the inventory request to AIoTF.

[0309] Step 1403: AIoTF or ADM generates a random number RAND_n and obtains the preset key Key1.

[0310] In this embodiment of the application, RAND_n can be a random number generated by AIoTF or ADM based on a random function.

[0311] Step 1404: AIoTF calculates the expected token 1 (XToken1).

[0312] Here, XToken1 can be calculated based on Key1; if Key1 is stored in ADM, AIoTF obtains Key1 from ADM and calculates XToken1 based on Key1; if Key1 is stored in AIoTF, AIoTF directly calculates XToken1 based on Key1.

[0313] Here, XToken1 can also be calculated based on Key1 and RAND_n; XToken1 can be calculated using KDF or HMAC functions based on Key1 and RAND_n; where the inputs of KDF are Key1 and RAND_n, and the inputs of HMAC functions are Key1 and RAND_n.

[0314] It should be noted that if RAND_n is generated by ADM, AIoTF obtains RAND_n from ADM.

[0315] Step 1405: AIoTF selects AIoT Reader and sends the inventory request to AIoT Reader;

[0316] The inventory request includes the Device ID of the tag (for single-tag inventory services), the RAND_n generated by the network side, and the Security Policy Indicator (SPI).

[0317] The SPI is used to instruct the AIoT Reader to perform fingerprint-based authentication on the tag. The SPI may be pre-configured on the network side, such as in the ADM or AIoTF, or it may be sent from the AIoT AF to the AIoTF with the inventory request.

[0318] Step 1406: The AIoT Reader sends the inventory request to the AIoT Device.

[0319] The inventory request carries the label Device ID (for single-label inventory services) and RAND_n.

[0320] Step 1407: AIoT Device Computation Token.

[0321] In this embodiment of the application, the AIoT Device calculates the Token based on the locally stored key (Key2) and the received RAND_n.

[0322] Here, the token can be calculated using the KDF function, where the inputs to the KDF are Key2 and RAND_n, or the token can be calculated using the HMAC function, where the inputs to the HMAC function are Key2 and RAND_n.

[0323] Step 1408: The AIoT Device responds to the inventory request and sends the inventory response to the AIoT Reader.

[0324] The inventory response includes the actual identifier (Device ID) reported by the tag and the locally calculated token.

[0325] Step 1409: The AIoT Reader extracts the device fingerprint of the AIoT Device according to the instructions of the SPI.

[0326] It should be noted that step 1409 can be executed at any time after step 1405 and before step 1410.

[0327] Step 1410: The AIoT Reader sends the inventory response to the AIoTF.

[0328] The inventory response includes the real identifier, token, and device fingerprint reported by the AIoT Device.

[0329] Step 1411: AIoTF authenticates the tag based on XToken1 and the received token.

[0330] The XToken and the Token are compared. If they are equal, the tag passes the network's authentication process. If they are not equal, the tag fails the network's authentication process.

[0331] Step 1412: If authentication is successful, AIoTF verifies the tag fingerprint.

[0332] Step 1413: If the verification is successful, AIoTF will send the Device ID reported by the AIoT Device to AIoT AF via NEF.

[0333] It should be noted that, Figure 14 The corresponding flowchart assumes the default steps for the tag authentication network. If your tag requires network authentication, please refer to [the provided flowchart]. Figure 10 The label authentication network steps in the process, namely Figure 14 The corresponding flowchart may also include the tag authentication network process.

[0334] Embodiments of this application provide a first function, which can be used to implement Figure 2 , Figure 5 , Figure 6 A corresponding embodiment provides a terminal authentication method, referring to... Figure 15 As shown, the first function 1500 includes:

[0335] The first receiving module 1501 is configured to receive a first message sent by a first device providing services to the first terminal; wherein the first message includes one or more of the following: a first token; a first characteristic parameter of the first terminal; the first token is generated by the first terminal based on a preset first key and / or random parameters;

[0336] The first processing module 1502 is used to authenticate the first terminal based on the first token and / or the first feature parameter.

[0337] In other embodiments of this application, the first acquisition module 1503 is used to acquire a second token; wherein, the second token is generated by the first function second token based on a second key and / or random parameters; the second key is preset in the first function or the second function and is the same as the first key;

[0338] The first acquisition module 1503 is used to acquire the second feature parameter of the first terminal; wherein the second feature parameter is preset in the first function or preset in the second function;

[0339] The first processing module 1502 is used to compare the first token and the second token;

[0340] The first processing module 1502 is used to compare the first feature parameter and the second feature parameter;

[0341] The first processing module 1502 is used to determine that the first terminal authentication is successful if the first token and the second token are the same, and / or the first feature parameter and the second feature parameter are the same.

[0342] In other embodiments of this application, the first receiving module 1501 is used to receive a first request sent by the third function through the fourth function; the first request includes a first identifier of the first terminal, or an area identifier corresponding to the location where the first terminal is stationed.

[0343] The first processing module 1502 is used to select a first device to provide services to the first terminal based on a first identifier or a region identifier;

[0344] The first sending module 1504 is used to forward the first request to the first device.

[0345] In other embodiments of this application, the first acquisition module 1503 is used to acquire a second key and / or random parameters; wherein the second key is preset by the first function, or the second key is acquired from the second function;

[0346] The first processing module 1502 is used to generate a second token based on a second key and / or random parameters;

[0347] The first sending module 1504 is used to forward a first request to the first device; wherein the first request includes a second token, or the first request includes random parameters and a second token.

[0348] In other embodiments of this application, the first processing module 1502 is used to encrypt the first identifier of the first terminal based on the second key or the second token to obtain the encrypted identifier;

[0349] The first sending module 1504 is used to forward a first request to the first device; wherein the first request also includes an encrypted identifier.

[0350] In other embodiments of this application, the first processing module 1502 is used to determine security policy indication parameters; wherein, the security policy indication parameters are used to instruct the first device to perform authentication based on feature parameters on the first terminal;

[0351] The first sending module 1504 is used to forward a first request to the first device; wherein the first request further includes security policy indication parameters.

[0352] In other embodiments of this application, the first function communicates directly with the first device, or the first function communicates with the first device through the fifth function.

[0353] In other embodiments of this application, the first function, the first device, and the second function belong to the first security domain; the fourth function and the fifth function belong to the second security domain; the first security domain and the second security domain are isolated and protected by a security gateway.

[0354] The descriptions of the above device embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0355] It should be noted that, in the embodiments of this application, if the above-mentioned terminal authentication method is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a terminal device to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, mobile hard drives, read-only memory (ROM), magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0356] Embodiments of this application provide a first device that can be used to implement Figure 3 , Figure 5 , Figure 6 A corresponding embodiment provides a terminal authentication method, referring to... Figure 16 As shown, the first device 1600 includes:

[0357] The second receiving module 1601 is used to receive a second message sent by the first terminal; the second message includes a first token generated by the first terminal based on a preset first key and / or random parameters; and a device that provides services to the first terminal.

[0358] The second processing module 1602 is used to determine the first characteristic parameter of the first terminal;

[0359] The second sending module 1603 is used to send a first message to the first function; wherein the first message includes one or more of the following: a first token; a first characteristic parameter of the first terminal.

[0360] In other embodiments of this application, the second receiving module 1601 is used to receive a first request for forwarding by the first function; wherein, the first request includes one or more of the following: a second token; random parameters; security policy indication parameters; a first identifier of the first terminal; an encrypted identifier; the second token is generated by the first function or the second function based on a second key and / or random parameters; the encrypted identifier is obtained by the first function encrypting the first identifier based on the second key or the second token; the security policy indication parameters are used to instruct the first device to perform authentication based on feature parameters on the first terminal;

[0361] The second sending module 1603 is used to send a second request to the first terminal; wherein the second request includes one or more of the following: a second token; random parameters; a first identifier of the first terminal; and an encrypted identifier.

[0362] In other embodiments of this application, the second processing module 1602 is used to determine the first feature parameter based on the security policy indication parameter if the first request includes a security policy indication parameter.

[0363] The descriptions of the above device embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0364] It should be noted that, in the embodiments of this application, if the above-described terminal authentication method is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a terminal device to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROMs, magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0365] This application provides a first terminal, which can be used to implement... Figure 4 , Figure 5 , Figure 6 A corresponding embodiment provides a terminal authentication method, referring to... Figure 17 As shown, the first terminal 1700 includes one or more of the following:

[0366] The third sending module 1701 is used to send a second message to the first device; wherein the second message includes a first token generated by the first terminal based on a preset first key and / or random parameters; the first device is a device that provides services to the first terminal.

[0367] In other embodiments of this application, the third receiving module 1702 is used to receive a second request forwarded by the first device; wherein the second request includes one or more of the following: a second token; random parameters; a first identifier of the first terminal; an encrypted identifier; the second token is generated by the first function or the second function based on a second key and / or random parameters; the encrypted identifier is obtained by the first function encrypting the first identifier based on the second key or the second token;

[0368] The third acquisition module 1703 is used to acquire the first key;

[0369] The third processing module 1704 is used to generate a first token based on the first key and / or random parameters.

[0370] In other embodiments of this application, the third processing module 1704 is used to compare the first token and the second token if the second request includes the second token.

[0371] The third processing module 1704 is used to determine that the first terminal has successfully authenticated with the network if the first token and the second token are the same.

[0372] In other embodiments of this application, the third processing module 1704 is used to decrypt the encrypted identifier based on the first key or the first token if the second request includes the encrypted identifier.

[0373] The third processing module 1704 is used to determine that the first terminal has successfully authenticated the network if the first identifier is obtained after successful decryption.

[0374] In other embodiments of this application, the third processing module 1704 is used to cache identity indication parameters in the storage device of the first terminal if the second request is a disk storage request and the first terminal has successfully authenticated the network; wherein the identity indication parameters indicate that the first terminal has successfully authenticated the network.

[0375] In other embodiments of this application, the third processing module 1704 is used to determine that no network authentication is required if the second request is a command-type request and an identity indication parameter exists in the storage device of the first terminal.

[0376] The descriptions of the above device embodiments are similar to those of the above method embodiments, and have similar beneficial effects. For technical details not disclosed in the device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0377] It should be noted that, in the embodiments of this application, if the above-mentioned terminal authentication method is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiments of this application, or the part that contributes to the related technology, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a network device to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, mobile hard drives, ROMs, magnetic disks, or optical disks. Thus, the embodiments of this application are not limited to any specific hardware and software combination.

[0378] Figure 18 This is a schematic structural diagram of a communication device 1800 provided in an embodiment of this application. The communication device can be a first function, a first device, or a first terminal. Figure 18The communication device 1800 shown includes a processor 1810, which can call and run computer programs from memory to implement the methods in the embodiments of this application.

[0379] Optionally, such as Figure 18 As shown, the communication device 1800 may further include a memory 1820. The processor 1810 can retrieve and run computer programs from the memory 1820 to implement the methods described in this embodiment.

[0380] The memory 1820 can be a separate device independent of the processor 1810, or it can be integrated into the processor 1810.

[0381] Optionally, such as Figure 18 As shown, the communication device 1800 may also include a transceiver 1830, and the processor 1810 may control the transceiver 1830 to communicate with other devices. Specifically, it may send information or data to other devices or receive information or data sent by other devices.

[0382] The transceiver 1830 may include a transmitter and a receiver. The transceiver 1830 may further include an antenna, and the number of antennas may be one or more.

[0383] Optionally, the communication device 1800 may specifically be the first function of the embodiments of this application, and the communication device 1800 may implement the corresponding processes implemented by the first function in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0384] Optionally, the communication device 1800 may specifically be the first device in the embodiments of this application, and the communication device 1800 may implement the corresponding processes implemented by the first device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0385] Optionally, the communication device 1800 may specifically be the first terminal in the embodiments of this application, and the communication device 1800 may implement the corresponding processes implemented by the first terminal in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0386] This application also provides a computer program product, including a computer program that can be executed by the processor 1810 of the communication device 1800 to complete the steps described in any of the foregoing methods.

[0387] It should be understood that the processor in the embodiments of this application may be an integrated circuit chip with signal processing capabilities. In implementation, the steps of the above method embodiments can be completed by integrated logic circuits in the processor's hardware or by instructions in software form. The processor described above can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method.

[0388] As one embodiment, the processor may include one or more general-purpose central processing units (CPUs). Each of these processors may be a single-core processor or a multi-core processor. Here, "processor" may refer to one or more devices, circuits, and / or processing cores used for processing data (e.g., executing instructions).

[0389] It is understood that the memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be ROM, Programmable Read-Only Memory (PROM), Erasable Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM), or flash memory. The volatile memory can be Random Access Memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Synchlink DRAM (SLDRAM), and Direct Rambus RAM (DR RAM). It should be noted that the memory used in the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

[0390] This application also provides a computer-readable storage medium for storing computer programs.

[0391] Optionally, the computer-readable storage medium can be applied to the first function in the embodiments of this application, and the computer program causes the computer to execute the corresponding process implemented by the first function in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0392] Optionally, the computer-readable storage medium can be applied to the first device in the embodiments of this application, and the computer program causes the computer to execute the corresponding processes implemented by the first device in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0393] Optionally, the computer-readable storage medium can be applied to the first terminal in the embodiments of this application, and the computer program causes the computer to execute the corresponding processes implemented by the first terminal in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0394] In the above embodiments, the implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, in the form of a computer program product.

[0395] A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the flow or function according to the embodiments of this application is generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

[0396] The authentication method, first function, first device, first terminal, computer-readable storage medium, and computer program product of the terminal provided in the embodiments of this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The description of the above embodiments is only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

[0397] It should be understood that the phrases "an embodiment," "an embodiment," "an embodiment of this application," "the foregoing embodiment," "some implementations," or "some embodiments" mentioned throughout the specification mean that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, the phrases "an embodiment," "an embodiment," "an embodiment of this application," "the foregoing embodiment," "some implementations," or "some embodiments" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above-described processes do not imply a sequential order of execution; the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above-described embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0398] Unless otherwise specified, the execution of any step in the embodiments of this application by the first function / first device / first terminal may be performed by the processor of the first function / first device / first terminal. Unless otherwise specified, the embodiments of this application do not limit the order in which the first function / first device / first terminal performs the following steps. In addition, the methods used to process data in different embodiments may be the same or different methods.

[0399] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods, such as: multiple units or components can be combined, or integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the various components shown or discussed can be through some interfaces, and the indirect coupling or communication connection between devices or units can be electrical, mechanical, or other forms.

[0400] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0401] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0402] The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined to obtain new method embodiments without conflict. The features disclosed in the several product embodiments provided in this application can be arbitrarily combined to obtain new product embodiments without conflict. The features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined to obtain new method embodiments or device embodiments without conflict.

[0403] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0404] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to related technologies, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROMs, magnetic disks, or optical disks.

[0405] The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms, unless the context clearly indicates otherwise.

[0406] It should be noted that in the various embodiments involved in this application, all steps or some steps may be performed, as long as a complete technical solution can be formed.

[0407] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A terminal authentication method, characterized in that, Applied to the first function, the method includes: Receive a first message sent by a first device that provides services to a first terminal; wherein the first message includes one or more of the following: a first token; a first characteristic parameter of the first terminal; the first token is generated by the first terminal based on a preset first key and / or random parameters; The first terminal is authenticated based on the first token and / or the first feature parameter.

2. The method according to claim 1, characterized in that, The authentication of the first terminal based on the first token and / or the first feature parameter includes: Obtain a second token; wherein the second token is generated by the first function or the second function based on the second key and / or the random parameters; the second key is preset in the first function or the second function and is the same as the first key; Obtain the second feature parameter of the first terminal; wherein the second feature parameter is preset in the first function or preset in the second function; Compare the first token and the second token; Compare the first feature parameter and the second feature parameter; If the first token and the second token are the same, and / or the first feature parameter and the second feature parameter are the same, then the first terminal authentication is confirmed to be successful.

3. The method according to claim 1, characterized in that, Before receiving the first message sent by the first device providing services to the first terminal, the method further includes: Receive a first request sent by the third function through the fourth function; the first request includes a first identifier of the first terminal, or an area identifier corresponding to the location where the first terminal is stationed. Based on the first identifier or the region identifier, a first device is selected to provide services to the first terminal; Forward the first request to the first device.

4. The method according to claim 3, characterized in that, The forwarding of the first request to the first device includes: Obtain a second key and / or random parameters; wherein the second key is preset by the first function, or the second key is obtained from the second function; A second token is generated based on the second key and / or the random parameters; Forward a first request to the first device; wherein the first request includes the second token, or the first request includes the random parameter and the second token.

5. The method according to claim 4, characterized in that, The forwarding of the first request to the first device includes: Based on the second key or the second token, the first identifier of the first terminal is encrypted to obtain the encrypted identifier; Forward a first request to the first device; wherein the first request further includes the encrypted identifier.

6. The method according to claim 4 or 5, characterized in that, The method further includes: Determine security policy indication parameters; wherein, the security policy indication parameters are used to instruct the first device to perform feature-based authentication on the first terminal; Forward a first request to the first device; wherein the first request further includes the security policy indication parameters.

7. The method according to claim 1, characterized in that, The first function communicates directly with the first device, or the first function communicates with the first device through the fifth function.

8. The method according to claim 1, characterized in that, The first function, the first device, and the second function belong to the first security domain; the fourth function and the fifth function belong to the second security domain; the first security domain and the second security domain are isolated and protected by a security gateway.

9. A terminal authentication method, characterized in that, Applied to a first device, the method includes: Receives a second message sent by the first terminal; the second message includes a first token generated by the first terminal based on a preset first key and / or random parameters; the first device is a device that provides services to the first terminal; Determine the first characteristic parameter of the first terminal; Send a first message to the first function; wherein the first message includes one or more of the following: a first token; a first characteristic parameter of the first terminal.

10. The method according to claim 9, characterized in that, Before receiving the second message sent by the first terminal, the method further includes: The device receives a first request forwarded by the first function; wherein the first request includes one or more of the following: a second token; random parameters; security policy indication parameters; a first identifier of the first terminal; and an encrypted identifier; the second token is generated by the first function or the second function based on a second key and / or random parameters; the encrypted identifier is obtained by the first function encrypting the first identifier based on the second key or the second token; and the security policy indication parameters are used to instruct the first device to perform authentication based on feature parameters on the first terminal. Send a second request to the first terminal; wherein the second request includes one or more of the following: a second token; a random parameter; a first identifier of the first terminal; and an encrypted identifier.

11. The method according to claim 10, characterized in that, Determining the first characteristic parameter of the first terminal includes: If the first request includes a security policy indication parameter, the first feature parameter is determined based on the security policy indication parameter.

12. A terminal authentication method, characterized in that, Applied to a first terminal, the method includes: Send a second message to the first device; wherein the second message includes a first token generated by the first terminal based on a preset first key and / or random parameters; the first device is a device that provides services to the first terminal.

13. The method according to claim 12, characterized in that, Before sending the second message to the first device, the method further includes: The system receives a second request forwarded by the first device; wherein the second request includes one or more of the following: a second token; random parameters; a first identifier of the first terminal; an encrypted identifier; the second token is generated by the first function or the second function based on a second key and / or the random parameters; the encrypted identifier is obtained by the first function encrypting the first identifier based on the second key or the second token; Obtain the first key; A first token is generated based on the first key and / or the random parameters.

14. The method according to claim 13, characterized in that, The method further includes: If the second request includes a second token, compare the first token and the second token; If the first token and the second token are the same, it is determined that the first terminal has successfully authenticated with the network.

15. The method according to claim 13, characterized in that, The method further includes: If the second request includes an encrypted identifier, the encrypted identifier is decrypted based on the first key or the first token; If decryption is successful and the first identifier is obtained, it is determined that the first terminal has successfully authenticated with the network.

16. The method according to claim 13, characterized in that, The method further includes: If the second request is a disk storage request, and the first terminal has successfully authenticated with the network, the identity indication parameter is cached in the storage device of the first terminal; wherein the identity indication parameter indicates that the first terminal has successfully authenticated with the network.

17. The method according to claim 16, characterized in that, The method further includes: If the second request is a command request, and the identity indication parameter exists in the storage device of the first terminal, it is determined that no network authentication is required.

18. A first function, characterized in that, The first function includes: The first receiving module is configured to receive a first message sent by a first device providing services to the first terminal; wherein the first message includes one or more of the following: a first token; a first characteristic parameter of the first terminal; the first token is generated by the first terminal based on a preset first key and / or random parameters; The first processing module is used to authenticate the first terminal based on the first token and / or the first feature parameter.

19. A first device, characterized in that, The first device includes: The second receiving module is used to receive a second message sent by the first terminal; the second message includes a first token generated by the first terminal based on a preset first key and / or random parameters; the first device is a device that provides services to the first terminal; The second processing module is used to determine the first characteristic parameter of the first terminal; The second sending module is used to send a first message to the first function; wherein the first message includes one or more of the following: a first token; a first characteristic parameter of the first terminal.

20. A first terminal, characterized in that, The first terminal includes: The third sending module is used to send a second message to the first device; wherein the second message includes a first token generated by the first terminal based on a preset first key and / or random parameters; the first device is a device that provides services to the first terminal.

21. A first function, characterized in that, The first function includes: a first memory for storing executable instructions; and a first processor for executing the executable instructions stored in the first memory to implement the authentication method of the terminal according to any one of claims 1 to 8.

22. A first device, characterized in that, The first device includes: a second memory for storing executable instructions; and a second processor for implementing the authentication method of the terminal according to any one of claims 9 to 11 when executing the executable instructions stored in the second memory.

23. A first terminal, characterized in that, The first terminal includes: a third memory for storing executable instructions; and a third processor for implementing the authentication method of the terminal according to any one of claims 12 to 17 when executing the executable instructions stored in the third memory.

24. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more programs, which can be executed by one or more processors to implement the authentication method of the terminal according to any one of claims 1 to 8, or the authentication method of the terminal according to any one of claims 9 to 11, or the authentication method of the terminal according to any one of claims 12 to 17.

25. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the authentication method of the terminal according to any one of claims 1 to 8, or the authentication method of the terminal according to any one of claims 9 to 11, or the authentication method of the terminal according to any one of claims 12 to 17.

Images