Communication method, and device

Abstract

The present application relates to a communication method, and a device. The method comprises: receiving a request message, wherein the request message carries a security-protected command, and the command is used for activating or deactivating a first AIoT device.

Description

Communication methods and devices Technical Field

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

[0002] In related technologies, Ambient Powered IoT (AIoT) devices interact with AIoT Functions (AIoTFs) via their corresponding readers or readers / writers. In this scenario, AIoTFs typically use commands to activate or deactivate AIoT devices. However, ensuring the security of these activation or deactivation operations becomes a problem that needs to be addressed. Summary of the Invention

[0003] This application provides a communication method and device.

[0004] This application provides a communication method executed by a first AIoT device, including:

[0005] A request message is received, wherein the request message carries a security protection command, which is used to activate or deactivate the first AIoT device.

[0006] This application provides a communication method executed by AIoTF, including:

[0007] Send a request message, wherein the request message carries a security protection command, the command being used to activate or deactivate the first AIoT device.

[0008] This application provides a first AIoT device, including:

[0009] A first communication unit is configured to receive a request message, wherein the request message carries a security protection command, the command being used to activate or deactivate the first AIoT device.

[0010] This application provides an AIoTF, including:

[0011] The second communication unit is used to send a request message, wherein the request message carries a security protection command, which is used to activate or deactivate the first AIoT device.

[0012] This application provides a first 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 cause the first AIoT device to perform the methods described above.

[0013] This application provides an AIoTF, 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 AIoTF 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] This application provides a computer program that, when run on a computer, causes the computer to perform the above-described method.

[0019] By adopting the above scheme, a request message is sent to the first AIoT device, and this request message carries a security-protected command to activate or deactivate the first AIoT device. In this way, when performing management operations to activate or deactivate the AIoT device via commands, the commands are securely protected, ensuring the security of the management operations.

[0020] Furthermore, the integrity and / or confidentiality of commands can be protected based on a pre-shared key between the first AIoT device and the core network, or between the first AIoT device and a third-party server (AAA server or AF). This eliminates the need for the AIoT device to perform authentication and generate session keys, thereby improving processing efficiency while ensuring the security of AIoT device management operations.

[0021] Furthermore, a request message carrying a security protection command can be sent to the first AIoT device in either an inventory-only process or a command-only process. This enables management operations on AIoT devices across multiple processes, ensuring the security of these operations and comprehensive scenario coverage. Attached Figure Description

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

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

[0024] Figure 3 is a schematic flowchart of a communication method in an inventory-only process according to an embodiment of this application.

[0025] Figure 4 is a schematic flowchart of another communication method in an inventory-only process according to an embodiment of this application.

[0026] Figure 5 is a schematic flowchart of a communication method in a command-only flow according to an embodiment of this application.

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

[0028] Figure 7 is a schematic block diagram of an AIoTF according to an embodiment of this application.

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

[0030] Figure 9 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 LTE, LTE-A, NR, NR evolution, WLAN, WiFi, or other communication systems.

[0032] This application describes various embodiments in conjunction with network devices and terminals. The terminal can be mobile or fixed, and may also be referred to as a mobile station, user unit, etc. The 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] 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.

[0035] Figure 1 exemplarily illustrates a communication system 100. The communication system includes network devices 110 and terminals 120. In one possible implementation, the communication system 100 may include multiple network devices 110, and the coverage area of ​​each network device 110 may include multiple terminals 120; 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 network devices may further include access network devices and core network devices. That is, the communication system may also include multiple core networks for communicating with the access network devices. The access network devices may be base stations of LTE, LTE-A, or NR systems. Taking the communication system shown in Figure 1 as an example, the communication devices may include network devices and terminals with communication functions. The communication devices may also include other devices in the communication system, such as network controllers, mobility management entities, and other network entities; this embodiment does not limit this.

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

[0037] S210 is executed on the AIoTF side to send a request message, wherein the request message carries a security protection command, which is used to activate or deactivate the first AIoT device.

[0038] S220 is executed on the first AIoT device side to receive a request message, wherein the request message carries a security protection command, which is used to activate or deactivate the first AIoT device.

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

[0040] The request message is one of the following: an inventory request message or a command request message. An inventory request message can be alternatively referred to as an Inventory Request or an AIoT Inventory Request. A command request message can be alternatively referred to as a Command Request or an AIoT Command Request.

[0041] After completing the corresponding operation of the command on the first AIoT device side, a response message can be sent, and the AIoTF can receive the response message. The response message can be one of the following: an inventory response message or a command response message.

[0042] In some possible implementations, the request message is an inventory request message, which can be an inventory request message only in the inventory process. In this implementation, security protection and / or security verification are based on the key between the first AIoT device and the core network.

[0043] Referring to Figure 3, the communication method in the inventory counting process is explained:

[0044] Step 301: The Application Function (AF) sends a first request to the AIoTF. The first request carries at least one of the following: identification-related information, or a command. Specifically, the first request can be an inventory request, an inventory business request, or an inventory service request.

[0045] AIoTF checks whether it has or stores a key for security protection. If it does, it proceeds to step 302a; otherwise, it proceeds to step 302b.

[0046] Step 302a: AIoTF obtains the key locally and then performs step 303.

[0047] Step 302b: AIoTF sends an AIoT key Request message to ADM (AIoT Unified Data Management).

[0048] Step 302c: ADM sends an AIoT key response message to AIoTF. The AIoT key response message is used by AIoTF to obtain the key and then execute step 303.

[0049] Step 303: AIoTF provides security protection for commands based on key pairs, whereby the security protection includes integrity protection (hereinafter referred to as integrity protection) and / or encryption.

[0050] Step 304: AIoTF sends an inventory request message through the RAN / UEreader (reader / writer). The inventory request message contains a security protection command. The security protection command may include at least one of the following: (encrypted) command and integrity verification parameters. The command may be an Enable Command or a Disable Command (such as a temporary deactivation command or a permanent deactivation command).

[0051] Step 305: The first AIoT device performs integrity verification and / or decryption of the security protection command.

[0052] Step 306: The first AIoT device sends a response message, wherein the response message carries at least one of the following information: an encrypted identifier of the first AIoT device, a temporary identifier of the first AIoT device, or a confirmation response to the command. For example, Figure 3 shows that this response message is an inventory response message (or AIoT Inventory Response).

[0053] Step 307: AIoTF obtains the identifier (ID) of the first AIoT device.

[0054] Step 308: AIoTF sends the inventory response message to AF.

[0055] In one embodiment, prior to step 301, at least one of the following may be included: step 300a: the reader and the network complete registration; step 300b: the first AIoT device shares subscription data with the core network.

[0056] This reader can also be called a read / write device. The reader can include access network equipment and / or terminals. For example, in Figure 3, the reader is represented as RAN (Radio Access Network) / UE Reader.

[0057] The core network may include ADM and / or AIoTF. Subscription data may include at least one of the following: the identifier (Device ID) and credential of the first AIoT device. The credential may be a security credential or a security credential of the first AIoT device, or it may be a security credential of a first group, which includes the first AIoT device.

[0058] In one example, when the reader / writer is a terminal (UE), steps 300a and 300b are executed.

[0059] This embodiment does not limit the process of performing the registration process between the terminal (UE) and the network and completing the registration.

[0060] In one example, when the reader is an access network device, step 300a can be omitted and only step 300b can be executed.

[0061] In one embodiment, the AF can determine whether to execute step 301 based on its own needs or strategy. Here, the specific triggering reason for the AF to send the first request is not limited.

[0062] Optionally, step 301 can be: AF can directly send the first request to AIoTF.

[0063] Optionally, as shown in Figure 3, step 301 can be: AF sends a first request to AIoTF through NEF (Network Exposure Function).

[0064] In step 301, the identification-related information carried in the first request may include one of the following: the identifier of the first AIoT device, the group identification information of the first group, wherein the first group includes the first AIoT device.

[0065] The identifier of the first AIoT device can be a permanent identifier for the first AIoT device.

[0066] The group identification information for the first group is used to uniquely identify the first group. The group identification information can be one of the following: a mask, an identifier prefix, etc.

[0067] The mask can be a group mask, and its generation method is not limited in this embodiment.

[0068] The identifier prefix can consist of the first N bits that are the same in the identifiers of multiple AIoT devices in the group, where N can be an integer greater than or equal to 2. The identifier prefix of the first group can consist of the first N bits that are the same in the identifiers of multiple AIoT devices in the first group.

[0069] In step 301, the command carried in the first request is an activation command or a deactivation command.

[0070] The activation command is used to activate the first AIoT device or each AIoT device in the first group. Specifically, the activation command is used to wake up, activate, or enable a temporarily disabled AIoT device. Wake up, activate, or enable can refer to enabling the radio frequency (RF) function or RF capability of the AIoT device. That is, the activation command is used to activate, enable, or perform an RF function or RF capability on an AIoT device that is temporarily deactivated. This activation command allows the AIoT device to be enabled, which means waking up and using a temporarily disabled AIoT device.

[0071] The deactivation command can be either a temporary deactivation command or a permanent deactivation command.

[0072] The temporary deactivation command is used to temporarily deactivate the first AIoT device or each AIoT device in the first group. Specifically, the temporary deactivation command is used to temporarily disable the radio frequency (RF) function or RF capability of the AIoT device. Furthermore, this temporary deactivation command allows the AIoT device to perform a temporary deactivation operation, meaning that the RF function or RF capability of the AIoT device is temporarily disabled and can be woken up by an activation command or activation operation.

[0073] The permanent deactivation command is used to permanently deactivate the first AIoT device or all AIoT devices in the first group. Specifically, the permanent deactivation command permanently disables the radio frequency (RF) function or RF capability of the AIoT device. Furthermore, this permanent deactivation command enables the AIoT device to perform a permanent deactivation operation, meaning that the AIoT device's RF function or RF capability is permanently disabled and cannot be woken up by an activation command or activation operation.

[0074] The above is merely an exemplary description of the content that the first request may carry. In actual processing, the first request may also carry other content, such as business type indication information. In this embodiment, the business type indication information can be used to indicate only the inventory process or only the inventory business.

[0075] When the identified information is the identifier of the first AIoT device, the subsequent processing is for the scenario of activating or deactivating the first AIoT device. When the identified information is the group identification information of the first group, the subsequent processing is for the scenario of activating or deactivating each AIoT device in the first group (including the first AIoT device).

[0076] In one embodiment, the AF side may not execute step 301, but instead the AIoTF may directly determine whether to execute step 302a or step 302b.

[0077] In this embodiment, when AIoTF determines, based on its own needs or related strategies, that it needs to perform a simple inventory process to activate or deactivate the first AIoT device, or to activate or deactivate each AIoT device in the first group (including the first AIoT device), AIoTF checks whether it has or stores a key for security protection. If it does, it executes step 302a; otherwise, it executes step 302b. This embodiment does not limit the specific reasons why AIoTF determines to activate or deactivate the first AIoT device, or to activate or deactivate each AIoT device in the first group.

[0078] In one example, if AIoTF determines, based on its own needs or relevant policies, that it needs to perform a simple inventory process to activate or deactivate the first AIoT device, the subsequent processing is tailored to the scenario of activating or deactivating the first AIoT device.

[0079] In one example, if AIoTF determines, based on its own needs or relevant policies, that it needs to perform an inventory process to activate or deactivate each AIoT device in the first group, the subsequent processing is targeted at activating or deactivating each AIoT device in the first group (including the first AIoT device).

[0080] Next, we will first explain steps 302a to 308 for the scenario of activating or deactivating the first AIoT device.

[0081] In one embodiment, AIoTF checks whether it has a key corresponding to the first AIoT device (i.e. a key used for security protection) stored locally. If it has or stores a key corresponding to the first AIoT device, then step 302a is executed.

[0082] AIoTF execution step 302a may include: AIoTF obtaining the key based on the identifier of the first AIoT device. In this embodiment, the key may refer to the key of the first AIoT device or the key corresponding to the first AIoT device.

[0083] For example, AIoTF can store the identifier of the first AIoT device and its associated or corresponding key in the security credential, which can be the security credential of the first AIoT device. AIoTF obtaining the key based on the identifier of the first AIoT device can include: AIoTF searching for the security credential of the first AIoT device based on the identifier, and obtaining the key from the security credential of the first AIoT device. It should be noted that in actual processing, the identifier of the first AIoT device and its corresponding or associated key can also be stored in other content or other locations, which is not limited here.

[0084] Optionally, the key can be used for both integrity and encryption. That is, the key corresponding to the first AIoT device can serve as both an integrity key and a confidentiality key, meaning the integrity key and the confidentiality key are the same. The integrity key can also be called an integrity protection key, and the confidentiality key can also be called a confidentiality protection key; these will not be repeated below.

[0085] Optionally, the key includes an integrity key and / or a confidentiality key. The integrity key and the confidentiality key are different; the integrity key can be referred to as the integrity key corresponding to the first AIoT device, and the confidentiality key can be referred to as the confidentiality key corresponding to the first AIoT device.

[0086] In one example, the key is pre-shared between AIoTF and the first AIoT device. This key (the key corresponding to the first AIoT device) is a pre-shared key between the first AIoT device and the core network.

[0087] Optionally, the pre-shared key between the first AIoT device and the core network serves as both an integrity key and a confidentiality key.

[0088] Optionally, the pre-shared key includes a pre-shared integrity key and / or a pre-shared confidentiality key, wherein the pre-shared integrity key serves as the integrity key corresponding to the first AIoT device, and the pre-shared confidentiality key can be the confidentiality key corresponding to the first AIoT device.

[0089] In one example, the key is the authenticated session key. The authenticated session key can be stored in both the first AIoT device and the AIoTF. This authenticated session key can be generated after the first AIoT device authenticates with the network side; the authentication can include two-way authentication, one-way authentication, etc., and is not limited here.

[0090] Optionally, the session key authenticated by the first AIoT device can serve as both the integrity key and the confidentiality key corresponding to the first AIoT device.

[0091] Optionally, the authenticated key includes an authenticated integrity key and / or an authenticated confidentiality key, wherein the authenticated integrity key serves as the integrity key corresponding to the first AIoT device, and the authenticated confidentiality key serves as the confidentiality key corresponding to the first AIoT device.

[0092] For example, when temporarily disabling the first AIoT device, a key is stored, such as only an integrity key (which can be a pre-shared integrity key or an authenticated integrity key), and all other security contexts are deleted. When the first AIoT device needs to be enabled through this inventory-only process, this integrity key is used directly to perform integrity protection to ensure that the messages are not tampered with.

[0093] In one embodiment, the AIoTF checks whether it has the key of the first AIoT device (i.e., the key used for security protection) stored locally. If it does not have or has not stored the key corresponding to the first AIoT device, then step 302b is executed. In this embodiment, by executing steps 302b and 302c, the key finally obtained by the AIoTF side is the key corresponding to the first AIoT device.

[0094] In one example, the processing performed by AIoTF also includes receiving the key.

[0095] Specifically, the AIoT key Request message in step 302b carries the identifier of the first AIoT device.

[0096] The AIoT key Response message in step 302c carries a key. After receiving the AIoT key Request message, the ADM may perform step 302c by: the ADM searching for the locally stored key based on the identifier of the first AIoT device carried in the AIoT key Request message; and sending the key (or the identifier and key of the first AIoT device) to the AIoTF in the AIoT key Response message.

[0097] For example, the ADM's search for the locally stored key based on the identifier of the first AIoT device carried in the AIoT key Request message may include: the ADM searching for the security credentials of the first AIoT device in its local storage based on the identifier of the first AIoT device carried in the AIoT key Request message, extracting the key from the security credentials of the first AIoT device, and sending the key (or the identifier and key of the first AIoT device) back to the AIoTF in the AIoT key Response message. The relevant descriptions regarding the security credentials of the first AIoT device are the same as in the aforementioned embodiments and will not be repeated.

[0098] Optionally, the key is pre-shared between the first AIoT device and the ADM, and this key can be referred to as the pre-shared key between the first AIoT device and the core network (or ADM).

[0099] The pre-shared key between the first AIoT device and the core network can serve as both the integrity key and the confidentiality key corresponding to the first AIoT device.

[0100] Alternatively, the pre-shared key between the first AIoT device and the core network may include a pre-shared integrity key and / or a pre-shared confidentiality key. The pre-shared integrity key serves as the integrity key corresponding to the first AIoT device, and the pre-shared confidentiality key may be the confidentiality key corresponding to the first AIoT device.

[0101] Optionally, the key is an authenticated session key, which can be stored in both the first AIoT device and the core network (ADM).

[0102] This key is the authenticated session key, which can be used as both an integrity key and a confidentiality key.

[0103] Alternatively, the authenticated key may include an authenticated integrity key and / or an authenticated confidentiality key, with the authenticated integrity key serving as the integrity key corresponding to the first AIoT device and the authenticated confidentiality key serving as the confidentiality key corresponding to the first AIoT device.

[0104] In one example, on the AIoTF side, the key is calculated based on a root key and a second fresh value, wherein the second fresh value may include one of the following: a second random number, a second count value, or a second sequence value. The processing performed by AIoTF also includes receiving the root key. This root key is the root key of the first AIoT device.

[0105] Specifically, the AIoT key Request message in step 302b carries the identifier of the first AIoT device.

[0106] The AIoT key Response message in step 302c carries the root key. After receiving the AIoT key Request message, the ADM may perform step 302c by: the ADM searching for the root key of the first AIoT device in its local storage based on the identifier of the first AIoT device carried in the AIoT key Request message; and sending the root key (or the identifier and root key of the first AIoT device) to the AIoTF in the AIoT key Response message.

[0107] The processing after AIoTF receives the root key and before performing step 303 also includes: calculating the key based on the root key and the second fresh value.

[0108] The second random number can be generated by AIoTF, for example, it can be generated by AIoTF using a random number generator, etc., there is no limitation here.

[0109] The second count value can be generated based on a second counter maintained by AIoTF, and the value of this second counter is the second count value. The update method of the second counter value can be pre-configured, default, or protocol-specified. For example, the value of the second counter can be incremented by one as the number of times AIoTF acquires or generates keys increases, or the value of the second counter can be incremented by one as the number of times AIoTF receives requests from AF, or the value of the second counter can be incremented by one as the number of times AIoTF sends request messages, etc., without limitation or exhaustive list.

[0110] The second sequence value can be obtained by truncating or shortening the second count value. This embodiment does not limit the specific processing method of AIoTF to truncate or shorten the second count value.

[0111] Optionally, the key can serve as both an integrity key and a confidentiality key.

[0112] On the AIoTF side, the key calculated based on the root key and the second freshness value can be expressed as: K'=f(K,NONCE_2). Where K' is the key corresponding to the first AIoT device calculated by ADM, which can at least be used to securely protect activation or deactivation commands (such as temporary or permanent deactivation commands); K is the root key of the first AIoT device, and NONCE_2 is the second fresh value; f() represents the algorithm for calculating the key (i.e., the key corresponding to the first AIoT device). This algorithm can be the default on the AIoTF side, configured according to actual conditions, or specified by the protocol. For example, the algorithm for calculating the key can be at least one of the following: KDF (Key Derivation Function), first authentication function (such as the f1 function defined in 3GPP), second authentication function (such as the f2 function defined in 3GPP), third key generation function (such as the f3 function defined in 3GPP), fourth key generation function (such as the f4 function defined in 3GPP), fifth key generation function (such as the f5 function defined in 3GPP), hash algorithm, Advanced Encryption Standard (AES), ACSON, SNOW 3G (Snow Third Encryption Standard). Generation (third-generation mobile communication), ZUC (ZUChongzhi), XOR computation, and direct connection computation. The hash algorithm can be represented as HASH(), which may include HMAC-SHA-256 (Hash based Message Authentication Code-Secure Hash Algorithm-256), or other lightweight hash algorithms (such as SPECK, SIMON, etc.). This embodiment does not exhaustively list them all.

[0113] It should be understood that this is only an illustrative example. In actual processing, the algorithm for calculating the key may include many more possibilities. The algorithms for calculating the key are not exhaustively listed here. Furthermore, the calculation key may also use other parameters, such as the identifier of the first AIoT device (permanent or temporary identifier), the identifier of the AIoTF, etc., at least one of these. This is not limited or exhaustively listed here.

[0114] For example, calculating the key on the AIoTF side based on the root key and the second fresh value can be expressed as: K' = f(K, NONCE_2, AIoT ID_1), where AIoT ID_1 represents the identifier (permanent or temporary) of the first AIoT device. The meanings of the other parameters are the same as in the previous example and will not be repeated. It should also be noted that in the key calculation process, the identifier of the first AIoT device refers to either the permanent or temporary identifier of the first AIoT device, which will not be explained again below.

[0115] Optionally, the key may include an integrity key and / or a confidentiality key.

[0116] AIoTF's key calculation based on the root key and the second fresh value may include: calculating a first key based on the root key and the second fresh value; deriving or deducing an integrity key and / or a confidentiality key based on the first key.

[0117] The method by which AIoTF calculates the first key can be represented as: K_1 = f(K, NONCE_2). Here, K_1 is the first key calculated by ADM; K is the root key of the first AIoT device; NONCE_2 is the second fresh value; f() represents the algorithm for calculating the first key. This algorithm on the AIoTF side can be the default, configured according to actual conditions, or specified by the protocol. For example, the algorithm for calculating the first key can be at least one of the following: KDF, first authentication function, second authentication function, third key generation function, fourth key generation function, fifth key generation function, hash algorithm, AES, ACSON, SNOW 3G, ZUC, XOR calculation, direct connection calculation, etc.

[0118] It should be understood that this is merely an illustrative example. In actual processing, the algorithm for calculating the key can include many more possibilities. We will not exhaustively list all possible algorithms for calculating the key here. Furthermore, the calculation of the first key may also use other possible parameters, such as the identifier of the first AIoT device, the identifier of the AIoTF (permanent or temporary), etc., at least one of these. For example, the calculation of the first key using AIoTF can be expressed as: K_1 = f(K, NONCE_2, AIoT ID_1). This is not limited or exhaustively listed here. It should be noted that in the process of calculating the first key, the identifier of the first AIoT device refers to either the permanent identifier or the temporary identifier of the first AIoT device, which will not be explained again below.

[0119] This embodiment does not limit the specific processing method for deriving or deducing the integrity key based on the first key; nor does it limit the specific processing method for deriving or deducing the confidentiality key based on the first key, as long as the final generated integrity key and confidentiality key are different, they are within the protection scope of this embodiment.

[0120] In one example, the key is calculated by ADM based on the root key and a second fresh value. AIoTF processing also includes one of the following: receiving the second fresh value, wherein the second fresh value includes one of the following: a second random number, a second count value, or a second sequence value; and sending the second fresh value.

[0121] In one scenario, the processing performed by AIoTF includes sending a second fresh value. The processing performed by AIoTF also includes receiving the key.

[0122] Specifically, the AIoT key Request message in step 302b carries the identifier of the first AIoT device and the second freshness value.

[0123] The AIoT key Response message in step 302c carries a key. After receiving the AIoT key Request message, the ADM can perform step 302c by: the ADM looking up the root key of the first AIoT device in its local storage based on the identifier of the first AIoT device carried in the AIoT key Request message; calculating the key based on the root key and the second freshness value; and sending the key (or the identifier and key of the first AIoT device) to the AIoTF in the AIoT key Response message.

[0124] The second fresh value is generated by AIoTF. The explanation of how AIoTF generates this second fresh value is the same as in the previous example, so it will not be repeated here.

[0125] Optionally, the key can serve as both an integrity key and a confidentiality key. The process of calculating the key based on the root key and the second fresh value on the ADM side is the same as the process of calculating the key based on the root key and the second fresh value in the aforementioned AIoTF example, and will not be repeated here.

[0126] Optionally, the key may include an integrity key and / or a confidentiality key.

[0127] ADM's key calculation based on the root key and the second fresh value may include: calculating a first key based on the root key and the second fresh value; deriving or deducing an integrity key and / or a confidentiality key based on the first key.

[0128] The method by which ADM calculates the first key is the same as that by AIoTF, and will not be repeated here.

[0129] The specific processing method for ADM to derive or deduce the integrity key based on the first key is not limited in this embodiment; the specific processing method for deriving or deduce the confidentiality key based on the first key is also not limited in this embodiment, as long as the final generated integrity key and confidentiality key are different, it is within the protection scope of this embodiment.

[0130] In one scenario, the processing performed by AIoTF further includes receiving the key. The processing performed by AIoTF also includes receiving a second fresh value.

[0131] Specifically, the AIoT key Request message in step 302b carries the identifier of the first AIoT device.

[0132] The AIoT key Response message in step 302c carries a second fresh value and a key. After receiving the AIoT key Request message, the ADM can perform step 302c by: the ADM looking up the root key of the first AIoT device stored locally based on the identifier of the first AIoT device carried in the AIoT key Request message; calculating the key based on the root key and the second fresh value; and sending the second fresh value and the key (or the identifier of the first AIoT device, the second fresh value and the key) to the AIoTF in the AIoT key Response message.

[0133] The content of the second fresh value is the same as that in the previous embodiment. The only difference is that in this example, it is replaced by one of the second random number, the second count value, and the second sequence value generated by ADM. The specific method of ADM generating one of the second random number, the second count value, and the second sequence value is similar to that of AIoTF, so it will not be described again.

[0134] The key calculated on the ADM side can also serve as both an integrity key and a confidentiality key, or it can include both an integrity key and / or a confidentiality key. The specific explanation of the ADM key calculation is the same as the previous example and will not be repeated.

[0135] In one embodiment, the security protection includes encryption only. Step 303, performed by AIoTF, may include: encrypting the command based on a key to obtain the encrypted command. The security-protected command includes the encrypted command.

[0136] Specifically, AIoTF encrypts the command based on a key to obtain the encrypted command, which may include: encrypting the command based on the key, a first freshness value, and a pre-configured confidentiality protection algorithm to obtain the encrypted command, wherein the first freshness value includes one of the following: a first random number, a first count value, and a first sequence value. The key is used for both integrity protection and encryption; alternatively, the key can be a confidentiality key.

[0137] The first random number can be generated by AIoTF using a random number generator, etc., and there are no restrictions here. The first random number and the second random number can be the same or different.

[0138] The first count value can be generated based on a first counter maintained by AIoTF, and the value of this first counter is the first count value. The update method of the first counter value can be pre-configured, default, or protocol-specified; no limitations or exhaustive list are provided here. The first counter and the second counter can be the same or different, and the first count value can be the same or different from the first count value.

[0139] The first sequence number can be obtained by truncating or shortening the first count value. The specific method of truncating or shortening the first count value is not limited in this embodiment. The first sequence number and the second sequence number can be the same or different.

[0140] The pre-configured confidentiality protection algorithm can be configured according to the actual situation. For example, it can be at least one of the following: AES function, Snow 3G, ZUC, HMAC-SHA256 function, Hash function, other Hash function or other lightweight functions (such as SPECK, SIMON algorithm), etc. There is no limit or exhaustive list here.

[0141] For example, AIoTF encrypts the command to obtain the encrypted command based on a key, a first fresh value, and a pre-configured confidentiality protection algorithm. This process includes: AIoTF using the first fresh value as input parameters for encryption calculation, employing the pre-configured confidentiality protection algorithm, the input parameters, and the confidentiality key to calculate an encryption key stream; and then performing a computation between the encryption key stream and the command to obtain the encrypted command. The computation between the encryption key stream and the command can be an XOR operation or other operations, which are not limited here.

[0142] The input parameters for this encrypted computation may include, in addition to the first fresh value, other parameters such as the command length, the length of the first fresh value, a fixed value assigned by a third party (e.g., FC = 0x7E), the bearer ID, a 1-bit transmission direction (e.g., 0 for the upline and 1 for the downline), the length of the encryption key stream (LENGTH), the permanent identifier of the first AIoT device, the length of the permanent identifier of the first AIoT device, the temporary identifier of the first AIoT device, the length of the temporary identifier of the first AIoT device, etc., at least one of these. The length of the encryption key stream can be the length of the command. This section does not limit or exhaustively list all possible input parameters for the encrypted computation. It should be noted that the identifier of the first AIoT device involved in both the encrypted and decrypted computations may include the permanent identifier and / or the temporary identifier of the first AIoT device, which will not be explained again below.

[0143] In one embodiment, the security protection performed by AIoTF includes only integrity protection. Step 303 of the AIoTF process may include: calculating the integrity verification parameters based on the key and the command. The security protection command includes the integrity verification parameters. Furthermore, the security protection command also includes commands.

[0144] The AIoTF calculates the integrity verification parameters based on the key and the command, which may include: calculating the integrity verification parameters based on the key, a first freshness value, and a pre-configured integrity protection algorithm, wherein the first freshness value includes one of the following: a first random number, a first count value, and a first sequence value. The key is used for both integrity protection and encryption; alternatively, the key may be an integrity key.

[0145] The pre-configured integrity protection algorithm can be configured according to the actual situation. For example, it can be at least one of the following: MAC function, AES function, Snow 3G, ZUC, HMAC-SHA256 function, Hash function, other Hash functions or other lightweight functions. No limit or exhaustive list is made here.

[0146] For example, AIoTF calculates the integrity verification parameters for the command based on the key, the first freshness value, and the pre-configured integrity protection algorithm, including: AIoTF uses the first freshness value and the command as input parameters for integrity protection calculation, and uses the pre-configured integrity protection algorithm, the input parameters for integrity protection calculation, and the integrity key to calculate and obtain the integrity verification parameters.

[0147] In addition to the first fresh value and the command, the input parameters for the integrity assurance calculation may include other parameters, such as the command length, the length of the first fresh value, a fixed value assigned by a third party (e.g., FC=0x7E), the permanent identifier of the first AIoT device, the length of the permanent identifier of the first AIoT device, the temporary identifier of the first AIoT device, and the length of the temporary identifier of the first AIoT device, etc. At least one of these parameters is not limited or exhaustively listed here. It should be noted that the identifier of the first AIoT device involved in the integrity assurance calculation input parameters may include the permanent identifier and / or the temporary identifier of the first AIoT device, which will not be explained again below.

[0148] For example, the computation integrity verification parameters can be represented as: f1(K_int, AIoT ID_1, Command, NONCE), where f1() represents the pre-configured integrity protection algorithm, K_int represents the integrity key, AIoT ID_1 represents the identifier (permanent or temporary) of the first AIoT device, Command represents the command, and NONCE represents the first random number.

[0149] In some embodiments, the security protections performed by AIoTF include encryption and integrity verification. The security protection commands include: encryption commands and integrity verification parameters.

[0150] In one embodiment, AIoTF can encrypt first and then perform integrity verification. The processing of step 303 performed by AIoTF may include: encrypting the command based on a key to obtain the encrypted command; and calculating the integrity verification parameters based on the key and the encrypted command.

[0151] The key used for encryption calculation and the key used for integrity protection calculation (i.e., calculating integrity verification parameters) can be the same, that is, both use the key used for integrity protection and encryption; or, the key used for encryption calculation is a confidentiality key, and the key used for integrity protection calculation is an integrity key.

[0152] The specific processing of the encryption command is the same as in the aforementioned embodiments, and will not be repeated here.

[0153] The step of calculating the integrity verification parameter based on the key and the encrypted command includes: calculating the integrity verification parameter based on the key, a first freshness value and a pre-configured integrity protection algorithm, wherein the first freshness value includes one of the following: a first random number, a first count value, and a first sequence value.

[0154] The processing of integrity verification parameters differs from the previous embodiments only in that the commands in the input parameters of the integrity verification calculation are replaced with encrypted commands, so it will not be described again.

[0155] In one embodiment, AIoTF can perform integrity verification first and then encryption. Step 303 performed by AIoTF may include: calculating the integrity verification parameters based on the key and the command; and encrypting the command based on the key to obtain the encrypted command. The specific processing for calculating the encrypted command is the same as in the previous embodiments, and the processing for calculating the integrity verification parameters is also the same as in the previous embodiments, and will not be described again.

[0156] In one embodiment, step 304 may specifically include: AIoTF forwarding the AIoT Inventory Request (i.e., inventory request message) to the first AIoT device via the RAN / UEreader. The AIoT Inventory Request (i.e., inventory request message) may be carried or transmitted by a Paging message.

[0157] In addition to security protection commands, the inventory request message may also include the AIoT ID (identifier of the first AIoT device).

[0158] Optionally, if the key (the key corresponding to the first AIoT device) is calculated by AIoTF or ADM, the request message (i.e., the inventory request message) also carries a second fresh value, wherein the second fresh value includes one of the following: a second random number, a second count value, or a second sequence value.

[0159] Optionally, if the first fresh value is used in the encryption and / or integrity processing in step 303, the request message (i.e., the inventory request message) also carries the first fresh value.

[0160] In some embodiments, the first AIoT device performing step 305 may include: the first AIoT device receiving a paging message carrying an inventory request message; if the identifier of the first AIoT device carried in the inventory request message matches its own identifier, determining to temporarily enable radio frequency function (or radio frequency capability); the first AIoT device performing integrity verification and / or decryption of commands protected by a key pair; and if the integrity verification and / or decryption are successful, the first AIoT device executing the corresponding operation of the command. In this embodiment, the key is the key corresponding to the first AIoT device.

[0161] In one embodiment, on the first AIoT device side, the key is pre-shared between the first AIoT device and AIoTF or ADM, and this key (the key corresponding to the first AIoT device) is the Pre-Shared Key between the first AIoT device and the core network.

[0162] In this embodiment, the first AIoT device directly uses the locally stored key. For example, the first AIoT device may obtain a pre-shared key from its local storage as the key for this use, even if the request message (inventory request message) does not carry a second fresh value.

[0163] Optionally, the pre-shared key between the first AIoT device and the core network (or AIoTF or ADM) serves as both an integrity key and a confidentiality key.

[0164] Optionally, the pre-shared key includes a pre-shared integrity key and / or a pre-shared confidentiality key. The first AIoT device directly uses the pre-shared integrity key as the integrity key, and the first AIoT device directly uses the pre-shared confidentiality key as the confidentiality key.

[0165] In one embodiment, the key is an authenticated session key. This key (i.e., the key corresponding to the first AIoT device) can be referred to as the first AIoT device's authenticated session key. This authenticated session key can be generated after the first AIoT device authenticates with the network side, and the first AIoT device's authenticated session key can be stored in both the first AIoT device and the core network (AIoTF or ADM).

[0166] In this embodiment, the first AIoT device directly uses the locally stored key. For example, the first AIoT device may obtain the authenticated session key from locally as the key used for this operation, even if the request message (inventory request message) does not carry a second fresh value.

[0167] Optionally, the authenticated session key serves as both an integrity key and a confidentiality key.

[0168] Optionally, the authenticated session key includes an authenticated integrity key and / or an authenticated confidentiality key. The first AIoT device directly uses the authenticated integrity key as its integrity key, and the first AIoT device directly uses the authenticated confidentiality key as its confidentiality key.

[0169] In one embodiment, on the first AIoT device side, the key is calculated based on the root key and the second fresh value, wherein the second fresh value includes one of the following: a second random number, a second count value, and a second sequence value.

[0170] The second freshness value is carried in the request message, i.e., the inventory request message. For example, the first AIoT device may calculate the key while carrying the second freshness value in the request message (inventory request message).

[0171] Optionally, the key can serve as both an integrity key and a confidentiality key.

[0172] The specific method by which the first AIoT device calculates the key should be the same as the method used by ADM or AIoTF in the aforementioned embodiments to calculate the key based on the root key and the second fresh value, and will not be repeated here.

[0173] Optionally, the key may include an integrity key and / or a confidentiality key.

[0174] The calculation of the key by the first AIoT device based on the root key and the second fresh value may include: calculating a first key based on the root key and the second fresh value; deriving or proposing an integrity key and / or a confidentiality key based on the first key. The specific processing for calculating the first key, the integrity key, and the confidentiality key should be the same as that of AIoTF or ADM. As long as the integrity key calculated by the first AIoT device is the same as the integrity key obtained by AIoTF, and the confidentiality key calculated by the first AIoT device is the same as the confidentiality key obtained by AIoTF, it is within the scope of protection of this embodiment and is not limited here.

[0175] In one embodiment, the security protection command includes integrity verification parameters. The security protection command may also include commands.

[0176] The processing performed on the first AIoT device side verifies the integrity of the integrity verification parameters based on the key.

[0177] On the first AIoT device side, integrity verification based on the key pair integrity verification parameters may include: performing integrity verification on the integrity verification parameters based on the key, a first freshness value, and a pre-configured integrity protection algorithm, wherein the first freshness value includes one of the following: a first random number, a first count value, and a first sequence value. The key may be used for both integrity protection and encryption; alternatively, the key may be an integrity key.

[0178] The first freshness value can be carried in the request message, i.e., the inventory request message.

[0179] The pre-configured integrity protection algorithm can be pre-written into the first AIoT device. Here, we do not limit the specific algorithm or function. As long as the first AIoT device and the AIoTF use the same integrity protection algorithm, it is within the protection scope of this embodiment.

[0180] For example, the first AIoT device performs integrity verification on the integrity verification parameters based on the key, the first freshness value, and the pre-configured integrity protection algorithm, including: the first AIoT device uses the first freshness value and the command as input parameters for integrity protection calculation, and calculates the integrity verification parameters using the pre-configured integrity protection algorithm, the input parameters for integrity protection calculation, and the integrity key corresponding to the first AIoT device; and performs integrity verification based on the integrity verification parameters and the integrity verification parameters.

[0181] The input parameters for integrity verification calculation should be the same as those for AIoTF, and the calculation method for integrity verification parameters should also be the same as that for integrity verification parameters calculated on the AIoTF side. No further explanation will be given.

[0182] Integrity verification based on integrity check parameters and integrity verification parameters includes: determining that the integrity verification is successful or passes when the integrity check parameters and integrity verification parameters are the same; and / or determining that the integrity verification fails or does not pass when the integrity check parameters and integrity verification parameters are different.

[0183] In one embodiment, the secure command includes an encrypted command. Processing on the first AIoT device side includes decrypting the encrypted command based on a key.

[0184] The first AIoT device decrypts the encrypted command based on the key, which may include: decrypting the encrypted command based on the key, a first freshness value, and a pre-configured confidentiality protection algorithm, wherein the first freshness value includes one of the following: a first random number, a first count value, and a first sequence value. The key can be used for both integrity protection and encryption; alternatively, the key can be a confidentiality key.

[0185] The description of the first freshness value is the same as that in the previous embodiments, and will not be repeated here.

[0186] The pre-configured confidentiality protection algorithm is pre-written into the first AIoT device. Here, we do not limit its specific algorithm or function. As long as the first AIoT device and the AIoTF use the same confidentiality protection algorithm, it is within the protection scope of this embodiment.

[0187] For example, the first AIoT device decrypts the encrypted command based on a key, a first fresh value, and a pre-configured confidentiality protection algorithm. This includes: using the first fresh value as input parameters for decryption calculation; calculating a decryption key stream using the pre-configured confidentiality protection algorithm, the input parameters, and the confidentiality key corresponding to the first AIoT device; and performing a decryption operation between the decryption key stream and the encrypted command to obtain the decryption result. The operation performed between the decryption key stream and the encrypted command can be an XOR operation or other operations, which are not limited here.

[0188] The input parameters for the decryption calculation should be similar to those for the encryption calculation used on the AIoTF side. Specifically, in addition to the first fresh value, the input parameters for the decryption calculation may include other parameters, such as the length of the encrypted command, the length of the first fresh value, a fixed value assigned by a third party (e.g., FC = 0x7E), the bearer ID, a 1-bit transmission direction (e.g., 0 for uplink and 1 for downlink), the length of the decryption keystream (LENGTH), the permanent identifier of the first AIoT device, the length of the permanent identifier of the first AIoT device, the temporary identifier of the first AIoT device, the length of the temporary identifier of the first AIoT device, etc., at least one of these. The length of the decryption keystream can be the length of the encrypted command. This does not limit or exhaustively list all possible input parameters for the decryption calculation.

[0189] Furthermore, the processing after the first AIoT device obtains the decryption result may also include: if the decryption result is not garbled, determining that the decryption was successful or the verification of the security protection command was successful, and obtaining the command; and / or, if the decryption result is garbled, determining that the decryption failed or the verification of the security protection command failed.

[0190] In one embodiment, the security-protected command includes: an encrypted command and integrity verification parameters. The processing by the first AIoT device includes: performing integrity verification on the integrity verification parameters based on a key; and decrypting the encrypted command based on the key.

[0191] Preferably, AIoTF encrypts first and then protects integrity; the first AIoT device performs integrity verification first and then decrypts. The processing performed by the first AIoT device may include: performing integrity verification on the integrity verification parameters based on the key, the first freshness value, and a pre-configured integrity protection algorithm; and decrypting the encrypted command based on the key, the first freshness value, and the pre-configured confidentiality protection algorithm if the integrity verification is successful or passes.

[0192] The specific process for decrypting encrypted commands is the same as in the aforementioned embodiments and will not be repeated here.

[0193] The processing of integrity verification parameters differs from the previous embodiments only in that the commands in the input parameters of the integrity calculation are replaced with encrypted commands, so it will not be described again.

[0194] Optionally, AIoTF performs integrity protection before encryption; the first AIoT device decrypts the data before performing integrity verification. The processing performed by the first AIoT device may include: decrypting the encrypted command based on the key, the first freshness value, and a pre-configured confidentiality protection algorithm; and, if decryption is successful, performing integrity verification on the integrity verification parameters based on the key, the first freshness value, and the pre-configured integrity protection algorithm.

[0195] The specific processing of the encryption command is the same as in the previous embodiments, and the processing of the integrity verification parameters is also the same as in the previous embodiments, so they will not be described again.

[0196] Furthermore, the processing of the first AIoT device may include: if the integrity verification is successful and the decryption result is not garbled, determining that the security protection command verification is successful and obtaining the command; if the integrity verification fails and / or the decryption result is garbled, determining that the security protection command verification fails.

[0197] After the first AIoT device receives the command, it can execute the corresponding operation, such as activation or deactivation (temporary deactivation or permanent deactivation).

[0198] If the command is an activation command, the first AIoT device can perform step 306 after performing the activation operation. If the command is a temporary deactivation or permanent deactivation command, the first AIoT device can first perform step 306, and then perform the temporary deactivation or permanent deactivation operation.

[0199] In addition, if the first AIoT device fails to verify the security protection command, it can perform at least one of the following actions: terminate the process, or send a verification failure response to the AIoTF (which can be sent to the AIoTF via a reader / writer).

[0200] In one embodiment, the first AIoT device performing step 306 may be: the first AIoT device sends the response message to the AIoTF through the RAN / UEreader.

[0201] The method for generating the encrypted identifier of the first AIoT device may include: encrypting the identifier based on an encryption algorithm and an encryption key corresponding to the first AIoT device to obtain an encrypted identifier. The encryption key corresponding to the first AIoT device may be the same as or different from the confidentiality key in the aforementioned embodiments, and this is not limited here; the encryption algorithm may be pre-written into the first AIoT device, and this encryption algorithm may be the same as or different from the pre-configured confidentiality algorithm in the aforementioned embodiments, and this is not limited here.

[0202] In one embodiment, after receiving the response message, the AIoTF can execute step 307.

[0203] In one example, the response message carries an encrypted identifier of the first AIoT device.

[0204] AIoTF execution step 307 may include: receiving a response message from a first AIoT device, extracting the encrypted identifier of the first AIoT device from the response message; decrypting the encrypted identifier of the first AIoT device, and, if decryption is successful, obtaining the identifier of the first AIoT device. The related processing of AIoTF for decrypting the encrypted identifier should correspond to the processing of the first AIoT device for encrypting the identifier, and will not be repeated here.

[0205] In one example, the response message carries a temporary identifier for the first AIoT device.

[0206] AIoTF execution step 307 may include: receiving a response message from a first AIoT device and extracting a temporary identifier of the first AIoT device from the response message.

[0207] Optionally, the response message may also carry an acknowledgment of the command. Accordingly, the AIoTF processing may further include: obtaining an acknowledgment of the command and determining that the first AIoT device has completed the activation or deactivation operation corresponding to the command.

[0208] After AIoTF obtains the identifier of the first AIoT device (or the temporary identifier of the first AIoT device), step 308 can be performed, or step 308 can be omitted.

[0209] Optionally, step 308 may include: AIoTF directly sending the AIoT Inventory Response to AF.

[0210] Optionally, as shown in Figure 3, step 308 may include: AIoTF forwarding the AIoT Inventory Response to AF via NEF.

[0211] For the scenario of activating or deactivating each AIoT device in the first group (including the first AIoT device), the processing of steps 302a to 308 differs from the aforementioned embodiments mainly in that the key used by each AIoT device can be a group key.

[0212] In one embodiment, AIoTF checks whether the keys of the first group are stored or present locally. If the keys of the first group are present or stored, step 302a is executed.

[0213] AIoTF execution step 302a may include: AIoTF obtaining the key based on the group identification information of the first group. This key may refer to the key of the first group, or the group key of the first group, or the group key corresponding to the first group. For example, the AIoTF side may search for the security credentials of the first group based on the group identification information of the first group, and obtain the key from the security credentials of the first group.

[0214] This key is pre-shared between the AIoTF and the first group (including the first AIoT device). This key (the key corresponding to the first group) can also be referred to as the pre-shared key between the first group and the core network (or AIoTF).

[0215] Optionally, the pre-shared key can serve as both an integrity key and a confidentiality key.

[0216] Optionally, the pre-shared key between the first group and the core network (or AIoTF) includes a pre-shared integrity key and / or a pre-shared confidentiality key. The pre-shared integrity key serves as the integrity key corresponding to the first group, and the pre-shared confidentiality key serves as the confidentiality key corresponding to the first group.

[0217] In one embodiment, the AIoTF checks whether it stores or has the key for the first group locally. If it does not have or does not store the key for the first group, steps 302b and 302c are executed. In this embodiment, by executing steps 302b and 302c, the key obtained by the AIoTF is the key corresponding to the first group.

[0218] In one example, the key is pre-shared by each AIoT device and the ADM in a first group, which includes a first AIoT device. This key may be referred to as a pre-shared key, a pre-shared group key, or a pre-shared group key between each AIoT device in the first group and the core network (or ADM). The processing performed by AIoTF also includes receiving the key.

[0219] Specifically, in step 302b, the AIoT key Request message sent by AIoTF to ADM carries the group identification information of the first group.

[0220] In step 302c, the ADM sends an AIoT key response message to the AIoTF carrying a key. After receiving the AIoT key request message, the ADM's execution of step 302c may include: the ADM searching for the key of the first group in its local storage based on the group identification information of the first group carried in the AIoT key request message; and sending the key (or the group identification information and the key of the first group) to the AIoTF in the AIoT key response message. The specific processing in this example is similar to the way the AIoTF obtains the key of the first AIoT device from the ADM in the previous example, the only difference being that this example obtains the key of the first group, so it will not be described in detail.

[0221] In one example, on the AIoTF side, the key is calculated based on the root key and the second freshness value. The processing performed by AIoTF also includes receiving the root key. This root key can be the group root key corresponding to the first group.

[0222] Specifically, in step 302b, the AIoT key Request message sent by AIoTF to ADM carries the group identification information of the first group.

[0223] In step 302c, the ADM sends an AIoT key response message to the AIoTF carrying the root key. After receiving the AIoT key request message, the ADM can perform step 302c by: the ADM searching for the root key corresponding to the first group in its local storage based on the group identification information of the first group carried in the AIoT key request message; and sending the root key (or the group identification information of the first group and the root key) to the AIoTF in the AIoT key response message.

[0224] After AIoTF receives the root key and before performing step 303, the processing also includes: calculating a key based on the root key and a second fresh value. The description of the second fresh value is the same as in the previous embodiments and will not be repeated. The specific description of AIoTF calculating the key is similar to the process of calculating the key for the first AIoT device in the previous embodiments, the main difference being that the root key is the root key of the first group, and therefore will not be repeated.

[0225] In one example, the key is calculated by ADM based on the root key and a second fresh value. The processing performed by AIoTF also includes sending the second fresh value. The processing performed by AIoTF also includes receiving the key.

[0226] Specifically, in step 302b, the AIoT key Request message sent by AIoTF to ADM carries the group identification information of the first group and the second freshness value.

[0227] In step 302c, the ADM sends an AIoT key Response message to the AIoTF carrying a key. After receiving the AIoT key Request message, the ADM can perform step 302c by: the ADM searching for the root key of the first group in its local storage based on the group identification information of the first group carried in the AIoT key Request message; calculating the key based on the root key and the second freshness value; and sending the key (or the group identification information of the first group and the key) to the AIoTF in the AIoT key Response message.

[0228] The second fresh value is generated by AIoTF. The specific explanation of how AIoTF generates this second fresh value is the same as in the previous example, and therefore will not be repeated. The specific method of calculating the key on the ADM side is also similar to the previous embodiment, and will not be repeated.

[0229] In one example, the key is calculated by ADM based on the root key and a second fresh value. The processing performed by AIoTF also includes receiving the key. The processing performed by AIoTF further includes receiving the second fresh value.

[0230] Specifically, in step 302b, the AIoT key Request message sent by AIoTF to ADM carries the group identification information of the first group.

[0231] In step 302c, the ADM sends an AIoT key Response message to the AIoTF carrying a second fresh value and a key. After receiving the AIoT key Request message, the ADM can perform step 302c by: the ADM searching for the root key of the first group in its local storage based on the group identification information of the first group carried in the AIoT key Request message; calculating the key based on the root key and the second fresh value; and sending the second fresh value and the key (or the group identification information of the first group, the second fresh value and the key) in the AIoT key Response message to the AIoTF.

[0232] The second fresh value is generated by the ADM, and the relevant explanations for the second fresh value are the same as in the previous example, so they will not be repeated. The relevant processing for calculating the key corresponding to the first group on the ADM side is the same as in the previous example, so it will not be repeated.

[0233] In the group scenario, the processing of step 303 performed by AIoTF is similar to that in the aforementioned embodiments. The difference lies in that the key is the key corresponding to the first group. For example, the key corresponding to the first group can serve as both an integrity key and a confidentiality key, or the key corresponding to the first group includes both a confidentiality key and / or an integrity key. The input parameters for integrity calculation can include, in addition to the first fresh value and the command, other parameters such as the command length, the length of the first fresh value, a fixed value assigned by a third party (e.g., FC = 0x7E), the group identification information of the first group, the length of the group identification information of the first group, the identifier (temporary identifier and / or permanent identifier) ​​of each AIoT device in the first group, and the identifier (temporary identifier and / or permanent identifier) ​​of each AIoT device in the first group. The input parameters for the encrypted calculation may include, in addition to the first fresh value, other parameters such as the command length, the length of the first fresh value, a fixed value assigned by a third party (e.g., FC=0x7E), the bearer ID, a 1-bit transmission direction (e.g., 0 for the up line and 1 for the down line), the length of the key stream, the group identification information of the first group, the length of the group identification information of the first group, the identifier (temporary identifier and / or permanent identifier) ​​of each AIoT device in the first group, and the length of the identifier (temporary identifier and / or permanent identifier) ​​of each AIoT device in the first group, etc. The processing of step 303 by AIoTF in the group scenario will not be elaborated here.

[0234] Step 304 may specifically include: AIoTF forwards the AIoT Inventory Request (i.e., inventory request message) to each AIoT device in the first group through the RAN / UEreader.

[0235] In addition to security protection commands, the inventory request message may also include group identification information for the first group. Other content that the inventory request message may carry is the same as in the aforementioned embodiments and will not be repeated here.

[0236] The first AIoT device executing step 305 may include: the first AIoT device receiving a paging message carrying an inventory request message; if the group identification information of the first group carried in the inventory request message matches the group identification information of its own group, determining to temporarily enable the radio frequency function (or radio frequency capability); the first AIoT device performing integrity verification and / or decryption of the command based on key pair security protection; and the first AIoT device executing the corresponding operation of the command if the integrity verification and / or decryption are successful. In the group scenario, the specific processing of step 305 by the first AIoT device differs from the aforementioned embodiment only in that the key can be the key corresponding to the first group, and group identification information can be added to the input parameters of the integrity calculation and the decryption calculation. The remaining processing is the same and will not be described in detail.

[0237] The processing of step 306 after the first AIoT device receives the command is the same as in the previous embodiment and will not be repeated. The processing of steps 307 and 308 by AIoTF is the same as in the previous embodiment and will not be repeated.

[0238] By adopting the solution provided in the above embodiments, an inventory request message is sent to the first AIoT device, and the request message carries a security protection command to activate or deactivate the first AIoT device. In this way, when managing operations involving activating or deactivating the AIoT device by sending commands during the inventory process alone, the commands are securely protected, ensuring the security of the management operations.

[0239] Furthermore, the integrity and / or confidentiality of commands can be protected based on the pre-shared key between the first AIoT device and the core network. This eliminates the need for the AIoT device to perform authentication and session key generation processes, thus improving processing efficiency while ensuring the security of AIoT device management operations.

[0240] In some possible implementations, the request message is an inventory request message, which can be an inventory request message only in the inventory process. In this implementation, security protection and / or security verification are based on keys shared or jointly owned by the first AIoT device and a third party (such as AF and / or AAA servers).

[0241] Referring to Figure 4, another communication method in the inventory counting process will be explained:

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

[0243] After receiving the first request, AIoTF first checks whether it has or stores a key for security protection. If it does, it executes step 402a; otherwise, it executes step 402b.

[0244] Step 402a: AIoTF obtains the key locally and then performs step 403.

[0245] Step 402b: AIoTF sends an AIoT key Request message to the AAA server.

[0246] Step 402c: The AAA server sends an AIoT key response message to the AIoTF, whereby the AIoT key response message is used by the AIoTF to obtain the key, and then proceeds to step 403.

[0247] Steps 403 to 404 are the same as steps 303 to 304 in the previous embodiments, and will not be described again.

[0248] Step 405: The first AIoT device performs integrity verification and / or decryption of the security protection command.

[0249] Steps 406 to 408 are the same as steps 306 to 308 in the previous embodiments, and will not be described again.

[0250] In one embodiment, prior to step 401, at least one of the following may be included: step 400a: the reader and the network complete registration; step 400b: the first AIoT device shares subscription data with a third-party server (such as an AAA server or AF).

[0251] The description of step 400a is the same as that in the previous embodiment and will not be repeated. The only difference between step 400b and step 300b is that the first AIoT device shares the subscription data with the AAA server or AF.

[0252] In one embodiment, the AF side may not execute step 401, but instead the AIoTF may directly determine whether to execute step 402a or step 402b.

[0253] AIoTF can also perform step 402a or step 402b if it determines, based on its own needs or relevant strategies, that it needs to perform a simple inventory process to activate or deactivate the first AIoT device, or to activate or deactivate each AIoT device in the first group (including the first AIoT device).

[0254] In one example, if AIoTF determines, based on its own needs or relevant policies, that it needs to perform a simple inventory process to activate or deactivate the first AIoT device, it can execute step 402a. In this example, the subsequent steps 402a to 408 are for the scenario of activating or deactivating the first AIoT device.

[0255] In one example, if AIoTF determines, based on its own needs or relevant policies, that it needs to perform an inventory-only process to activate or deactivate each AIoT device in the first group, it executes step 402a. In this example, the subsequent steps 402a to 408 are for the scenario of activating or deactivating each AIoT device in the first group (including the first AIoT device).

[0256] Next, we will first explain steps 402a to 408 for the scenario of activating or deactivating the first AIoT device.

[0257] In one embodiment, AIoTF checks whether it has a key corresponding to the first AIoT device stored locally. If it has or stores the key of the first AIoT device, then step 402a is executed.

[0258] In this embodiment, the reason why AIoTF may store the key corresponding to the first AIoT device locally may be that AIoTF obtains and stores the key corresponding to the first AIoT device from the AF or AAA server in other processes.

[0259] Optionally, the key corresponding to the first AIoT device can serve as both an integrity key and a confidentiality key, meaning that the integrity key and the confidentiality key are the same.

[0260] Optionally, the key includes an integrity key and / or a confidentiality key. The integrity key and the confidentiality key are different; the integrity key can be referred to as the integrity key corresponding to the first AIoT device, and the confidentiality key can be referred to as the confidentiality key corresponding to the first AIoT device.

[0261] In one embodiment, the AIoTF checks whether it has the key of the first AIoT device stored locally. If it does not have or does not store the key of the first AIoT device, then step 402b is executed. In this embodiment, by executing steps 402b and 402c, the key finally obtained by the AIoTF is the key corresponding to the first AIoT device.

[0262] In one example, the processing performed by AIoTF also includes receiving the key.

[0263] Specifically, the AIoT key Request message in step 402b carries the identifier of the first AIoT device.

[0264] In step 402c, the AIoT key Response message carries the key. After receiving the AIoT key Request message, the AAA server may perform step 402c by: searching for the locally stored key based on the identifier of the first AIoT device carried in the AIoT key Request message; and sending the key (or the identifier and key of the first AIoT device) to AIoTF in the AIoT key Response message.

[0265] For example, finding the locally stored key based on the identifier of the first AIoT device carried in the AIoT key Request message may include: finding the locally stored key corresponding to the first AIoT device based on the identifier of the first AIoT device carried in the AIoT key Request message, and sending the key (or the identifier and key of the first AIoT device) back to AIoTF in the AIoT key Response message.

[0266] Optionally, this key is pre-shared between the first AIoT device and the AAA server; this key can be referred to as the pre-shared key between the first AIoT device and the AAA server. The pre-shared key between the first AIoT device and the AAA server can serve as both an integrity key and a confidentiality key.

[0267] Optionally, the key includes an integrity key and / or a confidentiality key. The integrity key can be a pre-shared integrity key between the first AIoT device and the AAA server, and the confidentiality key can be a pre-shared confidentiality key between the first AIoT device and the AAA server.

[0268] In one example, on the AIoTF side, the key is calculated based on the root key and a second fresh value, wherein the second fresh value may include one of the following: a second random number, a second count value, or a second sequence value.

[0269] The processing performed by AIoTF also includes receiving the root key. This root key is the root key of the first AIoT device.

[0270] Specifically, the AIoT key Request message in step 402b carries the identifier of the first AIoT device.

[0271] The AIoT key Response message in step 402c carries the root key. After receiving the AIoT key Request message, the AAA server may perform step 402c by: finding the root key of the first AIoT device stored locally based on the identifier of the first AIoT device carried in the AIoT key Request message; and sending the root key (or the identifier and root key of the first AIoT device) to AIoTF in the AIoT key Response message.

[0272] The processing after AIoTF receives the root key and before performing step 403 also includes: calculating the key based on the root key and the second fresh value.

[0273] The explanation of the second freshness value is the same as that in the aforementioned embodiments, and will not be repeated here.

[0274] Optionally, the key can serve as both an integrity key and a confidentiality key.

[0275] The key is calculated on the AIoTF side based on the root key and the second freshness value. The relevant explanations for calculating the key in AIoTF are the same as those in the previous embodiments, and will not be repeated here.

[0276] Optionally, the key may include an integrity key and / or a confidentiality key.

[0277] AIoTF's key calculation based on the root key and the second freshness value may include: calculating a first key based on the root key and the second freshness value; and deriving or proposing an integrity key and / or a confidentiality key based on the first key. The related explanations for AIoTF's calculation of the first key, integrity key, and confidentiality key are the same as in the aforementioned embodiments and will not be repeated.

[0278] In one example, the key is calculated by the AAA server based on the root key and a second fresh value. The processing performed by AIoTF also includes sending the second fresh value. The processing performed by AIoTF also includes receiving the key.

[0279] Specifically, the AIoT key Request message in step 402b carries the identifier of the first AIoT device and the second freshness value.

[0280] The AIoT key Response message in step 402c carries a key. After receiving the AIoT key Request message, the AAA server may perform step 402c by: finding the root key of the first AIoT device in local storage based on the identifier of the first AIoT device carried in the AIoT key Request message; calculating the key based on the root key and the second freshness value; and sending the key (or the identifier and key of the first AIoT device) to AIoTF in the AIoT key Response message.

[0281] The second fresh value is generated by AIoTF. The explanation of how AIoTF generates this second fresh value is the same as in the previous example, so it will not be repeated here.

[0282] Optionally, the key can serve as both an integrity key and a confidentiality key. The process of calculating the key based on the root key and the second fresh value on the AAA server side is the same as the process of calculating the key based on the root key and the second fresh value in the aforementioned examples of AIoTF or ADM, and will not be repeated here.

[0283] Optionally, the key may include an integrity key and / or a confidentiality key.

[0284] The AAA server's calculation of keys based on the root key and the second fresh value may include: calculating a first key based on the root key and the second fresh value; deriving or deducing an integrity key and / or a confidentiality key based on the first key.

[0285] The method by which the AAA server calculates the first key is the same as that of AIoTF or ADM, and will not be repeated here.

[0286] This embodiment does not limit the specific processing method of the AAA server deriving or deducing the integrity key based on the first key; nor does it limit the specific processing method of deriving or deducing the confidentiality key based on the first key, as long as the final generated integrity key and confidentiality key are different, it is within the protection scope of this embodiment.

[0287] In one example, the key is calculated by the AAA server based on the root key and a second fresh value. The processing performed by AIoTF also includes receiving the key. The processing performed by AIoTF further includes receiving the second fresh value.

[0288] Specifically, the AIoT key Request message in step 402b carries the identifier of the first AIoT device.

[0289] The AIoT key Response message in step 402c carries a second fresh value and a key. After receiving the AIoT key Request message, the AAA server may perform step 302c by: finding the root key of the first AIoT device stored locally based on the identifier of the first AIoT device carried in the AIoT key Request message; calculating the key based on the root key and the second fresh value; and sending the second fresh value and the key (or the identifier of the first AIoT device, the second fresh value, and the key) to AIoTF in the AIoT key Response message.

[0290] The content of the second fresh value is the same as that in the previous embodiment. The only difference is that in this example, it is replaced by one of the second random number, the second count value, and the second sequence value generated by the AAA server. The specific method by which the AAA server generates one of the second random number, the second count value, and the second sequence value is similar to that of AIoTF, so it will not be described again.

[0291] The key calculated on the AAA server side can also serve as both an integrity key and a confidentiality key, or it can include both integrity and / or confidentiality keys. The specific explanation of the AAA server's key calculation is the same as the previous example and will not be repeated.

[0292] In some embodiments, the first AIoT device performs step 405 in a process similar to step 305 in the foregoing embodiments. The difference lies in the fact that, in this embodiment, the side key or root key of the first AIoT device is different from that in step 305 of the foregoing embodiments.

[0293] In one embodiment, on the first AIoT device side, the key is pre-shared between the first AIoT device and the AAA server. This key (the key corresponding to the first AIoT device) is a pre-shared key between the first AIoT device and the AAA server.

[0294] Optionally, the pre-shared key serves as both an integrity key and a confidentiality key.

[0295] Optionally, the key includes an integrity key and / or a confidentiality key. That is, the pre-shared key between the first AIoT device and the AAA server includes a pre-shared integrity key and / or a pre-shared confidentiality key.

[0296] In this embodiment, the first AIoT device directly uses the locally stored key.

[0297] In one embodiment, on the first AIoT device side, the key is calculated based on the root key and a second freshness value. The second freshness value is carried by the request message, i.e., the inventory request message.

[0298] Optionally, the key can serve as both an integrity key and a confidentiality key.

[0299] The specific method by which the first AIoT device calculates the key should be the same as the method by which the AIoTF or AAA server calculates the key based on the root key and the second fresh value in the aforementioned embodiments, and will not be repeated here.

[0300] Optionally, the key may include an integrity key and / or a confidentiality key.

[0301] The calculation of the key by the first AIoT device based on the root key and the second fresh value may include: calculating a first key based on the root key and the second fresh value; deriving or proposing an integrity key and / or a confidentiality key based on the first key. The specific processing related to calculating the first key, the integrity key, and the confidentiality key should be the same as that of the AIoTF or AAA server. As long as the integrity key calculated by the first AIoT device is the same as the integrity key obtained by the AIoTF, and the confidentiality key calculated by the first AIoT device is the same as the confidentiality key obtained by the AIoTF, it is within the scope of protection of this embodiment and is not limited here.

[0302] The specific process of integrity verification and / or decryption performed by the first AIoT device is the same as step 305 in the aforementioned embodiment, and therefore will not be described in detail.

[0303] In some alternative embodiments, when activating or deactivating the first AIoT device, the aforementioned key may be pre-shared between the first AIoT device and the AF. This key may serve as both an integrity key and a confidentiality key; or the key may include both an integrity key and / or a confidentiality key.

[0304] In this embodiment, in step 401, the AF can send the key corresponding to the first AIoT device to the AIoTF in the first request.

[0305] In this embodiment, steps 402a, 402b, and 402c do not need to be executed. After receiving the first request, AIoTF can directly execute step 403.

[0306] Steps 403 to 404 are the same as steps 303 to 304 in the previous embodiments, and will not be described again.

[0307] In step 405, the first AIoT device can directly use the key shared with AF for integrity verification and / or decryption. Other processing in step 405 is the same as in the aforementioned embodiments and will not be described in detail.

[0308] Steps 406 to 408 are the same as steps 306 to 308 in the previous embodiments, and will not be described again.

[0309] Next, steps 402a to 408 will be explained for the scenario of activating or deactivating each AIoT device in the first group.

[0310] In one embodiment, AIoTF checks whether it has or stores the key corresponding to the first group locally. If it has or stores the key of the first group, then step 402a is executed.

[0311] In this embodiment, the reason why the AIoTF may store the key corresponding to the first group locally may be that the AIoTF obtains and stores the key corresponding to the first group from the AF or AAA server in other processes.

[0312] Optionally, the key corresponding to the first group can be used as both an integrity key and a confidentiality key, that is, the integrity key and the confidentiality key are the same.

[0313] Optionally, the key includes an integrity key and / or a confidentiality key. The integrity key and the confidentiality key are different; the integrity key can be referred to as the integrity key corresponding to the first group, and the confidentiality key can be referred to as the confidentiality key corresponding to the first group.

[0314] In one embodiment, the AIoTF checks whether it stores or has the key for the first group locally. If it does not have or does not store the key for the first A group, then step 402b is executed. In this embodiment, by executing steps 402b and 402c, the key finally obtained by the AIoTF side is the key corresponding to the first group.

[0315] In one example, the processing performed by AIoTF also includes receiving the key.

[0316] Specifically, the AIoT key Request message in step 402b carries the group identification information of the first group.

[0317] In step 402c, the AIoT key Response message carries a key. After receiving the AIoT key Request message, the AAA server may perform step 402c by: finding the key corresponding to the first group in local storage based on the group identification information of the first group carried in the AIoT key Request message; and sending the key (or the group identification information of the first group and the key) to AIoTF in the AIoT key Response message.

[0318] Optionally, the key is pre-shared by the various AIoT devices in the first group and the AAA server. This key can be referred to as the pre-shared key between the first group and the AAA server, and it can serve as both an integrity key and a confidentiality key.

[0319] Optionally, the key includes an integrity key and / or a confidentiality key. The integrity key can be a pre-shared integrity key between the first group and the AAA server, and the confidentiality key can be a pre-shared confidentiality key between the first group and the AAA server.

[0320] In one example, on the AIoTF side, the key is calculated based on the root key and a second fresh value, wherein the second fresh value may include one of the following: a second random number, a second count value, or a second sequence value.

[0321] The processing performed by AIoTF also includes receiving the root key. This root key is the root key for the first group.

[0322] Specifically, the AIoT key Request message in step 402b carries the group identification information of the first group.

[0323] The AIoT key Response message in step 402c carries the root key. After receiving the AIoT key Request message, the AAA server may perform step 402c by: finding the root key of the first group stored locally based on the group identification information of the first group carried in the AIoT key Request message; and sending the root key (or the group identification information of the first group and the root key) to AIoTF in the AIoT key Response message.

[0324] The processing after AIoTF receives the root key and before performing step 403 also includes: calculating the key based on the root key and the second freshness value. The relevant description of the second freshness value is the same as in the previous embodiments and will not be repeated.

[0325] Optionally, the key can serve as both an integrity key and a confidentiality key.

[0326] On the AIoTF side, the key corresponding to the first group is calculated based on the root key and the second fresh value. The relevant explanations for AIoTF calculating the key corresponding to the first group are the same as those in the previous embodiments and will not be repeated.

[0327] Optionally, the key may include an integrity key and / or a confidentiality key.

[0328] AIoTF's key calculation based on the root key and the second fresh value may include: calculating a first key based on the root key and the second fresh value; deriving or proposing an integrity key and / or a confidentiality key corresponding to the first group based on the first key. The related explanations for AIoTF's calculation of the first key, the integrity key corresponding to the first group, and the confidentiality key corresponding to the first group are the same as in the aforementioned embodiments and will not be repeated.

[0329] In one example, the key is calculated by the AAA server based on the root key and a second fresh value. The processing performed by AIoTF also includes sending the second fresh value. The processing performed by AIoTF also includes receiving the key.

[0330] Specifically, the AIoT key Request message in step 402b carries the group identification information of the first group and the second freshness value.

[0331] The AIoT key Response message in step 402c carries a key. After receiving the AIoT key Request message, the AAA server may perform step 402c by: finding the root key of the first group in local storage based on the group identification information of the first group carried in the AIoT key Request message; calculating the key corresponding to the first group based on the root key and the second freshness value; and sending the key (or the group identification information and the key of the first group) to AIoTF in the AIoT key Response message.

[0332] The explanation of how AIoTF specifically generates this second fresh value is the same as in the previous example, so it will not be repeated here.

[0333] Optionally, the key can serve as both an integrity key and a confidentiality key. The process of calculating the key corresponding to the first group based on the root key and the second freshness value on the AAA server side is the same as the process of calculating the key corresponding to the first group based on the root key and the second freshness value in the aforementioned AIoTF example, and will not be repeated. The method by which the AAA server calculates the first key is the same as the method by which AIoTF calculates the first key, and will not be repeated. The specific processing method by which the AAA server derives or deduces the integrity key corresponding to the first group based on the first key is not limited in this embodiment; the specific processing method by which it derives or deduces the confidentiality key corresponding to the first group based on the first key is also not limited in this embodiment, as long as the ultimately generated integrity key and confidentiality key are different, it is within the protection scope of this embodiment.

[0334] In one example, the key is calculated by the AAA server based on the root key and a second fresh value. The processing performed by AIoTF also includes receiving the key. The processing performed by AIoTF further includes receiving the second fresh value.

[0335] Specifically, the AIoT key Request message in step 402b carries the group identification information of the first group.

[0336] The AIoT key Response message in step 402c carries a second fresh value and a key. After receiving the AIoT key Request message, the AAA server may perform step 302c by: finding the root key of the first group stored locally based on the group identification information of the first group carried in the AIoT key Request message; calculating the key based on the root key and the second fresh value; and sending the second fresh value and the key (or the group identification information of the first group, the second fresh value and the key) to AIoTF in the AIoT key Response message.

[0337] The content of the second fresh value is the same as that in the previous embodiment. The only difference is that in this example, it is replaced by one of the second random number, the second count value, and the second sequence value generated by the AAA server. The specific method by which the AAA server generates one of the second random number, the second count value, and the second sequence value is similar to that of AIoTF, so it will not be described again.

[0338] The key calculated on the AAA server side can also serve as both an integrity key and a confidentiality key, or it can include both integrity and / or confidentiality keys. The specific explanation of the AAA server's key calculation is the same as the previous example and will not be repeated.

[0339] In some embodiments, the first AIoT device performs step 405 in a manner similar to step 305 in the foregoing embodiments.

[0340] In one embodiment, on the first AIoT device side, the key is pre-shared between each AIoT device in the first group (including the first AIoT device) and the AAA server. This key (the key corresponding to the first group) is the Pre-Shared Key between the first group and the AAA server.

[0341] Optionally, the pre-shared key serves as both an integrity key and a confidentiality key.

[0342] Optionally, the key may include an integrity key and / or a confidentiality key.

[0343] In this embodiment, the first AIoT device directly uses the locally stored key.

[0344] In one embodiment, on the first AIoT device side, the key is calculated based on the root key and a second freshness value. The second freshness value is carried by the request message, i.e., the inventory request message.

[0345] Optionally, the key can serve as both an integrity key and a confidentiality key.

[0346] The specific method by which the first AIoT device calculates the key corresponding to the first group should be the same as the method by which the AIoTF or AAA server calculates the key corresponding to the first group based on the root key and the second fresh value in the aforementioned embodiments, and will not be repeated here.

[0347] Optionally, the key may include an integrity key and / or a confidentiality key.

[0348] The calculation of keys by the first AIoT device based on the root key and the second fresh value may include: calculating a first key based on the root key and the second fresh value; deriving or proposing an integrity key and / or a confidentiality key corresponding to the first group based on the first key. The specific processing for calculating the first key, the integrity key corresponding to the first group, and the confidentiality key corresponding to the first group should be the same as that of the AIoTF or AAA server. As long as the integrity key corresponding to the first group calculated by the first AIoT device is the same as the integrity key corresponding to the first group obtained by the AIoTF, and the confidentiality key corresponding to the first group calculated by the first AIoT device is the same as the confidentiality key corresponding to the first group obtained by the AIoTF, it is within the scope of protection of this embodiment and is not limited here.

[0349] The specific process of integrity verification and / or decryption performed by the first AIoT device is the same as step 305 in the aforementioned embodiment, and therefore will not be described in detail.

[0350] By adopting the solution provided in the above embodiments, an inventory request message is sent to the first AIoT device, and the request message carries a security protection command to activate or deactivate the first AIoT device. In this way, when managing operations involving activating or deactivating the AIoT device by sending commands during the inventory process alone, the commands are securely protected, ensuring the security of the management operations.

[0351] Furthermore, the integrity and / or confidentiality of commands can be protected based on a pre-shared key between the first AIoT device and a third-party server (AAA server or AF). This eliminates the need for the AIoT device to perform authentication and generate session keys, thus improving processing efficiency while ensuring the security of AIoT device management operations.

[0352] In some possible implementations, the request message is a command request message, which can be a command request message in a command-only flow.

[0353] Referring to Figure 5, the communication method in the command-only flow is explained:

[0354] Step 501: The AF sends a second request to the AIoTF. The second request carries at least one of the following: identification information, or a command. Specifically, the second request can be a command request or a command service request message, such as carrying a service type indicator indicating command only.

[0355] After receiving the second request, AIoTF first checks whether it has or stores a key for security protection. If it does, it executes step 502a; otherwise, it executes step 502b.

[0356] Step 502a: AIoTF obtains the key locally and then performs step 503.

[0357] Step 502b: AIoTF sends an AIoT key Request message to the ADM / AAA server.

[0358] Step 502c: The ADM / AAA server sends an AIoT key response message to the AIoTF. The AIoT key response message is used by the AIoTF to obtain the key, and then step 503 is executed.

[0359] Step 503 is the same as step 303 in the previous embodiment, and will not be described again.

[0360] Step 504: AIoTF sends an AIoT Command Request message through the UE / RAN reader. This command request message contains a security-protected command, which may include at least one of the following: an encrypted command or an integrity verification parameter. The command can be an Enable Command or a Disable Command (such as a temporary deactivation command or a permanent deactivation command).

[0361] Step 505: The first AIoT device performs integrity verification and / or decryption of the security protection command.

[0362] Step 506: The first AIoT device sends a response message, wherein the response message carries an acknowledgment of the command. This response message is a command response message (e.g., AIoT Command Response).

[0363] Step 507: AIoTF sends the command response message to AF.

[0364] In one embodiment, prior to step 501, at least one of the following may be included: step 500a: the reader (represented as RAN / UE Reader in Figure 5) and the network complete registration; step 500b: the first AIoT device shares subscription data with the core network or AF or AAA server.

[0365] The description of step 500a is the same as that of step 300a in the aforementioned embodiment, and will not be repeated.

[0366] The only difference between step 500b and the aforementioned step 30b is that the first AIoT device shares the subscription data with the AAA server or AF or core network.

[0367] In one embodiment, the AF can determine whether to execute step 501 based on its own needs or strategy. Here, the specific triggering reason for the AF to send the first request is not limited.

[0368] Optionally, step 501 can be: AF can directly send a second request to AIoTF.

[0369] Optionally, as shown in Figure 5, step 501 can be: AF sends a second request to AIoTF through NEF (Network Exposure Function).

[0370] The descriptions of the relevant information and commands are the same as those in the previous embodiments, and will not be repeated here.

[0371] When the relevant information is identified as the identifier of the first AIoT device, the subsequent steps 502a to 507 are for the scenario of activating or deactivating the first AIoT device. When the relevant information is identified as the group identification information of the first group, the subsequent steps 502a to 507 are for the scenario of activating or deactivating each AIoT device (including the first AIoT device) in the first group.

[0372] In one embodiment, the AF side may not execute step 501, but instead the AIoTF may directly determine whether to execute step 502a or step 502b.

[0373] AIoTF can also perform step 502a or step 502b if, based on its own needs or relevant strategies, it determines that a simple inventory process is required to activate or deactivate the first AIoT device, or to activate or deactivate each AIoT device in the first group (including the first AIoT device). This will not be repeated here.

[0374] Next, we will first explain steps 502a to 507 for the scenario of activating or deactivating the first AIoT device.

[0375] In one embodiment, AIoTF checks whether it has a key corresponding to the first AIoT device stored locally. If it has or stores the key of the first AIoT device, then step 502a is executed.

[0376] In this embodiment, the description of the key corresponding to the first AIoT device stored locally by the AIoTF is the same as the description of step 302a in the previous embodiment, and will not be repeated.

[0377] In one embodiment, the AIoTF checks whether it has the key of the first AIoT device stored locally. If it does not have or has not stored the key of the first AIoT device, then step 502b is executed. In this embodiment, by executing steps 502b and 502c, the key finally obtained by the AIoTF is the key corresponding to the first AIoT device.

[0378] Optionally, steps 502b and 502c can be performed between the AIoTF and the ADM. In this case, the processing performed between the AIoTF and the ADM is the same as steps 302b and 302c in the foregoing embodiments, and will not be described again.

[0379] Optionally, the AIoTF can perform steps 502b and 502c with the AAA server. In this case, the processing performed between the AIoTF and the AAA server is the same as steps 402b and 402c in the foregoing embodiments, and will not be described again.

[0380] In an alternative embodiment, the AF may carry the key corresponding to the first AIoT device in the second request. In this embodiment, the AIoTF may no longer need to execute steps 502a to 502c.

[0381] In one embodiment, step 504 may specifically include: AIoTF forwarding a command request message to the first AIoT device through the RAN / UEreader.

[0382] In addition to security protection commands, the command request message may also include the AIoT ID (identifier of the first AIoT device).

[0383] Optionally, if the key (the key corresponding to the first AIoT device) is calculated by the AIoTF, ADM, or AAA server, the request message (i.e., the command request message) also carries a second fresh value.

[0384] Optionally, if the first fresh value is used in the encryption and / or integrity protection process in step 503, the request message (i.e., the command request message) also carries the first fresh value.

[0385] In some embodiments, the first AIoT device performs step 505 in a process similar to step 305 in the foregoing embodiments. The difference lies in the fact that, in this embodiment, the side key or root key of the first AIoT device is different from that in step 505 of the foregoing embodiments.

[0386] In one embodiment, the key is pre-shared by the first AIoT device and one of the following: ADM, AF, AAA server, or AIoTF. This key (the key corresponding to the first AIoT device) is a pre-shared key.

[0387] Optionally, the pre-shared key serves as both an integrity key and a confidentiality key.

[0388] Optionally, the key includes an integrity key and / or a confidentiality key. That is, the key corresponding to the first AIoT device includes a pre-shared integrity key and / or a pre-shared confidentiality key.

[0389] In this embodiment, the first AIoT device directly uses the locally stored key.

[0390] In one embodiment, the key is an authenticated session key. The relevant description of the authenticated session key is the same as that in the previous embodiment and will not be repeated here.

[0391] In one embodiment, on the first AIoT device side, the key is calculated based on the root key and a second freshness value. The second freshness value is carried by the request message, i.e., the inventory request message.

[0392] Optionally, the key can serve as both an integrity key and a confidentiality key.

[0393] The specific method by which the first AIoT device calculates the key should be the same as the method used by the AIoTF, AAA server, or ADM in the aforementioned embodiments to calculate the key based on the root key and the second fresh value, and will not be repeated here.

[0394] Optionally, the key may include an integrity key and / or a confidentiality key.

[0395] The calculation of the key by the first AIoT device based on the root key and the second fresh value may include: calculating a first key based on the root key and the second fresh value; deriving or proposing an integrity key and / or a confidentiality key based on the first key. The specific processing related to calculating the first key, the integrity key, and the confidentiality key should be the same as that of the AIoTF, AAA server, or ADM. As long as the integrity key calculated by the first AIoT device is the same as the integrity key obtained by the AIoTF, and the confidentiality key calculated by the first AIoT device is the same as the confidentiality key obtained by the AIoTF, it is within the scope of protection of this embodiment and is not limited here.

[0396] The specific process of integrity verification and / or decryption performed by the first AIoT device is the same as step 305 in the aforementioned embodiment, and therefore will not be described in detail.

[0397] In one embodiment, the first AIoT device performing step 506 may be: the first AIoT device sends the response message to the AIoTF through the RAN / UEreader.

[0398] After receiving the response message, AIoTF can proceed to step 507.

[0399] Optionally, step 508 may include: AIoTF directly sending the AIoT Command Response to AF.

[0400] Optionally, as shown in Figure 5, step 508 may include: AIoTF forwarding the AIoT Command Response to AF via NEF.

[0401] For the scenario of activating or deactivating each AIoT device in the first group (including the first AIoT device), the descriptions of steps 502a to 507 are similar to those for activating or deactivating the first AIoT device, except that the key is replaced with the key corresponding to the first group, or the integrity key and / or the confidentiality key corresponding to the first group, so they will not be repeated.

[0402] In some alternative embodiments, the communication method provided in this application can also be used in the inventory and command flow, as illustrated in Figure 5:

[0403] Optionally, in step 501, the second request may be an inventory and command request, or the second request may carry a business type, which is used to indicate inventory and command.

[0404] After receiving the second request, AIoT F can send an inventory request message through the Reader. The inventory request message can carry content specified by the relevant protocol, such as the identifier of the first AIoT device.

[0405] If AIoT F does not receive an inventory response message from the first AIoT device, it determines that paging the first AIoT device has failed, and AIoT F can further determine that the reason for the failure to paging the first AIoT device is that the first AIoT device has been temporarily deactivated.

[0406] Then, AIoTF can check whether it has or stores a secure key. If it does, it proceeds to step 502a; otherwise, it proceeds to step 502b.

[0407] Optionally, AIoT F can also trigger the execution of inventory and command processes on its own. That is, AIoT F does not trigger the execution of subsequent execution steps 502a or 502b based on the second request of AF. This will not be repeated here.

[0408] Steps 502a to 503 are the same as those in the previous embodiments and will not be described again.

[0409] Step 504 is similar, except that the command request message contains a security-protected command. The security-protected command may include at least one of the following: an (encrypted) command and an integrity verification parameter. Preferably, the command may be an Enable Command.

[0410] Steps 505 and 506 are the same as in the above embodiment, except that step 507 may not be executed in this embodiment, which is not limited here.

[0411] By adopting the solution provided in the above embodiments, a command request message is sent to the first AIoT device, and the request message carries a security-protected command to activate or deactivate the first AIoT device. In this way, when performing management operations to activate or deactivate the AIoT device by sending commands in a command-only flow, the commands are securely protected, ensuring the security of the management operations.

[0412] The solutions provided in this embodiment can send a request message to the first AIoT device, and carry a security protection command in the request message to activate or deactivate the first AIoT device. In this way, when performing management operations to activate or deactivate the AIoT device via commands, the commands can be securely protected, ensuring the security of the management operations.

[0413] Furthermore, the integrity and / or confidentiality of commands can be protected based on a pre-shared key between the first AIoT device and the core network, or between the first AIoT device and a third-party server (AAA server or AF). This eliminates the need for the AIoT device to perform authentication and generate session keys, thereby improving processing efficiency while ensuring the security of AIoT device management operations.

[0414] Furthermore, a request message carrying a security protection command can be sent to the first AIoT device in either an inventory-only process or a command-only process. This enables management operations on AIoT devices across multiple processes, ensuring the security of these operations and comprehensive scenario coverage.

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

[0416] The first communication unit 601 is configured to receive a request message, wherein the request message carries a security protection command, the command being used to activate or deactivate the first AIoT device.

[0417] The security protection commands include integrity verification parameters.

[0418] As shown in Figure 6, the first AIoT device also includes a first processing unit 602.

[0419] The first processing unit is used to perform integrity verification on the integrity verification parameters based on the key.

[0420] The first processing unit is configured to perform integrity verification on the integrity verification parameters based on the key, the first freshness value, and the pre-configured integrity protection algorithm, wherein the first freshness value includes one of the following: a first random number, a first count value, and a first sequence value.

[0421] The security protection commands include encrypted commands.

[0422] The first processing unit is used to decrypt the encrypted command based on the key.

[0423] The first processing unit is configured to decrypt the encrypted command based on the key, the first freshness value, and a pre-configured confidentiality protection algorithm, wherein the first freshness value includes one of the following: a first random number, a first count value, and a first sequence value.

[0424] The key is pre-shared by the first AIoT device and one of the following: ADM, application function AF, AAA server, and AIoT function F.

[0425] The key is the authenticated session key.

[0426] The key is calculated based on the root key and a second fresh value, wherein the second fresh value includes one of the following: a second random number, a second count value, and a second sequence value.

[0427] The key includes an integrity key and / or a confidentiality key.

[0428] The request message is one of the following: inventory request message or command request message.

[0429] The first communication unit is configured to send a response message, wherein the response message carries at least one of the following: an encrypted identifier of the first AIoT device, a temporary identifier of the first AIoT device, and a confirmation response to the command.

[0430] The response message is one of the following: inventory response message or command response message.

[0431] Figure 7 is a schematic diagram of the composition structure of an AIoTF according to an embodiment of this application, including:

[0432] The second communication unit 701 is used to send a request message, wherein the request message carries a security protection command, and the command is used to activate or deactivate the first AIoT device.

[0433] The security protection commands include encrypted commands.

[0434] As shown in Figure 7, the AIoTF also includes a second processing unit 702.

[0435] The second processing unit is used to encrypt the command based on the key to obtain the encrypted command.

[0436] The second processing unit is used to encrypt the command to obtain the encrypted command based on the key, the first freshness value and the pre-configured confidentiality protection algorithm, wherein the first freshness value includes one of the following: a first random number, a first count value, and a first sequence value.

[0437] The security protection commands include integrity verification parameters.

[0438] The second processing unit is used to calculate the integrity verification parameters based on the key and the command.

[0439] The second processing unit is used to calculate the integrity verification parameters for the command based on the key, the first freshness value and the pre-configured integrity protection algorithm, wherein the first freshness value includes one of the following: a first random number, a first count value, and a first sequence value.

[0440] The second processing unit is used to calculate the integrity verification parameters based on the key and the encrypted command.

[0441] The second processing unit is used to calculate the integrity verification parameters for the encrypted command based on the key, the first freshness value and the pre-configured integrity protection algorithm, wherein the first freshness value includes one of the following: a first random number, a first count value, and a first sequence value.

[0442] The key is pre-shared between the AIoTF and the first AIoT device.

[0443] The key is the authenticated session key.

[0444] The second communication unit is used to receive the key.

[0445] The key is calculated based on the root key and a second fresh value, wherein the second fresh value includes one of the following: a second random number, a second count value, and a second sequence value.

[0446] The key includes an integrity key and / or a confidentiality key.

[0447] The request message is one of the following: inventory request message or command request message.

[0448] The second communication unit is configured to receive a response message, wherein the response message carries at least one of the following: an encrypted identifier of the first AIoT device, a temporary identifier of the first AIoT device, and a confirmation response to the command.

[0449] The response message is one of the following: inventory response message or command response message.

[0450] The device in this application embodiment can realize the corresponding functions of the various devices in the foregoing communication 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.).

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

[0452] In one possible implementation, the communication device 800 may be the first AIoT device or AIoTF in the embodiments of this application, and the communication device 800 may implement the corresponding processes implemented by the first AIoT device or AIoTF in the various methods of the embodiments of this application. For the sake of brevity, it will not be described in detail here.

[0453] Figure 9 is a schematic structural diagram of a chip 900 according to an embodiment of this application. The chip 900 includes a processor 910, which can call and run computer programs from a memory to implement the methods in the embodiments of this application. In one possible implementation, the chip 900 may further include a memory 920. The processor 910 can call and run computer programs from the memory 920 to implement the methods executed by the first AIoT device or AIoTF 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 chip 900 may further include an input interface 930. The processor 910 can control the input interface 930 to communicate with other devices or chips, specifically, to acquire information or data sent by other devices or chips. In one possible implementation, the chip 900 may further include an output interface 940. The processor 910 can control the output interface 940 to communicate with other devices or chips, specifically, to output information or data to other devices or chips.

[0454] In one possible implementation, the chip can be applied to the first AIoT device or AIoTF in the embodiments of this application, and the chip can implement the corresponding processes implemented by the first 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-on-a-chip, chip system, or system-on-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 may 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.

[0455] This application also provides a communication system. The communication system includes a first AIoT device and an AIoTF. The first AIoT device is used to implement the corresponding functions implemented by the first AIoT device in the above-described method, and the AIoTF is used to implement the corresponding functions implemented by the AIoTF in the above-described method. Alternatively, the first AIoT device is used to implement the corresponding functions implemented by the first AIoT device in the above-described method, and the AIoTF is used to implement the corresponding functions implemented by the AIoTF in the above-described method.

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

[0457] 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. A communication method performed by a first-environment Internet of Things (AIoT) device, comprising: A request message is received, wherein the request message carries a security protection command, which is used to activate or deactivate the first AIoT device.

2. The method of claim 1, wherein, The security protection commands include integrity verification parameters; The method further includes: Integrity verification is performed on the integrity verification parameters based on the key.

3. The method of claim 2, wherein, The integrity verification based on the key for the integrity verification parameters includes: Integrity verification is performed on the integrity verification parameters based on the key, the first freshness value, and the pre-configured integrity protection algorithm, wherein the first freshness value includes one of the following: a first random number, a first count value, and a first sequence value.

4. The method according to any one of claims 1-3, wherein, The security protection commands include encrypted commands; The method further includes: The encrypted command is decrypted based on the key.

5. The method of claim 4, wherein, The decryption of the encrypted command based on the key includes: The encrypted command is decrypted based on the key, the first freshness value, and the pre-configured confidentiality protection algorithm, wherein the first freshness value includes one of the following: a first random number, a first count value, and a first sequence value.

6. The method according to any one of claims 2-5, wherein, The key is pre-shared by the first AIoT device and one of the following: ADM, Application Function AF, AAA server, AIoTF.

7. The method according to any one of claims 2-5, wherein, The key is the authenticated session key.

8. The method according to any one of claims 2-5, wherein, The key is calculated based on the root key and a second fresh value, wherein the second fresh value includes one of the following: a second random number, a second count value, and a second sequence value.

9. The method according to any one of claims 2-8, wherein, The key includes an integrity key and / or a confidentiality key.

10. The method according to any one of claims 1-9, wherein, The request message is one of the following: inventory request message or command request message.

11. The method according to any one of claims 1-10, further comprising: Send a response message, wherein the response message carries at least one of the following: an encrypted identifier of the first AIoT device, a temporary identifier of the first AIoT device, or an acknowledgment response to the command.

12. The method according to claim 11, wherein, The response message is one of the following: inventory response message or command response message.

13. A communication method performed by AIoTF, comprising: Send a request message, wherein the request message carries a security protection command, the command being used to activate or deactivate the first AIoT device.

14. The method according to claim 13, wherein, The security protection commands include encrypted commands; The method further includes: The encrypted command is obtained by encrypting the command using a key.

15. The method according to claim 14, wherein, The encrypted command obtained by encrypting the command based on the key includes: Based on the key, the first freshness value, and the pre-configured confidentiality protection algorithm, the command is encrypted to obtain the encrypted command, wherein the first freshness value includes one of the following: a first random number, a first count value, and a first sequence value.

16. The method according to any one of claims 13-15, wherein, The security protection commands include integrity verification parameters; The method also includes: The integrity verification parameters are calculated based on the key and the command.

17. The method according to claim 16, wherein, The calculation of the integrity verification parameters based on the key and the command includes: Based on the key, the first freshness value, and the pre-configured integrity protection algorithm, the integrity verification parameters are calculated for the command, wherein the first freshness value includes one of the following: a first random number, a first count value, and a first sequence value.

18. The method according to any one of claims 13-15, wherein, The security protection command includes integrity verification parameters; the method also includes: The integrity verification parameters are calculated based on the key and encrypted commands.

19. The method according to claim 18, wherein, The command based on the key and encryption calculates the integrity verification parameters, including: Based on the key, the first freshness value, and the pre-configured integrity protection algorithm, the integrity verification parameters are calculated for the encrypted command, wherein the first freshness value includes one of the following: a first random number, a first count value, and a first sequence value.

20. The method according to any one of claims 14-19, wherein, The key is pre-shared between the AIoTF and the first AIoT device.

21. The method according to any one of claims 14-19, wherein, The key is the authenticated session key.

22. The method according to any one of claims 14-19, further comprising: Receive the key.

23. The method according to any one of claims 14-19, wherein the key is calculated based on the root key and the second freshness value, wherein, The second fresh value includes one of the following: a second random number, a second count value, or a second sequence value.

24. The method according to any one of claims 14-23, wherein, The key includes an integrity key and / or a confidentiality key.

25. The method according to any one of claims 13-24, wherein, The request message is one of the following: inventory request message or command request message.

26. The method according to any one of claims 13-25, further comprising: A response message is received, wherein the response message carries at least one of the following: an encrypted identifier of the first AIoT device, a temporary identifier of the first AIoT device, and a confirmation response to the command.

27. The method according to claim 26, wherein, The response message is one of the following: inventory response message or command response message.

28. A first AIoT device, comprising: A first communication unit is configured to receive a request message, wherein the request message carries a security protection command, the command being used to activate or deactivate the first AIoT device.

29. An AIoTF, comprising: The second communication unit is used to send a request message, wherein the request message carries a security protection command, which is used to activate or deactivate the first AIoT device.

30. A first 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 first AIoT device to perform the method as described in any one of claims 1 to 12.

31. An AIoTF, 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 AIoTF to perform the method as described in any one of claims 13 to 27.

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

33. 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 12 or 13 to 27.

34. A computer program product comprising computer program instructions that cause a computer to perform the method as claimed in any one of claims 1 to 12 or 13 to 27.

35. A computer program that causes a computer to perform the method as claimed in any one of claims 1 to 12 or 13 to 27.

Images