Authentication method, and device

Abstract

The present application relates to an authentication method, and a device. The method comprises: receiving a command request, which carries first information, wherein the first information is used for an AIoT device to execute authentication.

Description

Certification methods and equipment Technical Field

[0001] This application relates to the field of communications, and more specifically, to an authentication method and apparatus. Background Technology

[0002] The UE authentication process in related technologies is relatively complex, while the computing power of AIoT (Ambient Powered IoT) devices is extremely limited. If the same authentication process as in related technologies is used, the availability of AIoT devices may be poor. Therefore, how to ensure the efficiency of authentication while guaranteeing the security of AIoT devices has become a problem that needs to be solved. Summary of the Invention

[0003] This application provides an authentication method and device.

[0004] This application provides an authentication method performed by an AIoT device, including:

[0005] A command request is received, wherein the command request carries first information, the first information being used by the AIoT device to perform authentication.

[0006] This application provides an authentication method performed by AIoT F, including:

[0007] Send a command request, wherein the command request carries first information, the first information being used by the AIoT device to perform authentication.

[0008] This application provides an AIoT device, including:

[0009] A first communication unit is configured to receive a command request, wherein the command request carries first information, the first information being used by the AIoT device to perform authentication.

[0010] This application provides an AIoT F, including:

[0011] The second communication unit is used to send a command request, wherein the command request carries first information, which is used for the AIoT device to perform authentication.

[0012] This application provides an AIoT device, including a transceiver, a processor, and a memory. The memory stores a computer program, the transceiver communicates with other devices, and the processor calls and runs the computer program stored in the memory to enable the AIoT device to perform the methods described above.

[0013] This application provides an AIoT F, including a transceiver, a processor, and a memory. The memory stores a computer program, the transceiver communicates with other devices, and the processor calls and runs the computer program stored in the memory to cause the AIoT F to perform the methods described above.

[0014] This application provides a chip for implementing the above method.

[0015] Specifically, the chip includes a processor for retrieving and running a computer program from memory, causing a device equipped with the chip to perform the methods described above.

[0016] This application provides a computer-readable storage medium for storing a computer program, which, when run by a device, causes the device to perform the above-described method.

[0017] This application provides a computer program product, including computer program instructions that cause a computer to perform the above-described method.

[0018] By adopting the above scheme, the AIoT device performs authentication through the first information carried in the command request. In this way, authentication related to the AIoT device can be implemented during the command interaction process between the network side and the AIoT device. This ensures the security of the AIoT device executing commands while reducing signaling overhead caused by authentication, thereby improving authentication efficiency.

[0019] Furthermore, the inventory request can include a second piece of information, enabling the AIoT device to determine that the network requires AIoT device authentication. The device then calculates the RES (Realm Assurance) and sends it back to the network side via the inventory response. The network side then triggers the calculation of authentication parameters and sends a command request carrying the first piece of information to the AIoT device, ensuring that the AIoT device determines it needs network authentication. This ensures the security of the commands executed by the AIoT device and the security of the data related to the AIoT device obtained by the network side. Moreover, since the network side only triggers the generation of authentication parameters after confirming successful paging of the AIoT device, it avoids the waste of computational resources caused by calculating authentication parameters before sending the inventory request, thus saving network resources.

[0020] Furthermore, AIoT devices can determine whether two-way or one-way authentication is required based on the content included in the first information, providing a solution for how AIoT devices determine which authentication to perform in command-only or inventory and command processes. Furthermore, authenticating the network through message authentication codes and / or authenticating AIoT devices through RES ensures the security of commands executed by the AIoT device and / or the security of related data of the AIoT device obtained by the network side, and reduces signaling overhead caused by authentication, thereby improving the efficiency of both AIoT device-side authentication of the network and / or network-side authentication of AIoT devices. Attached Figure Description

[0021] Figure 1 is a schematic diagram of an application scenario according to an embodiment of this application.

[0022] Figure 2 is a schematic flowchart of an authentication method according to an embodiment of this application.

[0023] Figure 3 is a schematic flowchart of an authentication method for two-way authentication under inventory and command flow according to an embodiment of this application.

[0024] Figure 4 is a schematic flowchart of another authentication method for two-way authentication under inventory and command flow according to an embodiment of this application.

[0025] Figure 5 is a schematic flowchart of an authentication method for one-way authentication under an inventory and command flow according to an embodiment of this application.

[0026] Figure 6 is a schematic flowchart of another authentication method for one-way authentication under inventory and command flow according to an embodiment of this application.

[0027] Figure 7 is a schematic flowchart of an authentication method for two-way authentication under a command-only flow according to an embodiment of this application.

[0028] Figure 8 is a schematic flowchart of an authentication method for one-way authentication under a command-only flow according to an embodiment of this application.

[0029] Figure 9 is a schematic flowchart of another authentication method under a command-only flow according to an embodiment of this application.

[0030] Figure 10 is a schematic block diagram of an AIoT device according to an embodiment of this application.

[0031] Figure 11 is a schematic block diagram of an AIoT F according to an embodiment of this application.

[0032] Figure 12 is a schematic block diagram of a communication device according to an embodiment of this application.

[0033] Figure 13 is a schematic block diagram of a chip according to an embodiment of this application. Detailed Implementation

[0034] The technical solutions of this application embodiment can be applied to various communication systems, such as NR, NR evolution, WLAN, WiFi, 6G, or other communication systems.

[0035] This application describes various embodiments in conjunction with network devices and terminals. A terminal is a device with data collection capabilities, which can be mobile or fixed, and may also be referred to as a mobile station, user unit, etc. A terminal can be a station in a WLAN, or a smart terminal, wireless modem, laptop, tablet, etc. In this application's embodiments, the terminal can be a VR / AR terminal, industrial control terminal, autonomous driving terminal, telemedicine terminal, smart grid terminal, transportation safety terminal, smart city terminal, or smart home wireless terminal, etc. By way of example and not limitation, in this application's embodiments, the terminal can also be a wearable device.

[0036] In this embodiment, the network device can be a device for communicating with a terminal. The network device can be an access point in a WLAN, an evolved base station in LTE, a relay station, a network device (gNB) in a vehicle-mounted device, wearable device, or NR network, or a network device in a future PLMN network, or a network device in a non-terrestrial network, etc. As an example and not a limitation, in this embodiment, the network device can have mobility characteristics; for example, the network device can be a mobile device.

[0037] In this embodiment, the network device may include at least one of the following: a 6G system architecture 6G Radio Access Network (RAN) and a 6G Core Network Function (CN NF). Under the 6G system architecture, independent distributed NAS termination can be supported between user equipment (UE) and its corresponding 6G network function. That is, each function within a 6G user equipment can directly transmit signals with the appropriate network function (NF) without going through a single termination point. Therefore, the 6G Radio Access Network (RAN) and the 6G Core Network Function (CN NF) can communicate directly with each other.

[0038] 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.

[0039] Figure 1 exemplarily illustrates a communication system 100. The communication system includes network devices 110 and terminals 90. In one possible implementation, the communication system 100 may include multiple network devices 110, and each network device 110 may include at least one terminal 90 within its coverage area; this embodiment does not limit this. In another possible implementation, the communication system 100 may also include other network entities such as mobility management entities and access and mobility management functions; this embodiment does not limit this. The communication system may also include multiple core networks for communicating with access network devices. Access network devices may be base stations of LTE, LTE-A, or NR systems, or 6G radio access networks (RANs). Taking the communication system shown in Figure 1 as an example, the communication devices may include network devices and terminals with communication functions. The communication devices may also include other devices in the communication system, such as network controllers, mobility management entities, and other network entities; this embodiment does not limit this.

[0040] Figure 2 is a schematic flowchart of an authentication method according to an embodiment of this application. In Figure 2, the authentication method is described from the perspective of the interaction between the AIoT device and the AIoT Function (AIoT F). As shown in Figure 2, the authentication method may include the following steps:

[0041] S210 is executed on the AIoT F side to send a command request, wherein the command request carries first information, which is used for the AIoT device to perform authentication.

[0042] S220 is executed on the AIoT device side to receive a command request, wherein the command request carries first information, the first information being used by the AIoT device to perform authentication.

[0043] AIoT F can also be replaced by AIoT NF (Network Function) or AIoT MF (Management Function), etc.

[0044] The first information includes at least one of the following: a command, a message authentication code for authenticating the network, a first freshness value, a second freshness value, a two-way authentication indicator, an authentication network indicator, a command-only service indicator, an inventory and command service indicator, a service association indicator (correlation ID), and indication information indicating that the network side stores the result of the AIoT device authentication network. The command includes at least one of the following: a read command, a write command, an activation command, and a deactivation command.

[0045] Two-way authentication indicator and authentication network indicator are different indicators among authentication type indicators. The authentication network indicator can also be called the AIoT device authentication network indicator.

[0046] In addition to two-way authentication indicators and authentication network indicators, authentication type indicators may also include network authentication AIoT device indicators (or simply authentication AIoT device indicators).

[0047] Different types of authentication type indicators or different representations of indicators can be configured according to actual needs.

[0048] For example, the two-way authentication indicator, the authentication network indicator, and the AIoT device authentication indicator can all have the same length, which is K bits. Different values ​​of K bits represent the two-way authentication indicator, the authentication network indicator, and the AIoT device authentication indicator, respectively. Here, K is an integer greater than or equal to 2.

[0049] Taking Table 1 as an example, K equals 2, and different values ​​of the two bits represent different indicators under the authentication type indicator:

[0050] Table 1

[0051] It should be noted that the above is only an exemplary description of the two-way authentication indicator, the authentication network indicator, and the network authentication AIoT device indicator. In actual processing, the above authentication type indicators can also adopt other representations. As long as both AIoT F and AIoT device can identify or determine the same authentication type through the above different values, it is within the protection scope of this embodiment. Here, no limitation or exhaustive list is made.

[0052] Only the command service indicator, inventory and command service indicator are different indicators among the service type indicators.

[0053] This service type indicator can be used to indicate the type of service, and the AIoT device can determine the authentication type through the service type indicator.

[0054] For example, the command-only service indicator can enable an AIoT device to determine that authentication includes the AIoT device authentication network, or that authentication includes network authentication of the AIoT device; or, for example, the inventory and command service indicator can enable an AIoT device to determine that authentication includes the AIoT device authentication network and network authentication of the AIoT device, i.e., authentication is two-way authentication.

[0055] In addition, the business type indicator may also include other types, such as the inventory-only business indicator. Since this application mainly targets the command-only business or process, as well as the authentication-related processing under the inventory and command business (or process), the following embodiments do not exhaustively list all possible related processing under the business type indicator.

[0056] The representation of the inventory-only service indicator, the inventory and command service indicator, and the command-only service indicator can be configured according to the actual situation.

[0057] For example, the inventory-only indicator, the inventory and command indicator, and the command-only indicator can all have the same length, which is M bits. Different values ​​of the M bits represent the inventory-only service indicator, the inventory and command service indicator, and the command-only service indicator, respectively. Here, M is an integer greater than or equal to 2.

[0058] Taking Table 2 as an example, M equals 2, and different values ​​of the two bits represent different service type indicators:

[0059] Table 2

[0060] It should be noted that the above are merely exemplary descriptions of the inventory-only service indicator, the inventory and command service indicator, and the command-only service indicator. In actual processing, the above service type indicators can also adopt other representation methods. As long as both AIoT F and AIoT device can uniquely identify or determine the same service type through the values ​​of different indicators, it is within the protection scope of this embodiment. No limitation or exhaustive list is made here.

[0061] The service association indicator can be generated by the AIoT F, and this service association indicator corresponds to the service request (or service request, or service operation request) of the AF. This application does not limit the specific way the AIoT F generates the service association indicator corresponding to the service request of the AF. As long as the AIoT F generates different service association indicators for different service types indicated by the service request of the AF, and these indicators can be recognized by the AIoT device, they are within the scope of protection of this embodiment. This service association indicator can also be referred to as a service association indicator; this is not limited or exhaustive.

[0062] The first freshness value and / or the second freshness value are generated on the network side. In this application, the freshness value can be a random number or a count value, which will not be repeated below.

[0063] In some possible implementations, under the inventory and command process, authentication includes the AIoT device authentication network, and authentication includes the network authenticating the AIoT devices.

[0064] The following section, with reference to Figure 3, describes one authentication method for two-way authentication under the inventory and command flow, specifically including:

[0065] Step 301: The Application Function (AF) sends a service request to the AIoT F. This service request can carry service type indicators such as inventory and commands.

[0066] Business requests can also be replaced with AF inventory request messages.

[0067] Preferably, the service type can indicate inventory and command (read). This service type can include information indicating inventory and command, and read commands. That is, the service type indicates the inventory and command process for this read operation, or the process of reading data through inventory and command. This is because the process of reading data from an AIoT device requires, on the one hand, that the AIoT device trusts the network, performs the data reading operation and reports the data when the network is confirmed to be trustworthy; on the other hand, the network needs to trust the AIoT device before the network side will trust the data reported by the AIoT device. Therefore, the two-way authentication method under the inventory and command process provided in this embodiment is particularly suitable for data reading scenarios.

[0068] It should be noted that the above are merely preferred exemplary descriptions and are not intended to limit this embodiment. The two-way authentication method under the inventory and command flow provided in this embodiment can also be used for write operations, activation, or deactivation (including temporary or permanent deactivation) according to actual needs, etc., without limitation or exhaustive enumeration.

[0069] Furthermore, the service request may also carry at least one of the following: the identifier of the AIoT device, group identification information, number of devices, single transmission (or single transmission indication), group transmission (or group transmission indication), etc.

[0070] Among them, the identifier of the AIoT device can be a permanent identifier for the AIoT device.

[0071] Group identification information may include one of the following: a mask, a group identifier prefix, etc.

[0072] The mask can be determined according to the actual situation, and no restrictions are imposed here.

[0073] The group identifier prefix can be the first N bits that are the same in the identifiers of multiple AIoT devices within the group, where N is an integer greater than or equal to 2. In other words, all AIoT devices in the same group can share the same first N bits in their identifiers, and these identical first N bits can be used as the group identifier prefix to identify the group.

[0074] In one embodiment, the service request may carry the service type and the identifier of the AIoT device. The service request may also carry a single-transmission indication, or it may not carry a single-transmission indication; this is not limited here. After receiving the service request, AIoT F can perform step 302 and subsequent processing for that single AIoT device.

[0075] In one embodiment, the service request may carry service type and group identification information. The service request may also carry a mass sending instruction, or it may not carry a mass sending instruction; this is not limited here.

[0076] After receiving a service request, AIoT F can determine the identifier of each AIoT device in the group based on the mapping relationship between the stored group identification information and the identifiers of multiple AIoT devices in the group. In a group scenario, AIoT F can perform step 302 and its subsequent processing for each AIoT device in the group. Since the subsequent processing flow is the same for each AIoT device, the following process will not describe the processing of each AIoT device in the group scenario in detail.

[0077] Step 302, AIoT F sends an inventory request, wherein the inventory request carries second information, the second information being used by the AIoT device to perform network authentication of the AIoT device.

[0078] Specifically, AIoT F sends an inventory request carrying second information to the Reader. The Reader may include an access network device or a terminal (UE), and may also be referred to as a read / write device, etc.

[0079] Furthermore, the inventory request can also include the identifier of the AIoT device.

[0080] Furthermore, AIoT F can also send business type indications, inventory counts, and commands to the Reader. This business type is the same as in the business request and will not be repeated here.

[0081] Optionally, AIoT F can send a first request message to the Reader, which carries a service type (same as in step 301) and an inventory request. For example, the first request message carries a service type and a NAS container, which carries or encapsulates the inventory request.

[0082] Optionally, the business type can be carried in the inventory request, and the inventory request sent by the AIoT F to the reader can be called the first inventory request.

[0083] The second information includes at least one of the following: a second freshness value, a fifth freshness value, a network-certified AIoT device indicator, an inventory and command service indicator, a service association indicator, and a read command.

[0084] This embodiment does not involve a second freshness value. The second information may include at least one of the following: a fifth freshness value, a network authentication AIoT device indicator, an inventory and command service indicator, a service association indicator, and a read command. The fifth freshness value is generated by the AIoT F. The fifth freshness value is used by the AIoT device to calculate RES. This embodiment does not limit the specific method by which the AIoT F generates the fifth freshness value.

[0085] In one embodiment, the second information includes only the fifth freshness value.

[0086] In one embodiment, the second information may include a fifth freshness value; and the second information may further include at least one of the following: a network-authenticated AIoT device indicator, an inventory and command service indicator, a service association indicator, and a read command. The service association indicator corresponds to the inventory and command service.

[0087] Step 303: The Reader sends a paging message, wherein the paging message carries an inventory request.

[0088] Specifically, the Reader sends a paging message carrying an inventory request to the AIoT device. Correspondingly, the processing on the AIoT device side also includes receiving the inventory request, wherein the inventory request carries second information, which is used by the AIoT device to perform network authentication of the AIoT device.

[0089] The inventory request sent by the Reader to the AIoT device can carry secondary information and the identifier of the AIoT device.

[0090] Optionally, AIoT F sends a first request message to the Reader carrying the service type and inventory request. This inventory request can be carried or encapsulated in a NAS container. The inventory request also carries second information and the identifier of the AIoT device. The paging message sent by the Reader to the AIoT device only carries the inventory request. That is, the Reader can save the service type from the first request message locally and send the inventory request (i.e., the NAS container) to the AIoT device in the paging message.

[0091] Optionally, the inventory request sent by AIoT F to the Reader is a first inventory request, which carries second information, the identifier of the AIoT device, and the service type. The Reader can store the service type locally, and the inventory request carried in the paging message sent to the AIoT device includes the second information and the identifier of the AIoT device.

[0092] Step 304: Based on the second information, the AIoT device determines to perform network authentication on the AIoT device.

[0093] In one embodiment, the second information includes only the fifth freshness value.

[0094] An AIoT device can determine whether the network needs to authenticate the AIoT device or the network needs to authenticate the AIoT device if the number of fresh values ​​included in the second information is one.

[0095] In one embodiment, the second information may include a fifth freshness value. Furthermore, the second information may also include at least one of the following: a network-authenticated AIoT device indicator, an inventory and command service indicator, a service association indicator, and a read command. The service association indicator corresponds to the inventory and command service.

[0096] In one example, the AIoT device determines that the network needs to authenticate the AIoT device if the second information includes at least one of the following: a network authentication AIoT device indicator, an inventory and command service indicator, a service association indicator corresponding to the inventory and command service, and a read command.

[0097] Optionally, the AIoT device may determine that the network needs to authenticate the AIoT device if the second information carried in the inventory request includes a read command.

[0098] Optionally, the AIoT device may determine that the network needs to authenticate the AIoT device if the second information includes a network authentication AIoT device indicator.

[0099] Optionally, the AIoT device may determine that the network needs to authenticate the AIoT device if the second information includes any one of the inventory and command service indicators and the service association indicators corresponding to the inventory and command services.

[0100] Optionally, the AIoT device may determine that the network needs to authenticate the AIoT device if the second information includes a network authentication AIoT device indicator, an inventory indicator, and a command service indicator.

[0101] Optionally, the AIoT device may determine that the network needs to authenticate the AIoT device if the second information includes a network-authenticated AIoT device indicator and a service association indicator corresponding to inventory and command services.

[0102] In one example, the AIoT device may further combine the number of fresh values ​​in the second information to jointly determine whether the network needs to authenticate the AIoT device.

[0103] For example, if the second information includes at least one of the following: a network-authenticated AIoT device indicator, an inventory and command service indicator, a service association indicator corresponding to the inventory and command service, and a read command, and the second information includes a fresh value, the AIoT device determines that the network needs to authenticate the AIoT device.

[0104] It should be noted that the above is merely an illustrative example and does not limit or exhaust all possible situations of the content that the second information may include, or all possible ways in which the AIoT device specifically determines that the network needs to authenticate the AIoT device. As long as the AIoT device can determine that the network needs to authenticate the AIoT device based on the content included in the second information, it is within the protection scope of this embodiment.

[0105] Step 305: The AIoT device calculates RES (Response).

[0106] In one embodiment, the AIoT device calculates RES based on a fifth freshness value.

[0107] Optionally, calculating RES based on the fifth freshness value may include: calculating RES based on the root key of the AIoT device, the identifier of the AIoT device, and the fifth freshness value using the first algorithm.

[0108] The first algorithm can be pre-configured on the AIoT device side. For example, the first algorithm includes at least one of the following: KDF (Key Derivation Function), key derivation function, first authentication function (which can be abbreviated as f1 function), second authentication function (which can be abbreviated as f2 function), third key generation function (which can be abbreviated as f3 function), fourth key generation function (which can be abbreviated as f4 function), fifth key generation function (which can be abbreviated as f5 function), hash algorithm, Advanced Encryption Standard (AES), ACSON, SNOW 3G (Snow Third Generation), ZUC (ZUChongzhi), XOR computation, direct connection computation, etc.

[0109] For example, calculating RES can be represented as: RES = function1(K, RAND5, Device ID), where function1() represents the first algorithm, K represents the root key of the AIoT device, RAND5 represents the fifth fresh value carried in the inventory request, and Device ID represents the identifier of the AIoT device.

[0110] Optionally, calculating RES based on the fifth freshness value may include: calculating AK (Anonymity Key) based on the root key of the AIoT device and the fifth freshness value using the second algorithm, and calculating RES based on AK and the identifier of the AIoT device using the third algorithm.

[0111] The calculation of RES based on the third algorithm for the identifiers of AK and AIoT devices can include: directly calculating RES based on the third algorithm for the identifiers of AK and AIoT devices; or, calculating RES based on the third algorithm for the root key of AK, AIoT devices and the identifier of AIoT devices.

[0112] Both the second and third algorithms are pre-configured in the AIoT device. For example, the second algorithm may include any one of the functions f1 to f5; the third algorithm may include at least one of KDF, key derivation function, functions f1 to f5, hash algorithm, AES, ACSON, SNOW 3G, ZUC, XOR calculation, direct connection calculation, etc.

[0113] For example, calculating RES can be represented as: AK = function2(K, RAND5), RES = function3(AK, K, Device ID). Here, function2() represents the second algorithm, and function3() represents the third algorithm; the meanings of the other parameters are the same as in the previous example and will not be repeated.

[0114] In one embodiment, the AIoT device calculates RES based on a fourth freshness value, wherein the fourth freshness value is generated by the AIoT device.

[0115] Optionally, calculating RES based on the fourth freshness value may include: calculating RES based on the root key of the AIoT device, the identifier of the AIoT device, and the fourth freshness value using the first algorithm. For example, calculating RES can be expressed as: RES = function1(K, RAND4, Device ID), where RAND4 represents the fourth freshness value, and the meanings of the other parameters are the same as in the previous example, and will not be repeated.

[0116] Optionally, calculating RES based on the fourth freshness value may include: calculating AK based on the root key of the AIoT device and the fourth freshness value using the second algorithm, and calculating RES based on the AK and the identifier of the AIoT device using the third algorithm.

[0117] The processing of RES for calculating the identifiers of AK and AIoT devices based on the third algorithm is the same as in the aforementioned embodiments and will not be repeated here.

[0118] For example, calculating RES can be represented as: AK = function2(K, RAND4), RES = function3(AK, K, Device ID). The meanings of the parameters are the same as in the previous example and will not be repeated.

[0119] In one embodiment, the RES is calculated based on a fourth freshness value and a fifth freshness value, wherein the fourth freshness value is generated by the AIoT device.

[0120] Optionally, RES is calculated based on the root key of the AIoT device, the identifier of the AIoT device, the fifth freshness value, and the fourth freshness value using the first algorithm. For example, RES can be calculated as: RES = function1(K, RAND5, RAND4, Device ID), where RAND4 represents the fourth freshness value, and the meanings of the other parameters are the same as in the previous example, and will not be repeated.

[0121] Optionally, AK is calculated based on the root key, fifth fresh value, and fourth fresh value of the AIoT device using the second algorithm, and RES is calculated based on AK and the identifier of the AIoT device using the third algorithm. The processing for calculating RES based on AK and the identifier of the AIoT device using the third algorithm is the same as in the aforementioned embodiments and will not be repeated here.

[0122] For example, calculating RES can be represented as: AK = function2(K, RAND5, RAND4), RES = function3(AK, K, Device ID). The meanings of the parameters are the same as in the previous example and will not be repeated.

[0123] Step 306: The AIoT device sends an inventory response, wherein the inventory response carries a RES used to authenticate the AIoT device. Specifically, the AIoT device sends the inventory response to the Reader.

[0124] In one embodiment, in step 305, the AIoT device calculates RES using only the fifth fresh value, and the AIoT device does not generate a third fresh value. The inventory response in step 306 may only carry RES.

[0125] In one embodiment, the AIoT device uses a fourth fresh value when calculating RES in step 305, and the AIoT device does not generate a third fresh value. In addition to carrying RES, the inventory response in step 306 also carries the fourth fresh value.

[0126] In one embodiment, in step 305, the AIoT device calculates RES using only the fifth fresh value, and the AIoT device generates a third fresh value. In this embodiment, the AIoT device's processing further includes sending the third fresh value. Specifically, the inventory response in step 306 may carry both RES and the third fresh value.

[0127] In one embodiment, the AIoT device uses a fourth fresh value when calculating RES in step 305, and the AIoT device generates a third fresh value. Several scenarios are possible:

[0128] In one scenario, the third freshness value and the fourth freshness value are different, and the inventory response can carry RES, the third freshness value, and the fourth freshness value.

[0129] In one scenario, the third and fourth freshness values ​​are the same, and the inventory response can carry RES, the third freshness value, and the fourth freshness value.

[0130] In one scenario, the third and fourth freshness values ​​are the same, and the inventory response can carry only RES and the fourth freshness value.

[0131] Based on the various embodiments of the inventory response above, it should be noted that the network side (including at least ADM, or may include ADM and AIoT F) and the AIoT device need to have corresponding default rules or policies for both parties, or need to determine or clarify whether to transmit the third fresh value, and the specific functions of the third fresh value and / or the fourth fresh value based on the protocol.

[0132] In one example, the AIoT device side can determine, based on default rules or policies or protocol stipulations, that the inventory response should not include a third fresh value if the AIoT device has not generated one. Conversely, the AIoT device side can determine, based on default rules or policies or protocol stipulations, that the inventory response must include a third fresh value if the AIoT device generates one, regardless of whether the third fresh value is the same as a fourth fresh value (or regardless of whether a fourth fresh value is generated). Correspondingly, the network side can determine, based on default rules or policies corresponding to the AIoT device or protocol stipulations, that it should only use the fresh value generated by the network side to calculate the message authentication code if no third fresh value is received. Conversely, the network side can determine, based on default rules or policies corresponding to the AIoT device or protocol stipulations, that it needs to combine the third fresh value with the message authentication code if a third fresh value is received, regardless of whether the third fresh value is the same as a fourth fresh value (or regardless of whether a fourth fresh value is received).

[0133] In one example, the AIoT device can determine, based on default rules or policies, or based on protocol specifications, that if the AIoT device generates both a third and a fourth fresh value, and the fourth and third fresh values ​​are identical, the inventory response will not carry the third fresh value but will carry the fourth fresh value. Correspondingly, the network can determine, based on default rules or policies corresponding to the AIoT device, or based on protocol specifications, that if it does not receive a third fresh value but receives a fourth fresh value, it is determined that the AIoT device has generated a third fresh value, and that the third and fourth fresh values ​​are identical. The network will then use the fourth fresh value as the third fresh value to calculate the message authentication code.

[0134] In some alternative embodiments, the RES is pre-stored by the AIoT device. In this embodiment, the AIoT device does not need to calculate the RES before sending the inventory response. The AIoT device may omit step 305, and the inventory response in step 306 may carry the RES.

[0135] It should be noted that the inventory response may also include other content as specified in the agreement, such as the identification of AIoT devices, which will not be limited or exhaustively listed here.

[0136] Step 307: The Reader sends an inventory response. Specifically, the Reader sends an inventory response to the AIoT F. Correspondingly, the AIoT F receives the inventory response, wherein the inventory response carries a RES used to authenticate the AIoT device. The AIoT F's processing further includes sending the fifth fresh value, wherein the fifth fresh value is used to calculate XRES (Expected Response).

[0137] In one embodiment, the inventory response received by AIoT F includes only RES.

[0138] The authentication vector request carries a fifth fresh value.

[0139] Alternatively, AIoT F's processing may also include sending the RES. That is, the authentication vector request carries the RES and the fifth fresh value.

[0140] In one embodiment, the inventory response received by AIoT F includes RES; and the inventory response also carries a fourth freshness value, wherein the fourth freshness value is used to calculate XRES. The processing of AIoT F further includes step 308: AIoT F sends an authentication vector request to ADM.

[0141] The authentication vector request can carry the fifth fresh value and the fourth fresh value; or, the authentication vector request can carry RES, the fourth fresh value, and the fifth fresh value.

[0142] In one embodiment, the AIoT F process includes: receiving a third fresh value; and sending the third fresh value, wherein the third fresh value is used to calculate a message authentication code. Specifically, the inventory response received by the AIoT F includes RES and the third fresh value.

[0143] The authentication vector request can carry the third fresh value and the fifth fresh value; or, the authentication vector request can carry RES, the third fresh value, and the fifth fresh value.

[0144] In one embodiment, the inventory response received by AIoT F includes RES, a third freshness value, and a fourth freshness value.

[0145] The authentication vector request may carry only the third fresh value, the fourth fresh value, and the fifth fresh value; or, the authentication vector request may carry RES, the third fresh value, the fourth fresh value, and the fifth fresh value.

[0146] Step 309: ADM calculates XRES.

[0147] In one embodiment, the authentication vector request carries only the fifth fresh value and does not carry RES.

[0148] The process of ADM calculating XRES based on the fifth freshness value should be the same as step 305, and will not be repeated. In this embodiment, after ADM completes the calculation of XRES, step 310 can be executed.

[0149] In one embodiment, the authentication vector request carries a fourth fresh value and a fifth fresh value, but does not carry RES. The processing of ADM calculating XRES based on the fourth fresh value, or calculating XRES based on the fourth fresh value and the fifth fresh value, should be the same as step 305 and will not be repeated. In this embodiment, after ADM completes the calculation of XRES, step 310 can be executed.

[0150] In one embodiment, the authentication vector request carries a fifth fresh value, or a fourth fresh value and a fifth fresh value; and the authentication vector request carries RES.

[0151] The specific instructions for calculating XRES using ADM should be the same as those for step 305, and will not be repeated.

[0152] After calculating XRES, ADM's processing may further include: authenticating the AIoT device based on the RES and XRES.

[0153] Specifically, authenticating the AIoT device based on the RES and XRES includes: determining whether the authentication of the AIoT device is successful or passed when the RES and XRES are the same; and / or determining whether the authentication of the AIoT device fails or is not passed when the RES and XRES are different.

[0154] Furthermore, if the ADM successfully or passes the authentication of the AIoT device, it performs step 310.

[0155] In addition, if the ADM fails to authenticate the AIoT device, it shall perform at least one of the following actions: terminate the process, send a notification of the failure to authenticate the AIoT device to AIoT F, etc. Here, we will not limit or exhaust all possible actions after the ADM fails to authenticate the AIoT device.

[0156] Step 310: ADM calculates the message authentication code.

[0157] In one embodiment, the authentication vector request does not carry a third fresh value or a fourth fresh value. In this embodiment, the ADM can determine the message authentication code based on the default rules or policies corresponding to the AIoT device, or based on the protocol specifications. As long as the authentication vector request it receives does not carry a third fresh value (i.e., no third fresh value has been received), the first fresh value is used to calculate the message authentication code. The first fresh value is generated by the ADM, and the specific method by which the ADM generates the first fresh value is not limited.

[0158] Specifically, calculating the message authentication code based on the first freshness value can include: calculating the message authentication code based on the root key of the AIoT device, the identifier of the AIoT device, and the first freshness value using the fourth algorithm.

[0159] The fourth algorithm can be pre-configured, and may include at least one of the following: KDF, key derivation function, f1 to f5 functions, hash algorithm, AES, ACSON, SNOW 3G, ZUC, XOR calculation, direct connection calculation, etc.

[0160] Whether the fourth algorithm is the same as or different from the first algorithm, it is within the protection scope of this embodiment.

[0161] The root key of an AIoT device can be pre-stored in the ADM. This embodiment does not limit the specific method by which the ADM obtains the root key of the AIoT device or the specific method of storing it.

[0162] For example, the ADM can be represented as: function4(K, RAND1, Device ID), where function4() represents the fourth algorithm, K represents the root key of the AIoT device, RAND1 represents the first fresh value, and Device ID represents the identifier of the AIoT device.

[0163] In one embodiment, the authentication vector request carries a third fresh value. In this embodiment, the ADM can be determined based on the default rules or policies corresponding to the AIoT device, or based on the protocol specifications. As long as the authentication vector request carries a third fresh value, regardless of whether the third fresh value is the same as the fourth fresh value (or regardless of whether the authentication vector request includes the fourth fresh value), the message authentication code needs to be calculated in combination with the third fresh value.

[0164] Specifically, ADM calculates the message authentication code based on the first freshness value and the third freshness value.

[0165] Calculating the message authentication code based on the first freshness value and the third freshness value can include: calculating the message authentication code based on the root key of the AIoT device, the identifier of the AIoT device, the first freshness value, and the third freshness value using a fourth algorithm. For example, the message authentication code calculated by ADM based on the root key of the AIoT device, the identifier of the AIoT device, the first freshness value, and the third freshness value using the fourth algorithm can be represented as: function4(K, RAND1, RAND3, Device ID), where function4() represents the fourth algorithm, K represents the root key of the AIoT device, RAND1 represents the first freshness value, RAND3 represents the third freshness value, and Device ID represents the identifier of the AIoT device.

[0166] In one embodiment, the authentication vector request carries a fourth fresh value but not a third fresh value.

[0167] For example, on the ADM side, it can determine the message authentication code based on the default rules or policies corresponding to the AIoT device, or based on the protocol specifications, as long as the authentication vector request it receives does not carry a third fresh value (i.e., no third fresh value has been received). In this example, the relevant explanation of ADM calculating the message authentication code based on the first fresh value is the same as in the previous example and will not be repeated.

[0168] For example, the ADM side determines, based on the default rules or policies corresponding to the AIoT device, or based on the protocol provisions, that as long as the authentication vector request it receives does not carry a third fresh value but carries a fourth fresh value (i.e., it has not received a third fresh value but has received a fourth fresh value), the ADM will use the fourth fresh value as the third fresh value to calculate the message authentication code.

[0169] In this example, the ADM side calculates the message authentication code based on a first freshness value and a third freshness value, where the third freshness value equals the fourth freshness value. The specific method for calculating the message authentication code based on the first and third freshness values ​​is the same as in the previous embodiments, and therefore will not be repeated.

[0170] Step 311: ADM sends an authentication vector response to AIoT F.

[0171] In one embodiment, the authentication vector request does not carry RES. The authentication vector response carries a message authentication code, a first freshness value, XRES, and the identifier of the AIoT device; wherein, the message authentication code, the first freshness value, and XRES can be used as authentication parameters in the authentication vector response.

[0172] In other words, the processing of AIoT F after completing step 308 (sending the authentication vector request) further includes: receiving the message authentication code and the first fresh value. Furthermore, the processing of AIoT F after sending the authentication vector request also includes: receiving the XRES.

[0173] After receiving the XRES, AIoT F can execute step 312 to authenticate the AIoT device based on the RES and XRES. The explanation of authenticating the AIoT device based on the RES and XRES is the same as in the previous embodiments and will not be repeated.

[0174] If the AIoT F certification of the AIoT device is successful or passes, step 313 can be further performed.

[0175] In addition, if AIoT F fails to authenticate the AIoT device, the relevant processing of AIoT F may include at least one of the following: ending the process, sending a notification of AIoT device authentication failure to AF, or sending a notification of authentication failure to AIoT device.

[0176] In one embodiment, the authentication vector request carries RES. Correspondingly, the authentication vector response carries a message authentication code and a first freshness value; wherein the message authentication code and the first freshness value can be used as authentication parameters in the authentication vector response.

[0177] In other words, the processing of AIoT F after completing step 308 of sending the authentication vector request also includes: receiving the message authentication code and the first freshness value.

[0178] In this embodiment, AIoT F can determine whether the ADM-side authentication of the AIoT device is successful or passed upon receiving the authentication vector response, and AIoT F can directly execute step 313. Alternatively, the authentication vector response can also carry the authentication result of whether the AIoT device authentication is successful or passed. Accordingly, AIoT F can determine whether the ADM-side authentication of the AIoT device is successful or passed based on the authentication result upon receiving the authentication vector response, and AIoT F can directly execute step 313.

[0179] If AIoT F does not receive an authentication vector response, or receives an authentication result indicating that the AIoT device authentication has failed, it determines that the AIoT device authentication has failed and then performs at least one of the following actions: ending the process, sending a notification of AIoT device authentication failure to AF, or sending a notification of authentication failure to the AIoT device. This does not limit or exhaust all possible actions taken by AIoT F after determining that the AIoT device authentication has failed.

[0180] In some alternative embodiments, the RES is pre-stored by the AIoT device. The inventory response in step 306 may carry the RES. In this case, after receiving the inventory response, AIoT F can obtain XRES from the locally stored authentication vector and directly authenticate the AIoT device based on XRES and RES. If the authentication is successful, it sends an authentication vector request to ADM (which may not carry the RES), receives the authentication vector response from ADM (including the message authentication code and the first freshness value), and then executes step 313. Alternatively, AIoT F may include the RES in the authentication vector request and send it to ADM, where ADM still authenticates the AIoT device. Then, AIoT F receives the authentication vector response from ADM (including the message authentication code and the first freshness value), and then AIoT F can determine that the AIoT device authentication is successful and execute step 313. This is not limited or exhaustive.

[0181] Step 313: AIoT F sends a command request, wherein the command request carries first information, which is used by the AIoT device to perform authentication. Specifically, AIoT F sends the command request to the Reader.

[0182] In one embodiment, the first information includes only: a command, a message authentication code, and a first freshness value. Preferably, in this embodiment, the command request carries a read command.

[0183] In one embodiment, the first information includes: a command, a message authentication code, and a first freshness value; and the first information further includes at least one of the following: a two-way authentication indicator, an authentication network indicator, an inventory and command service indicator, and a service association indicator. The service association indicator corresponds to the inventory and command service.

[0184] It should be noted that the command request may also carry other content as specified in the relevant protocol, such as the identifier of the AIoT device, which will not be limited or exhaustively listed here.

[0185] Step 314: The Reader sends a command request. Specifically, the Reader sends a command request to the AIoT device.

[0186] Step 315: The AIoT device determines to perform authentication based on the first information. Specifically, the AIoT device determines to perform two-way authentication based on the first information; or, the AIoT device determines to perform AIoT device authentication network based on the first information.

[0187] Here, whether the AIoT device determines that it needs to perform two-way authentication or determines that it needs to authenticate the network, the AIoT device can then perform the authentication network's processing to ultimately complete the two-way authentication.

[0188] Specifically, since the AIoT device sent RES through the inventory response in step 306, if the AIoT device receives the command request, the AIoT device can determine that the network authentication of the AIoT device has been successful or passed. Therefore, the AIoT device determines to perform two-way authentication in step 315, which means that the AIoT device needs to further perform the authentication network processing to complete the two-way authentication.

[0189] Similarly, since the AIoT device sent RES through the inventory response in step 306, if the AIoT device receives the command request, the AIoT device can determine that the network authentication of the AIoT device has been successful or passed. Therefore, the AIoT device determines in step 315 that the AIoT device needs to authenticate the network, which means that the AIoT device needs to perform the authentication network processing to finally complete the two-way authentication.

[0190] In one embodiment, the first information includes only: command, message authentication code, and first freshness value.

[0191] The processing of AIoT devices can include one of the following:

[0192] If the first information includes a command, determine whether to perform two-way authentication or to perform AIoT device authentication network;

[0193] If the first information includes a command and a message authentication code, determine whether to perform two-way authentication or AIoT device authentication network.

[0194] If the first information includes a command, a message authentication code, and a fresh value, determine whether to perform two-way authentication or AIoT device authentication network.

[0195] If the first information includes a message authentication code, it is determined whether two-way authentication or AIoT device authentication network is required.

[0196] If the first piece of information includes a message authentication code and a fresh value, it is determined whether two-way authentication or AIoT device authentication network is required.

[0197] In this embodiment, the preferred command is a read command. Therefore, the AIoT device needs to trust the network, and the network also needs to trust the AIoT device. If the first information includes a read command, the AIoT device can determine whether to perform two-way authentication or AIoT device authentication with the network. This is only a preferred example. In actual processing, the read command can also be replaced by an activation command, a deactivation command, or a write command. This is not a limitation or an exhaustive list.

[0198] In one embodiment, the first information includes: a command, a message authentication code, and a first freshness value; and the first information further includes at least one of the following: a two-way authentication indicator, an authentication network indicator, an inventory and command service indicator, and a service association indicator. The service association indicator corresponds to the inventory and command service.

[0199] In one example, the AIoT device may determine whether to perform two-way authentication or to authenticate the network if the first information includes at least one of the following: a command, a two-way authentication indicator, an authentication network indicator, an inventory and command service indicator, and a service association indicator corresponding to the inventory and command service.

[0200] Preferably, the AIoT device can determine the network that needs to be authenticated if the first information includes a command and an authentication network indicator.

[0201] Optionally, the AIoT device may determine that two-way authentication needs to be performed if the first information includes a command and a two-way authentication indicator.

[0202] Optionally, the AIoT device may determine whether two-way authentication or network authentication is required if the first information includes commands, inventory and command service indicators or service association indicators corresponding to inventory and command services.

[0203] Optionally, the AIoT device may determine whether two-way authentication or AIoT device authentication network is required if the first information includes at least one of a command, an authentication network indicator, an inventory and command service indicator, and a service association indicator corresponding to the inventory and command service.

[0204] Optionally, the AIoT device may determine whether to perform two-way authentication or to authenticate the network if the first information includes at least one of a command, a two-way authentication indicator, an inventory and command service indicator, and a service association indicator corresponding to the inventory and command service.

[0205] Optionally, the AIoT device may determine the network that needs to be authenticated if the first information includes an authentication network indicator.

[0206] Optionally, the AIoT device may determine that two-way authentication needs to be performed if the first information includes a two-way authentication indicator.

[0207] In one example, the AIoT device can also combine the number of fresh values ​​in the first information and / or the message authentication code to determine whether two-way authentication is required or whether the AIoT device needs to authenticate the network.

[0208] For example, if the first information includes at least one of a two-way authentication indicator, an authentication network indicator, an inventory and command service indicator, and a service association indicator corresponding to the inventory and command service, and the first information includes a command and a message authentication code, the AIoT device may determine whether two-way authentication or AIoT device authentication network is required.

[0209] For example, an AIoT device may determine whether to perform two-way authentication or to authenticate the network if the first information includes at least one of a two-way authentication indicator, an authentication network indicator, an inventory and command service indicator, and a service association indicator corresponding to the inventory and command service, and the first information includes a command, a message authentication code, and a fresh value.

[0210] It should be noted that the above is merely an illustrative example and does not limit or exhaust all possible situations of the content that the first information may include, or all possible ways in which the AIoT device specifically determines that it needs to perform two-way authentication or needs to authenticate the network. As long as the AIoT device can determine that it needs to perform two-way authentication or needs to authenticate the network based on the content included in the first information, it is within the protection scope of this embodiment.

[0211] In this way, AIoT devices can determine whether two-way authentication is required based on at least one of the message authentication code, various indicators, and one or more fresh values ​​in the first information. This allows for a more flexible approach to enabling AIoT devices to determine authentication procedures. This method provides a solution for how AIoT devices determine the specific type of authentication to perform during inventory and command processes.

[0212] Step 316: The AIoT device authenticates the network based on the message verification code and message authentication code.

[0213] In this step, the AIoT device first calculates the message verification code. Specifically, the AIoT device can calculate the message verification code based on a first freshness value. Alternatively, the AIoT device can calculate the message verification code based on the first freshness value and a third freshness value, wherein the third freshness value is generated by the AIoT device. The AIoT device can perform the process of calculating the message verification code based on the first freshness value and the third freshness value if it has generated and sent the third freshness value; otherwise, the AIoT device calculates the message verification code based on the first freshness value.

[0214] The specific method by which AIoT devices calculate message verification codes should be the same as the method used by ADM to calculate message authentication codes in step 310, therefore it will not be repeated. The fourth algorithm pre-configured on the AIoT device and the network side (such as ADM) should be the same, and will not be elaborated further.

[0215] The authentication network based on the message verification code and the message authentication code may include: determining that the authentication network is successful or passes when the message verification code and the message authentication code are the same; and / or determining that the authentication network fails or fails when the message verification code and the message authentication code are different.

[0216] It should be noted that the message authentication code included in the first information is used for AIoT devices to perform authentication, at least referring to AIoT devices authenticating the network based on the message authentication code. Optionally, the AIoT device can combine the message authentication code (or combine the message authentication code with other content included in the first information) to determine whether authentication (authentication network or two-way authentication) is required; alternatively, the AIoT device can determine whether authentication (authentication network or two-way authentication) is required based solely on other content included in the first information without combining the message authentication code.

[0217] If the AIoT device authentication network is successful, step 317 can be performed.

[0218] In the event of an AIoT device authentication network failure, subsequent steps (process termination) and / or sending a message indicating the authentication network failure may not be performed. This message can be sent to the AIoT F via a Reader. Accordingly, upon receiving the message indicating the authentication network failure, the AIoT F can perform at least one of the following: send a notification of the AIoT device authentication network failure to the AF; or terminate the process. This document does not limit or exhaustively list all possible actions that the AIoT device and AIoT F may perform when the AIoT device authentication network fails.

[0219] Step 317: The AIoT device sends a command response.

[0220] In a preferred embodiment, in step 301, the service type in the service request sent by the AF indicates inventory and command (read). In step 313, the command request issued by the AIoT AF carries a read command, and in step 314, the command request sent by the Reader to the AIoT device carries a read command.

[0221] Accordingly, if the AIoT device successfully authenticates with the network, the AIoT device reads data based on a read command and then executes...

[0222] Step 317: The AIoT device sends a command response to the Reader, which carries data.

[0223] Step 318: The Reader sends data to the AIoT F. Specifically, the Reader can send a command response (carrying data) to the AIoT F. Correspondingly, the AIoT F receives the command response, which carries data.

[0224] In this embodiment, the command response can also indicate that the AIoT device has successfully authenticated with the network. It should be noted that the command response can be used to indicate successful AIoT device authentication with the network, but this does not limit whether the command response carries information indicating successful AIoT device authentication with the network. Rather, it indicates that by sending the command response, the network side (such as AIoTF) can determine or confirm that the AIoT device has successfully authenticated with the network. In other words, as long as the AIoT device performs the action or process of sending a command response, it can indicate that the AIoT device has successfully authenticated with the network. Correspondingly, the network side (such as AIoTF) can determine that the AIoT device has successfully authenticated with the network as long as it receives the command request. This embodiment does not limit whether the command response needs to carry additional information indicating successful AIoT device authentication with the network.

[0225] Step 319, AIoT F sends the data to AF.

[0226] In one possible embodiment, in step 301, the service type in the service request sent by the AF indicates inventory and command (write). In step 313, the command request issued by the AIoT AF carries a write command, and in step 314, the command request sent by the Reader to the AIoT device carries a write command.

[0227] Accordingly, if the AIoT device successfully authenticates the network, the AIoT device writes data based on the write command, and then executes step 317, in which the AIoT device sends a command response (without carrying data) to the Reader.

[0228] Step 318: The Reader sends a command response (without data) to the AIoT F. After receiving the command response, the AIoT F can terminate the process. This command response can also indicate that the AIoT device has successfully authenticated the network, which will not be repeated here.

[0229] In this embodiment, in step 301, the service type in the service request sent by the AF can be replaced with an instruction to inventory and a command (deactivate (temporary deactivate or permanent deactivate)) or an instruction to inventory and a command (activate). Accordingly, the command requests in steps 313 and 314 carry a deactivation command (temporary deactivation command or permanent deactivation command) or an activation command.

[0230] Accordingly, after the AIoT device has successfully authenticated the network, it can execute an activation command and then execute step 317, in which the AIoT device sends a command response to the Reader; or, after the AIoT device has successfully authenticated the network, it executes step 317, in which the AIoT device sends a command response to the Reader, and then executes a deactivation operation based on the deactivation command (temporary deactivation command or permanent deactivation command). This operation may temporarily disable the radio frequency function or capability (which can be re-enabled by the activation command later) or permanently disable the radio frequency function or capability (which cannot be re-activated or enabled later).

[0231] Here, we do not limit or exhaustively list all possible processing methods for AIoT devices and AIoT F under all possible command types.

[0232] By employing the authentication method provided in the above embodiments, the inventory request can carry second information to enable the AIoT device to determine that the network needs to authenticate the AIoT device. Then, the RES is calculated and fed back to the network side via the inventory response. The network side then triggers the calculation of the authentication vector or authentication parameters (message authentication code and / or XRES), and sends a command request carrying the first information to the AIoT device to enable the AIoT device to determine that the AIoT device needs to authenticate the network. After successful network authentication, the AIoT device then sends back a command response. In this way, two-way authentication can be achieved in the inventory and command processes, providing a solution for how the AIoT device determines to perform two-way authentication in the inventory and command processes. Furthermore, since the network side only triggers the generation of the message authentication code and / or XRES after confirming successful paging of the AIoT device, it avoids the waste of computing resources caused by calculating the message authentication code and / or XRES before sending the inventory request, which results in the failure of paging the AIoT device, thus saving network side resources.

[0233] In some other possible implementations, referring to Figure 4, another authentication method for two-way authentication under the inventory and command flow is described, specifically including:

[0234] Step 401 is the same as step 301, and will not be described again.

[0235] After receiving the service request, AIoT F checks whether the authentication parameters are stored locally. If no authentication parameters are stored, it proceeds to step 402; if the authentication parameters are stored, it proceeds to step 406.

[0236] In one embodiment, the service request may carry the service type and the identifier of the AIoT device. The service request may also carry a single-transmission instruction, or it may not carry a single-transmission instruction; this is not limited here.

[0237] After receiving a service request, AIoT F can first check whether the authentication parameters (or authentication status) of the AIoT device are stored locally. If the authentication parameters of the AIoT device are not stored, step 402 is executed to request the authentication parameters of the AIoT device; if the authentication parameters (or authentication status) of the AIoT device are stored, step 406 is executed directly.

[0238] The "checking whether the authentication parameters (or authentication status) of the AIoT device are stored locally" means that AIoT F checks whether the authentication parameters or authentication status of the AIoT device are stored locally based on the AIoT device's identifier.

[0239] If AIoT F locally stores the authentication parameters (or authentication status) of the AIoT device, these parameters may include: message authentication code, XRES, first freshness value, and second freshness value.

[0240] In one embodiment, the service request may carry service type and group identification information. The service request may also carry a mass sending instruction, or it may not carry a mass sending instruction; this is not limited here.

[0241] In this embodiment, after receiving a service request, AIoT F can determine the identifier of each AIoT device among the multiple AIoT devices included in the group based on the mapping relationship between the saved group identification information and the identifiers of multiple AIoT devices in the group.

[0242] In a group scenario, AIoT F can check locally for each AIoT device in the group whether the authentication parameters (or authentication status) of that AIoT device are already stored. If the authentication parameters of the AIoT device are not stored, step 402 is executed to request the authentication parameters of the AIoT device; if the authentication parameters (or authentication status) of the AIoT device are already stored, step 406 is executed directly. Since the subsequent processing flow is the same for each AIoT device in a group scenario, the following process will not describe the processing of each AIoT device in a group scenario in detail.

[0243] Step 402: AIoT F sends an authentication vector request. Specifically, AIoT F sends an authentication vector request to ADM to request authentication parameters, and the authentication vector request may carry the identifier of the AIoT device.

[0244] Step 403: ADM generates a first fresh value and calculates the message authentication code based on the first fresh value.

[0245] The method by which the ADM generates the first fresh value is not limited. The processing method of the ADM side to calculate the message authentication code based on the first fresh value is the same as the processing method of calculating the message authentication code based on the first fresh value in step 310 of the aforementioned embodiment, and will not be described again.

[0246] Step 404: ADM generates a second fresh value, and XRES is calculated based on the second fresh value. The method by which ADM generates the second fresh value is not limited. This second fresh value may be the same as or different from the first fresh value.

[0247] In one embodiment, calculating XRES based on the second freshness value may include: calculating XRES based on the root key of the AIoT device, the identifier of the AIoT device, and the second freshness value using the first algorithm. The fourth algorithm may be the same as or different from the first algorithm.

[0248] In one scenario, the first fresh value and the second fresh value are the same. The fourth algorithm should be different from the first algorithm. For example, the first algorithm could be the f1 function or AES, while the fourth algorithm could be the f2 function, etc. This is not a limitation or an exhaustive list.

[0249] In one scenario, the first freshness value differs from the second freshness value. The fourth algorithm may be the same as or different from the first algorithm; this is not limited or exhaustive.

[0250] For example, the ADM calculation of XRES can be represented as: XRES = function1(K, RAND2, Device ID), where function1() represents the first algorithm, RAND2 represents the second fresh value, and the meanings of the other parameters are the same as in the previous example, and will not be repeated.

[0251] In one embodiment, on the ADM side, calculating XRES based on the second freshness value may include: calculating AK based on the root key of the AIoT device and the second freshness value using a second algorithm, and calculating XRES based on AK and the identifier of the AIoT device using a third algorithm.

[0252] Specifically, calculating XRES based on the third algorithm for the identifiers of AK and AIoT devices can include: directly calculating XRES based on the third algorithm for the identifiers of AK and AIoT devices; or calculating XRES based on the third algorithm for the root key of AK, AIoT devices and the identifier of AIoT devices.

[0253] In one scenario, the first fresh value and the second fresh value are the same. For example, the ADM calculation of XRES can be represented as: AK = function2(K, RAND1), XRES = function3(AK, K, Device ID). Here, function3() represents the third algorithm; RAND1 is the first fresh value, meaning the first and second fresh values ​​are the same, and this example uses the first fresh value; the meanings of the remaining parameters are the same as in the previous example and will not be repeated.

[0254] In one scenario, the first freshness value differs from the second freshness value. For example, the ADM calculation of XRES can be represented as: AK = function2(K, RAND2), XRES = function3(AK, K, Device ID). The meanings of the parameters are the same as in the previous example and will not be repeated.

[0255] The execution order of steps 403 and 404 is not important. For example, ADM can execute step 403 first and then step 404, or it can execute step 404 first and then step 403. This embodiment does not limit this.

[0256] Step 405: ADM returns authentication parameters to AIoT F. Specifically, ADM sends an authentication vector response to AIoT F, which carries the authentication parameters.

[0257] Accordingly, the AIoT F processing includes receiving at least one of the following: a message authentication code, a first freshness value, and a second freshness value.

[0258] Optionally, the authentication parameters include a message authentication code, a first freshness value, and a second freshness value; that is, the ADM may not return XRES to the AIoT F. Correspondingly, the AIoT F receives the authentication parameters carried in the authentication vector response, including the message authentication code, the first freshness value, and the second freshness value.

[0259] Optionally, the AIoT F processing also includes receiving XRES. Specifically, the authentication parameters include a message authentication code, XRES, a first freshness value, and a second freshness value. Accordingly, after receiving the message authentication code, XRES, first freshness value, and second freshness value included in the authentication parameters of the authentication vector response, the AIoT F can save the XRES locally.

[0260] Step 406: AIoT F sends an inventory request, wherein the inventory request carries second information, which is used by the AIoT device to perform network authentication of the AIoT device. Specifically, AIoT F sends an inventory request carrying the second information to the Reader.

[0261] Furthermore, the inventory request can also include the identifier of the AIoT device.

[0262] Furthermore, AIoT F can also send business type indications, inventory counts, and commands to the Reader. This business type is the same as in the business request and will not be repeated here.

[0263] Optionally, AIoT F can send a first request message to the Reader, which carries the service type and inventory request. For example, the first request message may include the service type and the NAS container, which carries or encapsulates the inventory request.

[0264] Optionally, the business type can be carried in the inventory request, and the inventory request sent by the AIoT F to the reader can be called the first inventory request.

[0265] The second information includes at least one of the following: a second freshness value, a network-certified AIoT device indicator, an inventory and command service indicator, a service association indicator, and a read command.

[0266] In one embodiment, the second information includes only the second freshness value.

[0267] In one embodiment, the second information may include a second freshness value; and the second information may further include at least one of the following: a network-authenticated AIoT device indicator, an inventory and command service indicator, a service association indicator, and a read command. The service association indicator corresponds to the inventory and command service.

[0268] Step 407: The Reader sends a paging message, which carries an inventory request. Specifically, the Reader sends a paging message carrying an inventory request to the AIoT device.

[0269] The inventory request sent by the Reader to the AIoT device can carry secondary information and the identifier of the AIoT device.

[0270] Optionally, AIoT F sends a first request message to the Reader carrying the service type and inventory request. This inventory request can be carried or encapsulated in a NAS container. The inventory request also carries second information and the identifier of the AIoT device. The paging message sent by the Reader to the AIoT device only carries the inventory request. That is, the Reader can store the service type from the first request message locally and send the inventory request (i.e., the NAS container) from the first request message to the AIoT device in the paging message.

[0271] Optionally, AIoT F sends a first inventory request to the Reader, which carries second information, the identifier of the AIoT device, and the service type. The Reader can store the service type locally, and the inventory request carried in the paging message sent to the AIoT device only includes the second information and the identifier of the AIoT device.

[0272] Step 408: Based on the second information, the AIoT device determines to perform network authentication on the AIoT device.

[0273] In one embodiment, the second information includes only the second freshness value.

[0274] An AIoT device can determine whether the network needs to authenticate the AIoT device or the network needs to authenticate the AIoT device if the number of fresh values ​​included in the second information is one.

[0275] In one embodiment, the second information may include a second freshness value. Furthermore, the second information may also include at least one of the following: a network-authenticated AIoT device indicator, an inventory and command service indicator, a service association indicator corresponding to the inventory and command service, and a read command.

[0276] In one example, the AIoT device determines that the network needs to authenticate the AIoT device if the second information includes at least one of the following: a network authentication AIoT device indicator, an inventory and command service indicator, a service association indicator corresponding to the inventory and command service, and a read command.

[0277] Preferably, the AIoT device can determine that the network needs to authenticate the AIoT device if the second information includes a read command.

[0278] Preferably, the AIoT device can determine that the network needs to authenticate the AIoT device if the second information includes a network authentication AIoT device indicator.

[0279] Optionally, the AIoT device may determine that the network needs to authenticate the AIoT device if the second information includes any one of the inventory and command service indicators and the service association indicators corresponding to the inventory and command services.

[0280] Optionally, the AIoT device may determine that the network needs to authenticate the AIoT device if the second information includes a network authentication AIoT device indicator and the second information includes at least one of an inventory and command service indicator, a service association indicator corresponding to the inventory and command service, and a read command.

[0281] In one example, the AIoT device can also combine the number of fresh values ​​in the second information to determine whether the network needs to authenticate the AIoT device.

[0282] For example, if the second information includes at least one of the following: a network-authenticated AIoT device indicator, an inventory and command service indicator, a service association indicator corresponding to the inventory and command service, and a read command, and the second information includes a fresh value, the AIoT device determines that the network needs to authenticate the AIoT device.

[0283] It should be noted that the above is merely an illustrative example and does not limit or exhaust all possible situations of the content that the second information may include, or all possible ways in which the AIoT device specifically determines that the network needs to authenticate the AIoT device. As long as the AIoT device can determine that the network needs to authenticate the AIoT device based on the content included in the second information, it is within the protection scope of this embodiment.

[0284] Step 409, the AIoT device calculates the RES (Response).

[0285] In one embodiment, the AIoT device calculates RES based on a second freshness value. In this embodiment, the process of the AIoT device calculating RES based on the second freshness value should be the same as the method of ADM calculating XRES based on the second freshness value in step 404, and will not be described again.

[0286] In one embodiment, the AIoT device calculates RES based on a fourth freshness value, wherein the fourth freshness value is generated by the AIoT device.

[0287] This embodiment does not limit the way in which the AIoT device generates the fourth fresh value. As long as the fourth fresh value is different from the first fresh value and different from the second fresh value, it is within the protection scope of this embodiment.

[0288] The specific process for calculating RES based on the fourth freshness value is the same as the specific process for calculating RES based on the fourth freshness value in step 305 of Figure 3 above, and will not be described again.

[0289] In one embodiment, the AIoT device calculates RES based on a second freshness value and a fourth freshness value.

[0290] Calculating RES based on the second and fourth freshness values ​​can include: calculating RES using the root key of the AIoT device, the identifier of the AIoT device, the second freshness value, and the fourth freshness value based on the first algorithm. For example, calculating RES can be represented as: RES = function1(K, RAND2, RAND4, Device ID), where RAND2 represents the second freshness value, RAND4 represents the fourth freshness value, and the meanings of the other parameters are the same as in the previous example, and will not be repeated.

[0291] Alternatively, calculating RES based on the second and fourth fresh values ​​may include: calculating AK based on the root key of the AIoT device, the second and fourth fresh values ​​using the second algorithm, and calculating RES based on the AK and the identifier of the AIoT device using the third algorithm.

[0292] The calculation of RES based on the third algorithm for the identifiers of AK and AIoT devices is the same as in step 305 above, and will not be repeated here.

[0293] For example, calculating RES can be represented as: AK = function2(K, RAND2, RAND4), RES = function3(AK, K, Device ID). The meanings of the parameters are the same as in the previous example and will not be repeated.

[0294] Step 410: The AIoT device sends an inventory response, wherein the inventory response carries a RES used to authenticate the AIoT device. Specifically, the AIoT device sends the inventory response to the Reader.

[0295] Optionally, if the AIoT device uses only the second freshness value when calculating RES in step 409, then RES can be carried in the inventory response.

[0296] Optionally, if the AIoT device uses its own generated fourth fresh value when calculating RES in step 409, the inventory response carries the fourth fresh value in addition to RES, wherein the fourth fresh value is used to calculate XRES.

[0297] It should be noted that the inventory response may also include other content as specified in the agreement, such as the identification of AIoT devices, which will not be limited or exhaustively listed here.

[0298] Step 411: The Reader sends an inventory response. Specifically, the Reader sends an inventory response to the AIoT F. Correspondingly, the AIoT F receives the inventory response, wherein the inventory response carries RES for authenticating the AIoT device.

[0299] Upon receiving the inventory response, AIoT F determines that the AIoT device paging was successful and can then execute one of the following implementation methods:

[0300] In one embodiment, in step 405, the authentication parameters carried in the authentication vector response returned by ADM to AIoT F include XRES; and the inventory response received by AIoT F does not carry a fourth freshness value.

[0301] In this embodiment, AIoT F performs step 412, authenticating the AIoT device based on the RES and XRES. The specific processing of step 412 is the same as step 312 in the previous embodiment, and will not be described again.

[0302] In one embodiment, in step 405, the authentication parameters carried in the authentication vector response returned by ADM to AIoT F do not include XRES; and the inventory response received by AIoT F does not carry a fourth freshness value.

[0303] The processing performed by AIoT F also includes sending the RES. Specifically, AIoT F sends the RES and the identifier of the AIoT device to ADM, and receives the authentication result of the AIoT device from ADM, wherein the authentication result includes: successful authentication of the AIoT device or failure to authenticate the AIoT device.

[0304] The ADM's processing may include: receiving the RES and the identifier of the AIoT device from the AIoT F; authenticating the AIoT device based on the RES and XRES; and sending the authentication result of the AIoT device to the AIoT F. The specific processing of authenticating the AIoT device based on the RES and XRES is the same as in the previous embodiments and will not be described again.

[0305] In one embodiment, the inventory response received by AIoT F carries a fourth freshness value. The processing performed by AIoT F further includes sending the RES. Furthermore, the processing by AIoT F further includes sending the fourth freshness value, wherein the fourth freshness value is used to calculate XRES.

[0306] Specifically, AIoT F sends RES, the fourth freshness value, and the identifier of the AIoT device to ADM, and receives the authentication result of the AIoT device from ADM.

[0307] The ADM's processing may include: receiving the RES, the fourth freshness value, and the identifier of the AIoT device from the AIoT F; calculating the XRES; authenticating the AIoT device based on the RES and XRES; and sending the authentication result of the AIoT device to the AIoT F.

[0308] The calculation of XRES on the ADM side can include: calculating XRES based on a fourth fresh value; or calculating XRES based on a second fresh value and a fourth fresh value. The specific processing method for calculating XRES on the ADM side based on the fourth fresh value, or based on the second fresh value and the fourth fresh value, should be the same as the processing method for the AIoT device in step 409 above, and therefore will not be repeated. Optionally, if the ADM has already calculated XRES in step 404, the ADM can discard or delete the XRES calculated in step 404 and use the XRES calculated in this step to authenticate the AIoT device.

[0309] The ADM side, based on RES and XRES, performs the same authentication process for the AIoT device as in the aforementioned embodiments, and will not be repeated here.

[0310] Regardless of which of the above embodiments is used to perform or implement the authentication of AIoT devices, the AIoT F side will obtain the authentication result of the AIoT device.

[0311] Furthermore, if the AIoT device authentication is successful or passes, AIoT F executes step 413. Alternatively, if the AIoT device authentication fails, AIoT F may execute at least one of the following: send a notification of AIoT device authentication failure to AF; send a notification of AIoT device authentication failure to the AIoT device; or terminate the process. This document does not limit or exhaustively list all the processes that AIoT F may execute when AIoT device authentication fails.

[0312] Step 413: AIoT F sends a command request, wherein the command request carries first information, which is used by the AIoT device to perform authentication. Specifically, AIoT F sends the command request to the Reader.

[0313] In this step, the relevant description of the first information is the same as that in step 313 of the aforementioned embodiment, and will not be repeated.

[0314] It should be noted that the command request may also carry other content as stipulated in the relevant agreement, which will not be limited or exhaustively listed here.

[0315] Step 414: The Reader sends a command request. Specifically, the Reader sends a command request to the AIoT device.

[0316] Step 415 is the same as step 315 in the previous embodiment, so it will not be described again.

[0317] Step 416: The AIoT device authenticates the network based on the message verification code and the message authentication code.

[0318] In this step, the AIoT device first calculates the message verification code. Specifically, the AIoT device calculates the message verification code based on the first freshness value. The specific method by which the AIoT device calculates the message verification code should be the same as the method by which the ADM calculates the message authentication code in step 403, so it will not be described again.

[0319] The authentication network based on the message verification code and the message authentication code may include: determining that the authentication network is successful or passes when the message verification code and the message authentication code are the same; and / or determining that the authentication network fails or fails when the message verification code and the message authentication code are different.

[0320] Furthermore, if the AIoT device authentication network succeeds, step 417 can be executed. Alternatively, if the AIoT device authentication network fails, subsequent steps may not be executed (processing terminated) and / or a message indicating authentication network failure may be sent. The message indicating authentication network failure can be sent to AIoT F via a Reader. Accordingly, after receiving the message indicating authentication network failure on the AIoT F side, at least one of the following can be executed: send a notification of AIoT device authentication network failure to AF; terminate processing. This document does not limit or exhaustively list all possible processes that the AIoT device and AIoT F may perform when the AIoT device authentication network fails.

[0321] The processing of steps 417 to 419 is the same as that of steps 317 to 319 in the previous embodiment, and will not be described again.

[0322] By adopting the above implementation method, in the inventory and command process, the AIoT device can determine the AIoT device that needs to be authenticated by the network based on the second information carried in the inventory request, including the quantity of fresh values ​​and / or indicators; and the AIoT device can determine the network that needs to be authenticated based on the message authentication code and / or indicators included in the first information, providing a solution for how the AIoT device determines how to perform two-way authentication in the inventory and command process. Furthermore, by carrying the RES for authenticating the AIoT device in the inventory response and authenticating the network through the message authentication code, the security of the commands executed by the AIoT device and the security of the relevant data of the AIoT device obtained by the network side are ensured, and the signaling overhead caused by authentication can be reduced, thus improving the efficiency of both the AIoT device-side authentication of the network and the network-side authentication of the AIoT device.

[0323] In some possible implementations, under the inventory and command process, authentication only includes one-way authentication by the AIoT device authentication network, that is, network authentication of AIoT devices is not required.

[0324] The following section, with reference to Figure 5, describes one method for one-way authentication in an AIoT device authentication network under the inventory and command flow, specifically including:

[0325] Step 501 is similar to step 301. The difference lies in that, since this embodiment is designed for a one-way authentication scenario of the AIoT device authentication network, preferably, the service type indicated by the service request issued by AF in step 501 is an inventory and command (write) indicator. That is, the service type is used to indicate the inventory and command process for this write operation, or to write data through the inventory and command process. This is because the process of writing data from an AIoT device especially requires the AIoT device to trust the network. Therefore, the one-way authentication method of the AIoT device authentication network under the inventory and command process provided in this embodiment is particularly suitable for scenarios involving writing data.

[0326] It should be noted that the above is only a preferred exemplary description. The one-way authentication method of the AIoT device authentication network under the inventory and command flow provided in this embodiment can also be used for read operations, activation, or deactivation (including temporary deactivation or permanent deactivation) according to actual needs. It is not limited or exhaustive here.

[0327] Furthermore, regarding the AIoT F's ability to determine whether to execute step 502 and its subsequent processing for a single AIoT device based on the identifier of the single AIoT device, or to determine whether to execute step 502 and its subsequent processing for each AIoT device in the group based on the identifier of each AIoT device in the group, the descriptions are similar to those in the previous embodiments after the AIoT F receives the service request in step 301, and therefore will not be repeated.

[0328] Step 502: AIoT F sends an inventory request. Specifically, AIoT F sends an inventory request to the Reader.

[0329] Furthermore, the inventory request can also include the identifier of the AIoT device.

[0330] Furthermore, AIoT F can also send business type indications, inventory counts, and commands to the Reader. This business type is the same as in the business request and will not be repeated here.

[0331] The specific method by which AIoT F sends an inventory request to the Reader is similar to step 302 in the aforementioned embodiment. The only difference is that the inventory request in this embodiment does not carry the second information, and this embodiment is preferably applicable to write operation scenarios. All other descriptions are the same as step 302 and will not be repeated.

[0332] Step 503: The Reader sends a paging message, which carries an inventory request. Specifically, the Reader sends a paging message carrying an inventory request to the AIoT device. Correspondingly, the processing on the AIoT device side also includes receiving the inventory request.

[0333] Among them, the inventory request sent by the Reader to the AIoT device can carry the identifier of the AIoT device.

[0334] The description of the Reader sending an inventory request to the AIoT device in this step is similar to step 303 in the previous embodiment. The only difference is that the inventory request in this embodiment does not carry the second information, and this embodiment is preferably applicable to write operation scenarios. The rest of the description is the same as step 302 and will not be repeated.

[0335] Step 504: Based on the inventory request, the AIoT device determines that the network does not need to authenticate the AIoT device. Specifically, the AIoT device can determine that the network does not need to authenticate the AIoT device and that RES does not need to be calculated if the inventory request does not contain any of the following: freshness value, network authentication AIoT device indicator, inventory and command service indicator, or service association indicator corresponding to the inventory and command service.

[0336] Step 505: The AIoT device sends an inventory response.

[0337] Optionally, the inventory response may only carry the content specified in the relevant protocol, such as the identifier of the AIoT device, which is not limited here.

[0338] Optionally, the AIoT device can also send a third freshness value. Specifically, in addition to carrying content specified in the relevant protocol, such as the AIoT device's identifier, the inventory response carries a third freshness value, which is generated by the AIoT device. This third freshness value is used by the network side to calculate the message authentication code.

[0339] Step 506: The Reader sends an inventory response to the AIoT F.

[0340] Step 507: AIoT F sends an authentication vector request to ADM.

[0341] In one embodiment, the inventory response carries only the content specified in the relevant protocol. After receiving the inventory response and confirming that the AIoT device has been successfully paged, AIoT F can send an authentication vector request to ADM, which carries the identifier of the AIoT device.

[0342] In one embodiment, the AIoT F processing further includes: receiving a third fresh value; and sending the third fresh value, wherein the third fresh value is used to calculate the message authentication code.

[0343] Specifically, the inventory response includes the information specified in the relevant protocol, and also carries a third freshness value. After receiving the inventory response and confirming that the AIoT device has been successfully paged, AIoT F can send an authentication vector request to ADM, which carries the AIoT device's identifier and the third freshness value.

[0344] Step 508: ADM calculates the message authentication code.

[0345] In one embodiment, the authentication vector request does not carry a third fresh value. On the ADM side, the message authentication code is calculated based on the first fresh value, which is generated by the ADM. The specific processing method for calculating the message authentication code based on the first fresh value is the same as the specific processing method in step 310 of the aforementioned embodiment, and will not be repeated here.

[0346] In one embodiment, the authentication vector request carries a third freshness value. The ADM side calculates the message authentication code based on the first freshness value and the third freshness value. The specific processing method for calculating the message authentication code based on the first freshness value and the third freshness value is the same as the specific processing method in step 310 of the aforementioned embodiment, and will not be repeated here.

[0347] Step 509: ADM sends an authentication vector response to AIoT F. The authentication vector response carries a message authentication code, a first freshness value, and the identifier of the AIoT device; wherein, the message authentication code and the first freshness value can be used as authentication parameters in the authentication vector response.

[0348] Step 510: AIoT F sends a command request, wherein the command request carries first information, which is used for the AIoT device to perform authentication, the authentication including the AIoT device authentication network. Specifically, AIoT F sends the command request to the Reader.

[0349] In this step, the description of the first information is similar to that of step 313 in the aforementioned embodiment. The difference is that in this embodiment, the command in the first information is preferably a write command, which can be replaced by a read command, a deactivation command, or an activation command. Furthermore, in this embodiment, the first information does not include a two-way authentication indicator. The remaining content is the same as in step 313, so it will not be described in detail. It should be noted that the command request may also carry other content specified by the relevant protocol, such as the identifier of the AIoT device, etc., which are not limited or exhaustively listed here.

[0350] Step 511: The Reader sends a command request. Specifically, the Reader sends a command request to the AIoT device.

[0351] Step 512: Based on the first information, the AIoT device determines the AIoT device authentication network to be executed.

[0352] In one embodiment, the first information includes only: command, message authentication code, and first freshness value.

[0353] The processing of an AIoT device may include one of the following: determining to execute an AIoT device authentication network when the first information includes a command; determining to execute an AIoT device authentication network when the first information includes a command and a message authentication code; determining to execute an AIoT device authentication network when the first information includes a command, a message authentication code, and a fresh value; determining an AIoT device authentication network when the first information includes a message authentication code; or determining that an AIoT device authentication network needs to be executed when the first information includes a message authentication code and a fresh value.

[0354] In this embodiment, the command is preferably a write command. The AIoT device can determine to execute the AIoT device authentication network if the first information includes a write command. This is merely a preferred example; in actual processing, the write command in the first information can also be replaced with an activation command, a deactivation command, or a read command. No limit or exhaustive list is provided here.

[0355] In one embodiment, the first information includes: a command, a message authentication code, and a first freshness value; and the first information further includes at least one of the following: an authentication network indicator, an inventory and command service indicator, and a service association indicator. The service association indicator corresponds to the inventory and command service.

[0356] In one example, the AIoT device may determine that it needs to authenticate the network if the first information includes a command and at least one of an authentication network indicator, an inventory and command service indicator, and a service association indicator corresponding to the inventory and command service.

[0357] In one example, an AIoT device may determine that it needs to perform AIoT device authentication network if the first information includes at least one of an authentication network indicator, an inventory and command service indicator, and a service association indicator corresponding to the inventory and command service.

[0358] In one example, the AIoT device can also combine the number of fresh values ​​in the first information and / or the message authentication code to determine whether two-way authentication is required or whether the AIoT device needs to authenticate the network.

[0359] For example, if the first information includes at least one of the following: an authentication network indicator, an inventory and command service indicator, and a service association indicator corresponding to the inventory and command service, and the first information includes a command and a message authentication code, the AIoT device may determine whether two-way authentication or AIoT device authentication network is required.

[0360] It should be noted that the above is merely an illustrative example and does not limit or exhaust all possible situations of the content that the first information may include, or all possible ways in which the AIoT device specifically determines that it needs an AIoT device authentication network. As long as the AIoT device can determine that it needs an AIoT device authentication network based on the content included in the first information, it is within the protection scope of this embodiment.

[0361] In this way, AIoT devices can determine the network requiring authentication based on the message authentication code in the first information, allowing them to determine the need for authentication with only a limited amount of information. Alternatively, AIoT devices can determine the network requiring authentication based on at least one of the following: the message authentication code, various indicators, or one or more fresh values. This allows for a more flexible approach to determining whether authentication is required. These methods provide solutions for how AIoT devices determine the specific type of authentication to perform during inventory and command processes.

[0362] Step 513 is the same as step 316 in the previous embodiment, and will not be described again.

[0363] Step 514: The AIoT device sends a command response.

[0364] In a preferred embodiment, in step 501, the service type in the service request sent by the AF indicates inventory and command (write), and correspondingly, the command request received by the AIoT device carries a write command.

[0365] Furthermore, if the AIoT device successfully authenticates the network, the AIoT device writes data based on the write command, and then executes step 514, in which the AIoT device sends a command response to the Reader, the command response not carrying data.

[0366] In step 515, the Reader sends the command response to the AIoT F. The AIoT F can then terminate the process upon receiving the command response.

[0367] In this embodiment, the command response can also indicate that the AIoT device has successfully authenticated with the network. It should be noted that the command response can be used to indicate that the AIoT device has successfully authenticated with the network, but this is not intended to limit whether the command response will carry information indicating that the AIoT device has successfully authenticated with the network; this will not be repeated here.

[0368] In an alternative embodiment, in step 501, the service type indication in the service request sent by the AF, which specifies an inventory and command (deactivation (temporary deactivation or permanent deactivation)), is replaced with an indication of an inventory and command (activation). Accordingly, the command request received by the AIoT device carries a deactivation command (temporary deactivation command or permanent deactivation command) or an activation command.

[0369] After the AIoT device has successfully authenticated the network, it can execute an activation command and then send a command response to the Reader in step 514; or, after the AIoT device has successfully authenticated the network, the AIoT device in step 514 sends a command response to the Reader and then performs a deactivation operation based on the deactivation command (temporary deactivation command or permanent deactivation command). This operation may temporarily disable the radio frequency function or capability (which can be re-enabled by the activation command later) or permanently disable the radio frequency function or capability (which cannot be re-activated or enabled later).

[0370] It should be noted that the above embodiments can also be used alternatively in scenarios where data is read. In scenarios where data is read, the command response issued by the AIoT device in step 514 carries data, and after completing step 515, the AIoTF can report data to the AF. Here, the possible processing of the AIoT device and the AIoTF under all possible command types is not limited or exhaustively listed.

[0371] By adopting the above implementation method, in the inventory and command process, the AIoT device can determine that network authentication of the AIoT device is not required based on the absence of the second information in the inventory request. Furthermore, the AIoT device can determine the network that needs authentication based on the message authentication code and / or indicator included in the first information, providing a solution for the one-way processing of how the AIoT device determines the network to be authenticated in the inventory and command process. Further, since the network side generates the message authentication code only after confirming a successful page to the AIoT device, it avoids the waste of computing resources caused by calculating the message authentication code and / or XRES before sending the inventory request, which could lead to page failures. This saves network side resources. Furthermore, authenticating the network using the message authentication code ensures the security of the commands executed by the AIoT device and reduces the signaling overhead generated during authentication, thus improving the efficiency of both the AIoT device-side network authentication and the network-side AIoT device authentication.

[0372] In some other possible implementations, referring to Figure 6, another authentication method for one-way authentication of the AIoT device authentication network under the inventory and command flow is described, specifically including:

[0373] Step 601 is similar to step 401. The difference lies in that, since this embodiment is designed for a one-way authentication scenario of the AIoT device authentication network, preferably, the service type indicated by the service request issued by AF in step 601 is used to indicate the inventory and command (write) process for this write operation. This is because the process of writing data from an AIoT device requires the AIoT device to trust the network, therefore this embodiment is particularly suitable for scenarios involving writing data. It should be noted that the above is only a preferred exemplary description. The one-way authentication method under the inventory and command process provided in this embodiment can also be used for read operations, activation, or deactivation (including temporary or permanent deactivation) according to actual needs, etc., without limitation or exhaustive enumeration.

[0374] After receiving a service request, AIoT F checks whether authentication parameters are stored locally. If no authentication parameters are stored, step 602 is executed; if authentication parameters are stored, step 605 is executed. Regarding the AIoT F's ability to determine whether to execute step 602 and subsequent processing for a single AIoT device or a group-related content based on the identifier of the single AIoT device, or to determine whether to execute step 602 and subsequent processing for each AIoT device in the group based on the identifier of each AIoT device in the group, the explanations are similar to those in the previous embodiments regarding the AIoT F receiving the service request in step 401, and will not be repeated.

[0375] Step 602 is the same as step 402, and will not be described in detail.

[0376] Step 603: ADM generates a first fresh value and calculates the message authentication code based on the first fresh value. The method by which ADM generates the first fresh value is not limited. The specific processing method for calculating the message authentication code based on the first fresh value on the ADM side is the same as the processing method for calculating the message authentication code based on the first fresh value in step 310 of the aforementioned embodiment, and will not be repeated.

[0377] Step 604: ADM returns authentication parameters to AIoT F. Specifically, ADM sends an authentication vector response to AIoT F, which carries the authentication parameters.

[0378] Accordingly, the AIoT F process includes receiving at least one of the following: a message authentication code, or a first freshness value.

[0379] Specifically, the authentication parameters include a message authentication code and a first freshness value. Correspondingly, AIoT F receives the message authentication code and first freshness value included in the authentication parameters of the authentication vector response.

[0380] Steps 605 to 607 are the same as steps 502 to 504, and will not be described again.

[0381] Step 608: The AIoT device sends an inventory response. The inventory response may carry content specified in the relevant protocol, such as the identifier of the AIoT device; however, this is not limited here.

[0382] Step 609 is the same as step 506, and will not be described in detail.

[0383] Steps 610 to 612 are the same as steps 510 to 512, and will not be described again.

[0384] Step 613: The AIoT device calculates a message verification code based on the first freshness value; based on the message verification code and the message authentication code, it authenticates the network. The process of the AIoT device calculating the message verification code based on the first freshness value should be the same as the ADM process in step 603, and will not be repeated here.

[0385] The specific processing based on the message verification code and the message authentication code authentication network is the same as the relevant descriptions in the foregoing embodiments, such as the processing based on the message verification code and the message authentication code authentication network in step 316, or step 416, or step 513, and will not be repeated here.

[0386] The processing of steps 614 to 615 is the same as that of steps 514 to 515 in the previous embodiments, and will not be repeated.

[0387] By adopting the above implementation method, in the inventory and command process, the AIoT device can determine that network authentication is not required because the inventory request does not carry the second information. Furthermore, the AIoT device can determine the network that needs authentication based on the message authentication code and / or indicator included in the first information, providing a solution for the one-way processing of how the AIoT device determines the network to be authenticated in the inventory and command process. Further, authenticating the network using the message authentication code carried in the command request ensures the security of the commands executed by the AIoT device and reduces the signaling overhead generated during authentication, thereby improving the efficiency of both the AIoT device-side network authentication and the network-side AIoT device authentication.

[0388] In some possible implementations, under the command-only flow, authentication includes the AIoT device authentication network, and authentication also includes the network authenticating the AIoT device. The authentication method for two-way authentication under the command-only flow is described below with reference to Figure 7, specifically including:

[0389] Step 701: The AF sends a service request to the AIoT F. This service request may carry a service type indicator command only. The service request may also be replaced by an inventory request message from the AF.

[0390] Preferably, the service type can indicate a command-only (read) operation. This service type may include information indicating the command-only operation and the read command itself. In other words, the service type indicates the command-only process for this read operation. This is because the process of reading data from an AIoT device requires both the AIoT device and the network to trust each other. Therefore, the two-way authentication method under the command-only process provided in this embodiment is particularly suitable for data reading scenarios.

[0391] The above is merely a preferred example and is not intended to limit this embodiment. The two-way authentication method under the command flow provided in this embodiment can also be used for write operations, activation, or deactivation (including temporary or permanent deactivation) according to actual needs. No limit or exhaustive list is made here.

[0392] Furthermore, the service request may also carry at least one of the following: the identifier of the AIoT device, group identification information, number of devices, single transmission (or single transmission indication), group transmission (or group transmission indication), etc. The descriptions of each item are the same as those in the foregoing embodiments, and will not be repeated here.

[0393] After receiving a service request, AIoT F checks whether authentication parameters are stored locally. If no authentication parameters are stored, it proceeds to step 702; if authentication parameters are stored, it proceeds to step 706. The explanation regarding whether AIoT F determines whether authentication parameters exist for a single AIoT device and performs subsequent processing, or whether it determines whether authentication parameters exist for each AIoT device in a group and then performs subsequent processing separately, is the same as the content corresponding to Figure 4 above and will not be repeated.

[0394] Steps 702 to 705 are the same as steps 402 to 405 in the embodiment of Figure 4 above, and will not be described again.

[0395] Step 706: AIoT F sends a command request, wherein the command request carries first information, which is used by the AIoT device to perform authentication. Specifically, AIoT F sends the command request to the Reader.

[0396] In one embodiment, the first information includes only: command, message authentication code, first freshness value, and second freshness value.

[0397] In one embodiment, the first information includes: a command, a message authentication code, a first freshness value, and a second freshness value; and the first information further includes at least one of the following: a two-way authentication indicator, a command-only service indicator, and a service association indicator. The service association indicator corresponds to the command-only service.

[0398] It should be noted that the command request may also carry other content as specified in the relevant protocol, such as the identifier of the AIoT device, which is not limited or exhaustive here.

[0399] Optionally, AIoT F can send a second request message to the Reader, which carries a service type (same as in step 701) and a command request. For example, the second request message may include a service type and a NAS container, which carries or encapsulates the command request.

[0400] Optionally, the service type can be carried in the command request, and the command request sent by the AIoT F to the reader can be called the first command request.

[0401] Step 707: The Reader sends a command request. Specifically, the Reader sends a paging message to the AIoT device, the paging message carrying the command request.

[0402] Optionally, AIoT F sends a second request message to the Reader carrying the service type and command request. This command request can be carried or encapsulated in a NAS container. The command request carries the first information and the identifier of the AIoT device. The paging message sent by the Reader to the AIoT device only carries the command request. That is, the Reader can save the service type from the second request message locally and send the command request (i.e., the NAS container) to the AIoT device in the paging message.

[0403] Optionally, the command request sent by AIoT F to the Reader is a first command request, which carries first information, the identifier of the AIoT device, and the service type. The Reader can store the service type locally, and the command request carried in the paging message sent to the AIoT device includes the first information and the identifier of the AIoT device.

[0404] Step 708: Based on the first information, the AIoT device determines to perform two-way authentication.

[0405] In one embodiment, the first information includes only: command, message authentication code, first freshness value, and second freshness value.

[0406] The processing of an AIoT device may include one of the following: determining to perform two-way authentication when the first information includes a command; determining to perform two-way authentication when the first information includes a command and a message authentication code; determining to perform two-way authentication when the first information includes a command, a message authentication code, and two fresh values; determining that two-way authentication is required when the first information includes two fresh values; and determining that two-way authentication is required when the first information includes a message authentication code and the first information includes two fresh values.

[0407] In this embodiment, the command is preferably a read command. Therefore, the AIoT device needs to trust the network, and the network also needs to trust the AIoT device. When the AIoT device includes a read command in the first information, it determines to perform two-way authentication. This is only a preferred example. In actual processing, the first information can also be replaced with an activation command, a deactivation command, or a write command. This is not limited or exhaustive.

[0408] In one embodiment, the first information may include: a command, a message authentication code, a first freshness value, and a second freshness value. Furthermore, the first information may also include at least one of the following: a two-way authentication indicator, a command-only service indicator, and a service association indicator corresponding to a command-only service.

[0409] In one example, an AIoT device may determine that two-way authentication needs to be performed if the first information includes at least one of a command, a two-way authentication indicator, a command-only service indicator, and a service association indicator corresponding to the command-only service.

[0410] Preferably, the AIoT device can determine that two-way authentication needs to be performed if the first information includes a command and a two-way authentication indicator.

[0411] Preferably, the AIoT device can determine that two-way authentication needs to be performed if the first information includes a two-way authentication indicator.

[0412] Preferably, the AIoT device may determine that two-way authentication needs to be performed if the first information includes a command, a two-way authentication indicator, and the first information includes at least one of a command-only service indicator and a service association indicator corresponding to the command-only service.

[0413] Alternatively, the two-way authentication indicator can be replaced with an authentication network indicator and a network-authenticated AIoT device indicator. That is, the AIoT device can determine that two-way authentication needs to be performed if the first information includes the authentication network indicator and the network-authenticated AIoT device indicator.

[0414] In one example, the AIoT device can also combine the number of fresh values ​​in the first information and / or the message authentication code to determine whether two-way authentication needs to be performed.

[0415] For example, an AIoT device may determine whether to perform two-way authentication or to authenticate the network if the first information includes at least one of a two-way authentication indicator, a command-only service indicator, and a service association indicator corresponding to the command-only service, and the first information includes a command and a message authentication code.

[0416] For example, an AIoT device may determine that two-way authentication needs to be performed if the first information includes at least one of a two-way authentication indicator, a command-only service indicator, and a service association indicator corresponding to the command-only service, and the first information includes a command, a message authentication code, and two fresh values.

[0417] It should be noted that the above is merely an illustrative example and does not limit or exhaust all possible situations of the content that the first information may include, or all possible ways in which the AIoT device specifically determines that two-way authentication needs to be performed. As long as the AIoT device can determine that two-way authentication needs to be performed based on the content included in the first information, it is within the protection scope of this embodiment.

[0418] Thus, the AIoT device can determine the need for two-way authentication based on the message authentication code in the first information, allowing it to determine the need for authentication with only a limited amount of information. Alternatively, the AIoT device can determine the need for two-way authentication based on at least one of the message authentication code, various indicators, or one or more fresh values ​​in the first information, allowing for a more flexible approach to determining when to perform authentication. These methods provide solutions for how AIoT devices determine the specific type of authentication to perform within a command-only flow.

[0419] Step 709: The AIoT device calculates a message verification code based on the first freshness value; and authenticates the network based on the message verification code and the message authentication code.

[0420] The specific method by which the AIoT device calculates the message verification code based on the first freshness value should be the same as the method by which the ADM calculates the message authentication code in step 703, therefore it will not be repeated. The relevant descriptions of the authentication network based on the message verification code and the message authentication code are also the same as in the previous embodiments, and will not be elaborated upon.

[0421] Furthermore, if the AIoT device authentication network is successful, step 710 can be executed. Alternatively, if the AIoT device authentication network fails, the processing that the AIoT device and AIoT F may perform is the same as in the aforementioned embodiments, and will not be described again.

[0422] Step 710: The AIoT device sends a command response, wherein the command response carries a RES for authenticating the AIoT device.

[0423] In one embodiment, the AIoT device calculates RES before sending a command response.

[0424] In one scenario, the AIoT device calculates RES based on the second fresh value. The process of the AIoT device calculating RES based on the second fresh value should be the same as the method used by the ADM to calculate XRES based on the second fresh value in step 704, and will not be repeated here. In this case, the command response carries RES.

[0425] In one scenario, the AIoT device calculates RES based on a fourth freshness value, or based on a second freshness value and a fourth freshness value. The specific processing for calculating RES based on the fourth freshness value is the same as the specific processing in step 409 of Figure 4 above, where RES is calculated based on the fourth freshness value, or based on a second freshness value and a fourth freshness value, and will not be repeated here. In this case, the command response also carries the fourth freshness value. That is, the command response carries RES and the fourth freshness value.

[0426] In another embodiment, the RES is pre-stored by the AIoT device. In this embodiment, the AIoT device does not need to calculate the RES before sending the command response. The command response carries the RES.

[0427] It should be noted that command responses may or may not carry the response data corresponding to the command.

[0428] Preferably, if the command is a read command, the response data carried in the command response includes the data read by the AIoT device.

[0429] Optionally, if the command is a write command or an activation command, the response data carried in the command response can be an acknowledgment response, or the command response can also carry no response data.

[0430] Optionally, if the command is a deactivation command (permanent deactivation or temporary deactivation), the command response needs to be sent before the AIoT device performs the deactivation process. The response data carried by the command response can be an acknowledgment response, or the command response can carry no response data.

[0431] Step 711: The Reader sends a command response to the AIoT F. Correspondingly, the AIoT F's processing further includes receiving a command response, wherein the command response carries a RES for authenticating the AIoT device.

[0432] Upon receiving a command response, AIoT F determines that the AIoT device paging was successful and / or the AIoT device authentication network was successful, and then can execute one of the following embodiments:

[0433] In one embodiment, in step 705, the authentication vector response returned by the ADM to the AIoT F carries authentication parameters including XRES; and in step 711, the command response received by the AIoT F carries RES but not the fourth fresh value. The AIoT F executes step 712 to authenticate the AIoT device based on the RES and XRES. The related processing for authenticating the AIoT device based on the RES and XRES is the same as in the foregoing embodiments and will not be described again.

[0434] In another embodiment, the RES is pre-stored by the AIoT device. The command response carries the RES. The AIoT F side can also locally store the authentication parameters (or authentication status) of the AIoT device, and the AIoT F can directly execute step 712 to authenticate the AIoT device based on the RES and XRES.

[0435] In one embodiment, in step 705, the authentication parameters carried in the authentication vector response returned by ADM to AIoT F do not include XRES; and in step 711, the command response received by AIoT F carries RES but does not carry the fourth fresh value.

[0436] The processing performed by AIoT F also includes sending the RES. Specifically, AIoT F sends the RES and the identifier of the AIoT device to ADM, and receives the authentication result of the AIoT device from ADM, wherein the authentication result includes: successful authentication of the AIoT device or failure to authenticate the AIoT device.

[0437] The ADM's processing may include: receiving the RES and the identifier of the AIoT device from the AIoT F; authenticating the AIoT device based on the RES and XRES; and sending the authentication result of the AIoT device to the AIoT F. The specific processing of authenticating the AIoT device based on the RES and XRES is the same as in the previous embodiments and will not be described again.

[0438] In one embodiment, the command response received by AIoT F in step 711 also carries a fourth fresh value, wherein the fourth fresh value is used to calculate XRES. The processing performed by AIoT F further includes sending the RES. Furthermore, the processing by AIoT F also includes sending the fourth fresh value.

[0439] Specifically, AIoT F sends RES, the fourth freshness value, and the identifier of the AIoT device to ADM, and receives the authentication result of the AIoT device from ADM. The processing of ADM may include: receiving RES, the fourth freshness value, and the identifier of the AIoT device from AIoT F; calculating XRES; authenticating the AIoT device based on RES and XRES; and sending the authentication result of the AIoT device to AIoT F.

[0440] The calculation of XRES on the ADM side can include: calculating XRES based on a fourth fresh value; or calculating XRES based on a second fresh value and a fourth fresh value. The specific processing method for calculating XRES on the ADM side based on a fourth fresh value, or based on a second fresh value and a fourth fresh value, should be the same as the processing method for calculating RES on the AIoT device based on a fourth fresh value, or based on a second fresh value and a fourth fresh value, in step 710 above, and therefore will not be repeated.

[0441] The ADM side, based on RES and XRES, performs the same authentication process for the AIoT device as in the aforementioned embodiments, and will not be repeated here.

[0442] Regardless of which of the above embodiments is used to perform or implement the authentication of AIoT devices, the AIoT F side will obtain the authentication result of the AIoT device.

[0443] Furthermore, if the AIoT device authentication is successful or passes, AIoT F executes step 713. Alternatively, if the AIoT device authentication fails, AIoT F may execute at least one of the following: send a notification of AIoT device authentication failure to AF; send a notification of AIoT device authentication failure to the AIoT device; or terminate the process. This document does not limit or exhaustively list all the processes that AIoT F may execute when AIoT device authentication fails.

[0444] Step 713: AIoT F successfully authenticates the AIoT device and sends data to AF.

[0445] It should be noted that step 713 is an optional step. In this embodiment, when applied to a command-only (read) scenario, step 713 is executed, meaning that the AIoT F successfully authenticates the AIoT device, confirms the reliability of the data reported by the AIoT device in the command response, and then can send data to the AF. In this embodiment, when applied to a command-only (write) scenario, or a command-only deactivation scenario, or a command-only activation scenario, step 713 may not be executed.

[0446] By adopting the above implementation method, in the command-only process, the AIoT device can determine the need for two-way authentication based on the message authentication code and / or indicator included in the first information, providing a solution for how the AIoT device determines and performs two-way authentication in the command-only process. Furthermore, authenticating the network through the message authentication code and authenticating the AIoT device through the RES carried in the command response ensures the security of the commands executed by the AIoT device and the security of the relevant data of the AIoT device obtained by the network side under the command-only process. It also reduces the signaling overhead caused by authentication, thus improving the efficiency of both the AIoT device authenticating the network and the network authenticating the AIoT device.

[0447] In some possible implementations, under the command-only process, authentication includes one-way authentication by the AIoT device authentication network. Referring to Figure 8, the authentication method for one-way authentication of the AIoT device authentication network under the command-only process is described, specifically including:

[0448] Step 801: AF sends a service request to AIoT F. This service request may carry a service type indicator command.

[0449] Preferably, the service type can indicate a command-only (write) operation. This service type may include information indicating the command-only operation and the write command itself. That is, the service type indicates the command-only flow for this write operation. The above is merely a preferred example and is not intended to limit this embodiment. The one-way authentication method under the command-only flow provided in this embodiment can also be used for activation or deactivation (including temporary or permanent deactivation) according to actual needs, and is not limited or exhaustive here.

[0450] Furthermore, after receiving the service request, AIoT F checks whether authentication parameters are stored locally. If no authentication parameters are stored, step 802 is executed; if authentication parameters are stored, step 805 is executed. The explanation regarding AIoT F's determination of whether authentication parameters exist for a single AIoT device and the execution of subsequent related processing, or the determination of whether authentication parameters exist for each AIoT device in a group and the execution of subsequent related processing, is the same as the explanation of the command-only flow corresponding to Figure 7 above, and will not be repeated here.

[0451] Steps 802 to 804 are the same as steps 602 to 604 shown in Figure 6 above, and will not be repeated.

[0452] Step 805: AIoT F sends a command request, wherein the command request carries first information, which is used by the AIoT device to perform authentication. Specifically, AIoT F sends the command request to the Reader.

[0453] In one embodiment, the first information includes only: command, message authentication code, and first freshness value.

[0454] In one embodiment, the first information includes: a command, a message authentication code, and a first freshness value; and the first information further includes at least one of the following: an authentication network indicator, a command-only service indicator, and a service association indicator. The service association indicator corresponds to the command-only service.

[0455] In this embodiment, the command is preferably a write command.

[0456] It should be noted that the command request may also carry the identifier of the AIoT device as specified in the relevant protocol, and / or AIoT F may also send relevant descriptions such as the service type to the Reader, all of which are similar to step 706 in the aforementioned embodiment, and are not limited or exhaustive here.

[0457] Step 806 is the same as step 707 shown in Figure 7, and will not be described again.

[0458] Step 807: Based on the first information, the AIoT device determines the AIoT device authentication network to be executed.

[0459] In one embodiment, the first information includes only: command, message authentication code, and first freshness value.

[0460] In this embodiment, the specific description of how the AIoT device determines the execution of the AIoT device authentication network based on the first information is the same as the description of determining the execution of the AIoT device authentication network in step 512 of Figure 5 in the aforementioned embodiment when the first information only includes the command, message authentication code, and first freshness value, so it will not be repeated.

[0461] In one embodiment, the first information may include: a command, a message authentication code, and a first freshness value. Furthermore, the first information may also include at least one of the following: an authentication network indicator, a command-only service indicator, and a service association indicator corresponding to a command-only service.

[0462] In one example, an AIoT device may determine that it needs to perform AIoT device authentication network if the first information includes at least one of a command, an authentication network indicator, a command-only service indicator, and a service association indicator corresponding to the command-only service.

[0463] Optionally, the AIoT device may determine that it needs to perform AIoT device authentication network if the first information includes a command. This command is preferably a write command.

[0464] Optionally, the AIoT device may determine that it needs to perform AIoT device authentication network if the first information includes a command and an authentication network indicator.

[0465] Optionally, if the first information includes either a command-only service indicator or a service association indicator corresponding to the command-only service, the AIoT device may determine that it needs to perform AIoT device authentication network.

[0466] Optionally, the AIoT device may determine that it needs to perform AIoT device authentication network if the first information includes an authentication network indicator and the first information includes at least one of a command-only service indicator and a service association indicator corresponding to the command-only service.

[0467] In one example, the AIoT device can also combine the number of fresh values ​​in the first information and / or the message authentication code to determine whether to perform the AIoT device authentication network.

[0468] Optionally, the AIoT device may determine that it needs to perform AIoT device authentication network if the first information includes at least one of the following: authentication network indicator, command-only service indicator, and service association indicator corresponding to the command-only service, and the first information includes a command and a message authentication code.

[0469] It should be noted that the above is merely an illustrative example and does not limit or exhaust all possible situations of the content that the first information may include, or all possible ways in which the AIoT device specifically determines that it needs an AIoT device authentication network. As long as the AIoT device can determine that it needs an AIoT device authentication network based on the content included in the first information, it is within the protection scope of this embodiment.

[0470] Thus, the AIoT device can determine the network requiring authentication based on the message authentication code in the first information, allowing it to determine the need for authentication with only a limited amount of information. Alternatively, the AIoT device can determine the network requiring authentication based on at least one of the following: the message authentication code in the first information, various indicators, and one or more fresh values. This allows for a more flexible approach to determining whether authentication is required. These methods provide solutions for how AIoT devices specifically determine authentication and the type of authentication to be performed within a command-only flow.

[0471] Step 808 is the same as step 709 in the previous embodiment, and will not be described again.

[0472] Step 809: The AIoT device sends a command response.

[0473] Preferably, the command is a write command or an activation command, and the response data carried by the command response can be a confirmation response, or the command response may not carry any response data.

[0474] Optionally, in the scenario where the command is a read command, the response data carried in the command response includes the data read by the AIoT device.

[0475] Optionally, if the command is a deactivation command (permanent deactivation or temporary deactivation), the command response needs to be sent before the AIoT device performs the deactivation process. The response data carried by the command response can be an acknowledgment response, or the command response can carry no response data.

[0476] Step 810: The Reader sends a command response to AIoT F.

[0477] Preferably, this embodiment is used for a command-only (write) scenario, in which the AIoT F can end the processing after receiving the command response.

[0478] Optionally, this embodiment may also be used in scenarios where only command deactivation or only command activation is required. In such scenarios, after AIoT F receives the command response, it can also end the processing.

[0479] Optionally, this embodiment may also be used in command-only read scenarios. In such scenarios, after receiving the command response, AIoT F can send data to AF. This is not limited or exhaustive.

[0480] By adopting the above implementation method, in the command-only process, the AIoT device can determine the network to be authenticated based on the message authentication code and / or indicator included in the first information, providing a solution for how the AIoT device determines and executes one-way authentication of the authentication network in the command-only process. Furthermore, authenticating the network using the message authentication code ensures the security of commands executed by the AIoT device in the command-only process and reduces signaling overhead caused by authentication, thereby improving the efficiency of both the AIoT device-side authentication of the network and the network-side authentication of the AIoT device.

[0481] In some possible implementations, under a command-only process, authentication includes one-way authentication of the AIoT device authentication network, or authentication includes two-way authentication.

[0482] Referring to Figure 9, another authentication method under the command-only flow is described, specifically including:

[0483] Step 901: AF sends a service request to AIoT F. This service request may carry a service type indicator command.

[0484] Preferably, the service type can indicate command only (read). The above is only a preferred exemplary description and is not intended to limit this embodiment. The one-way authentication method under the command only process provided in this embodiment can also be used for write, or activation, or deactivation (including temporary deactivation or permanent deactivation) and other scenarios according to actual needs. It is not limited or exhaustive here.

[0485] Step 902: AIoT F checks whether the network side has stored the result of the AIoT device authentication network. If the network side has stored the result of the AIoT device authentication network, then proceed to step 903; if the network side has not stored the result of the AIoT device authentication network, then proceed to steps 702 to 713 (or steps 702 to 712) as shown in Figure 7 above, or proceed to steps 802 to 810 as shown in Figure 8 above.

[0486] In one embodiment, the service request may carry the service type and the identifier of the AIoT device. The service request may also carry a single-transmission instruction, or it may not carry a single-transmission instruction; this is not limited here.

[0487] In this embodiment, after AIoT F receives a service request, it can first check whether the network side has stored the result of the AIoT device authentication network. If the network side has stored the result of the AIoT device authentication network, then step 903 is executed; if the network side has not stored the result of the AIoT device authentication network, then steps 702 to 713 (or steps 702 to 712) as shown in Figure 7 are executed, or steps 802 to 810 as shown in Figure 8 are executed.

[0488] In one embodiment, the service request may carry service type and group identification information. The service request may also carry a mass sending instruction, or it may not carry a mass sending instruction; this is not limited here.

[0489] In this embodiment, after receiving a service request, AIoT F can determine the identifier of each AIoT device among the multiple AIoT devices included in the group based on group identification information. Specifically, AIoT F can store a mapping relationship between group identification information and the identifiers of the multiple AIoT devices in the group; therefore, AIoT F can determine the identifier of each AIoT device among the multiple AIoT devices in the group based on the group identification information.

[0490] In a group scenario, AIoTF checks whether the network side has stored the authentication network result for each AIoT device in the group. If the network side has stored the authentication network result, step 902 is executed; if the network side has not stored the authentication network result, steps 702 to 713 (or steps 702 to 712) as shown in Figure 7, or steps 802 to 810 as shown in Figure 8, are executed for that AIoT device. Since the subsequent processing for each AIoT device in a group scenario is the same as that for a single AIoT device, this embodiment will only describe the subsequent processing for one AIoT device, and will not go into detail.

[0491] Step 903: AIoT F sends a command request, wherein the command request carries first information, which is used by the AIoT device to perform authentication. Specifically, AIoT F sends the command request to the Reader.

[0492] The first information includes at least one of the following: a command, indication information for indicating that the network side stores the result of the AIoT device authentication network, a two-way authentication indicator, an authentication network indicator, a command-only service indicator, and a service association indicator corresponding to the command-only service.

[0493] The first information may or may not include a second fresh value. The second fresh value may be pre-stored by the AIoTF, and the method of generating this second fresh value is not limited. If the second fresh value is pre-stored by the AIoTF, it means that the AIoTF may have saved the second fresh value in the authentication status, authentication parameters, or authentication result. Alternatively, the second fresh value may be pre-generated by the ADM and sent to the AIoTF. This embodiment does not limit how the AIoTF specifically requests and / or obtains the second fresh value from the ADM.

[0494] Preferably, in this embodiment, the command request carries a read command.

[0495] The command request may also carry the identifier of the AIoT device as specified in the relevant protocol, and / or AIoT F may also send relevant descriptions such as the service type to the Reader, all of which are similar to step 706 in the aforementioned embodiment, and are not limited or exhaustive here.

[0496] Step 904 is the same as step 707 shown in Figure 7, and will not be described again.

[0497] Step 905: The AIoT device determines to perform authentication based on the first information. Specifically, the AIoT device determines to perform AIoT device authentication network based on the first information; or, the AIoT device determines to perform two-way authentication based on the first information.

[0498] An AIoT device may determine that it needs to perform AIoT device authentication network if the first information includes at least one of the following: a command, an indication information indicating that the network side stores the result of the AIoT device authentication network, a two-way authentication indicator, an authentication network indicator, a command-only service indicator, and a service association indicator corresponding to the command-only service.

[0499] Optionally, if the first information includes a command (such as a read command), the AIoT device determines whether to perform authentication network or two-way authentication.

[0500] Optionally, the AIoT device may determine that two-way authentication needs to be performed if the first information includes indication information indicating that the network side stores the result of the AIoT device's authentication network.

[0501] Optionally, if the first information includes a command or indication information indicating that the network side stores the result of the AIoT device's authentication network, the AIoT device may determine that two-way authentication needs to be performed.

[0502] Optionally, if the first information includes indication information indicating that the network side stores the result of the AIoT device authentication network, or an authentication network indicator, the AIoT device may determine whether to perform AIoT device authentication network or perform two-way authentication.

[0503] Optionally, the AIoT device may determine to perform two-way authentication if the first information includes indication information indicating that the network side stores the result of the AIoT device's authentication network, or a two-way authentication indicator.

[0504] Optionally, if the first information includes either a command-only service indicator or a service association indicator corresponding to the command-only service, the AIoT device may determine that it needs to perform AIoT device authentication network.

[0505] Optionally, the AIoT device may determine that it needs to perform AIoT device authentication network if the first information includes a command, an indication that the network side stores the result of the AIoT device authentication network, and an authentication network indicator.

[0506] Optionally, the first information may also include a second fresh value. For example, if the first information includes an indication that the network side has stored the result of the AIoT device's authentication network and a fresh value, the AIoT device may determine that two-way authentication needs to be performed. For example, if the first information includes a command, an indication that the network side has stored the result of the AIoT device's authentication network, and a fresh value, the AIoT device may determine that two-way authentication needs to be performed.

[0507] It should be noted that the above is merely an illustrative example and does not limit or exhaust all possible situations of the content that the first information may include, or all possible ways in which the AIoT device specifically determines that it needs to perform the AIoT device authentication network. As long as the AIoT device can determine that it needs to perform the AIoT device authentication network or two-way authentication based on the content included in the first information, it is within the protection scope of this embodiment.

[0508] In this way, AIoT devices can determine which authentication needs to be performed based on the initial information, allowing for a more flexible approach to authentication determination. This method provides a solution for how AIoT devices determine the specific authentication to be performed and the type of authentication to be performed within the command-only process.

[0509] Step 906: The AIoT device, having stored the results of the authentication network, determines that the authentication network was successful.

[0510] Specifically, after determining that an AIoT device needs to authenticate with an AIoT network, it can check whether the authentication network result is stored locally. If the authentication network result is stored, there is no need to calculate the message verification code or determine whether the message verification code is the same as the message authentication code. The authentication network can be directly determined to be successful, and then step 907 can be executed.

[0511] Step 907: The AIoT device sends a command response. Specifically, the AIoT device sends a command response to the Reader.

[0512] In one embodiment, if the AIoT device determines through the first information that it is only performing the AIoT device authentication network, then the command response in step 907 may only carry the response data corresponding to the command.

[0513] Preferably, in the scenario where the command is a read command, the response data carried by the command response includes the data read by the AIoT device. In this case, the Reader sends a command response (carrying data) to the AIoT F. After receiving the command response, the AIoT F can send the data to the AF and then end the processing.

[0514] Optionally, if the command is a write command or an activation command, the response data carried in the command response can be an acknowledgment response, or the command response may not carry any response data. In this case, the Reader sends the command response to the AIoT F and can then end the processing.

[0515] Optionally, if the command is a deactivation command (permanent deactivation or temporary deactivation), the command response needs to be sent before the AIoT device performs the deactivation process. The response data carried by the command response can be an acknowledgment response, or the command response can carry no response data. In this case, the Reader sends the command response to the AIoT F, and then the processing can end.

[0516] In one embodiment, if the AIoT device determines to perform two-way authentication through the first information, the command response in step 907 may carry RES for authenticating the AIoT device.

[0517] Before sending a command response, the AIoT device calculates RES. The calculation of RES by the AIoT device can include: calculating RES based on a fourth fresh value; or calculating RES based on a second fresh value and a fourth fresh value; or calculating RES based on a second fresh value. This embodiment does not limit the method by which the AIoT device generates the fourth fresh value, as long as the fourth fresh value is different from the first fresh value and different from the second fresh value, it is within the scope of protection of this embodiment. The specific processing of the AIoT device calculating RES is the same as the specific processing of the embodiment based on the fourth fresh value in step 409 of Figure 4 above, and will not be described again.

[0518] If the AIoT device uses a fourth fresh value when calculating RES, the command response will also carry the fourth fresh value.

[0519] Regarding whether the command response carries response data, and the content of the response data carried in different scenarios, it is the same as in the aforementioned embodiments, and will not be repeated here.

[0520] In this embodiment, the following subsequent steps need to be performed:

[0521] Step 908: The Reader sends a command response to AIoT F.

[0522] Step 909: Upon receiving the command response, AIoT F determines that the AIoT device authentication network has been successful.

[0523] Step 910: AIoT F sends an authentication vector request, which carries the identifier of the AIoT device (and may also carry a fourth fresh value).

[0524] Step 911: ADM calculates XRES. The specific method by which ADM calculates XRES should be the same as that used by AIoT devices to calculate RES, and will not be described in detail here.

[0525] Step 912, ADM sends an authentication vector response to AIoT F, which carries the XRES and the identifier of the AIoT device.

[0526] In other words, the processing of AIoT F after completing step 910 also includes receiving XRES.

[0527] Step 913, AIoT F authenticates the AIoT device based on the RES and XRES.

[0528] The AIoT F-side authentication process for the AIoT device is based on RES and XRES and is the same as in the aforementioned embodiments, so it will not be repeated here.

[0529] In the scenario where the command is a read command, if the AIoT device is successfully authenticated or passes the authentication process, AIoT F executes step 914. AIoT F successfully authenticates the AIoT device, determines that the data reported by the AIoT device in the command response is reliable, and then sends the data to AF.

[0530] It should be noted that when this embodiment is applied to a scenario of only command (write), only command deactivation, or only command activation, step 914 may not be executed.

[0531] By adopting the above implementation method, in the command-only process, the AIoT device can determine whether two-way authentication or one-way authentication of the network is required based on the message authentication code and / or indicator included in the first information, providing a solution for how the AIoT device determines which authentication to perform in the command-only process. Furthermore, authenticating the network through the message authentication code and / or authenticating the AIoT device through the RES carried in the command response ensures the security of the commands executed by the AIoT device and / or the security of the relevant data of the AIoT device obtained by the network side under the command-only process. It also reduces the signaling overhead caused by authentication, improving the efficiency of both the AIoT device authenticating the network and the network authenticating the AIoT device.

[0532] By adopting the solution provided in this application embodiment, the AIoT device can perform authentication through the first information carried in the command request. Thus, authentication related to the AIoT device can be implemented during the command interaction process between the network side and the AIoT device. This ensures the security of the AIoT device executing commands while reducing signaling overhead caused by authentication, thereby improving authentication efficiency.

[0533] Figure 10 is a schematic diagram of the composition structure of an AIoT device according to an embodiment of this application, including:

[0534] The first communication unit 1001 is configured to receive a command request, wherein the command request carries first information, which is used by the AIoT device to perform authentication.

[0535] The first information includes at least one of the following: a command, a message authentication code for authenticating the network, a first freshness value, a second freshness value, a two-way authentication indicator, an authentication network indicator, a command-only service indicator, an inventory and command service indicator, a service association indicator, and indication information for indicating that the network side stores the result of the AIoT device authentication network. The command includes at least one of the following: a read command, a write command, an activation command, and a deactivation command.

[0536] As shown in Figure 10, the AIoT device further includes: a first processing unit 1002, used to determine the AIoT device authentication network based on the first information.

[0537] The first processing unit 1002 is used to determine whether to perform two-way authentication based on the first information.

[0538] The first processing unit 1002 is used to calculate a message verification code based on the first freshness value.

[0539] The first processing unit 1002 is used to calculate a message verification code based on the first freshness value and the third freshness value, wherein the third freshness value is generated by an AIoT device.

[0540] The first communication unit 1001 is used to send the third fresh value.

[0541] The first processing unit 1002 is used to authenticate the network based on the message verification code and the message authentication code.

[0542] The first processing unit is configured to determine that the authentication network was successful, provided that the result of the stored authentication network is stored.

[0543] The first communication unit is configured to send a command response, wherein the command response carries a RES for authenticating the AIoT device.

[0544] The command response also carries a fourth freshness value.

[0545] The first communication unit is configured to receive an inventory request, wherein the inventory request carries second information, the second information being used by the AIoT device to perform network authentication of the AIoT device.

[0546] The second information includes at least one of the following: the second freshness value, the fifth freshness value, the network authentication AIoT device indicator, the inventory and command service indicator, the service association indicator, and the read command.

[0547] The first processing unit is configured to determine, based on the second information, to perform network authentication on the AIoT device.

[0548] The first communication unit is configured to send an inventory response, wherein the inventory response carries a RES for authenticating the AIoT device.

[0549] A first processing unit is configured to calculate the RES based on the second freshness value.

[0550] The inventory response also carries a fourth freshness value.

[0551] A first processing unit is configured to calculate the RES based on the fourth freshness value, wherein the fourth freshness value is generated by the AIoT device; or, to calculate the RES based on the second freshness value and the fourth freshness value.

[0552] A first processing unit is used to calculate the RES based on the fifth freshness value.

[0553] A first processing unit is configured to calculate the RES based on the fourth freshness value and the fifth freshness value, wherein the fourth freshness value is generated by the AIoT device.

[0554] The RES is pre-stored in the AIoT device.

[0555] Figure 11 is a schematic diagram of the composition structure of an AIoT F device according to an embodiment of this application, including:

[0556] The second communication unit 1101 is used to send a command request, wherein the command request carries first information, which is used for the AIoT device to perform authentication.

[0557] The first information includes at least one of the following: a command, a message authentication code for authenticating the network, a first freshness value, a second freshness value, a two-way authentication indicator, an authentication network indicator, a command-only service indicator, an inventory and command service indicator, a service association indicator, and indication information for indicating that the network side stores the result of the AIoT device authentication network. The command includes at least one of the following: a read command, a write command, an activation command, and a deactivation command.

[0558] The second communication unit is configured to receive at least one of the following: the message authentication code, the first freshness value, and the second freshness value.

[0559] The second communication unit is configured to receive a third fresh value and send the third fresh value, wherein the third fresh value is used to calculate the message authentication code.

[0560] The second communication unit is configured to receive a command response, wherein the command response carries a response RES for authenticating the AIoT device.

[0561] The command response also carries a fourth fresh value, which is used to calculate XRES.

[0562] The second communication unit is used to send an inventory request, wherein the inventory request carries second information, which is used by the AIoT device to perform network authentication of the AIoT device.

[0563] The second information includes at least one of the following: the second freshness value, the fifth freshness value, the network-authenticated AIoT device indicator, the inventory and command service indicator, the service association indicator, and the read command, wherein the fifth freshness value is generated by the AIoT F.

[0564] The second communication unit is configured to receive an inventory response, wherein the inventory response carries a response RES for authenticating the AIoT device.

[0565] The inventory response also carries a fourth freshness value, which is used to calculate XRES.

[0566] The second communication unit is used to send the fourth fresh value.

[0567] The second communication unit is used to send the fifth fresh value, wherein the fifth fresh value is used to calculate XRES.

[0568] The second communication unit is used to receive the XRES.

[0569] As shown in Figure 11, the AIoTF further includes a second processing unit 1102, used to authenticate the AIoT device based on the RES and XRES.

[0570] The second communication unit is used to transmit the RES.

[0571] The device in this application embodiment can realize the corresponding functions of the devices in the foregoing authentication method embodiments. The processes, functions, implementation methods, and beneficial effects of each module (sub-module, unit, or component, etc.) in this device can be found in the corresponding descriptions in the above method embodiments, and will not be repeated here. It should be noted that the functions described for each module (sub-module, unit, or component, etc.) in the device of this application embodiment can be implemented by different modules (sub-modules, units, or components, etc.) or by the same module (sub-module, unit, or component, etc.).

[0572] It should be understood that the sequence number of each process in the various embodiments of this application does not imply the order of execution; the execution order of each process should be determined by its function and internal logic. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. The above descriptions are merely specific embodiments of this application, and 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 technical scope 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.

[0573] Figure 12 is a schematic structural diagram of a communication device 1200 according to an embodiment of this application. The communication device 1200 includes a processor 1210, which can call and run computer programs from a memory to enable the communication device 1200 to implement the methods in the embodiments of this application. In one possible implementation, the communication device 1200 may further include a memory 1220. The processor 1210 can call and run computer programs from the memory 1220 to enable the communication device 1200 to implement the methods in the embodiments of this application. The memory 1220 may be a separate device independent of the processor 1210, or it may be integrated into the processor 1210. In one possible implementation, the communication device 1200 may further include a transceiver 1230, which the processor 1210 can control to communicate with other devices. Specifically, it can send information or data to other devices, or receive information or data sent by other devices. The transceiver 1230 may include a transmitter and a receiver. The transceiver 1230 may further include antennas, and the number of antennas may be one or more.

[0574] In one possible implementation, the communication device 1200 may be an AIoT device or AIoT F as described in the embodiments of this application, and the communication device 1200 may implement the corresponding processes implemented by the AIoT device or AIoT F in the various methods of the embodiments of this application. For the sake of brevity, these will not be elaborated here.

[0575] Figure 13 is a schematic structural diagram of a chip 1300 according to an embodiment of this application. The chip 1300 includes a processor 1310, which can call and run computer programs from memory to implement the methods in the embodiments of this application. In one possible implementation, the chip 1300 may further include a memory 1320. The processor 1310 can call and run computer programs from the memory 1320 to implement the methods executed by an AIoT device or AIoT F in the embodiments of this application. The memory 1320 may be a separate device independent of the processor 1310, or it may be integrated into the processor 1310. In one possible implementation, the chip 1300 may further include an input interface 1330. The processor 1310 can control the input interface 1330 to communicate with other devices or chips; specifically, it can acquire information or data sent by other devices or chips. In one possible implementation, the chip 1300 may further include an output interface 1340. The processor 1310 can control the output interface 1340 to communicate with other devices or chips, specifically, it can output information or data to other devices or chips.

[0576] In one possible implementation, the chip can be applied to the AIoT device or AIoT F in the embodiments of this application, and the chip can implement the corresponding processes implemented by the AIoT device or AIoT F in the various methods of the embodiments of this application. For simplicity, it will not be described in detail here. It should be understood that the chip mentioned in the embodiments of this application can also be called a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc. The processor mentioned above can be a general-purpose processor, digital signal processor (DSP), field programmable gate array (FPGA), application-specific integrated circuit (ASIC), or other programmable logic device, transistor logic device, discrete hardware component, etc. Among them, the general-purpose processor mentioned above can be a microprocessor or any conventional processor, etc. The memory mentioned above can be volatile memory or non-volatile memory, or can include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (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). It should be understood that the above-described memory is exemplary but not limiting. For example, the memory in the embodiments of this application can also be static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), and direct memory bus RAM (DR RAM), etc. In other words, the memory in the embodiments of this application is intended to include, but is not limited to, these and any other suitable types of memory.

[0577] In the above embodiments, 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, as a computer program product. This computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another 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 can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The available media can 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)).

[0578] It should be understood that the sequence number of each process in the various embodiments of this application does not imply the order of execution; the execution order of each process should be determined by its function and internal logic. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. The above descriptions are merely specific embodiments of this application, and 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 technical scope 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. An authentication method performed by an environmental Internet of Things (AIoT) device, comprising: A command request is received, wherein the command request carries first information, the first information being used by the AIoT device to perform authentication.

2. The method of claim 1, wherein, The first information includes at least one of the following: a command, a message authentication code for authenticating the network, a first freshness value, a second freshness value, a two-way authentication indicator, an authentication network indicator, a command-only service indicator, an inventory and command service indicator, a service association indicator, and indication information for indicating that the network side stores the result of the AIoT device authentication network. The command includes at least one of the following: a read command, a write command, an activation command, and a deactivation command.

3. The method according to claim 2, further comprising: Based on the first information, it is determined to execute the AIoT device authentication network.

4. The method according to claim 2, further comprising: Based on the first information, it is determined that two-way authentication will be performed.

5. The method according to claim 3 or 4, further comprising: Calculate the message verification code based on the first freshness value.

6. The method according to claim 3 or 4, further comprising: The message verification code is calculated based on the first freshness value and the third freshness value, wherein the third freshness value is generated by the AIoT device.

7. The method according to claim 6, further comprising: Send the third fresh value.

8. The method according to any one of claims 5-7, further comprising: The network is authenticated based on the message verification code and the message authentication code.

9. The method according to claim 3 or 4, further comprising: If the results of the stored authentication network are valid, then the authentication network is considered successful.

10. The method of claim 4, further comprising: Send a command response, wherein the command response carries a response RES for authenticating the AIoT device.

11. The method of claim 10, wherein, The command response also carries a fourth freshness value.

12. The method according to claim 3, further comprising: Receive an inventory request, wherein the inventory request carries second information, the second information being used to perform network authentication of the AIoT device.

13. The method of claim 12, wherein, The second information includes at least one of the following: the second freshness value, the fifth freshness value, the network authentication AIoT device indicator, the inventory and command service indicator, the service association indicator, and the read command.

14. The method of claim 13, further comprising: Based on the second information, it is determined that network authentication of the AIoT device will be performed.

15. The method of claim 14, further comprising: Send an inventory response, wherein the inventory response carries a RES for authenticating the AIoT device.

16. The method according to claim 10 or 15, further comprising: The RES is calculated based on the second freshness value.

17. The method of claim 15, wherein, The inventory response also carries a fourth freshness value.

18. The method according to claim 11 or 17, further comprising: The RES is calculated based on the fourth freshness value, wherein the fourth freshness value is generated by the AIoT device; Alternatively, the RES can be calculated based on the second freshness value and the fourth freshness value.

19. The method of claim 15, further comprising: The RES is calculated based on the fifth freshness value.

20. The method of claim 17, further comprising: The RES is calculated based on the fourth freshness value and the fifth freshness value, wherein the fourth freshness value is generated by the AIoT device.

21. The method of claim 10 or 15, wherein, The RES is pre-stored in the AIoT device.

22. An authentication method performed by AIoT F, comprising: Send a command request, wherein the command request carries first information, the first information being used by the AIoT device to perform authentication.

23. The method of claim 22, wherein, The first information includes at least one of the following: a command, a message authentication code for authenticating the network, a first freshness value, a second freshness value, a two-way authentication indicator, an authentication network indicator, a command-only service indicator, an inventory and command service indicator, a service association indicator, and indication information for indicating that the network side stores the result of the AIoT device authentication network. The command includes at least one of the following: a read command, a write command, an activation command, and a deactivation command.

24. The method of claim 23, further comprising: Receive at least one of the following: the message authentication code, the first freshness value, and the second freshness value.

25. The method according to claim 23 or 24, further comprising: Receive third freshness value; Send the third fresh value, wherein the third fresh value is used to calculate the message authentication code.

26. The method according to any one of claims 23-25, further comprising: Receive a command response, wherein the command response carries a response RES for authenticating the AIoT device.

27. The method of claim 26, wherein, The command response also carries a fourth fresh value, which is used to calculate XRES.

28. The method according to any one of claims 23-25, further comprising: Send an inventory request, wherein the inventory request carries second information, the second information being used by the AIoT device to perform network authentication of the AIoT device.

29. The method of claim 28, wherein, The second information includes at least one of the following: the second freshness value, the fifth freshness value, the network-authenticated AIoT device indicator, the inventory and command service indicator, the service association indicator, and the read command, wherein the fifth freshness value is generated by the AIoT F.

30. The method of claim 29, further comprising: Receive an inventory response, wherein the inventory response carries a response RES for authenticating the AIoT device.

31. The method of claim 30, wherein, The inventory response also carries a fourth freshness value, which is used to calculate XRES.

32. The method according to claim 27 or 31, further comprising: Send the fourth fresh value.

33. The method of claim 30, further comprising: Send the fifth fresh value, wherein the fifth fresh value is used to calculate XRES.

34. The method according to any one of claims 26, 27, 29-33, further comprising: Receive the XRES.

35. The method of claim 34, further comprising: The AIoT device is authenticated based on the RES and XRES.

36. The method according to any one of claims 26, 27, 29-33, further comprising: Send the RES.

37. An AIoT device, comprising: A first communication unit is configured to receive a command request, wherein the command request carries first information, the first information being used by the AIoT device to perform authentication.

38. An AIoT F, comprising: The second communication unit is used to send a command request, wherein the command request carries first information, which is used for the AIoT device to perform authentication.

39. An AIoT device, comprising: A transceiver, a processor, and a memory for storing a computer program, the transceiver for communicating with other devices, and the processor for calling and running the computer program stored in the memory to cause the AIoT device to perform the method as described in any one of claims 1 to 21.

40. An AIoT F, comprising: A transceiver, a processor, and a memory for storing a computer program, the transceiver for communicating with other devices, and the processor for calling and running the computer program stored in the memory to cause the AIoT F to perform the method as described in any one of claims 22 to 36.

41. A chip comprising: A processor for retrieving and running a computer program from memory, causing a device having the chip mounted to perform the method as claimed in any one of claims 1 to 21 or 22 to 36.

42. A computer-readable storage medium for storing a computer program that, when run by a device, causes the device to perform the method as claimed in any one of claims 1 to 21 or 22 to 36.

43. A computer program product comprising computer program instructions that cause a computer to perform the method as claimed in any one of claims 1 to 21 or 22 to 36.

44. A computer program that causes a computer to perform the method as claimed in any one of claims 1 to 21 or 22 to 36.

Images