Authentication method and device

Abstract

The application relates to an authentication method and device. The method comprises the following steps: receiving an inventory request, wherein the inventory request carries first information, the first information is used for an AIoT device to perform authentication, and the first information comprises one or more freshness values.

Description

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 freshness value is received. The freshness value is carried in the inventory request. The inventory request carries first information, which is used by the AIoT device to perform authentication.

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

[0007] Send an inventory request, wherein the inventory request carries first information, the first information being used by the AIoT device to perform authentication, the first information including one or more freshness values.

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

[0009] A first communication unit is configured to receive an inventory request, wherein the inventory request carries first information, the first information being used by the AIoT device to perform authentication, and the first information including one or more freshness values.

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

[0011] The second communication unit is used to send an inventory request, wherein the inventory request carries first information, the first information being used by the AIoT device to perform authentication, and the first information includes one or more freshness values.

[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 inventory request. This allows for AIoT device-related authentication within the network's business interaction process, ensuring AIoT device security while reducing signaling overhead and thus improving authentication efficiency.

[0019] Furthermore, by carrying a message authentication code for network authentication in the inventory request, AIoT devices can authenticate the network before performing subsequent processing, thereby ensuring the security of subsequent processing and reducing signaling overhead caused by authentication, thus improving the efficiency of network authentication on the AIoT device side.

[0020] Furthermore, by including the RES for authenticating AIoT devices in the inventory response, the network side can perform subsequent processing after the AIoT device is successfully authenticated, ensuring the security of the relevant data of the AIoT device obtained by the network side, and reducing the signaling overhead caused by authentication, thereby improving the efficiency of the network side in authenticating AIoT devices. Attached Figure Description

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

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

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

[0024] Figure 4 This 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.

[0025] Figure 5 This is a schematic flowchart of an authentication method for two-way authentication in an inventory-only process according to an embodiment of this application.

[0026] Figure 6 This is a schematic flowchart of an authentication method for one-way authentication under an inventory-only process, according to an embodiment of this application.

[0027] Figure 7 This is a schematic block diagram of an AIoT device according to an embodiment of this application.

[0028] Figure 8 This is a schematic block diagram of an AIoT F according to an embodiment of this application.

[0029] Figure 9 This is a schematic block diagram of a communication device according to an embodiment of this application.

[0030] Figure 10 This is a schematic block diagram of a chip according to an embodiment of this application. Detailed Implementation

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

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

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

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

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

[0036] Figure 1 An exemplary communication system 100 is illustrated. This 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. The access network devices may be base stations of LTE, LTE-A, or NR systems, or 6G radio access networks (RANs). Figure 1 Taking the communication system shown as an example, the communication equipment may include network devices and terminals with communication functions. The communication equipment may also include other devices in the communication system, such as network controllers, mobility management entities and other network entities. This application embodiment does not limit this.

[0037] Figure 2 This is a schematic flowchart illustrating an authentication method according to an embodiment of this application. Figure 2The authentication method is described from the perspective of the interaction between AIoT devices and AIoT Functions (AIoT F), such as... Figure 2 As shown, the authentication method may include the following steps:

[0038] On the AIoT F side, S201 is executed to send an inventory request, wherein the inventory request carries first information, the first information being used by the AIoT device to perform authentication, and the first information includes one or more freshness values.

[0039] S202 is executed on the AIoT device side to receive an inventory request, wherein the inventory request carries first information, the first information being used by the AIoT device to perform authentication, and the first information including one or more freshness values.

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

[0041] The one or more fresh values ​​include a first fresh value and / or a second fresh value. Fresh values ​​can include random numbers or count values, etc., without limitation or exhaustive list. The first fresh value can be used to calculate message authentication codes on the network side and message verification codes on the AIoT device side. The second fresh value is used to calculate XRES on the network side and / or RES on the AIoT device side.

[0042] The first information also includes at least one of the following: a message authentication code for authenticating the network, an authentication type indicator, a service type indicator, and a service association indicator (Correlation ID).

[0043] The authentication type indicator includes at least one of the following: a two-way authentication indicator, an authentication network indicator, and an authentication AIoT device indicator.

[0044] The identifier for the authentication network can also be called the AIoT device authentication network identifier. The identifier for authenticating AIoT devices can also be called the network authentication AIoT device identifier.

[0045] The representation of the two-way authentication indicator, the authentication network indicator, and the authentication AIoT device indicator can be configured according to the actual situation.

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

[0047] Referring to Table 1 as an example, K equals 2, and the different values ​​of the two bits represent the two-way authentication indicator, the authentication network indicator, and the authentication AIoT device indicator, respectively:

[0048]

[0049] Table 1

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

[0051] The business type indicator includes one of the following: Inventory only indicator, Inventory & command indicator.

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

[0053] For example, an inventory indicator alone 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; another example is that an inventory and command 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.

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

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

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

[0057] Taking Table 2 as an example, M equals 2, and different values ​​of the two bits represent the inventory-only indicator, the inventory and command indicator, and the command-only indicator, respectively:

[0058]

[0059] Table 2

[0060] It should be noted that the above are merely exemplary descriptions of the inventory-only indicator, the inventory and command indicator, and the command-only indicator. In actual processing, the above service type indicators may also adopt other representation methods. As long as both AIoT F and AIoT device can identify or determine the same service type through the service type indicator, it is within the protection scope of this embodiment, and 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] Optionally, before sending the inventory request, AIoT F may also include receiving at least one of the following: the message authentication code, the one or more freshness values.

[0063] Optionally, AIoT F may also include receiving XRES (ExpectedResponse) before sending the inventory request.

[0064] In some possible implementations, under the inventory and command flow, authentication includes the AIoT device authentication network, and authentication includes the network authenticating the AIoT device. That is, first information is used for the AIoT device to perform two-way authentication, which includes the AIoT device authentication network and the network authenticating the AIoT device.

[0065] The following is combined Figure 3This section explains the authentication method for two-way authentication under inventory and command processes, specifically including:

[0066] Step 301: The Application Function (AF) sends a service request to the AIoT F. This service request may carry a service type indicator, inventory, and command.

[0067] In some possible examples, the business request can also be replaced by an AF inventory request message.

[0068] Preferably, the business type can indicate inventory count and command (read). This business type may include information indicating inventory count and command, and read commands. That is, the business type is used to indicate the inventory count and command process for this read operation, or to read data through the inventory count and command process.

[0069] This is because the process of reading data from AIoT devices requires, on the one hand, that the AIoT device trusts the network, and only when the network is confirmed to be trustworthy will it perform the data reading operation and report the data. 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 flow provided in this embodiment is particularly suitable for data reading scenarios.

[0070] 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 deactivation or permanent deactivation) according to actual needs. For example, this business type can be replaced with an instruction to inventory and a command (write), or the business type can be replaced with an instruction to inventory and a command (deactivation), etc. No limit or exhaustive list is made here.

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

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

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

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

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

[0076] 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 302; if the authentication parameters are stored, it proceeds to step 306.

[0077] In one embodiment, the service request may carry the service type and the identifier of the AIoT device.

[0078] In addition to carrying the service type and the identifier of the AIoT device, the service request may or may not carry a single-transmission instruction; there is no limitation on this.

[0079] In this embodiment, 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 302 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 306 is executed directly.

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

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

[0082] In one embodiment, the service request may carry service type and group identification information.

[0083] In addition to carrying the service type and group identification information, the service request may or may not carry a mass sending instruction; there is no limitation here.

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

[0085] The processing performed for each AIoT device is the same as in the aforementioned embodiments, so it will not be described again.

[0086] In a group scenario, since the subsequent processing flow is the same for each AIoT device, step 302 and the steps thereafter in this embodiment are applicable to the two-way authentication process of an AIoT device, and are also applicable to each AIoT device in the group. Therefore, the two-way authentication process of each AIoT device in the group scenario will not be described in detail.

[0087] Step 302, AIoT F sends an authentication vector request.

[0088] Specifically, AIoT F sends an authentication vector request to ADM (Ambient IoT Data Management) to request authentication parameters. The authentication vector request may carry the identifier of the AIoT device.

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

[0090] There are no restrictions on how ADM generates the first fresh value. The first fresh value can be the first random number or the first count value, etc., and there are no restrictions here either.

[0091] In one embodiment, on the ADM side, calculating the message authentication code based on the first freshness value may 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 a first algorithm.

[0092] The first algorithm can be pre-configured, and may include at least one of the following: KDF (Keyderivation 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.

[0093] The root key of an AIoT device can be pre-stored in an ADM (Automatic Device Manager). For example, the ADM can pre-associate and store the AIoT device's identifier and root key locally.

[0094] For example, the ADM computed message authentication code can be represented as: function1(K, RAND1, Device ID), where function1() represents the first algorithm, K represents the root key of the AIoT device, RAND1 represents the first fresh value, and DeviceID represents the identifier of the AIoT device.

[0095] In one embodiment, on the ADM side, calculating the message authentication code based on the first freshness value may include: calculating the AK (Anonymity Key) based on the root key of the AIoT device and the first freshness value using a second algorithm, and calculating the message authentication code based on the AK and the identifier of the AIoT device using a third algorithm.

[0096] The process of calculating the message authentication code based on the identifiers of the AK and AIoT device using the third algorithm can include: directly calculating the message authentication code based on the identifiers of the AK and AIoT device using the third algorithm; or, calculating the message authentication code based on the root key of the AK, the AIoT device, and the identifier of the AIoT device using the third algorithm.

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

[0098] For example, the ADM calculation message authentication code can be represented as: AK = function2(K, RAND1), message authentication code = function3(AK, K, Device ID). Here, function2() represents the second algorithm, function3() represents the third algorithm, and the meanings of the other parameters are the same as in the previous example, and will not be repeated.

[0099] Step 304: ADM generates a second freshness value and calculates XRES based on the second freshness value.

[0100] There are no restrictions on how ADM generates the second fresh value. The second fresh value can be a second random number or a second count value, etc., which are also not limited here.

[0101] The second freshness value may be the same as or different from the first freshness value.

[0102] In one embodiment, on the ADM side, 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 a fourth algorithm.

[0103] The fourth algorithm can be pre-configured, and for example, the fourth algorithm includes at least one of the following: KDF, key derivation function, f1~f5 function, etc.

[0104] The fourth algorithm may be the same as or different from the first algorithm.

[0105] In one scenario, the first freshness value is the same as the second freshness value, and ADM calculates 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 first algorithm.

[0106] In this case, 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.

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

[0108] For example, the ADM calculation of XRES can be expressed as: XRES = function4(K, RAND2, Device ID), where function4() represents the fourth 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.

[0109] 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 the AK and the identifier of the AIoT device using a fifth algorithm.

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

[0111] The description of the second algorithm is the same as that of the aforementioned embodiments, and will not be repeated.

[0112] The fifth algorithm is pre-configured. For example, the fifth algorithm may include at least one of the following: KDF, key derivation function, f1~f5 function, hash algorithm, AES, ACSON, SNOW 3G, ZUC, XOR calculation, direct connection calculation, etc.

[0113] The fifth algorithm may be the same as or different from the third algorithm.

[0114] In one scenario, the first freshness value is the same as the second freshness value, and ADM calculates the AK based on the root key of the AIoT device and the second freshness value using the second algorithm, and calculates the message authentication code based on the AK and the identifier of the AIoT device using the third algorithm.

[0115] In this case, the fifth algorithm is different from the third algorithm. For example, the third algorithm is the f1 function or AES, while the fifth algorithm is the f2 function, etc. This is not limited or exhaustive.

[0116] For example, the ADM calculation of XRES can be represented as: AK = function2(K, RAND1), XRES = function5(AK, K, Device ID). Here, function5() represents the fifth algorithm; RAND1 is the first fresh value, that is, the first fresh value and the second fresh value are the same, and the first fresh value is used in this example; the meanings of the other parameters are the same as in the previous example, and will not be repeated.

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

[0118] For example, the ADM calculation of XRES can be represented as: AK = function2(K, RAND2), XRES = function5(AK, K, Device ID). Here, function5() represents the fifth algorithm, and the meanings of the other parameters are the same as in the previous example, and will not be repeated.

[0119] It should also be noted that the execution order of steps 303 and 304 is not important. For example, ADM can execute step 303 first and then step 304, or it can execute step 304 first and then step 303. This embodiment does not limit this.

[0120] Step 305: ADM returns authentication parameters to AIoT F. Specifically, ADM sends an authentication vector response to AIoT F; correspondingly, AIoT F receives the authentication vector response. The authentication vector response may carry authentication parameters.

[0121] Optionally, the authentication parameters include a message authentication code, XRES, a first freshness value, and a second freshness value. After receiving the authentication vector response, AIoT F can save the XRES locally.

[0122] Optionally, the authentication parameters include the message authentication code, the first freshness value, and the second freshness value, meaning that ADM may not return XRES to AIoT F.

[0123] Furthermore, the authentication vector response can also carry the identifier of the AIoT device.

[0124] It should be noted that the first fresh value and the second fresh value may be the same or different. If the first fresh value and the second fresh value are different, ADM can return two fresh values ​​to AIoT F. Alternatively, if the first fresh value and the second fresh value are the same, ADM can return two identical fresh values ​​to AIoT F, or it can return only one fresh value (for example, it can only return the first fresh value).

[0125] Step 306: AIoT F sends an inventory request, wherein the inventory request carries first information, which is used by the AIoT device to perform authentication. In this embodiment, authentication may refer to two-way authentication.

[0126] Specifically, AIoT F sends an inventory request carrying the first information to the Reader.

[0127] The reader / writer may include access network equipment or terminal (UE), and may also be called a reading and writing device, etc., without limitation or exhaustive list.

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

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

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

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

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

[0133] It should be noted that the first freshness value and the second freshness value may be the same or different. If the first freshness value and the second freshness value are the same, both identical freshness values ​​may be included in the first information.

[0134] In one embodiment, the first information may include: a message authentication code, one or more fresh values, wherein the one or more fresh values ​​include a first fresh value and / or a second fresh value; and the first information may also include at least one of the following: an authentication type indicator, a service type indicator, and a service association indicator.

[0135] In some possible embodiments, the first information may further include a read command. For example, the first information may include a read command, and the first information may include a message authentication code, a first freshness value, and a second freshness value. Further, the first information may also include at least one of an authentication type indicator, a service type indicator, and a service association indicator.

[0136] The authentication type indicator in the first information can be a two-way authentication indicator; or, the authentication type indicator in the first information can include: an indicator for authenticating the network, or an indicator for authenticating the AIoT device.

[0137] The business type indicator is specifically the inventory and command indicator.

[0138] Business association indicators correspond to inventory and command businesses.

[0139] It should be noted that the first freshness value and the second freshness value may be the same or different.

[0140] If the first freshness value and the second freshness value are different, then the first information needs to include two freshness values, namely the first freshness value and the second freshness value.

[0141] If the first fresh value and the second fresh value are the same, the first information can include one fresh value or two identical fresh values. This is because AIoT devices can determine which type of authentication needs to be performed by at least one of the authentication type indicator, service type indicator, and service association indicator, so there is no limit to the number of fresh values.

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

[0143] Specifically, the Reader sends a paging message carrying an inventory request to the AIoT device.

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

[0145] Optionally, AIoT F sends a request message to the Reader carrying the service type and inventory request. This inventory request can be carried or encapsulated in a NAS container, and it carries initial 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 request message locally and send the inventory request (i.e., the NAS container) from the request message to the AIoT device in the paging message.

[0146] Optionally, the inventory request sent by AIoT F to the Reader is a first inventory 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 inventory request carried in the paging message sent to the AIoT device only includes the first information and the identifier of the AIoT device.

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

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

[0149] An AIoT device determines that two-way authentication needs to be performed based on the first information, which may include one of the following: if the first information includes two fresh values, it determines that two-way authentication needs to be performed; if the first information includes a message authentication code and the first information includes two fresh values, it determines that two-way authentication needs to be performed.

[0150] In one embodiment, the first information may include: a message authentication code, one or more fresh values, wherein the one or more fresh values ​​include a first fresh value and / or a second fresh value. Furthermore, the first information may also include at least one of the following: an authentication type indicator, a service type indicator, and a service association indicator.

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

[0152] Optionally, 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. For example, if the first information includes a two-way authentication indicator and a message authentication code, it is determined that two-way authentication needs to be performed; or, if the first information includes a two-way authentication indicator, a message authentication code, and two fresh values ​​(or the number of fresh values ​​included in the first information is two), it is determined that two-way authentication needs to be performed. This is not a limitation or an exhaustive list.

[0153] Optionally, if the first information includes an indicator for the authentication network and an indicator for authenticating the AIoT device, the AIoT device determines that it needs to perform the authentication of the AIoT device network and that it needs to perform network authentication of the AIoT device, that is, it determines that it needs to perform two-way authentication.

[0154] Optionally, if the first information includes an indicator of the authentication network and an indicator for authenticating the AIoT device, and a message authentication code, the AIoT device determines that two-way authentication needs to be performed.

[0155] Optionally, if the first information includes an indicator of the authentication network and an indicator for authenticating the AIoT device, a message authentication code, and two fresh values ​​(or the number of fresh values ​​included in the first information is two), the AIoT device determines that two-way authentication needs to be performed. No limit or exhaustive list is provided here.

[0156] Optionally, the AIoT device determines that two-way authentication is required if the first information includes inventory and command indicators.

[0157] Optionally, if the first information includes inventory and command indicator, and message authentication code, it is determined that two-way authentication needs to be performed; or, if the first information includes inventory and command indicator, message authentication code, and two freshness values, it is determined that two-way authentication needs to be performed.

[0158] Optionally, if the first information includes a business association indicator corresponding to the inventory and command business, the AIoT device determines that two-way authentication needs to be performed.

[0159] Optionally, if the first information includes a business association indicator and a message authentication code corresponding to the inventory and command services, the AIoT device determines that two-way authentication needs to be performed.

[0160] Optionally, if the first information includes a business association indicator corresponding to the inventory and command services, a message authentication code, and two freshness values, the AIoT device determines that two-way authentication needs to be performed.

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

[0162] Optionally, the AIoT device may determine that two-way authentication needs to be performed if the first information includes an inventory and command indicator, an indicator for the authentication network, and an indicator for authenticating the AIoT device.

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

[0164] In some possible embodiments, the first information may further include a read command. For example, the first information may include a read command, and the first information may include a message authentication code, a first freshness value, and a second freshness value. Further, the first information may also include at least one of an authentication type indicator, a service type indicator, and a service association indicator.

[0165] For example, if the first information includes a read command, the AIoT device determines that two-way authentication needs to be performed. Alternatively, if the first information includes both a read command and a message authentication code, the AIoT device determines that two-way authentication needs to be performed. The processing for the first information including a read command, and the AIoT device determining whether to perform two-way authentication based on the read command, is similar to the previous embodiments. The only difference is that in this embodiment, the AIoT device can determine whether to perform two-way authentication based solely on the read command, or combine the read command with at least one of the other contents in the first information to determine whether to perform two-way authentication. This is not exhaustive.

[0166] It should be noted that the above is merely an illustrative example and does not limit or exhaust all possible scenarios 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.

[0167] In this way, AIoT devices can determine the need for two-way authentication based on one or more fresh values ​​in the first information, allowing them to determine authentication requirements with only a limited amount of information. Alternatively, AIoT devices can determine the need for two-way authentication based on at least one of the message authentication code, various indicators, and one or more fresh values ​​in the first information, thus enabling a more flexible approach to authentication. These methods provide solutions for how AIoT devices determine authentication and the specific type of authentication to be performed during inventory and command processes.

[0168] The one or more fresh values ​​include a first fresh value. The processing performed by the AIoT device further includes step 309, calculating a message verification code based on the first fresh value; and authenticating the network based on the message verification code and the message authentication code.

[0169] The specific method by which the AIoT device calculates the message verification code should be the same as the method for calculating the message authentication code in step 303, therefore, it will not be repeated. It should be noted that the algorithms pre-configured on the AIoT device and the network side (such as ADM) should be the same. For example, the AIoT device and the network side (ADM) should be configured with at least one of the first algorithm, the second algorithm, and the third algorithm.

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

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

[0172] In the event of an AIoT device authentication network failure, subsequent steps may be omitted (process terminated) and / or a message indicating the authentication network failure may be sent. This message can be sent to the AIoT F via a Reader.

[0173] Accordingly, after receiving a message indicating network authentication failure on the AIoT F side, at least one of the following can be executed: return to step 302 to request ADM to recalculate authentication parameters; return to step 306 to resend the inventory request; send a notification to AF that the AIoT device's network authentication has failed; or terminate the process. This document does not limit or exhaustively list all possible actions that the AIoT device or AIoT F may perform when the AIoT device's network authentication fails.

[0174] Step 310: The AIoT device calculates RES.

[0175] In one embodiment, the one or more fresh values ​​include a second fresh value; the processing performed by the AIoT device further includes calculating RES (Response) based on the second fresh value.

[0176] In this embodiment, the specific method by which the AIoT device calculates RES should be the same as the specific method by which XRES is calculated in step 304, and therefore will not be repeated. It should be noted that the algorithms pre-configured on the AIoT device and the network side (such as ADM) should be the same, for example, the AIoT device and the network side (ADM) should be configured with at least one of the same second algorithm, fourth algorithm and fifth algorithm.

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

[0178] This embodiment does not limit the method by which the AIoT device generates the third fresh value. The third fresh value can be a third random number or a third count value. As long as the third 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.

[0179] In one example, the AIoT device calculates RES based on a second freshness value and a third freshness value.

[0180] Optionally, the AIoT device calculates RES' based on the second freshness value; and calculates RES based on the third freshness value and RES'.

[0181] The method for calculating RES' based on the second freshness value is the same as the method for calculating XRES in step 304, and will not be repeated here.

[0182] RES can be calculated based on the third freshness value and RES', which may include: calculating RES based on the third freshness value, RES', the identifier of the AIoT device, and AK using the sixth algorithm.

[0183] The calculation method of AK can be the same as that of step 304 above. For example, AK can be calculated based on the root key and the second fresh value of the AIoT device using the second algorithm, and can be expressed as AK=function2(K, RAND2).

[0184] The sixth algorithm is pre-configured on the AIoT device side. For example, the sixth algorithm may include at least one of the following: KDF, key derivation function, f1~f5 function, hash algorithm, AES, ACSON, SNOW 3G, ZUC, XOR calculation, direct connection calculation, etc.

[0185] For example, the calculation of RES by an AIoT device can be represented as: RES = function6(RES', Device ID, NONCE, AK), where function6() represents the sixth algorithm, NONCE represents the third fresh value generated by the AIoT device, and the meanings of the other parameters are the same as those described above, and will not be repeated.

[0186] Optionally, the AIoT device calculates AK based on the root key and the second fresh value of the AIoT device using the second algorithm; and calculates RES based on the third fresh value, the identifier of the AIoT device, and AK using the sixth algorithm.

[0187] For example, the calculation of RES for an AIoT device can be represented as: AK=function2(K, RAND2), RES=function6(NONCE, Device ID, AK), where the meaning of each parameter is the same as in the previous example and will not be repeated.

[0188] In one example, the AIoT device calculates RES based on a third freshness value. Specifically, this can include calculating RES using the AIoT device's root key, the AIoT device's identifier, and the third freshness value based on a sixth algorithm.

[0189] For example, the calculation of RES by an AIoT device can be represented as: RES = function6(K, NONCE, Device ID), where the meaning of each parameter is the same as in the previous example and will not be repeated.

[0190] It should be noted that the above is only an exemplary description of how AIoT devices use a third freshness value to calculate RES. Other methods may also be included in actual processing, which are not limited or exhaustive here.

[0191] Step 311, the AIoT device sends an inventory response, wherein the inventory response carries RES for authenticating the AIoT device.

[0192] Specifically, step 311 can be for the AIoT device to send an inventory response to the Reader.

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

[0194] Optionally, if the AIoT device uses its own generated third fresh value when calculating RES in step 310, then the inventory response also carries the third fresh value. That is, the inventory response needs to carry both RES and the third fresh value.

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

[0196] Step 312, the Reader sends an inventory response.

[0197] Specifically, step 312 includes the Reader sending an inventory response to the AIoT F. Correspondingly, the AIoT F receives the inventory response, wherein the inventory response carries a response RES for authenticating the AIoT device.

[0198] Step 313: AIoT F receives the inventory response and confirms that the AIoT device has successfully authenticated the network (or has successfully authenticated the network).

[0199] Specifically, AIoT F receives the inventory response; upon receiving the inventory response, it determines that the AIoT device authentication network has been successful.

[0200] It should be noted that while the inventory response can be used by AIoT F to determine that the AIoT device has successfully authenticated with the network, it does not mean that the inventory response must or necessarily carry information indicating successful network authentication. Rather, it indicates that sending the inventory response enables AIoT F to determine 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 an inventory response, it indicates that the AIoT device has successfully authenticated with the network; correspondingly, as long as AIoT F receives the inventory response, it can determine that the AIoT device has successfully authenticated with the network. This embodiment does not limit whether the inventory response needs to carry additional information indicating successful network authentication.

[0201] After completing step 313, AIoT F may employ one of the following processing methods provided in the embodiments to implement or perform network-side authentication of AIoT devices, which are described below:

[0202] In one embodiment, in step 314, AIoT F authenticates the AIoT device based on the RES and XRES.

[0203] Specifically, in step 305, the authentication vector response returned by ADM to AIoT F carries authentication parameters including XRES; and in step 313, the inventory response received by AIoT F does not carry a third freshness value. In this case, AIoT F performs step 314, authenticating the AIoT device based on the RES and XRES.

[0204] Specifically, authenticating the AIoT device based on the RES and XRES may include: 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.

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

[0206] The processing performed by AIoT F also includes: sending the RES; and receiving the authentication result for the AIoT device.

[0207] Specifically, AIoT F sends RES and the identifier of the AIoT device to ADM, and receives the authentication result of the AIoT device from ADM. The authentication result includes: successful authentication of the AIoT device or failure to authenticate the AIoT device.

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

[0209] In one embodiment, the inventory response received by AIoT F in step 313 also carries a third freshness value, wherein the third freshness value is used to calculate XRES. The processing performed by AIoT F further includes: sending the RES; and receiving the authentication result for the AIoT device. Furthermore, the processing by AIoT F also includes: sending the third freshness value.

[0210] Specifically, AIoT F sends RES, the third freshness value, and the identifier of the AIoT device to ADM, and receives the authentication result of the AIoT device from ADM. The authentication result includes: successful authentication of the AIoT device or failure to authenticate the AIoT device.

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

[0212] The specific processing method for calculating XRES based on the third freshness value on the ADM side should be the same as the processing method for calculating RES based on the third freshness value by the AIoT device in step 310 above, so it will not be described again.

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

[0214] Optionally, if the ADM has already calculated the XRES in step 304, the ADM can discard or delete the XRES calculated in step 304 and use the XRES calculated based on the third fresh value to authenticate the AIoT device.

[0215] Optionally, ADM may skip step 304 and instead perform the process of calculating XRES based on the third freshness value after receiving the third freshness value and RES from AIoT F.

[0216] In one embodiment, the inventory response received by AIoT F in step 313 carries a third fresh value. The processing performed by AIoT F further includes: sending the third fresh value, wherein the third fresh value is used by the ADM to calculate XRES. Furthermore, the processing after AIoT F sends the third fresh value may further include: receiving XRES. The processing after AIoT F receives XRES may include: authenticating the AIoT device based on the RES and XRES.

[0217] Specifically, AIoT F sends a third fresh value and the identifier of the AIoT device to ADM, and receives XRES from ADM; based on the RES and XRES, it authenticates the AIoT device.

[0218] The ADM's processing may include: receiving the third freshness value and the identifier of the AIoT device from the AIoT F; calculating XRES based on the third freshness value; and sending XRES to the AIoT F.

[0219] The specific processing method for calculating XRES based on the third freshness value on the ADM side should be the same as the processing method for calculating RES based on the third freshness value by the AIoT device in step 310 above, so it will not be described again.

[0220] The authentication process for the AIoT device based on RES and XRES is the same as in the previous embodiments and will not be described in detail here.

[0221] Optionally, if ADM has already calculated XRES in step 304, ADM can discard or delete the XRES calculated in step 304 and calculate XRES based on the third fresh value.

[0222] Optionally, ADM may skip step 304 and instead perform the process of calculating XRES based on the third fresh value after receiving the third fresh value from AIoT F.

[0223] In one embodiment, the inventory response received by AIoT F in step 313 carries a third freshness value. The processing performed by AIoT F further includes calculating the XRES based on the third freshness value. Furthermore, the processing by AIoT F further includes authenticating the AIoT device based on the RES and XRES.

[0224] In this embodiment, the process by which AIoT F calculates XRES based on the third freshness value should be the same as the process by which the AIoT device calculates RES based on the third freshness value in step 310, and therefore will not be repeated. It should be noted that AIoT F may not have stored the root key of the AIoT device, so AIoT F may request and obtain the root key of the AIoT device from ADM, which is not limited or exhaustive here.

[0225] The authentication process for the AIoT device based on RES and XRES is the same as in the previous embodiments and will not be described in detail here.

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

[0227] If the AIoT device is successfully certified or passes the certification process, AIoT F executes step 315.

[0228] In the event of failure or failure to authenticate an AIoT device, AIoT F may perform at least one of the following actions: return to step 302 to request ADM to recalculate the authentication parameters; return to step 306 to resend the inventory request; 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 possible actions that AIoT F may perform when AIoT device authentication fails.

[0229] Step 315, AIoT F sends a command request, wherein the command request carries at least one of the following: read command, write command, activation command, and deactivation command.

[0230] Specifically, AIoT F sends a command request to the Reader.

[0231] Step 316: The Reader sends a command request.

[0232] Specifically, the Reader sends command requests to the AIoT device.

[0233] Step 317: The AIoT device receives a command request and confirms that the network has successfully authenticated the AIoT device (or the network has successfully authenticated or passed the AIoT device authentication).

[0234] Specifically, the AIoT device receives a command request, wherein the command request carries at least one of the following: a read command, a write command, an activation command, or a deactivation command. Upon receiving the command request, it is determined that the network has successfully authenticated the AIoT device.

[0235] It should be noted that the command request can be used by the AIoT device to determine that the network has successfully authenticated the AIoT device. This does not mean that the command request carries information indicating successful network authentication of the AIoT device. Rather, it indicates that sending the command request enables the AIoT device to determine that the network has successfully authenticated the AIoT device. In other words, as long as the AIoT device performs the action or processing of sending the command request, it indicates that the network has successfully authenticated the AIoT device. Correspondingly, as long as the AIoT device receives the command request, it can determine that the network authentication itself has been successful. This embodiment does not limit whether the command request needs to additionally carry information indicating successful network authentication of the AIoT device.

[0236] Step 318: The AIoT device sends a command response.

[0237] 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 315, the command request issued by the AIoT AF carries a read command, and in step 316, the command request sent by the Reader to the AIoT device carries a read command.

[0238] Accordingly, in step 318, the processing of the AIoT device can be as follows: the AIoT device has successfully authenticated the network and determined that the network has successfully authenticated itself, so the AIoT device reads data based on the read command and sends a command response (carrying data) to the Reader.

[0239] Further, in step 319, the Reader sends the data to the AIoT F. Specifically, the Reader can send a command response (carrying data) to the AIoT F.

[0240] Step 320: AIoT F sends the data to AF.

[0241] 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 315, the command request issued by the AIoT AF carries a write command, and in step 316, the command request sent by the Reader to the AIoT device carries a write command.

[0242] Accordingly, in step 318, the AIoT device can process the following: the AIoT device has successfully authenticated the network and determined that the network has successfully authenticated itself, so the AIoT device can write data based on the write command and send a command response.

[0243] Specifically, step 318 can be: the AIoT device can send a command response to the Reader (without carrying data).

[0244] Further, in step 319, the Reader sends a command response (without carrying data) to the AIoT F. After receiving the command response, the AIoT F can end the processing.

[0245] In one possible embodiment, in step 301, the service type indication in the service request sent by the AF is an inventory and a command (deactivation (temporary deactivation or permanent deactivation)). Accordingly, the command requests in steps 315 and 316 carry a deactivation command (temporary deactivation command or permanent deactivation command).

[0246] In step 318, the AIoT device has successfully authenticated the network and confirmed that the network has successfully authenticated itself. The AIoT device can send a command response and then perform 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).

[0247] Step 319 allows the Reader to send a command response to the AIoT F. After receiving the command response, the AIoT F can end the process.

[0248] In one possible embodiment, in step 301, the service type in the service request sent by the AF indicates inventory and command (activation). Accordingly, the command requests in steps 315 and 316 carry an activation command.

[0249] In step 318, the AIoT device has successfully authenticated the network and confirmed that the network has successfully authenticated itself. Therefore, the AIoT device can perform activation operations (such as enabling radio frequency functions or capabilities) based on the activation command and send a command response.

[0250] Step 319 allows the Reader to send a command response to the AIoT F. After receiving the command response, the AIoT F can end the process.

[0251] This section will not limit or exhaustively list all possible processing options for AIoT devices and AIoT F under all possible command types.

[0252] By adopting the above implementation method, in the inventory and command process, the first information carried in the inventory request enables the AIoT device to determine whether to perform two-way authentication processing, namely, AIoT device authentication network authentication and network authentication of AIoT devices. Specifically, the AIoT device can determine whether to perform two-way authentication based on the number of fresh values ​​(or the number of fresh values ​​and message authentication codes) included in the first information; or, the AIoT device can determine whether to perform two-way authentication based on indicators (at least one of service type indicator, authentication type indicator, and service association indicator) included in the first information. This provides a solution for how the AIoT device determines whether to perform two-way authentication in the inventory and command process. Furthermore, by carrying the message authentication code for network authentication in the inventory request and the RES for AIoT device authentication in the inventory response, 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. This also reduces the signaling overhead caused by authentication, thereby improving the efficiency of both AIoT device authentication of the network and network authentication of AIoT devices.

[0253] In some possible implementations, under the inventory and command flow, authentication includes the AIoT device authentication network. That is, the first information is used for the AIoT device to perform one-way authentication, which is the AIoT device authentication network.

[0254] The following is combined Figure 4 This section explains the authentication method for one-way authentication under inventory and command processes, specifically including:

[0255] Step 401: AF sends a service request to AIoT F. This service request may carry a service type indicator, inventory, and command.

[0256] In some possible examples, the business request can also be replaced by an AF inventory request message.

[0257] Preferably, the business type can indicate inventory count and command (write). This business type may include information indicating inventory count and command, and write commands. That is, the business type is used to indicate the inventory count and command process for this write operation, or to read data through the inventory count and command process.

[0258] It should be noted that the above are merely preferred exemplary descriptions and are not intended to limit this embodiment. The one-way authentication method under the inventory and command flow provided in this embodiment can also be used for activation or deactivation (including temporary or permanent deactivation) according to actual needs. For example, this business type can be replaced with an instruction for inventory and command (deactivation or activation). In some possible cases, the solution provided in this embodiment can also be used for read operations, which is not limited or exhaustive here.

[0259] 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), or group transmission (or group transmission indication). The relevant descriptions of the AIoT device identifier, group identification information, number of devices, single transmission (or single transmission indication), and group transmission (or group transmission indication) are the same as those in the foregoing embodiments and will not be repeated.

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

[0261] The explanation regarding whether subsequent processing is performed on a single AIoT device or on each of multiple AIoT devices is the same as in the aforementioned embodiments and will not be repeated here.

[0262] Step 402: AIoT F sends an authentication vector request to ADM to request authentication parameters. The authentication vector request may carry the identifier of the AIoT device.

[0263] Step 403: ADM generates a first fresh value and calculates the message authentication code based on the first fresh value. The specific processing method of ADM in calculating the message authentication code is the same as step 303 in the previous embodiment, and will not be described again.

[0264] Optionally, in addition to carrying the identifier of the AIoT device, the authentication vector request may also carry information instructing the ADM to only calculate the message authentication code. Accordingly, the ADM may only perform step 403 to calculate the message authentication code.

[0265] Optionally, the authentication vector request may carry the identifier of the AIoT device. Accordingly, the ADM can perform step 403 to calculate the message authentication code. In this case, it is not limited whether the ADM performs the calculation of RES.

[0266] Step 404: ADM returns authentication parameters to AIoT F. Specifically, ADM sends an authentication vector response to AIoT F; correspondingly, AIoT F receives the authentication vector response. The authentication vector response may carry authentication parameters, including a message authentication code and a first freshness value. Furthermore, the authentication vector response may also carry the identifier of the AIoT device.

[0267] Step 405, AIoT F sends an inventory request, wherein the inventory request carries first information, the first information being used for AIoT devices to perform authentication, the authentication including the AIoT device authentication network.

[0268] Specifically, step 405 includes: AIoT F sending an inventory request carrying first information to the Reader.

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

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

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

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

[0273] In one embodiment, the first information may include only: message authentication code and first freshness value.

[0274] In one embodiment, the first information may include: a message authentication code and a first freshness value; and the first information may also include at least one of the following: an authentication type indicator, a service type indicator, and a service association indicator.

[0275] Preferably, the first information includes an authentication type indicator, and the authentication type indicator is an indicator of the authentication network.

[0276] Optionally, the first information may include an authentication type indicator and a business type indicator, specifically an inventory and command indicator.

[0277] Optionally, the first information may include an authentication type indicator and a business association indicator, which corresponds to the inventory and command business.

[0278] Optionally, the first information may include an authentication type indicator, a business type indicator, and a business association indicator, wherein the business type indicator is specifically an inventory and command indicator, and the business association indicator corresponds to the inventory and command business.

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

[0280] Specifically, step 406 includes: the Reader sending a paging message carrying an inventory request to the AIoT device.

[0281] The inventory request sent by the Reader to the AIoT device can carry initial information and the AIoT device's identifier. The description of the Reader sending a paging message carrying the inventory request to the AIoT device is similar to that of step 307 in the aforementioned embodiments, and therefore will not be repeated.

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

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

[0284] The processing of AIoT devices can be as follows: if the number of fresh values ​​included in the first information is one, it is determined that an AIoT device authentication network is required; if the first information includes a message authentication code and the number of fresh values ​​included in the first information is one, it is determined that an AIoT device authentication network is required.

[0285] In one embodiment, the first information may include: a message authentication code and a first freshness value. Furthermore, the first information may also include at least one of the following: an authentication type indicator, a service type indicator, and a service association indicator.

[0286] In one example, the first information includes an indicator of the authentication network.

[0287] Alternatively, the processing of the AIoT device can be as follows: if the first information includes an indicator of the authentication network, determine that the AIoT device needs to authenticate the network.

[0288] Optionally, 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. For example, if the first information includes an indicator of the authentication network and also includes a message authentication code, it is determined that the AIoT device needs to authenticate the network; or, if the first information includes an indicator of the authentication network, a message authentication code, and a fresh value (or the number of fresh values ​​included in the first information is one), it is determined that the AIoT device needs to authenticate the network. This is not a limitation or an exhaustive list.

[0289] In one example, the first information may include at least two of the above types of indicators.

[0290] For example, the first information includes an indicator of the authentication network, an inventory indicator, and a command indicator. An AIoT device can determine which AIoT device authentication network is required if the first information includes the inventory indicator, the command indicator, and the authentication network indicator.

[0291] For example, the first information includes an indicator for the authentication network and a service association indicator corresponding to the inventory and command services. If the first information includes the service association indicator corresponding to the inventory and command services and the authentication network indicator, the AIoT device can determine which AIoT device authentication network is required.

[0292] For example, the first information includes an indicator for the authentication network, an inventory and command indicator, and a service association indicator corresponding to the inventory and command service. If the first information includes the service association indicator corresponding to the inventory and command service, the inventory and command indicator, and the authentication network indicator, the AIoT device can determine which AIoT device authentication network is required.

[0293] In this example, the AIoT device can also further combine the number of fresh values ​​in the first information and / or the message authentication code to determine whether the AIoT device needs to authenticate the network, which will not be elaborated here.

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

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

[0296] Step 408: 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.

[0297] The specific processing of step 408 is the same as that of step 309 in the aforementioned embodiment, and will not be repeated.

[0298] Furthermore, if the AIoT device authentication network is successful, step 409 can be executed.

[0299] In the event of an AIoT device authentication network failure, subsequent steps may be omitted (processing terminated) and / or a message indicating authentication network failure may be sent. This message can be sent to the AIoT F via a Reader. Correspondingly, the processing that can be performed on the AIoT F side after receiving the authentication network failure message is the same as in the aforementioned embodiments and will not be repeated here.

[0300] Step 409: The AIoT device sends an inventory response.

[0301] Specifically, step 409 allows the AIoT device to send an inventory response to the Reader. The inventory response may carry other content specified in the protocol, such as the identifier of the AIoT device, etc., which are not limited or exhaustively listed here.

[0302] Step 410: The Reader sends an inventory response.

[0303] Specifically, step 410 includes the Reader sending an inventory response to the AIoT F. Correspondingly, the AIoT F receives the inventory response.

[0304] Step 411: AIoT F receives the inventory response and confirms that the AIoT device has successfully authenticated the network (or successfully authenticated the network).

[0305] It should be noted that the inventory response can be used by AIoT F to determine that the AIoT device has successfully authenticated the network. This does not mean that the inventory response must or will necessarily carry information indicating that the AIoT device has successfully authenticated the network. Rather, it means that by sending the inventory response, AIoT F can determine or confirm that the AIoT device has successfully authenticated the network. This will not be elaborated on here.

[0306] Step 412, AIoT F sends a command request to the Reader, wherein the command request carries at least one of the following: read command, write command, activation command, and deactivation command.

[0307] Step 413: The Reader sends a command request to the AIoT device.

[0308] Step 414: The AIoT device sends a command response.

[0309] In a preferred embodiment, in step 401, the service type in the service request sent by the AF indicates inventory and command (write). In step 412, the command request issued by the AIoT AF carries a write command, and in step 413, the command request sent by the Reader to the AIoT device carries a write command.

[0310] Accordingly, in step 414, the AIoT device can process the following: the AIoT device has successfully authenticated the network, so the AIoT device can write data based on the write command, and the AIoT device can send a command response (without carrying data) to the Reader.

[0311] Further, in step 415, the Reader sends a command response (without carrying data) to the AIoT F. After receiving the command response, the AIoT F can end the processing.

[0312] In one possible embodiment, in step 401, the service type indication in the service request sent by the AF is an inventory and a command (deactivation (temporary deactivation or permanent deactivation)). Accordingly, the command requests in steps 412 and 413 carry a deactivation command (temporary deactivation command or permanent deactivation command).

[0313] In step 414, the AIoT device has successfully authenticated the network. The AIoT device can send a command response to the Reader and then perform 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).

[0314] Step 415 allows the Reader to send a command response to the AIoT F. After receiving the command response, the AIoT F can end the process.

[0315] In one possible embodiment, in step 401, the service type in the service request sent by the AF indicates inventory and command (activation). Accordingly, the command requests in steps 412 and 413 carry an activation command.

[0316] In step 414, the AIoT device has successfully authenticated the network, so the AIoT device can perform activation operations (such as enabling radio frequency functions or capabilities) based on the activation command and send a command response.

[0317] Step 415 allows the Reader to send a command response to the AIoT F. After receiving the command response, the AIoT F can end the process.

[0318] In one possible embodiment, in step 401, the service type in the service request sent by the AF indicates inventory and a command (read). The command requests in steps 412 and 413 carry a read command.

[0319] Accordingly, in step 414, the processing of the AIoT device can be as follows: the AIoT device has successfully authenticated the network, the AIoT device can read data based on the read command, and the AIoT device sends a command response (carrying data) to the Reader.

[0320] Further, in step 415, the Reader can send a command response (carrying data) to the AIoT F. After receiving the command response, the AIoT F sends the data to the AF.

[0321] By adopting the above implementation method, in the inventory and command process, the first information carried in the inventory request enables the AIoT device to perform one-way authentication processing of the AIoT device authentication network. Specifically, the AIoT device can determine the need for AIoT device authentication network based on the number of fresh values ​​(or the number of fresh values ​​and the message authentication code) included in the first information; or, the AIoT device can determine the need for AIoT device authentication network based on the indicators (at least one of service type indicator, authentication type indicator, and service association indicator) included in the first information. This provides a solution for how the AIoT device determines how to perform one-way authentication processing of the AIoT device authentication network in the inventory and command process. Furthermore, by carrying the message authentication code for network authentication in the inventory request, the AIoT device can authenticate the network before performing subsequent processing, thereby ensuring the security of subsequent processing and reducing the signaling overhead caused by authentication, thus improving the efficiency of the AIoT device-side network authentication.

[0322] In some possible implementations, under the inventory-only process, two-way authentication is performed, i.e., authentication includes the AIoT device authentication network, and authentication includes the network authenticating the AIoT device.

[0323] Combination Figure 5 This section explains the authentication method for two-way authentication under the inventory-only process, specifically including:

[0324] Step 501: AF sends a service request to AIoT F. This service request may include a service type indication: inventory only.

[0325] In some possible examples, the business request can also be replaced by an AF inventory request message.

[0326] 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), or group transmission (or group transmission indication). The relevant descriptions of the AIoT device identifier, group identification information, number of devices, single transmission (or single transmission indication), and group transmission (or group transmission indication) are the same as those in the foregoing embodiments and will not be repeated.

[0327] After receiving a service request, AIoT F checks whether authentication parameters are stored locally. If no authentication parameters are stored, step 502 is executed; if authentication parameters are stored, step 506 is executed. The specific determination of whether subsequent processing is performed on a single AIoT device or on each of multiple AIoT devices is the same as in the aforementioned embodiments and will not be repeated here.

[0328] Steps 502 to 505 are the same as steps 302 to 305 in the previous embodiments, and will not be described again.

[0329] Step 506: AIoT F sends an inventory request, wherein the inventory request carries first information, which is used by the AIoT device to perform authentication. In this embodiment, authentication may refer to two-way authentication.

[0330] Specifically, AIoT F sends an inventory request carrying the first information to the Reader.

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

[0332] Furthermore, AIoT F can also send a service type indication to the Reader: Inventory Only. This service type is the same as in the service request and will not be repeated here.

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

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

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

[0336] It should be noted that the first freshness value and the second freshness value may be the same or different. If the first freshness value and the second freshness value are the same, both identical freshness values ​​may be included in the first information.

[0337] In one embodiment, the first information may include: a message authentication code, one or more fresh values, wherein the one or more fresh values ​​include a first fresh value and / or a second fresh value; and the first information may also include at least one of the following: an authentication type indicator, a service type indicator, and a service association indicator.

[0338] Preferably, the first information includes an authentication type indicator. The authentication type indicator in the first information may be a two-way authentication indicator; or, the authentication type indicator in the first information may include: an indicator for authenticating the network, or an indicator for authenticating the AIoT device.

[0339] Optionally, the first information may include an authentication type indicator (a two-way authentication indicator; or, an indicator for authenticating the network and an indicator for authenticating the AIoT device) and a service type indicator, specifically an inventory-only indicator.

[0340] Optionally, the first information may include an authentication type indicator (a two-way authentication indicator; or, an indicator for authenticating the network and an indicator for authenticating the AIoT device) and a service association indicator, which corresponds to the inventory-only service.

[0341] Optionally, the first information may include an authentication type indicator (a two-way authentication indicator; or, an indicator for authenticating the network and an indicator for authenticating the AIoT device), an inventory-only indicator, and a service association indicator corresponding to the inventory-only service.

[0342] Step 507: 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.

[0343] The processing of the Reader in this step is similar to step 307 in the aforementioned embodiment, except that the business type stored locally by the Reader is used to indicate that only an inventory is required, so it will not be described in detail.

[0344] Steps 508 to 513 are the same as steps 308 to 313 in the previous embodiments, and will not be described again.

[0345] After completing step 513, AIoT F can execute step 514. The specific processing of step 514 is the same as step 314 in the aforementioned embodiment, and will not be repeated here. Furthermore, the aforementioned... Figure 3 The corresponding implementation also provides other embodiments for implementing or performing network-side authentication of AIoT devices, which are also applicable after step 513 in this embodiment, and will not be described again.

[0346] As mentioned above Figure 3The provided embodiment differs in that, in this embodiment, if the AIoT device authentication is successful or passes, AIoT F can terminate the process. Furthermore, if the AIoT device authentication fails, AIoT F can perform at least one of the following: return to step 502 to request ADM to recalculate the authentication parameters; return to step 506 to resend the inventory request; 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 perform when AIoT device authentication fails.

[0347] By adopting the above implementation method, in the inventory-only process, the first information carried in the inventory request enables the AIoT device to perform two-way authentication processing, namely, authenticating the AIoT device to the network and the network to authenticate the AIoT device. Specifically, the AIoT device can determine whether two-way authentication needs to be performed based on the number of fresh values ​​(or the number of fresh values ​​and the message authentication code) included in the first information; or, the AIoT device can determine whether two-way authentication needs to be performed based on the indicators (at least one of the service type indicator, authentication type indicator, and service association indicator) included in the first information, providing a solution for how the AIoT device determines whether to perform two-way authentication in the inventory-only process. Furthermore, by carrying the message authentication code for authenticating the network in the inventory request and the RES for authenticating the AIoT device in the inventory response, the security of the inventory operation is ensured, and the signaling overhead caused by authentication can be reduced, thereby improving the efficiency of both the AIoT device authenticating the network and the network authenticating the AIoT device.

[0348] In some possible implementations, under a simple inventory process, authentication includes the AIoT device authentication network. That is, the first information is used by the AIoT device to perform the AIoT device authentication network.

[0349] Combination Figure 6 This document describes the authentication method for one-way authentication in AIoT device authentication networks under a simple inventory process, specifically including:

[0350] Step 601 is the same as step 501 in the previous embodiment, and will not be described again.

[0351] Steps 602 to 604 are the same as steps 402 to 404 in the previous embodiments, and will not be described again.

[0352] Step 605: AIoT F sends an inventory request, wherein the inventory request carries first information, which is used for AIoT devices to perform authentication. In this embodiment, the authentication includes the AIoT device authentication network.

[0353] Specifically, AIoT F sends an inventory request carrying the first information to the Reader.

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

[0355] Furthermore, AIoT F can also send a service type indication to the Reader: Inventory Only. This service type is the same as in the service request and will not be repeated here.

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

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

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

[0359] In one embodiment, the first information may include: a message authentication code and a first freshness value; and the first information may also include at least one of the following: an authentication type indicator, a service type indicator, and a service association indicator.

[0360] Optionally, the first information includes an authentication type indicator, and the authentication type indicator is an indicator of the authentication network.

[0361] Optionally, the first information may include a business type indicator, specifically an inventory-only indicator.

[0362] Optionally, the first information may include a business association indicator that corresponds to the inventory-only business.

[0363] Optionally, the first information may include at least two of the following: an indicator of the authentication network, an inventory-only indicator, and a service association indicator corresponding to the inventory-only service.

[0364] Step 606: 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. The Reader's processing in this step is similar to step 406 in the previous embodiment, except that the service type stored locally by the Reader is used to indicate inventory only, so it will not be described in detail.

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

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

[0367] The processing of AIoT devices can be as follows: if the number of fresh values ​​included in the first information is one, it is determined that an AIoT device authentication network is required; if the first information includes a message authentication code and the number of fresh values ​​included in the first information is one, it is determined that an AIoT device authentication network is required.

[0368] In one embodiment, the first information may include: a message authentication code and a first freshness value. Furthermore, the first information may also include at least one of the following: an authentication type indicator, a service type indicator, and a service association indicator.

[0369] In one example, the first information includes an indicator of the authentication network.

[0370] Alternatively, the processing of the AIoT device can be as follows: if the first information includes an indicator of the authentication network, determine that the AIoT device needs to authenticate the network.

[0371] Optionally, 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. For example, if the first information includes an indicator of the authentication network and also includes a message authentication code, it is determined that the AIoT device needs to authenticate the network; or, if the first information includes an indicator of the authentication network, a message authentication code, and a fresh value (or the number of fresh values ​​included in the first information is one), it is determined that the AIoT device needs to authenticate the network. This is not a limitation or an exhaustive list.

[0372] In one example, the first information includes an inventory-only indicator or a business association indicator corresponding to the inventory-only business.

[0373] Optionally, the processing of the AIoT device can be as follows: if the first information includes an inventory-only indicator or a service association indicator corresponding to the inventory-only service, determine that the AIoT device needs to authenticate the network.

[0374] Optionally, 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. For example, if the first information includes an inventory-only indicator or a service association indicator corresponding to the inventory-only service, and the first information includes a message authentication code, it is determined that the AIoT device needs to authenticate the network. This is not a limitation or an exhaustive list.

[0375] In one example, the first information may include at least two of the above types of indicators.

[0376] For example, the first information includes an indicator for the authentication network and an inventory-only indicator. An AIoT device can determine which AIoT device authentication network is required if the first information includes the authentication network indicator and the inventory-only indicator.

[0377] For example, the first information includes an indicator for the authentication network and a service association indicator corresponding to the inventory-only service. If the first information includes the service association indicator corresponding to inventory-only and the authentication network indicator, the AIoT device can determine which AIoT device authentication network is required.

[0378] For example, the first information includes an indicator for the authentication network, an inventory-only indicator, and a service association indicator corresponding to the inventory-only service. If the first information includes the service association indicator corresponding to the inventory-only service, the inventory-only indicator, and the authentication network indicator, the AIoT device can determine which AIoT device needs to authenticate with the network.

[0379] In this example, the AIoT device can also further combine the number of fresh values ​​in the first information and / or the message authentication code to determine whether the AIoT device needs to authenticate the network, which will not be elaborated here.

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

[0381] Thus, AIoT devices can determine the need for network authentication based on one or more fresh values ​​in the first information, allowing them to determine authentication based on relatively little information. Alternatively, AIoT devices can determine the need for network authentication based on at least one of the following: the message authentication code, various indicators, and one or more fresh values ​​in the first information. This allows for a more flexible approach to determining authentication. These methods provide solutions for how AIoT devices determine authentication and the specific type of authentication to be performed during inventory checks.

[0382] Steps 608 to 611 are the same as steps 408 to 411 in the previous embodiments, and will not be described again.

[0383] Since this embodiment only performs an inventory check process, the process can be terminated after completing step 611.

[0384] By adopting the above implementation method, in the inventory-only process, the first information carried in the inventory request enables the AIoT device to perform one-way authentication processing of the AIoT device authentication network. Specifically, the AIoT device can determine the need for AIoT device authentication network based on the number of fresh values ​​(or the number of fresh values ​​and the message authentication code) included in the first information; or, the AIoT device can determine the need for AIoT device authentication network based on the indicators (at least one of service type indicator, authentication type indicator, and service association indicator) included in the first information. This provides a solution for how the AIoT device determines how to perform one-way authentication processing of the AIoT device authentication network in the inventory-only process. Furthermore, by carrying the message authentication code for network authentication in the inventory request, the AIoT device can authenticate the network before performing subsequent processing, thereby ensuring the security of subsequent processing and reducing the signaling overhead caused by authentication, thus improving the efficiency of the AIoT device-side network authentication.

[0385] In some possible implementations, authentication includes network authentication of the AIoT device, that is, the first information is used by the AIoT device to perform one-way authentication of the network authentication AIoT device.

[0386] exist Figure 3 Based on this, an exemplary description of performing one-way authentication of network-authenticated AIoT devices under inventory and command flow is provided:

[0387] The process in step 301 is the same as in the previous embodiments, and will not be described again.

[0388] Step 302: AIoT F sends an authentication vector request to ADM to request authentication parameters. The authentication vector request may carry the identifier of the AIoT device.

[0389] In this embodiment, step 303 is skipped, and step 304 is executed directly. The ADM generates a second freshness value, and XRES is calculated based on the second freshness value. The specific calculation of XRES by the ADM is the same as in step 304 and will not be repeated here.

[0390] Optionally, in addition to carrying the identifier of the AIoT device, the authentication vector request may also carry information instructing the ADM to only calculate the XRES, so that the ADM may only perform step 304 to calculate the XRES.

[0391] Optionally, the authentication vector request may carry the identifier of the AIoT device. Accordingly, the ADM can perform step 304 to calculate XRES. In this case, it is not limited whether the ADM performs the processing of calculating the message authentication code.

[0392] Step 305 is replaced by: ADM sending an authentication vector response to AIoT F; correspondingly, AIoT F receiving the authentication vector response. The authentication vector response may carry authentication parameters, including XRES and a second freshness value; or, the authentication parameters may include a second freshness value.

[0393] Step 306 still involves AIoT F sending an inventory request carrying the first information to the Reader.

[0394] The inventory request includes the identifiers of the AIoT devices.

[0395] AIoT F can also send the service type to the Reader. The relevant instructions on AIoT F sending the service type to the Reader are the same as those in step 306, and will not be repeated here.

[0396] The content of the first message can be replaced as follows:

[0397] In one embodiment, the first information may include a second freshness value; and the first information may also include at least one of the following: an authentication type indicator, a service type indicator, and a service association indicator.

[0398] Preferably, the first information includes an authentication type indicator, and the authentication type indicator can be an indicator for authenticating the AIoT device.

[0399] Optionally, the first information may include an indicator for authenticating the AIoT device and a service type indicator, specifically an inventory and command indicator.

[0400] Optionally, the first information may include an indicator for authenticating the AIoT device and a service association indicator, the service association indicator corresponding to inventory and command services.

[0401] Optionally, the first information may include an indicator for authenticating the AIoT device, an inventory and command indicator, and a service association indicator corresponding to the inventory and command service.

[0402] In one embodiment, the first information may include only the second freshness value.

[0403] Step 307 is the same as in the previous embodiments and will not be described again.

[0404] Step 308 is replaced by AIoT device determining the network authentication AIoT device based on the first information.

[0405] In one embodiment, the first information may include a second freshness value. Furthermore, the first information may also include at least one of the following: an authentication type indicator, a service type indicator, and a service association indicator.

[0406] In one example, the first information includes an indicator for authenticating the AIoT device.

[0407] Alternatively, the processing of the AIoT device can be as follows: if the first information includes an indicator for authenticating the AIoT device, determine that the network needs to authenticate the AIoT device.

[0408] Optionally, the processing of the AIoT device can be as follows: if the first information includes an indicator for authenticating the AIoT device and a fresh value (or the number of fresh values ​​included in the first information is one), determine that the network needs to authenticate the AIoT device.

[0409] In one example, the first information may include at least two of the above types of indicators.

[0410] For example, the first information includes an indicator for authenticating the AIoT device, an inventory indicator, and a command indicator. The AIoT device can determine that the network needs to authenticate the AIoT device if the first information includes the inventory and command indicators and the indicator for authenticating the AIoT device.

[0411] In this example, the AIoT device can also further combine the number of fresh values ​​in the first information to jointly determine whether the network needs to authenticate the AIoT device, which will not be elaborated here.

[0412] It should be noted that the above is merely an illustrative example and does not limit or exhaust all possible scenarios of the content that the first 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 first information, it is within the protection scope of this embodiment.

[0413] In some possible implementations, the first information may consist only of a second fresh value. An AIoT device may determine that the network needs to authenticate it if the first information includes only one fresh value (and does not include a message authentication code).

[0414] In this embodiment, step 309 is not required; steps 310 to 312 are executed directly. The specific descriptions of steps 310 to 312 are the same as those in the previous embodiments and will not be repeated here.

[0415] After AIoT F receives the inventory response, it can perform step 314 to authenticate the AIoT device; or, it can use other embodiments described above to implement or perform network-side authentication of the AIoT device, which will not be repeated here.

[0416] If the AIoT device is successfully certified, proceed to steps 315-319 (or up to step 320). The specific processing of steps 315-319 (or up to step 320) is the same as in the aforementioned embodiments and will not be repeated here.

[0417] In the event of failure or inability to authenticate an AIoT device, the processing that AIoT F can perform is as described above. Figure 3 The corresponding implementation methods are the same and will not be described in detail.

[0418] exist Figure 3 Based on this, an exemplary description of performing one-way authentication of network-authenticated AIoT devices under an inventory-only process is provided:

[0419] In this embodiment, step 301 can still be performed, but the service request in step 301 is replaced with an inventory check carrying a service type indication. Other processing remains unchanged and will not be described again.

[0420] Step 302: AIoT F sends an authentication vector request to ADM to request authentication parameters. The authentication vector request may carry the identifier of the AIoT device.

[0421] In this embodiment, step 303 is skipped, and step 304 is executed directly. The ADM generates a second freshness value, and XRES is calculated based on the second freshness value. The specific calculation of XRES by the ADM is the same as in step 304 and will not be repeated here.

[0422] Step 305 is replaced by: ADM sending an authentication vector response to AIoT F; correspondingly, AIoT F receiving the authentication vector response. The authentication vector response may carry authentication parameters, including XRES and a second freshness value; or, the authentication parameters may include a second freshness value.

[0423] Step 306 still involves AIoT F sending an inventory request carrying the first information to the Reader.

[0424] The inventory request includes the identifiers of the AIoT devices.

[0425] AIoT F can also send the service type to the Reader. The relevant instructions on AIoT F sending the service type to the Reader are similar to those in step 306, except that the service type indication is only for inventory, which will not be elaborated here.

[0426] The content of the first message can be replaced as follows:

[0427] In one embodiment, the first information may include a second freshness value; and the first information may also include at least one of the following: an authentication type indicator, a service type indicator, and a service association indicator.

[0428] Optionally, the first information includes an authentication type indicator, and the authentication type indicator can be an indicator for authenticating the AIoT device.

[0429] Optionally, the first information may include at least one of an indicator for authenticating the AIoT device, an inventory-only indicator, and a business association indicator corresponding to the inventory-only service.

[0430] In one embodiment, the first information may include only the second freshness value.

[0431] Step 307 is the same as in the previous embodiments and will not be described again.

[0432] Step 308 is replaced by AIoT device determining the network authentication AIoT device based on the first information.

[0433] In one embodiment, the first information may include a second freshness value. Furthermore, the first information may also include at least one of the following: an authentication type indicator, a service type indicator, and a service association indicator.

[0434] In one example, the first information includes an indicator for authenticating the AIoT device. The explanation given by the AIoT device for determining that the network needs to authenticate the AIoT device is the same as in the previous example and will not be repeated here.

[0435] In one example, the first information includes one of an inventory-only indicator and a business association indicator corresponding to the inventory-only business.

[0436] If the first information includes either an inventory-only indicator or a service association indicator corresponding to the inventory-only service, the AIoT device determines that the network needs to authenticate the AIoT device. Alternatively, if the first information includes either an inventory-only indicator or a service association indicator corresponding to the inventory-only service, and also includes a fresh value, the AIoT device determines that the network needs to authenticate the AIoT device.

[0437] In one example, the first information may include at least two of the above types of indicators.

[0438] For example, the first information includes an indicator for authenticating the AIoT device and an inventory-only indicator. The AIoT device can determine that the network needs to authenticate the AIoT device if the first information includes both the inventory-only indicator and the indicator for authenticating the AIoT device.

[0439] In this example, the AIoT device can also further combine the number of fresh values ​​in the first information to jointly determine whether the network needs to authenticate the AIoT device, which will not be elaborated here.

[0440] The above is merely an illustrative example and does not limit or exhaustively describe all possible scenarios of the content that the first 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 first information, it is within the protection scope of this embodiment.

[0441] In some possible implementations, the first information may consist only of a second fresh value. An AIoT device may determine that the network needs to authenticate it if the first information includes only one fresh value (and does not include a message authentication code).

[0442] In this embodiment, step 309 is not required; steps 310 to 312 are executed directly. The specific descriptions of steps 310 to 312 are the same as those in the previous embodiments and will not be repeated here.

[0443] After AIoT F receives the inventory response, it can perform step 314 to authenticate the AIoT device; or, other of the aforementioned embodiments that implement or perform network-side authentication of the AIoT device can be used for processing, which will not be repeated here.

[0444] Under the inventory-only process, step 315 and subsequent steps are no longer performed after certifying the AIoT device.

[0445] By employing the above implementation method, the AIoT device determines that the network needs to authenticate it based on the first information carried in the inventory request. Specifically, the AIoT device can determine that the network needs to authenticate it based on the number of fresh values ​​and / or indicators (at least one of service type indicator, authentication type indicator, and service association indicator) included in the first information, thus providing a solution for the AIoT device to determine that the network needs to perform the authentication process. Furthermore, by carrying the RES for authenticating the AIoT device in the inventory response, the network side can perform subsequent processing if the AIoT device is successfully authenticated, ensuring the security of the AIoT device-related data obtained by the network side and reducing the signaling overhead caused by authentication, thereby improving the efficiency of network-side AIoT device authentication.

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

[0447] Figure 7A schematic diagram of the composition structure of an AIoT device according to an embodiment of this application includes:

[0448] The first communication unit 701 is configured to receive an inventory request, wherein the inventory request carries first information, the first information being used by the AIoT device to perform authentication, and the first information includes one or more freshness values.

[0449] The first information also includes at least one of the following: a message authentication code for authenticating the network, an authentication type indicator, a service type indicator, and a service association indicator.

[0450] The authentication type indicator includes at least one of the following: a two-way authentication indicator, an authentication network indicator, and an authentication AIoT device indicator.

[0451] The business type indicator includes one of the following: inventory only indicator, inventory and command indicator.

[0452] like Figure 7 As shown, the AIoT device also includes:

[0453] The first processing unit 702 is configured to determine, based on the first information, to execute the AIoT device authentication network.

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

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

[0456] The one or more fresh values ​​include a first fresh value; a first processing unit 702 is configured to calculate a message verification code based on the first fresh value; and to authenticate the network based on the message verification code and the message authentication code.

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

[0458] The one or more freshness values ​​include a second freshness value; the first processing unit is configured to calculate the RES based on the second freshness value.

[0459] The inventory response also carries a third freshness value; the first processing unit is used to calculate the RES based on the third freshness value, wherein the third freshness value is generated by the AIoT device.

[0460] Figure 8 A schematic diagram of the composition structure of an AIoT F according to an embodiment of this application includes:

[0461] The second communication unit 801 is used to send an inventory request, wherein the inventory request carries first information, the first information being used by the AIoT device to perform authentication, and the first information includes one or more freshness values.

[0462] The first information includes at least one of the following: a message authentication code for authenticating the network, an authentication type indicator, a service type indicator, and a service association indicator.

[0463] The authentication type indicator includes at least one of the following: a two-way authentication indicator, an authentication network indicator, and an authentication AIoT device indicator.

[0464] The business type indicator includes one of the following: inventory only indicator, inventory and command indicator.

[0465] The second communication unit 801 is configured to receive at least one of the following: the message authentication code, the one or more fresh values, wherein the one or more fresh values ​​include a first fresh value and / or a second fresh value.

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

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

[0468] like Figure 8 As shown, AIoT F also includes:

[0469] The second processing unit 802 is used to calculate the XRES based on the third freshness value.

[0470] The second communication unit 801 is used to send the third fresh value.

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

[0472] The second processing unit 801 is used to authenticate the AIoT device based on the RES and the expected response XRES.

[0473] The second communication unit 801 is used to send the RES and receive the authentication result of the AIoT device.

[0474] 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.).

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

[0476] Figure 9 This is a schematic structural diagram of a communication device 900 according to an embodiment of this application. The communication device 900 includes a processor 910, which can call and run computer programs from a memory to enable the communication device 900 to implement the methods in the embodiments of this application. In one possible implementation, the communication device 900 may further include a memory 920. The processor 910 can call and run computer programs from the memory 920 to enable the communication device 900 to implement the methods in the embodiments of this application. The memory 920 may be a separate device independent of the processor 910, or it may be integrated into the processor 910. In one possible implementation, the communication device 900 may further include a transceiver 930, which the processor 910 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 930 may include a transmitter and a receiver. The transceiver 930 may further include antennas, and the number of antennas may be one or more.

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

[0478] Figure 10 This is a schematic structural diagram of a chip 1000 according to an embodiment of this application. The chip 1000 includes a processor 1010, 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 1000 may further include a memory 1020. The processor 1010 can call and run computer programs from the memory 1020 to implement the methods executed by an AIoT device or AIoT F in the embodiments of this application. The memory 1020 may be a separate device independent of the processor 1010, or it may be integrated into the processor 1010. In one possible implementation, the chip 1000 may further include an input interface 1030. The processor 1010 can control the input interface 1030 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 1000 may further include an output interface 1040. The processor 1010 can control the output interface 1040 to communicate with other devices or chips, specifically, it can output information or data to other devices or chips.

[0479] In one possible implementation, the chip can be applied to the AIoT device or AIoTF in the embodiments of this application, and the chip can implement the corresponding processes implemented by the AIoT device or AIoTF in the various methods of the embodiments of this application. For simplicity, further details are omitted 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.

[0480] 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)).

[0481] 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 freshness value is received. The freshness value is carried in the inventory request. The inventory request carries first information, which is used by the AIoT device to perform authentication.

2. The method according to claim 1, wherein, The first information also includes at least one of the following: a message authentication code for authenticating the network, an authentication type indicator, a service type indicator, and a service association indicator.

3. The method according to claim 2, wherein, The business type indicator includes one of the following: inventory only indicator, inventory and command indicator.

4. The method according to any one of claims 1-3, further comprising: Based on the first information, it is determined to perform network authentication on the AIoT device.

5. The method according to claim 4, further comprising: Send an inventory response, wherein the inventory response carries a response RES for authenticating the AIoT device.

6. The method according to claim 5, wherein the inventory response further carries a third freshness value; therefore, the method further includes: The RES is calculated based on the third freshness value, wherein the third freshness value is generated by the AIoT device.

7. An authentication method performed by AIoT F, comprising: Send an inventory request, wherein the inventory request carries first information, the first information being used by the AIoT device to perform authentication, the first information including one or more freshness values.

8. The method according to claim 7, wherein, The first information also includes at least one of the following: a message authentication code for authenticating the network, an authentication type indicator, a service type indicator, and a service association indicator.

9. The method according to claim 8, wherein, The business type indicator includes one of the following: inventory only indicator, inventory and command indicator.

10. The method according to claim 8 or 9, further comprising: Receive at least one of the following: the message authentication code, the one or more fresh values, wherein the one or more fresh values ​​include a first fresh value and / or a second fresh value.

11. The method according to any one of claims 8-10, further comprising: Receive an inventory response, wherein the inventory response carries a response RES for authenticating the AIoT device.

12. The method according to claim 11, wherein, The inventory response also carries a third freshness value, which is used to calculate XRES.

13. The method of claim 12, further comprising: The AIoT device is authenticated based on the RES and the expected response XRES.

14. An AIoT device, comprising: A first communication unit is configured to receive an inventory request, wherein the inventory request carries first information, the first information being used by the AIoT device to perform authentication, and the first information including one or more freshness values.

15. An AIoT F, comprising: The second communication unit is used to send an inventory request, wherein the inventory request carries first information, the first information being used by the AIoT device to perform authentication, and the first information includes one or more freshness values.

16. 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 6.

17. 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 7 to 13.

18. 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 6 or 7 to 13.

Images