Communication method and apparatus
Patent Information
- Application Number
- PCT/CN2025/105171
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2024-08-09
- Filing Date
- 2025-06-28
- Publication Date
- 2026-02-12
Smart Images

Figure CN2025105171_12022026_PF_FP_ABST
Abstract
Description
A communication method and apparatus
[0001] Cross-references to related applications
[0002] This application claims priority to Chinese Patent Application No. 202411100975.1, filed on August 9, 2024, entitled "A Communication Method and Apparatus", the entire contents of which are incorporated herein by reference. Technical Field
[0003] This application relates to the field of communication technology, and in particular to a communication method and apparatus. Background Technology
[0004] Keys play a crucial role in communication, such as encrypting and decrypting information, network security, and authentication, ensuring communication security. For example, the security of terminal communication can be achieved through the terminal's root key and at least one key derived from that root key. In one possible communication scenario, at least one entity associated with the terminal can communicate with the core network or third-party devices through the terminal. The entity associated with the terminal can be different users on the terminal, virtual identities on the terminal (e.g., digital humans or virtual humans), applications installed on the terminal (APPs), or external devices attached to the terminal (e.g., smart devices, wearable devices, etc.). Therefore, ensuring the security of communication between entities associated with the terminal is a technical problem that needs to be solved. Summary of the Invention
[0005] This application provides a communication method and apparatus for obtaining the key of an entity associated with a terminal, which helps to ensure the security of communication between the entities associated with the terminal.
[0006] Firstly, this application provides a communication method applied to a first terminal. For example, the first terminal may be a first terminal device or a device within the first terminal device. Exemplarily, a device in the first terminal device may refer to a component within the first terminal device (e.g., a processor, chip, or chip system), or it may refer to a logic module or software capable of implementing all or part of the functions of the first terminal device. The method may include: the first terminal sending a first message to a first network element, the first message being used to request a first key for a first entity, the first key being used for the first entity to communicate with a first network, or the first key being used for the first entity to communicate with a first network device; and receiving a second message from the first network element, the second message including information about the first key.
[0007] Optionally, the first entity can be a device that supports establishing an association with the first terminal. For example, the device that supports establishing an association with the first terminal can be a smart device or a wearable device, etc., without limitation. Alternatively, the first entity can also be a device in the first terminal. For example, the first entity can be an app installed on the first terminal, different users on the first terminal, virtual identities on the first terminal (e.g., digital humans, or virtual humans, etc.), circuits in the first terminal, modules in the first terminal, or logic modules in the first terminal, etc.
[0008] In the above embodiments of this application, the first terminal can obtain the first key by sending a first message to the first network element, so that the first entity can communicate with the first network or the first network device based on the first key, which helps to ensure the security of entity communication.
[0009] Secondly, this application provides a communication method applied to a first terminal. For example, the first terminal may be a first terminal device or a device within the first terminal device. Exemplarily, a device in the first terminal device may refer to a component (e.g., a processor, chip, or chip system) within the first terminal device, or it may refer to a logic module or software capable of implementing all or part of the functions of the first terminal device. The method may include: the first terminal receiving a second message from a first network element, the second message including information about a first key, the first key being used for communication between a first entity and a first network, or the first key being used for communication between the first entity and a first network device.
[0010] Optionally, the first entity can be a device that supports establishing an association with the first terminal. For example, the device that supports establishing an association with the first terminal can be a smart device or a wearable device, etc., without limitation. Alternatively, the first entity can also be a device in the first terminal. For example, the first entity can be an app installed on the first terminal, different users on the first terminal, virtual identities on the first terminal (e.g., digital humans, or virtual humans, etc.), circuits in the first terminal, modules in the first terminal, or logic modules in the first terminal, etc.
[0011] In the above embodiments of this application, the first network element can actively send the information of the first key to the first terminal without the first terminal needing to send a message requesting the first key to the first network. This reduces signaling interaction, and the first entity communicates with the first network or the first network device based on the first key, which helps to ensure the security of entity communication.
[0012] Based on the first or second aspect described above, in one possible implementation, the information of the first key may include a random number, or the information of the first key may include a random number and the information of the first entity.
[0013] With the above implementation method, the first terminal and the first network element do not need to transmit the first key, but instead transmit a random number (or a random number and information of the first entity) used to generate the first key, which helps to improve the security of key transmission.
[0014] Based on the first or second aspect described above, in one possible implementation, the first terminal may further generate the first key based on the information of the first key and a preset key of the first terminal. Optionally, the preset key may be a root key, a key derived from the root key, or other long-term keys other than the root key, without limitation.
[0015] Through the above implementation, the first key can be generated based on the preset key of the first terminal and a random number (or a random number and information about the first entity). The preset key of the first terminal is a long-term key; therefore, the first key generated based on this preset key is not a temporary key but also a long-term key, which will not change due to the access operation of the first terminal, eliminating the need to frequently obtain the key of the first entity. Because the first key is a long-term key, the first entity is no longer limited to access operations through the first terminal. For example, it can access operations through other terminals based on this first key, or it can access operations independently based on this first key. This adapts to more communication scenarios and improves user experience.
[0016] Based on the first or second aspect described above, in one possible implementation, the first terminal may further send the first key to the first entity; or, the first terminal may further configure (or store) the first key. For example, if the first entity is a device that supports establishing an association with the first terminal, the first terminal may send the first key to the first entity. As another example, if the first entity is a device within the first terminal, the first terminal may configure the first key.
[0017] Based on the first or second aspect above, in another possible implementation, the information of the first key may include the first key and a ticket, the ticket including information of the first entity and the first key, wherein the ticket is encrypted by a second key, the second key being a key of the first network, or the second key being a key of the first network device.
[0018] In this implementation, the second key is the key of the first network or the first network device. The first terminal cannot decrypt the ticket, but can authenticate the access of the first entity using the first key and the ticket. The network side does not need to store or maintain the first key. This first key can be a long-term key that will not change due to the access operation of the first terminal, eliminating the need to frequently obtain the key of the first entity. Furthermore, the first entity is no longer limited to accessing through the first terminal; for example, it can access through other terminals based on the first key, or it can access independently based on the first key. This adapts to more communication scenarios and improves the user experience.
[0019] Based on the first or second aspect described above, in one possible implementation, the first terminal may further send the first key and the ticket to the first entity. Alternatively, the first terminal may further configure (or store) the first key and the ticket. For example, if the first entity is a device that supports establishing an association with the first terminal, the first terminal may send the first key and the ticket to the first entity. As another example, if the first entity is a device within the first terminal, the first terminal may configure the first key and the ticket.
[0020] Based on the first or second aspect described above, in one possible implementation, the first terminal may further send a third message to the second network element. The third message includes the ticket and information obtained by encrypting the information of the first entity based on the first key. The third message is used by the first entity to request access to the first network, or by the first entity to request access to the first network device. The terminal also receives a response message from the second network element regarding the third message, which indicates whether access is permitted. Optionally, the second network element can be the first network element; or it can be another network element besides the first network element, such as an application server or an application function network element.
[0021] Based on the first or second aspect above, in one possible implementation, the first terminal sends a third message to the second network element, including: the first terminal obtaining a fourth message, the fourth message including the ticket and information obtained by encrypting the information of the first entity based on the first key, the fourth message being used by the first entity to request access to the first network, or the fourth message being used by the first entity to request access to the first network device; and sending the third message to the second network element according to the fourth message.
[0022] Based on the first or second aspect above, in one possible implementation, if the first condition is met, the response message of the third message is used to indicate that access is allowed; or, if the first condition is not met, the response message of the third message is used to indicate that access is not allowed; wherein the first condition includes: the information of the first entity encrypted by the first key is the same as the information of the first entity included in the ticket.
[0023] Based on the first or second aspect above, in one possible implementation, the information obtained by encrypting the information of the first entity based on the first key may include: information obtained by encrypting at least one of the identifier of the first terminal, a first timestamp, a second timestamp, or a first duration, and the information of the first entity based on the first key; wherein, the first timestamp is the timestamp when the first terminal requests the first key, the second timestamp is the timestamp when the first entity uses the first key, and the first duration is used to indicate the effective duration of the first key.
[0024] Through the above implementation, the third message can also carry more verification information, such as the identifier of the first terminal, the first timestamp, the second timestamp, and the first duration. For example, it can verify whether the identifier of the first terminal, the first timestamp, and the first duration carried in the third message are consistent with the identifier of the first terminal, the application time of the first key, and the validity duration of the first key recorded on the network side, thereby improving the security of entity communication. As another example, the first duration can be used to verify whether the first key has expired, reducing the probability of the first key being cracked and improving the security of entity communication. Furthermore, it can verify whether the second timestamp is later than the time of the first entity's last access and close to the current time on the network side, reducing the probability of intrusion and improving the security of entity communication.
[0025] Based on the first or second aspect above, in one possible implementation, the ticket may further include at least one of the following: an identifier of the first terminal, a first timestamp, or a first duration; wherein the first timestamp is the timestamp at which the first terminal requests the first key, and the first duration is used to indicate the validity period of the first key.
[0026] The above implementation method allows the ticket to include more information for authentication, which helps improve the security of entity communication.
[0027] Based on the first or second aspect above, in one possible implementation, the information of the first key includes at least one of the following: information of the first entity, or a first duration, wherein the first duration is used to indicate the effective duration of the first key.
[0028] By implementing the above method, it can be determined that the first key is the key of the first entity and the validity period of the first key. The first key is valid within the first period and becomes invalid outside the first period. This reduces the probability of the first key being cracked and improves the security of entity communication.
[0029] Based on the first or second aspect above, in one possible implementation, the first message includes at least one of the following: the identifier of the first terminal, the information of the first entity, a first timestamp, or a second duration; wherein the first timestamp is the timestamp of the first terminal requesting the first key, and the second duration is used to indicate the expected validity period of the first key.
[0030] Based on the first or second aspect described above, in one possible implementation, the information of the first entity includes the identifier of the first entity and / or the type of the first entity. Optionally, the type of the first entity can be understood as the relationship between the first entity and the first terminal. Exemplarily, the type of the first entity may include, but is not limited to, at least one of the following: accessory device, application layer identity, wearable device, smart device, metaverse service, etc.
[0031] Through the above implementation, the first entity can be determined by its identifier or by its type, which can adapt to different communication scenarios.
[0032] Based on the first or second aspect described above, in one possible implementation, the identifier of the first entity is determined by the first terminal, or the identifier of the first entity is determined by the first network element, or the identifier of the first entity is determined by the third network element.
[0033] Through the above implementation, the identifier of the first entity can be determined in multiple ways, thus adapting to different communication scenarios.
[0034] Thirdly, this application provides a communication method applied to a first network element. For example, the first network element may be a network device with first network element functionality, or it may be a device within that network device. Exemplarily, the device within the network device may refer to a component within the network device (e.g., a processor, chip, or chip system), or it may refer to a logic module or software capable of implementing all or part of the first network element functionality. The method may include: the first network element receiving a first message from a first terminal, the first message being used to request a first key for a first entity, the first key being used for the first entity to communicate with a first network, or the first key being used for the first entity to communicate with a first network device; and sending a second message to the first terminal, the second message including information about the first key.
[0035] Optionally, the first entity can be a device that supports establishing an association with the first terminal. For example, the device that supports establishing an association with the first terminal can be a smart device or a wearable device, etc., without limitation. Alternatively, the first entity can also be a device in the first terminal. For example, the first entity can be an app installed on the first terminal, different users on the first terminal, virtual identities on the first terminal (e.g., digital humans, or virtual humans, etc.), circuits in the first terminal, modules in the first terminal, or logic modules in the first terminal, etc.
[0036] Fourthly, this application provides a communication method applied to a first network element. For example, the first network element may be a network device with first network element functions, or it may be a device within that network device. Exemplarily, the device within the network device may refer to a component within the network device (e.g., a processor, chip, or chip system), or it may refer to a logic module or software capable of implementing all or part of the functions of the first network element. The method may include: the first network element sending a second message to a first terminal, the second message including information about a first key, the first key being used for communication between the first entity and the first network, or the first key being used for communication between the first entity and the first network device.
[0037] Optionally, the first entity can be a device that supports establishing an association with the first terminal. For example, the device that supports establishing an association with the first terminal can be a smart device or a wearable device, etc., without limitation. Alternatively, the first entity can also be a device in the first terminal. For example, the first entity can be an app installed on the first terminal, different users on the first terminal, virtual identities on the first terminal (e.g., digital humans, or virtual humans, etc.), circuits in the first terminal, modules in the first terminal, or logic modules in the first terminal, etc.
[0038] Based on the third or fourth aspect above, in one possible implementation, the information of the first key includes a random number, or the information of the first key includes a random number and the information of the first entity.
[0039] Based on the third or fourth aspect mentioned above, in one possible implementation, the first network element may also generate the first key based on the information of the first key and the preset key of the first terminal; and store the first key.
[0040] Based on the third or fourth aspect above, in another possible implementation, the first network element may also send a fifth message to the third network element, the fifth message being used to request the first key for the first entity; and receive a response message from the third network element for the fifth message, the response message of the fifth message including information about the first key.
[0041] Through the two implementation methods described above, the first network element can generate and maintain the first key itself, or the first network element can obtain the information used to generate the first key from the third network element, without having to generate and maintain the first key itself, thus adapting to different communication scenarios.
[0042] Based on the third or fourth aspect above, in one possible implementation, the information of the first key includes the first key and the ticket, the ticket including the information of the first entity and the first key, wherein the ticket is encrypted by a second key, the second key being a key of the first network, or the second key being a key of the first network device.
[0043] Based on the third or fourth aspect above, in one possible implementation, the first network element may also receive a third message, which is used for the first entity to request access to the first network, or the third message is used for the first entity to request access to the first network device. The third message includes the ticket and information obtained by encrypting the information of the first entity based on the first key. A response message to the third message is sent, which is used to indicate whether access is allowed.
[0044] Based on the third or fourth aspect above, in one possible implementation, if the first condition is met, the response message of the third message is used to indicate that access is allowed; or, if the first condition is not met, the response message of the third message is used to indicate that access is not allowed; wherein the first condition includes: the information of the first entity encrypted by the first key is the same as the information of the first entity included in the ticket.
[0045] Based on the third or fourth aspect above, in one possible implementation, the information obtained by encrypting the information of the first entity based on the first key may include: information obtained by encrypting at least one of the identifier of the first terminal, a first timestamp, a second timestamp, or a first duration, and the information of the first entity based on the first key; wherein, the first timestamp is the timestamp when the first terminal requests the first key, the second timestamp is the timestamp when the first entity uses the first key, and the first duration is used to indicate the effective duration of the first key.
[0046] Based on the third or fourth aspect above, in one possible implementation, the ticket may further include at least one of the following: an identifier of the first terminal, a first timestamp, or a first duration; wherein the first timestamp is the timestamp at which the first terminal requests the first key, and the first duration is used to indicate the validity period of the first key.
[0047] Based on the third or fourth aspect above, in one possible implementation, the information of the first key may include at least one of the following: information of the first entity, or a first duration, wherein the first duration is used to indicate the effective duration of the first key.
[0048] Based on the third or fourth aspect above, in one possible implementation, the first message may include at least one of the following: the identifier of the first terminal, the information of the first entity, a first timestamp, or a second duration; wherein the first timestamp is the timestamp at which the first terminal requests the first key, and the second duration is used to indicate the expected validity period of the first key.
[0049] Based on the third or fourth aspect above, in one possible implementation, the information of the first entity may include the identifier of the first entity and / or the type of the first entity.
[0050] Based on the third or fourth aspect above, in one possible implementation, the identifier of the first entity is determined by the first terminal, or the identifier of the first entity is determined by the first network element, or the identifier of the first entity is determined by the third network element.
[0051] The technical effects that can be achieved by the third or fourth aspect and any of its possible implementations mentioned above should be referred to the technical effects that can be achieved by any of the first or second aspects and any of its possible implementations mentioned above, and will not be repeated here.
[0052] Fifthly, this application provides a communication method applied to a third network element. For example, the third network element may be a network device with third network element functionality, or it may be a device within that network device. Exemplarily, the device within the network device may refer to a component within the network device (e.g., a processor, chip, or chip system), or it may refer to a logic module or software capable of implementing all or part of the third network element functionality. The method may include: the third network element receiving a fifth message from a first network element, the fifth message being used to request a first key for a first entity, the first key being used for the first entity to communicate with a first network, or for the first entity to communicate with a first network device; and sending a response message to the fifth message to the first network element, the response message including information about the first key.
[0053] Optionally, the first entity can be a device that supports establishing an association with the first terminal. For example, the device that supports establishing an association with the first terminal can be a smart device or a wearable device, etc., without limitation. Alternatively, the first entity can also be a device in the first terminal. For example, the first entity can be an app installed on the first terminal, different users on the first terminal, virtual identities on the first terminal (e.g., digital humans, or virtual humans, etc.), circuits in the first terminal, modules in the first terminal, or logic modules in the first terminal, etc.
[0054] In one possible implementation, the information of the first key includes a random number, or the information of the first key includes a random number and information of the first entity.
[0055] In one possible implementation, the third network element may also generate the first key based on the information of the first key and the preset key of the first terminal; and store the first key.
[0056] The technical effects that can be achieved by the fifth aspect and any of its possible implementations are described above are similar to those achieved by any of the third or fourth aspects and any of their possible implementations, and will not be repeated here.
[0057] Sixthly, this application provides a communication device that can be used to perform the methods described in the first or second aspect and any possible implementation thereof. The communication device may be, for example, a first terminal device, or a device within a first terminal device. The communication device may include modules, units, or means corresponding to the methods described in the first or second aspect and any possible implementation thereof. These modules, units, or means may be implemented in hardware, software, or by hardware executing corresponding software. The hardware or software includes one or more modules or units corresponding to the aforementioned functions.
[0058] In one possible implementation, the communication device may include a baseband device and a radio frequency device.
[0059] In another possible implementation, the communication device may include a processing module (sometimes also called a processing unit) and a transceiver module (sometimes also called a transceiver unit). The transceiver module is capable of both sending and receiving functions. When the transceiver module performs the sending function, it may be called a sending module (sometimes also called a sending unit), and when it performs the receiving function, it may be called a receiving module (sometimes also called a receiving unit). The sending module and the receiving module may be the same functional module, referred to as the transceiver module, which performs both sending and receiving functions; or, the sending module and the receiving module may be different functional modules, with "transceiver module" being a collective term for these functional modules.
[0060] Seventhly, this application provides a communication device that can be used to perform the methods described in the third or fourth aspect and any possible implementation thereof. The communication device may be, for example, a first network element, or a device within the first network element. The communication device may include modules, units, or means corresponding to the methods described in the third or fourth aspect and any possible implementation thereof. These modules, units, or means may be implemented in hardware, software, or by hardware executing corresponding software implementations. The hardware or software includes one or more modules or units corresponding to the aforementioned functions.
[0061] In one possible implementation, the communication device may include a baseband device and a radio frequency device.
[0062] In another possible implementation, the communication device may include a processing module (sometimes also called a processing unit) and a transceiver module (sometimes also called a transceiver unit). The transceiver module is capable of both sending and receiving functions. When the transceiver module performs the sending function, it may be called a sending module (sometimes also called a sending unit), and when it performs the receiving function, it may be called a receiving module (sometimes also called a receiving unit). The sending module and the receiving module may be the same functional module, referred to as the transceiver module, which performs both sending and receiving functions; or, the sending module and the receiving module may be different functional modules, with "transceiver module" being a collective term for these functional modules.
[0063] Eighthly, this application provides a communication device that can be used to perform the methods described in the fifth aspect and any possible implementation thereof. The communication device may be, for example, a third network element, or a device within a third network element. The communication device may include modules, units, or means corresponding to the methods described in the fifth aspect and any possible implementation thereof. These modules, units, or means may be implemented in hardware, software, or by hardware executing corresponding software implementations. The hardware or software includes one or more modules or units corresponding to the aforementioned functions.
[0064] In one possible implementation, the communication device may include a baseband device and a radio frequency device.
[0065] In another possible implementation, the communication device may include a processing module (sometimes also called a processing unit) and a transceiver module (sometimes also called a transceiver unit). The transceiver module is capable of both sending and receiving functions. When the transceiver module performs the sending function, it may be called a sending module (sometimes also called a sending unit), and when it performs the receiving function, it may be called a receiving module (sometimes also called a receiving unit). The sending module and the receiving module may be the same functional module, referred to as the transceiver module, which performs both sending and receiving functions; or, the sending module and the receiving module may be different functional modules, with "transceiver module" being a collective term for these functional modules.
[0066] Ninthly, this application provides a communication system that may include at least one of the following: the communication device provided in the sixth aspect, the communication device provided in the seventh aspect, or the communication device provided in the eighth aspect.
[0067] In a tenth aspect, this application also provides a communication device. The communication device may include one or more processors. Optionally, the communication device may further include a memory. The memory is used to store one or more computer programs or instructions. The one or more processors are used to execute the one or more computer programs or instructions stored in the memory, causing the communication device to perform the methods described in any of the first to fifth aspects and any possible implementations thereof.
[0068] Eleventhly, this application also provides a communication device, comprising: a processor and an interface circuit; the interface circuit is configured to receive signals from other communication devices besides the communication device and transmit them to the processor, or to send signals from the processor to other communication devices besides the communication device. The processor is configured to implement the method described in any of the above aspects through logic circuits or by executing computer programs or instructions. The communication device may be a first terminal as described in the first or second aspect, or a device included in the first terminal, such as a chip; or, the communication device may be a first network element as described in the third or fourth aspect, or a device included in the first network element; or, the communication device may be a third network element as described in the fifth aspect, or a device included in the third network element.
[0069] In some possible designs, when the device is a chip system, it can be composed of chips or contain chips and other discrete components.
[0070] In a twelfth aspect, this application also provides a chip system comprising at least one chip and a memory, wherein the at least one chip is configured to read and execute a program stored in the memory to implement the method described in any of the first to fifth aspects and any possible implementation thereof.
[0071] In a thirteenth aspect, this application also provides a computer-readable storage medium for storing a computer program or instructions that, when executed, cause the method described in any of the first to fifth aspects and any possible implementation thereof to be implemented.
[0072] In a fourteenth aspect, this application also provides a computer program product comprising a computer program or instructions that, when executed on a computer, cause the method described in any of the first to fifth aspects and any possible implementation thereof to be implemented.
[0073] The technical effects achievable by aspects six through fourteen and any of their possible implementations are described in the same manner as those achievable by any of aspects one through five and any of their possible implementations, and will not be repeated here. Attached Figure Description
[0074] Figure 1 is a schematic diagram of a network architecture for a service-based communication system;
[0075] Figure 2 is a schematic diagram of the network architecture of a communication system provided in an embodiment of this application;
[0076] Figure 3 is a schematic diagram of multiple entities associated with the first terminal provided in an embodiment of this application;
[0077] Figure 4 is a flowchart illustrating a communication method provided in an embodiment of this application;
[0078] Figure 5 is a flowchart illustrating a communication method provided in an embodiment of this application;
[0079] Figure 6 is a flowchart illustrating a communication method provided in an embodiment of this application;
[0080] Figure 7 is a flowchart illustrating a communication method provided in an embodiment of this application;
[0081] Figure 8 is a schematic diagram of the structure of a communication device provided in an embodiment of this application;
[0082] Figure 9 is a schematic diagram of another communication device provided in an embodiment of this application;
[0083] Figure 10 is a schematic diagram of another communication device provided in an embodiment of this application. Detailed Implementation
[0084] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the embodiments of this application will be further described in detail below with reference to the accompanying drawings.
[0085] The network architecture and business scenarios described in this application are intended to more clearly illustrate the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of network architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.
[0086] I. In the embodiments of this application, "multiple" can refer to two or more. Therefore, in the embodiments of this application, "multiple" can also be understood as "at least two". "At least one" can be understood as one or more, such as one, two or more. For example, "including at least one" means including one, two or more. For example, including at least one of A, B and C, then it can include A, B, C, A and B, A and C, B and C, or A, B and C. "And / or" describes the association relationship of the associated objects. Specifically, there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist simultaneously, and B exists alone. In addition, the character " / ", unless otherwise specified, generally indicates that the associated objects before and after are in an "or" relationship.
[0087] II. In the embodiments of this application, the terms "system" and "network" can be used interchangeably, and "according to" and "based on" can be used interchangeably.
[0088] The ordinal numbers such as "first" and "second" mentioned in the embodiments of this application are generally used to distinguish different objects, and are not used to limit the order, timing, priority, or importance of multiple objects. For example, the first network element and the second network element involved in the embodiments of this application are used to distinguish different network elements, and do not limit the order, timing, priority, or importance of these two network elements.
[0089] 3. The terms “comprising” and “having” and any variations thereof are intended to cover non-exclusive inclusion, for example, a process, method, system, product or device that includes a series of steps or units is not necessarily limited to those steps or units that are expressly listed, but may include other steps or units that are not expressly listed or that are inherent to such process, method, product or device.
[0090] IV. In this application, "predefined" may include predefined terms, such as protocol definitions. "Predefined" can be implemented by pre-storing corresponding codes, tables, or other means of indicating relevant information in the device (e.g., including various network elements), and this application does not limit the specific implementation method.
[0091] V. The term "storage" or "preservation" in this application can refer to storage in one or more memory devices. These memory devices can be separately configured or integrated into an encoder, decoder, processor, or communication device. Alternatively, some memory devices can be separately configured, while others can be integrated into a decoder, processor, or communication device. The type of memory can be any form of storage medium, and this is not limited.
[0092] VI. The arrows or boxes indicated by dashed lines in the schematic diagrams in the accompanying drawings of this application represent optional steps or optional modules.
[0093] VII. In this application, "instruction" may include direct instruction, indirect instruction, explicit instruction, and implicit instruction. When describing a certain instruction information for the purpose of instructing A, it can be understood that the instruction information carries A, directly instructs A, or indirectly instructs A.
[0094] In this application, the information indicated by the instruction information is called the information to be instructed. In specific implementations, there are many ways to indicate the information to be instructed, such as, but not limited to, directly indicating the information to be instructed, such as the information to be instructed itself or its index. It can also indirectly indicate the information to be instructed by indicating other information, where there is a relationship between the other information and the information to be instructed. It can also indicate only a part of the information to be instructed, while the other parts are known or pre-agreed upon. For example, the instruction of specific information can be achieved by using a pre-agreed (e.g., protocol-defined) arrangement of various pieces of information, thereby reducing instruction overhead to some extent. Furthermore, the information to be instructed can be sent as a whole or divided into multiple sub-information pieces, and the sending period and / or timing of these sub-information pieces can be the same or different.
[0095] 8. In this application, "send" and "receive" indicate the direction of signal transmission. For example, "send information to XX" can be understood as the destination of the information being XX, which may include direct transmission via the air interface or indirect transmission by other units or modules via the air interface. "Receive information from YY" can be understood as the source of the information being YY, which may include direct reception from YY via the air interface or indirect reception from YY by other units or modules via the air interface. "Send" can also be understood as the "output" of the chip interface, and "receive" can also be understood as the "input" of the chip interface. In other words, sending and receiving can occur between devices, such as between network devices and terminal devices, or within a device, such as between components, modules, chips, software modules, or hardware modules within the device via a bus, wiring, or interface.
[0096] IX. In the embodiments of this application, the words "exemplarily," "for example," "for instance," etc., are used to indicate examples, illustrations, or descriptions. Any embodiment or design scheme described as an "example" in this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the word "example" is intended to present concepts in a specific manner. In the embodiments of this application, "of," "corresponding, relevant," and "corresponding" may sometimes be used interchangeably, and it should be noted that their intended meanings are consistent unless their distinction is emphasized.
[0097] 10. The embodiments of this application will be presented in the context of a system including multiple devices, components, modules, etc. It should be understood that the system may include other unmentioned devices, components, modules, etc., or may only include some of the devices, components, or modules mentioned in the embodiments. Optionally, the terms "component" and "part" in this application can be used interchangeably.
[0098] The communication system applicable to the embodiments of this application will be introduced below.
[0099] The technical solutions of this application embodiment can be applied to various communication systems, such as integrated sensing and communication (ISAC), universal mobile telecommunications system (UMTS), wireless local area network (WLAN), short-range wireless communication systems (such as sidelink, wireless fidelity, Wi-Fi, Bluetooth, etc.), wired networks, vehicle to everything (V2X) communication systems, device-to-device (D2D) communication systems, vehicle-to-everything (V2X) communication systems, 4th generation (4G) mobile communication systems (such as Long Term Evolution (LTE) systems), LTE frequency division duplex (FDD) systems, LTE time division duplex (TDD) systems, worldwide interoperability for microwave access (WiMAX) communication systems, and 5th generation (5G) mobile communication systems (such as New Radio). No restrictions are imposed on radio (NR) systems, future communication systems, or other similar communication systems.
[0100] Figure 1 illustrates a network architecture for a service-based communication system, which may include user equipment (UE) and operator network components. This network architecture may also include data network (DN) and / or application function (AF) network elements. The operator network may also be referred to as a general network, public network, public data network, or public land mobile network (PLMN), etc., without limitation.
[0101] A UE is a device with wireless transceiver capabilities that can be deployed on land, including indoors or outdoors, handheld or vehicle-mounted; it can also be deployed on water (such as ships); and it can also be deployed in the air (such as airplanes, balloons, and satellites).
[0102] For example, UE can also be referred to as terminal device, terminal equipment, terminal, user terminal, user equipment, user unit, user station, access terminal, access station, UE station, remote station, wireless communication equipment, mobile station (MS), or mobile terminal (MT), etc. For example, terminal devices can be: mobile phones, tablets, laptops, PDAs, mobile internet devices (MIDs), wearable devices (such as smartwatches, smart bracelets, pedometers, smart glasses, etc.), in-vehicle equipment (such as cars, bicycles, electric vehicles, airplanes, ships, trains, high-speed trains, etc.), satellite terminals, virtual reality (VR) devices, augmented reality (AR) devices, smart point-of-sale (POS) machines, customer-premises equipment (CPE), light user equipment (UE), reduced capability user equipment (REDCAP UE), wireless terminals in industrial control, smart home devices (such as refrigerators, televisions, air conditioners, electricity meters, etc.), wireless terminals in machine-to-machine (M2M) or machine-type communication (MTC), wireless terminals in the Internet of Things (IoT), smart robots, robotic arms, workshop equipment, wireless terminals in autonomous driving, and remote medical devices. Wireless terminals can be used in various applications, including medical devices, smart grids, transportation safety, smart cities, smart homes, and flying equipment (e.g., intelligent robots, hot air balloons, drones, airplanes). Terminal devices can also be vehicle-mounted devices, such as complete vehicle units, in-vehicle modules, in-vehicle chips, on-board units (OBUs), or telematics boxes (T-BOXs). They can also be other devices with terminal functions. For example, a terminal device can act as a terminal in device-to-device (D2D) communication.
[0103] An operator network may include, but is not limited to, one or more of the following network elements: authentication service function network elements, access management function network elements, policy control function network elements, unified data management network elements, session management function network elements, user plane function network elements, and access network (AN). The portion of the operator network excluding the access network can be referred to as the core network (CN). In one possible implementation, the operator network may also include an access point (AF). In other words, the AF may or may not belong to the core network; there is no restriction.
[0104] The aforementioned terminal devices can establish connections with the operator's network through interfaces provided by the operator's network (such as N1), and use data and / or voice services provided by the operator's network. The terminal devices can also access the DN (Network Provider) through the operator's network, and use operator services deployed on the DN, and / or services provided by third parties. These third parties can be service providers other than the operator's network and the terminal devices, and can provide data and / or voice services to the terminal devices. The specific form of these third parties can be determined based on the actual application scenario and is not limited here.
[0105] Core network elements can be divided into control plane elements and user plane elements. Control plane elements include, for example, access management function elements, unified data management function elements, session management function elements, policy control function elements, or authentication service function elements. User plane elements include, for example, user plane function elements. The following section introduces some of the network elements in the core network.
[0106] The authentication service function network element is responsible for providing UE identity authentication services. For example, it can authenticate the UE and provide one or more keys. In 5G communication systems, this authentication service function network element can be an authentication server function (AUSF) network element. In future communication systems, the authentication service function network element may have other names, without limitation.
[0107] The unified data management network element is responsible for generating authentication credentials, processing user identifiers (such as storing and managing permanent user identities), and managing subscription data. In 5G communication systems, this unified data management network element can be a unified data management (UDM) network element. In future communication systems, this unified data management network element may have other names, without limitation.
[0108] Access management function (AMF) network elements are responsible for access control and mobility management of terminal devices accessing the operator's network. This includes functions such as mobility state management, assigning temporary user identities, authentication, and authorization. In 5G communication systems, this AMF network element may be an Access and Mobility Management Function (AMF) network element. In future communication systems, AMF network elements may have other names, without limitation.
[0109] The session management function (SMF) network element is primarily responsible for session management in mobile networks, such as session establishment, modification, and release. It can also assign Internet Protocol (IP) addresses to users and select user plane function (MPF) network elements that provide packet forwarding capabilities. In 5G communication systems, this SMF network element may be a Session Management Function (SMF) network element. In future communication systems, the SMF network element may have other names without limitation.
[0110] The policy control function network element primarily provides policy rules and is also responsible for acquiring user subscription information related to policy decisions. In 4G communication systems, this policy control function network element can be a policy and charging rules function (PCRF) network element. In 5G communication systems, this policy control function network element can be a policy control function (PCF) network element. In future communication systems, the policy control function network element may have other names without limitation. The PCFs connected to the AMF and SMF correspond to the AM PCF (PCF for access and mobility control) and SM PCF (PCF for session management), respectively, but may not be the same PCF entity in actual deployment scenarios.
[0111] User plane function (UDP) network elements are responsible for receiving and forwarding user data. For example, they can receive user data from the DN (Digital Network Node) and transmit it to the terminal device through the access network equipment; UDP network elements can also receive user data from the terminal device through the access network equipment and forward it to the DN. In 5G communication systems, this UDP network element can be a user plane function (UPF) network element. In future communication systems, UDP network elements may have other names, without limitation.
[0112] Access networks include access network equipment. For example, an access network device is a network-side device with wireless transceiver capabilities, such as a device in a radio access network (RAN) that provides wireless communication capabilities to terminal devices, referred to as a RAN device or RAN node. As an example, the RAN can be an access network within the 3rd Generation Partnership Project (3GPP), such as a 4th generation (4G) network, a 5th generation (5G) network (e.g., a new radio (NR) network), or a future-oriented network. As another example, the RAN can also be an open RAN (O-RAN or ORAN), a cloud radio access network (CRAN), or a communication network combining two or more of these.
[0113] Optionally, the RAN equipment can be a base station, an evolved NodeB (eNodeB), a transmission reception point (TRP), a next-generation NodeB (gNB) in a 5G mobile communication system, a base station in a future mobile communication system, an access node in a Wi-Fi system, a wireless relay node, or a wireless backhaul node, etc. Optionally, the base station can be a terrestrial base station, or it can be a non-terrestrial base station, such as a satellite or a temporarily deployed drone base station, etc.
[0114] Optionally, the RAN equipment can also be a module or unit that performs some of the functions of the base station. For example, it can be a central unit (CU), a distributed unit (DU), or a radio unit (RU). For instance, the CU can perform the functions of the base station's Radio Resource Control Protocol (RRCP) and Packet Data Convergence Protocol (PDCP), and can also perform the functions of the Service Data Adaptation Protocol (SDAP). For instance, the DU can perform the functions of the base station's Radio Link Control (RAN) layer and Medium Access Control (MAC) layer, and can also perform some or all of the physical layer functions. For specific descriptions of the above protocol layers, please refer to the relevant technical specifications of the 3rd Generation Partnership Project (3GPP). The CU and DU can be set up separately, or they can be included in the same network element, such as in the baseband unit (BBU). The RU may be included in radio frequency equipment or radio frequency units, such as in a remote radio unit (RRU), an active antenna unit (AAU), or a remote radio head (RRH). Optionally, the CU may include a CU-control plane (CP) and / or a CU-user plane (UP).
[0115] In different systems, CU (or CU-CP and CU-UP), DU, or RU may have different names, but those skilled in the art will understand their meaning. For example, in an ORAN system, CU can also be called an open-CU (open-CU, O-CU), DU can also be called an open-DU (open-DU, O-DU), CU-CP can also be called an open-CU-CP (open-CU-CP, O-CU-CP), CU-UP can also be called an open-CU-UP (open-CU-UP, O-CU-UP), and RU can also be called an open-RU (open-RU, O-RU). For ease of description, this application uses CU, CU-CP, CU-UP, DU, and RU as examples. Any of the units among CU (or CU-CP, CU-UP), DU, and RU in this application can be implemented through software modules, hardware modules, or a combination of software modules and hardware modules.
[0116] It should be noted that the equipment with base station functions may differ in communication systems employing different wireless access technologies. For example, in a 5G communication system, this equipment may be called a gNB or 5G NodeB; in an LTE system, it may be called an evolved NodeB (eNB or eNodeB); and in a 3G communication system, it may be called a Node B, etc.
[0117] A Data Network (DN), located outside the mobile communication system, provides services to users. For example, a DN can be a Packet Data Network (PDN), such as the Internet, Internet Protocol Multimedia Service (IMS) networks, application-specific data networks, Ethernet, or Internet Protocol (IP) local area networks. A DN can deploy various services, providing data and / or voice services to terminal devices. A DN can contain multiple application servers (AS), each providing at least one service.
[0118] Application Providers (AFs) primarily convey application-side requests to the network side, such as Quality of Service (QoS) requirements or user state event subscriptions. AFs can be third-party functional entities or application services deployed by operators, such as IMS voice call services.
[0119] As shown above, Figure 1 mainly illustrates the network elements that may be involved in various embodiments of this application. The communication system shown in Figure 1 may also involve other network elements. For example, the core network may also include one or more of the following: a unified data repository (UDR) network element, a network slice selection function (NSSF) network element, or a network exposure function (NEF) network element, etc., which are not shown in Figure 1. For ease of description, the device names mentioned in the embodiments of this application may omit "network element". For example, an AUSF network element and AUSF have the same meaning. Another example is a UDM network element and UDM. Yet another example is an AF network element and AF have the same meaning.
[0120] In one possible implementation, the core network may also include an Identity Credential Management (IDCM) network element, as shown in Figure 2. The IDCM network element is responsible for managing or maintaining entity keys, etc. In future communication systems, the IDCM network element may also be called an Identity Credential Management Functional Network Element, or it may have other names without limitation. Optionally, the IDCM can be deployed independently or co-located with other network functions, without restriction. For example, the IDCM can be co-located with the UDM; or the UDM can also be responsible for managing or maintaining entity keys, etc., meaning the UDM has the functions of the IDCM. As another example, the IDCM can be co-located with the AUSF; or the AUSF can also be responsible for managing or maintaining entity keys, etc., meaning the AUSF has the functions of the IDCM.
[0121] In Figure 1 or Figure 2, Nausf, Namf, Npcf, Nsmf, Nudm, Naf, N1, N2, N3, N4, and N6 are interface sequence numbers. The meanings of these interface sequence numbers can be found in the 3rd Generation Partnership Project (3GPP) standard protocol, and are not limited here. Optionally, the IDCM interface sequence number can be Nidcm, or other interface sequence numbers, without restriction.
[0122] It is understood that the network element or function shown in Figure 1 or Figure 2 can be a network component in a hardware device, a software function running on dedicated hardware, or a virtualized function instantiated on a platform (e.g., a cloud platform). One possible implementation is that the aforementioned network element or function can be implemented by a single device, multiple devices working together, or a functional module within a single device; no specific limitations are imposed on this.
[0123] Furthermore, the embodiments of this application do not limit the names of each network element in the communication system. For example, in communication systems of different standards, each network element may have other names; or, for example, when multiple network elements are integrated into the same physical device, the physical device may also have other names.
[0124] In future networks, the functions of the core network and the access network may be split and reorganized. For example, the mobility management function of the AMF may be split and merged into the access network, and the functions of the AMF and SMF may be merged. The embodiments of this application are illustrated with the architecture of Figure 1 or Figure 2 as an example.
[0125] This application provides a communication method and apparatus for obtaining the key of an entity associated with a terminal, which helps ensure the security of communication between the entities associated with the terminal. The method and apparatus described in this application are based on the same technical concept. Since the principles by which the method and apparatus solve the problem are similar, the implementations of the apparatus and method can be mutually referred to, and repeated details will not be elaborated further.
[0126] The following describes some of the technical terms used in the embodiments of this application.
[0127] 1. The first entity can still be referred to as a terminal or a user; the naming of the first entity is not limited in this application embodiment. The first entity can be understood as an entity that supports access operations through a terminal. It is understood that the first entity can also support independent access operations. In this application embodiment, the first entity is associated with a first terminal. Optionally, the first entity can be associated with at least one terminal, and the at least one terminal includes the first terminal. Optionally, the first terminal can be associated with at least one entity, and the at least one entity includes the first entity.
[0128] In one embodiment, the association of the first entity with the first terminal can be understood as follows: the first entity is a device that supports establishing an association with the first terminal. For example, the device that supports establishing an association with the first terminal can be an external device attached to the first terminal, or a device within an external device attached to the first terminal. The external device attached to the first terminal can be, for example, a smart device (e.g., a smart home device, or a smart robot), or a wearable device (e.g., a smartwatch, a smart bracelet, a pedometer, or smart glasses), etc., and is not limited thereto. The external device attached to the first terminal can also be described as an accessory device of the first terminal.
[0129] In another embodiment, the first entity is associated with the first terminal, which can be understood as: the first entity is a device in the first terminal. For example, the first entity can be an APP installed on the first terminal, different users on the first terminal, virtual identities on the first terminal (e.g., digital humans, or virtual humans), circuits in the first terminal, modules in the first terminal, or logic modules in the first terminal, etc., without limitation.
[0130] Please refer to Figure 3, which is a schematic diagram of various entities associated with (or carried on, or bound to) the first terminal provided in this embodiment of the application. It is understood that this embodiment of the application does not limit the number of entities associated with the first terminal. As shown in Figure 3, the entities associated with the first terminal include entity 1, entity 2, entity 3, and entity 4. The entities associated with the first terminal can connect to the core network through the first terminal, as shown by entities 3 and 4 in Figure 3. Alternatively, the entities associated with the first terminal can also connect to a third-party device (e.g., an APP server), as shown by entity 1 in Figure 3.
[0131] Entity 1 can be an app installed on the first terminal. Entities 2 and 3 can be different users on the first terminal. For example, suppose the first terminal is a mobile phone subscribed to by user A from a carrier. User A's friend might want to use the first terminal with the same subscription (rate) plan; User A's son might want to use the first terminal to access the internet. The service policy for each user, such as User A's friend and User A's son, might be different. For example, for User A's friend, the service policy might consider limiting the speed and data consumption limits for guest users; for User A's son, the service policy might consider restricting access to certain content providers. Entity 4 can be a smart robot associated with (or bound to) the first terminal.
[0132] For example, a first terminal can use the public key stored in a universal integrated circuit card (UICC) to obtain a subscription concealed identifier (SUCI) from the subscriber permanent identifier (SUPI), and send the SUCI to the core network via the RAN for authentication and other operations. The UDM in the core network decodes the SUCI to obtain the SUPI. Based on this SUPI, it can store not only the first terminal's subscription configuration file, but also the configuration information of at least one entity associated with the first terminal. The entity's configuration information can be described by attributes and associated with the first terminal's SUPI. For example, the entity's configuration information may include at least one of the following: entity identifier, service policy, security policy (or security information), or credentials, etc. Figure 3 illustrates the configuration information of entity 1, entity 2, entity 3, and entity 4 as examples. Furthermore, in Figure 3, dashed lines represent control plane transmissions, and solid lines represent user plane transmissions. For AF, IDCM, AMF, RAN, and UDM, please refer to the relevant descriptions in Figure 1 or Figure 2; they will not be elaborated upon further.
[0133] 2. The first network element can be used to manage or maintain the entity's key. Optionally, the first network element can be an IDCM, a UDM that supports the management or maintenance of the entity's key, or an AUSF that supports the management or maintenance of the entity's key. This application embodiment does not limit the implementation form of the first network element. For the terms IDCM, UDM, and AUSF, please refer to the relevant descriptions in Figure 1 or Figure 2 above; they will not be repeated hereafter. For ease of understanding, unless otherwise specified, the following description will use an IDCM as the first network element.
[0134] The second network element can be used to verify the access of the first entity. Optionally, the second network element can be the first network element, or the second network element can be two different network elements from the first network element. For example, the first network element is an IDCM, and the second network element can be an APP server, or an AF, etc., without restriction.
[0135] The third network element can be used to manage or maintain the preset key of the first terminal. Optionally, the preset key can be the root key, or a key derived from the root key, or other long-term keys other than the root key, without restriction. Optionally, the third network element can be a UDM.
[0136] 3. The first key can be used for communication between the first entity and the first network. For example, the first key can be used for the first entity to communicate with the first network through a second terminal. The first network can be the core network.
[0137] Alternatively, the first key can be used for communication between the first entity and the first network device. For example, the first key can be used for communication between the first entity and the first network device via a second terminal. The first network device can be a network device within a first network, or it can be a network device outside the first network. For example, the first network device can be a network device within a third-party network. This third-party device can be, for example, an AF (Automatic Application Server) or an APP server, etc., without limitation.
[0138] In one possible implementation, the first entity can also communicate directly with the first network or the first network device based on the first key, without needing to communicate with the first network or the first network device through a terminal.
[0139] The second terminal can be the first terminal, or the second terminal and the first terminal can be two different terminals, without restriction.
[0140] The communication method provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings. This method can be applied to the communication systems shown in Figures 1, 2, or 3, but is not limited thereto. Unless otherwise specified, "first terminal" in this application refers to a first terminal device, or it may be a device within the first terminal device. For example, a device within the first terminal device may refer to a component (e.g., a processor, chip, or chip system) within the first terminal device, or it may refer to a logic module or software capable of implementing all or part of the functions of the first terminal device. Similarly, unless otherwise specified, "first network element" in this application may be a network device with first network element functions, or it may be a device within that network device. For example, a device within the network device may refer to a component (e.g., a processor, chip, or chip system) within the network device, or it may refer to a logic module or software capable of implementing all or part of the functions of the first network element. Unless otherwise specified, the term "second network element" in this application can refer to a network device with second network element functions, or it can refer to a device within that network device. For example, a device within the network device can refer to a component of the network device (e.g., a processor, chip, or chip system), or it can refer to a logic module or software capable of implementing all or part of the functions of the second network element. Similarly, unless otherwise specified, the term "third network element" in this application can refer to a network device with third network element functions, or it can refer to a device within that network device. For example, a device within the network device can refer to a component of the network device (e.g., a processor, chip, or chip system), or it can refer to a logic module or software capable of implementing all or part of the functions of the third network element.
[0141] It is understood that in the embodiments of this application, the first terminal, the first network element, the second network element, or the third network element may execute some or all of the steps in the embodiments of this application. These steps or operations are merely examples, and the embodiments of this application may also execute other operations or variations thereof. Furthermore, the various steps may be executed in different orders as presented in the embodiments of this application, and it is not necessarily necessary to execute all the operations in the embodiments of this application.
[0142] Figure 4 is a flowchart illustrating a communication method provided in an embodiment of this application. As shown in Figure 4, the method may include the following:
[0143] S401: The first terminal sends a first message to the first network element. Correspondingly, the first network element receives the first message from the first terminal.
[0144] The first message can be used to request (or apply for) a first key for a first entity. This first key can be used by the first entity to communicate with the first network, or by the first entity to communicate with a first network device. Optionally, the first message can be a user credential request message (e.g., denoted as USER_CRE_REQ), without limitation. For example, the first terminal can send the first message to the first network element after completing the main authentication process with the first network.
[0145] For example, the first message may include at least one of the following: an identifier of the first terminal, information of the first entity, a first timestamp, or a second duration. The identifier of the first terminal can be used to identify the first terminal. For example, the identifier of the first terminal can be a subscriber permanent identifier (SUPI), a mobile terminal device permanent identifier (PEI), a temporary mobile subscriber identifier (TMSI), or a combination of the aforementioned identifiers. This application embodiment does not limit the implementation form of the identifier of the first terminal. The information of the first entity may include the identifier of the first entity and / or the type of the first entity. The identifier of the first entity can be used to identify the first entity. The type of the first entity may include, but is not limited to, at least one of the following: accessory device, application layer identity, wearable device, smart device, metaverse service, etc. Optionally, the type of the first entity can be understood as the relationship between the first entity and the first terminal. The first timestamp can be the timestamp of the first terminal requesting the first key. The second duration can be used to indicate the expected validity period of the first key, for example, one day or one month, etc., without limitation.
[0146] Optionally, the identifier of the first entity can be predefined, or it can be determined by the first terminal, the first network element, or the third network element, without limitation. For example, the first terminal can create (or generate, or determine) the identifier of the first entity. As another example, the first network element can create (or generate, or determine) the identifier of the first entity and send the identifier of the first entity to the first terminal. Yet another example, the third network element can create (or generate, or determine) the identifier of the first entity and send the identifier of the first entity to the first terminal. Optionally, the third network element can also send the identifier of the first entity to the first network element and / or the second network element.
[0147] For the terms "first entity," "first key," "first network," "first network element," "second network element," "third network element," and "first network device," please refer to the aforementioned terminology descriptions; they will not be repeated here.
[0148] S402: The first network element sends a second message to the first terminal. Correspondingly, the first terminal receives the second message from the first network element.
[0149] The first network element can respond to the first terminal's first message by sending a second message to the first terminal, or the first network element can proactively send a second message to the first terminal, i.e., S401 is an optional step (shown as a dashed line in Figure 4). For example, the first network element can proactively send a second message to the first terminal based on the first entity's subscription information or service information. This application embodiment does not limit the motivation for the first network element to proactively send a second message to the first terminal. Optionally, the second message can be a user credential response message (e.g., denoted as USER_CRE_RES), without restriction.
[0150] The second message may include information about the first key. This information about the first key can be used to determine (or indicate) the first key. In this application embodiment, the information about the first key can be implemented in various ways, which are described below.
[0151] Method 1: The information of the first key may include a random number. Alternatively, the information of the first key may include a random number and information about the first entity. The random number can be used to distinguish the first key from other keys to prevent replay attacks and identify related sessions of the first entity. Optionally, the random number can be generated by a third network element and sent to the first network element. For example, the third network element can generate a random number according to a random number generation algorithm and send it to the first network element. The random number generation algorithm can be, for example, a linear congruence algorithm or a Mason swivel algorithm, etc. This application embodiment does not limit the random number generation algorithm. The information of the first entity is described in S401 and will not be repeated here.
[0152] Optionally, the information of the first key includes a random number, and the information of the first key may also include information of the first entity and / or a first duration. Alternatively, the information of the first key includes a random number and information of the first entity, and the information of the first key may also include a first duration.
[0153] The first duration can indicate the validity period of the first key, such as one day, one month, or three months. This embodiment does not limit the validity period of the first key. The first key is valid within the first duration and invalid outside of it, which reduces the probability of the first key being cracked and improves the security of entity communication. Optionally, the first duration can be determined based on a second duration. The second duration is described in S401 and will not be repeated here. For example, the first duration and the second duration can be the same, or they can be different; there are no restrictions.
[0154] For example, the first key can be generated based on a preset key of the first terminal and information about the first key. For instance, the first key can be generated based on a random number and a preset key of the first terminal. Alternatively, the first key can be generated based on a random number, information about the first entity, and a preset key of the first terminal. Optionally, the preset key can be a root key, a key derived from the root key, or any other long-term key other than the root key; there are no limitations.
[0155] In one example, the first key can be a key derived from a random number, the identifier of the first entity, and the root key of the first terminal. The preset key for the first key is a long-term key; therefore, the first key generated based on the preset key of the first terminal is not a temporary key but also a long-term key, which will not change due to the access operation of the first terminal, eliminating the need to frequently obtain the key of the first entity. Furthermore, the first entity is no longer limited to access operations through the first terminal; for example, it can access operations through other terminals based on the first key, or it can access operations independently based on the first key. This adapts to more communication scenarios and improves user experience.
[0156] In one possible implementation, the first network element can obtain (or determine) information about the first key and send the information about the first key to the first terminal. In one embodiment, the first network element can generate a first key based on the information about the first key and a preset key of the first terminal, store (or maintain) the first key, and send a second message to the first terminal. For example, after receiving a first message, the first network element can determine the information about the first key, generate the first key based on the information about the first key and a preset key of the first terminal, and store the first key. For example, the first network element can generate the first key based on a random number and a preset key of the first terminal. Another example is that the first network element can generate the first key based on a random number, information about a first entity, and a preset key of the first terminal. For example, the first network element can generate the first key based on a random number, the identifier of the first entity, and the root key of the first terminal. Optionally, the first network element can be a UDM (User Device Manager). Optionally, the first network element can also determine the identifier of the first entity and / or a first duration.
[0157] In another implementation, the first network element can send a fifth message to the third network element, which can be used to request a first key for the first entity. Correspondingly, the third network element receives the fifth message and sends a response message to the first network element, the response message including information about the first key. The first network element receives the response message and sends a second message to the first terminal. Optionally, the fifth message may include information about the first entity and / or the identifier of the first terminal. For example, the third network element receives the fifth message from the first network element, generates a first key based on the information of the first key and a preset key of the first terminal, stores the first key, and sends a response message to the first network element. For example, the third network element can determine the information of the first key, generate the first key based on the information of the first key and a preset key of the first terminal, and store the first key. For example, the third network element can generate the first key based on a random number and a preset key of the first terminal. Another example is that the third network element can generate the first key based on a random number, information about the first entity, and a preset key of the first terminal. For example, the third network element can generate the first key based on a random number, the identifier of the first entity, and the root key of the first terminal. Optionally, the response message of the fifth message may also include information about the first entity and / or the first duration. For example, the third network element may determine the identifier of the first entity and / or the first duration. Optionally, the third network element may be a UDM.
[0158] The first terminal receives the second message and can generate a first key based on the information of the first key and the preset key of the first terminal. Optionally, the first terminal can also store (or maintain) the first key. For example, the first terminal can generate the first key based on a random number and the preset key of the first terminal. As another example, the first terminal can generate the first key based on a random number, information of the first entity, and the preset key of the first terminal. For example, the first terminal can generate the first key based on a random number, the identifier of the first entity, and the root key of the first terminal.
[0159] In one possible implementation, the first terminal may send a first key to the first entity; correspondingly, the first entity may receive the first key from the first terminal. Optionally, the first terminal may also send an identifier and / or a first duration to the first entity; correspondingly, the first entity may receive the identifier and / or the first duration from the first terminal. For example, if the first entity is a device that supports establishing an association with the first terminal, such as an external device mounted on the first terminal, the first terminal may send the first key to the first entity.
[0160] In another possible implementation, the first terminal can configure (or store, or set) a first key. For example, the first terminal can configure a first key for a first entity. Optionally, the first terminal can also configure (or store) the identifier and / or first duration of the first entity. For example, if the first entity is a device in the first terminal, such as an application layer user, APP, or module, the first terminal can configure the first key.
[0161] In one possible implementation, after obtaining the first key, the first entity can access the first network or the first network device based on the first key. For example, the first entity can encrypt its information (or its identifier) based on the first key and send the encrypted information to the core network. The UDM in the core network can determine (or look up) the first key and the first duration based on the first entity's information (or its identifier). If the first key has expired, the UDM can refuse the first entity's access. If the first key has not expired, the UDM can perform authentication and / or key negotiation processes, such as performing the Extensible Authentication Protocol-Authentication and Key Agreement (EAP-AKA) process. This application embodiment does not limit the implementation process of the EAP-AKA process. Furthermore, this application embodiment does not limit the verification process of the first key.
[0162] In Method 1 described above, the first terminal and the first network element do not need to transmit the first key; instead, they transmit a random number (or a random number and information about the first entity) used to generate the first key, which improves the security of key transmission. Furthermore, this first key is a long-term key, eliminating the need to frequently obtain the first entity's key. It is also no longer limited to communication between the first terminal and the first network or network device, but supports flexible terminal switching, adapting to more communication scenarios and improving user experience.
[0163] Method 2: The information of the first key may include the first key and a ticket. This ticket can be, for example, a granted ticket (GT), and is not limited thereto. Exemplarily, the first network element can create the first key and ticket. For example, after receiving the first message, the first network element can create the first key and ticket. This application embodiment does not limit the method of creating the first key. Optionally, the first network element can also determine a first duration.
[0164] The ticket can be encrypted with a second key. The second key can be a key of the first network, or a key of a first network device. For example, the first key is used for communication between the first entity and the first network, and the second key can be a key of the first network. Alternatively, the first key is used for communication between the first entity and a first network device, and the second key can be a key of the first network device. Optionally, the first key being used for communication between the first entity and the first network can be understood as: the first key being used for communication between the first entity and one or more network elements (or network devices) within the first network.
[0165] The ticket may include information about the first entity and a first key. Optionally, the ticket may also include at least one of the following: an identifier of the first terminal, a first timestamp, or a first duration. The identifier of the first terminal, the first timestamp, and the first duration are described above and will not be repeated here. It is understood that the ticket, even after being encrypted with a second key, can still be called a ticket, or it can be given other names without restriction.
[0166] The second key is the key of the first network or the first network device, meaning that the first terminal cannot decrypt the ticket. The first entity's access can be authenticated using the first key and the ticket, and the network side does not need to store or maintain the first key. This first key can be a long-term key that will not change due to the first terminal's access operation, eliminating the need for frequent acquisition of the first entity's key. Furthermore, the first entity is no longer limited to accessing through the first terminal; for example, it can access through other terminals based on the first key, or it can access independently based on the first key. This adapts to more communication scenarios and improves user experience.
[0167] In one possible implementation, the first key can be transmitted based on a third key. For example, the first network element can encrypt the first key based on the third key and send the encrypted first key and ticket to the first terminal. Correspondingly, the first terminal can decrypt the first key based on the third key to obtain the first key. This third key can be generated based on a preset key of the first terminal. For example, the third key can be generated based on the root key of the first terminal. In one embodiment, the third key can be a key between the first terminal and the AUSF, such as denoted as Kausf, which is generated based on the root key of the first terminal. In another embodiment, the third key can also be a key between the first terminal and the first network element, which can be based on Kausf. For example, if the first network element is an IDCM, the third key is a key between the first terminal and the IDCM, such as denoted as Kidcm, which is generated based on Kausf. In this implementation, the first terminal and the first network element encrypt and transmit the first key, which helps improve the security of the first key transmission.
[0168] In one possible implementation, the first terminal can send a first key and a ticket to the first entity; correspondingly, the first entity can receive the first key and ticket from the first terminal. Optionally, the first terminal can also send an identifier of the first entity and / or a first duration to the first entity; correspondingly, the first entity can receive the identifier of the first entity and / or the first duration from the first terminal. For example, if the first entity is a device that supports establishing an association with the first terminal, such as an external device mounted on the first terminal, the first terminal can send the first key and ticket to the first entity.
[0169] In another possible implementation, the first terminal can configure (or store, or set) a first key and a ticket. For example, the first terminal can configure a first key and a ticket for a first entity. Optionally, the first terminal can also configure (or store) the identifier and / or first duration of the first entity. For example, if the first entity is a device in the first terminal, such as an application layer user, an APP, or a module, the first terminal can configure the first key and ticket.
[0170] In one possible implementation, the first terminal can send a third message to the second network element; the second network element receives the third message from the first terminal and sends a response message to the third message to the first terminal. The third message may include a ticket and information obtained by encrypting information of the first entity based on a first key. This third message can be used by the first entity to request access to the first network, or it can be used by the first entity to request access to a first network device. For example, if the ticket is encrypted with a key of the first network, the third message can be used by the first entity to request access to the first network. Similarly, if the ticket is encrypted with a key of the first network device, the third message can be used by the first entity to request access to the first network device. The third message can be, for example, a user access request message (e.g., denoted as USER-ACC-REQ), without limitation. The response message to the third message indicates whether access is permitted. The response message to the third message can be, for example, a user access response message (e.g., denoted as USER-ACC-RES), without limitation. Optionally, accessing the first network device can be replaced by establishing a connection with the first network device.
[0171] In one embodiment, the information obtained by encrypting the information of the first entity based on the first key may include: information obtained by encrypting at least one of the identifier of the first terminal, the first timestamp, the second timestamp, or the first duration, and the information of the first entity based on the first key. The second timestamp is the timestamp at which the first entity uses the first key. The identifier of the first terminal, the first timestamp, and the first duration are described above and will not be repeated here.
[0172] In one implementation, if a first condition is met, the response message of the third message can be used to indicate that access is allowed; or, if the first condition is not met, the response message of the third message can be used to indicate that access is not allowed. The first condition may include: the information of the first entity encrypted by the first key is the same as the information of the first entity included in the ticket; or, the information encrypted by the first key matches the information included in the ticket. In one example, a second network element receives information and a ticket obtained by encrypting the information of the first entity based on the first key, decrypts the ticket based on the second key to obtain the information of the first entity (e.g., denoted as information 1) and the first key, and decrypts the information encrypted by the first key based on the first key to obtain the information of the first entity (e.g., denoted as information 1). The second network element can compare information 1 and information 2. If information 1 and information 2 are the same (or identical), authentication is successful, and the second network element can send a response message of the third message to the first terminal, which indicates that access is allowed; or, if information 1 and information 2 are different, authentication fails, and the second network element can send a response message of the third message to the first terminal, which indicates that access is not allowed.
[0173] In another example, the ticket may include more information, and the information encrypted based on the first key may include even more information. For example, the ticket includes the first key, information about the first entity, a first duration, and a first timestamp. The first terminal sends the information and the ticket, which are encrypted based on the first key, the first duration, the first timestamp, and the second timestamp of the first entity, to the second network element. The second network element decrypts the ticket based on the second key to obtain the first key, the information about the first entity, the first duration, and the first timestamp (referred to as information 3, i.e., information 3 includes the information about the first entity, the first duration, and the first timestamp), and decrypts the information encrypted by the first key based on the first key to obtain the information about the first entity, the first duration, the first timestamp, and the second timestamp (referred to as information 4, i.e., information 4 includes the information about the first entity, the first duration, the first timestamp, and the second timestamp). The second network element can compare information 3 and information 4. If information 3 and information 4 match, authentication is successful, and the second network element can send a third message response to the first terminal, indicating that access is allowed. Alternatively, if information 3 and information 4 do not match, authentication fails, and the second network element can send a third message response to the first terminal, indicating that access is not allowed. Here, matching information 3 and information 4 can be understood as follows: the information of the first entity in information 3 is the same as the information of the first entity in information 4; the first timestamp in information 3 is the same as the first timestamp in information 4; the first duration in information 3 is the same as the first duration in information 4; and the second timestamp in information 4 is later than the time of the first entity's last access and close to the current network time.
[0174] It should be noted that the second network element can decrypt the ticket based on the second key, or the second network element can also decrypt the ticket based on a key associated with the second key. For example, if the second network element stores (or maintains) the symmetric key of the first network device's key, the ticket can be encrypted with the first network device's key, and the second network element can decrypt it based on the first network device's key; or, if the second network element does not store (or maintain) the symmetric key of the first network device's key, the ticket can be encrypted with the first network device's public key, and the second network element can decrypt it based on the first network device's private key.
[0175] In one implementation, the response message of the third message is used to indicate that access is allowed. The response message may include a first timestamp and a second timestamp, which are encrypted by a first key. In one example, the first entity is a device in a first terminal. The first entity can decrypt based on the first key to obtain the first and second timestamps and verify their consistency with locally stored timestamps. For example, if the decrypted timestamps match the locally stored timestamps, access is determined to be successful (or access is allowed); or, if the decrypted timestamps match the locally stored timestamps, access is determined to be unsuccessful (or access is not allowed).
[0176] In another example, the first entity is a device that supports establishing an association with the first terminal. The first terminal can send a response message of the third message to the first entity. The first entity receives the response message of the third message, decrypts it based on the first key to obtain the first timestamp and the second timestamp, and verifies the consistency between the decrypted first timestamp and the second timestamp and the locally stored first timestamp and the second timestamp.
[0177] In one implementation, the first terminal can obtain a fourth message and send a third message to the second network element based on the fourth message. For example, the first terminal can obtain the fourth message from a first entity. For example, the first entity can send the fourth message to the first terminal, and correspondingly, the first terminal can receive the fourth message from the first entity. The fourth message may include a ticket and information obtained by encrypting the information of the first entity based on a first key. This fourth message can be used by the first entity to request access to the first network, or it can be used by the first entity to request access to a first network device. For example, if the ticket is encrypted with a key of the first network, the fourth message can be used by the first entity to request access to the first network. As another example, if the ticket is encrypted with a key of the first network device, the fourth message can be used by the first entity to request access to the first network device.
[0178] In Method 2 above, the ticket is encrypted with a second key, which is the key of the first network or the first network device. This means that the first terminal cannot decrypt the ticket, and the access of the first entity can be authenticated through the first key and the ticket. The network side does not need to store or maintain the first key. Furthermore, this first key is a long-term key, eliminating the need to frequently obtain the first entity's key. It is also no longer limited to communication between the first terminal and the first network or the first network device, but supports flexible switching of terminals for access operations, adapting to more communication scenarios and improving user experience.
[0179] In the embodiment shown in Figure 4, the first network element can send the first key information to the first terminal in response to the first message from the first terminal, or it can actively send the first key information to the first terminal, so that the first terminal can obtain the first key. In this way, the first entity can communicate with the first network or the first network device based on the first key, which helps to ensure the security of entity communication.
[0180] The following section describes method 1 in conjunction with Figure 5.
[0181] Figure 5 shows a flowchart illustrating a communication method provided in an embodiment of this application. Figure 5 illustrates an example where the first entity is an external device serving as the first terminal, the first network element is an independently deployed IDCM, and the third network element is a UDM. As shown in Figure 5, the method may include the following:
[0182] S501: The first terminal sends a first message to the IDCM. Correspondingly, the IDCM receives the first message from the first terminal.
[0183] S501 is an optional step, indicated by a dashed line in Figure 5. The first message can be used to apply for (or request) a first key for the first entity. Optionally, the first message may include at least one of the following: an identifier of the first terminal, information about the first entity, a first timestamp, or a second duration.
[0184] S502: The IDCM sends the fifth message to the UDM. Correspondingly, the UDM receives the fifth message from the IDCM.
[0185] The fifth message can be used to request the first key for the first entity. Optionally, the fifth message may include information about the first entity and / or the identifier of the first terminal.
[0186] Optionally, IDCM can generate (or determine) the identifier of the first entity.
[0187] S503: UDM generates the first key based on the information of the first key and the preset key of the first terminal.
[0188] The information of the first key may include a random number, or a random number and information about the first entity. Figure 5 illustrates an example of UDM generating the first key based on a random number, the identifier of the first entity, and a preset key of the first terminal. Optionally, the preset key may be a root key, a key derived from the root key, or any other long-term key other than the root key; there are no restrictions.
[0189] Optionally, the UDM can determine the first duration, which is not shown in Figure 5.
[0190] Optionally, UDM can generate (or determine) the identifier of the first entity, which is not shown in Figure 5.
[0191] S504: UDM stores the first key.
[0192] UDM can store or maintain the first key.
[0193] S505: UDM sends a response message for the fifth message to IDCM. Correspondingly, IDCM receives the response message for the fifth message from UDM.
[0194] The response message of the fifth message may include information about the first key, or may include information about the first key and a first duration. It is understood that the first duration may also be included in the information about the first key, without limitation.
[0195] Figure 5 illustrates an example where the response message of the fifth message includes a random number, the identifier of the first entity, and the first duration.
[0196] S506: The ICDM sends a second message to the first terminal. Correspondingly, the first terminal receives the second message from the IDCM.
[0197] The second message may include information about the first key, or it may include information about the first key and a first duration. In this embodiment, the information about the first key includes a random number.
[0198] Figure 5 illustrates an example where the second message includes a random number, the identifier of the first entity, and the first duration.
[0199] S507: The first terminal generates the first key based on the information of the first key and the preset key of the first terminal.
[0200] For example, the first terminal can generate a first key based on the second message. Figure 5 illustrates an example of the first terminal generating a first key based on a random number, the identifier of the first entity, and a preset key of the first terminal.
[0201] Optionally, the first terminal may store or maintain a first key, which is not shown in Figure 5.
[0202] S508: The first terminal sends a first key to the first entity. Accordingly, the first entity receives the first key from the first terminal.
[0203] The first terminal can send a first key to the first entity, or send a first key and a first duration to the first entity. Figure 5 illustrates an example of the first terminal sending a first key and a first duration to the first entity.
[0204] After obtaining the first key, the first entity can access the first network or the first network device based on the first key. For example, the first entity can encrypt its information (or its identifier) based on the first key and send the encrypted information to the core network. The UDM in the core network can determine (or look up) the first key and the first duration based on the first entity's information (or its identifier). If the first key has expired, the UDM can deny the first entity's access. If the first key has not expired, the UDM can execute the EAP-AKA procedure.
[0205] Next, we will introduce method 2 above with reference to Figures 6 and 7.
[0206] Figure 6 shows a flowchart illustrating a communication method provided in an embodiment of this application. Figure 6 illustrates an example where the first entity is an external device of the first terminal, the first network element is an independently deployed IDCM, and the second network element is the same as the first network element. In this embodiment, the first network element and the second network element are the same network element. As shown in Figure 6, the method may include the following:
[0207] S601: The first terminal sends a first message to the IDCM. Correspondingly, the IDCM receives the first message from the first terminal.
[0208] S601 is an optional step, indicated by a dashed line in Figure 6. The first message can be used to apply for (or request) a first key for the first entity. Optionally, the first message may include at least one of the following: an identifier of the first terminal, information about the first entity, a first timestamp, or a second duration.
[0209] S602: IDCM creates the identifier and first key for the first entity.
[0210] The IDCM can create a first key, and the implementation process of creating the first key by the IDCM in this embodiment is not limited. Optionally, the IDCM can also create an identifier for a first entity. Figure 6 illustrates an example of the IDCM creating an identifier and a first key for a first entity.
[0211] S603: IDCM generates tickets.
[0212] The ticket is encrypted using a second key. The second key can be a key of the first network, or a key of a first network device. In this embodiment, the second key is a key of the first network. Optionally, the ticket may further include at least one of the following: an identifier of the first terminal, a first timestamp, or a first duration.
[0213] S604: The IDCM sends a second message to the first terminal. Correspondingly, the first terminal receives the second message from the IDCM.
[0214] The second message may include information about the first key, or information about the first key and a first duration. In this embodiment, the information about the first key includes the first key and the ticket.
[0215] Figure 6 illustrates an example where the second message includes the identifier of the first entity, the first key, the first duration, and the ticket.
[0216] S605: The first terminal sends the identifier of the first entity, the first key, the first duration, and the ticket to the first entity.
[0217] Accordingly, the first entity receives the first entity's identifier, first key, first duration, and ticket from the first terminal.
[0218] The first terminal may send a first key and a ticket to the first entity. Optionally, the first terminal may also send the identifier of the first entity and / or a first duration to the first entity.
[0219] Figure 6 illustrates an example of a first terminal sending the identifier, first key, first duration, and ticket of a first entity to a first entity.
[0220] S606: The first entity sends a fourth message to the first terminal. Accordingly, the first terminal receives the fourth message from the first entity.
[0221] The fourth message can be used to request access to the first network or to request access to the first network device. In this embodiment, requesting access to the first network is used as an example.
[0222] The fourth message may include a ticket and information 1, which is encrypted by the first key. For example, information 1 is obtained by encrypting information of the first entity based on the first key. Alternatively, information 1 is obtained by encrypting at least one of the identifier of the first terminal, a first timestamp, a second timestamp, or a first duration, and information of the first entity based on the first key.
[0223] S607: The first terminal sends a third message to the IDCM. Correspondingly, the IDCM receives the third message from the first terminal.
[0224] For example, the first terminal can send a third message to the IDMC based on the fourth message.
[0225] This third message can be used to request access to the first network. This third message includes a ticket and information 1.
[0226] S608: IDCM decrypts the ticket based on the second key to obtain information 2 and the first key.
[0227] Information 2 may include information about the first entity. Optionally, information 2 may include at least one of the identifier of the first terminal, a first timestamp, or a first duration, as well as information about the first entity.
[0228] S609: IDCM decrypts information 1 based on the first key to obtain the decrypted information 1.
[0229] S610: IDCM determines that the decrypted message 1 matches message 2.
[0230] IDCM can determine whether the decrypted information 1 matches information 2. For the implementation process, please refer to the relevant content in Figure 4, which will not be repeated here.
[0231] Figure 6 illustrates an example of matching decrypted information 1 with information 2.
[0232] S611: The IDCM sends a response message for the third message to the first terminal. Correspondingly, the first terminal receives the response message for the third message from the IDCM.
[0233] The response message to the third message can be used to indicate that access is permitted. The response message to the third message may include information 3, which is encrypted using the first key. For example, information 3 is information obtained by encrypting a first timestamp and / or a second timestamp using the first key.
[0234] Figure 6 illustrates information 3 as an example, obtained by encrypting the first timestamp and the second timestamp based on the first key.
[0235] S612: The first terminal sends a response message for the fourth message to the first entity. Accordingly, the first entity receives the response message for the fourth message from the first terminal.
[0236] For example, the first terminal can send a response message of the fourth message to the first entity based on the response message of the third message.
[0237] The response message to the fourth message can be used to indicate that access is permitted. The response message to the fourth message may include information 3, which is encrypted by the first key.
[0238] S613: The first entity decrypts information 3 based on the first key and obtains the decrypted information 3.
[0239] S614: The first entity determines that the first and second timestamps in the decrypted information 3 are the same as the local first and second timestamps.
[0240] For example, the first entity can determine whether the first and second timestamps in the decrypted information 3 are the same as the local first and second timestamps. Figure 6 illustrates an example where the first and second timestamps in the decrypted information 3 are the same as the local first and second timestamps.
[0241] Figure 7 shows a flowchart illustrating a communication method provided in an embodiment of this application. In Figure 7, the first entity is the device in the first terminal, the first network element is an independently deployed IDCM, and the second network element is an AF (Automatic Field Assembly). In this embodiment, the first network element and the second network element are two different network elements. As shown in Figure 7, the method may include the following:
[0242] S701: The first terminal sends a first message to the IDCM. Correspondingly, the IDCM receives the first message from the first terminal.
[0243] S701 is an optional step, indicated by a dashed line in Figure 7. The first message can be used to apply for (or request) a first key for the first entity. Optionally, the first message may include at least one of the following: an identifier of the first terminal, information about the first entity, a first timestamp, or a second duration.
[0244] S702: IDCM creates the identifier and first key for the first entity.
[0245] The IDCM can create a first key, and the implementation process of creating the first key by the IDCM in this embodiment is not limited. Optionally, the IDCM can also create an identifier for a first entity. Figure 7 illustrates an example of the IDCM creating an identifier and a first key for a first entity.
[0246] S703: IDCM generates tickets.
[0247] The ticket is encrypted using a second key. The second key can be a key of the first network, or a key of a first network device. In this embodiment, the second key is a key of the first network. Optionally, the ticket may further include at least one of the following: an identifier of the first terminal, a first timestamp, or a first duration.
[0248] S704: The IDCM sends a second message to the first terminal. Correspondingly, the first terminal receives the second message from the IDCM.
[0249] In this embodiment, the first entity is a device in the first terminal. Optionally, the first terminal, upon receiving the second message, can configure a first key and ticket for the first entity, as not shown in Figure 7.
[0250] The second message may include information about the first key, or information about the first key and a first duration. In this embodiment, the information about the first key includes the first key and the ticket.
[0251] Figure 7 illustrates an example where the second message includes the identifier of the first entity, the first key, the first duration, and the ticket.
[0252] S705: The first terminal sends a third message to the AF. Accordingly, the AF receives the third message from the first terminal.
[0253] The third message can be used to request access to the first network or to request access to the first network device. In this embodiment, the third message is used to request access to the first network device. The first network device can be, for example, an AF (Automatic Access Device), and is not limited thereto. The third message includes a ticket and information 1. Information 1 is encrypted with a first key. For example, information 1 is obtained by encrypting the information of the first entity based on the first key. Alternatively, information 1 is obtained by encrypting at least one of the identifier of the first terminal, a first timestamp, a second timestamp, or a first duration, and the information of the first entity based on the first key.
[0254] S706: AF decrypts the ticket based on the second key to obtain information 2 and the first key.
[0255] Information 2 may include information about the first entity. Optionally, information 2 may include at least one of the identifier of the first terminal, a first timestamp, or a first duration, as well as information about the first entity.
[0256] S707: AF decrypts information 1 based on the first key to obtain the decrypted information 1.
[0257] S708: AF determines that the decrypted information 1 matches information 2.
[0258] AF can determine whether the decrypted information 1 matches information 2. Please refer to the relevant content in Figure 4 for the implementation process, which will not be repeated here.
[0259] Figure 7 illustrates an example of matching decrypted information 1 with information 2.
[0260] S709: The AF sends a response message for the third message to the first terminal. Correspondingly, the first terminal receives the response message for the third message from the AF.
[0261] The response message to the third message can be used to indicate that access is permitted. The response message to the third message may include information 3, which is encrypted using the first key. For example, information 3 is information obtained by encrypting a first timestamp and / or a second timestamp using the first key.
[0262] Figure 7 illustrates information 3 as an example, obtained by encrypting the first timestamp and the second timestamp using the first key.
[0263] S710: The first terminal decrypts information 3 based on the first key and obtains the decrypted information 3.
[0264] S711: The first terminal determines that the first and second timestamps in the decrypted information 3 are the same as the local first and second timestamps.
[0265] For example, the first terminal can determine whether the first and second timestamps in the decrypted information 3 are the same as the local first and second timestamps. Figure 7 illustrates this with the example of the first and second timestamps in the decrypted information 3 being the same as the local first and second timestamps.
[0266] The embodiments provided in this application describe the methods provided by the embodiments of this application from the perspective of interaction among multiple communication devices (e.g., a first terminal, a first network element, and a third network element). The steps performed by the communication devices (e.g., a first terminal, a first network element, or a third network element) can be implemented by different functional entities that make up the communication devices. The communication devices (e.g., a first terminal, a first network element, or a third network element) may include hardware structures and / or software modules, implementing the above functions in the form of hardware structures, software modules, or a combination of hardware structures and software modules. Whether a particular function is executed in the form of hardware structures, software modules, or a combination of hardware structures and software modules depends on the specific application and design constraints of the technical solution.
[0267] The communication device used to implement the above method in the embodiments of this application is described below with reference to the accompanying drawings. Therefore, the content above can be used in subsequent embodiments, and repeated content will not be described again.
[0268] Figure 8 illustrates a schematic diagram of a communication device 800. This communication device 800 can implement the functions or steps performed by the first terminal, the first network element, or the third network element in the various method embodiments described above.
[0269] For example, when the communication device 800 is used to implement the functions or steps implemented by the first terminal in the above method embodiments, the communication device 800 may be the first terminal or a device in the first terminal.
[0270] For example, when the communication device 800 is used to implement the functions or steps implemented by the first network element in the above method embodiments, the communication device 800 may be the first network element or a device in the first network element.
[0271] For example, when the communication device 800 is used to implement the functions or steps implemented by the third network element in the above method embodiments, the communication device 800 may be the third network element or a device in the third network element.
[0272] In one embodiment, the communication device 800 may include a processing module 801 and a transceiver module 802. The processing module 801 can be used for data processing, such as executing the various method embodiments described above. The processing module 801 may also be referred to as a processing unit, etc. The transceiver module 802 can be used to implement corresponding communication functions, such as receiving or sending relevant data, information, or messages. The transceiver module 802 may also be referred to as a communication interface, a communication module, or a transceiver unit, etc.
[0273] It should be noted that the communication device 800 may include a processing module 801, but not a transceiver module 802. Alternatively, the communication device 800 may include a transceiver module 802, but not a processing module 801. Specifically, it depends on whether the above-described scheme executed by the communication device 800 includes processing and transceiver actions.
[0274] Optionally, the communication device 800 may further include a storage module 803, shown as a dashed line in FIG8. The storage module 803 may be used to store instructions and / or data, and the processing module 801 may read the instructions and / or data in the storage module 803 to enable the communication device 800 to implement the aforementioned method embodiment.
[0275] Optionally, the transceiver module 802 may include a sending module and a receiving module. The sending module is used to perform the sending operation in the above method embodiments. The receiving module is used to perform the receiving operation in the above method embodiments.
[0276] It should be noted that the communication device 800 may include a transmitting module but not a receiving module. Alternatively, the communication device 800 may include a receiving module but not a transmitting module. Specifically, it depends on whether the above-described scheme executed by the communication device 800 includes both transmitting and receiving actions.
[0277] Optionally, the communication device 800 is a chip system, the transceiver module 802 can be the input / output interface of a chip (e.g., a baseband chip), and the processing unit can be the processor of the chip system.
[0278] In the first implementation, the communication device 800 can perform the functions of a first terminal, executing the following: a transceiver module 802, configured to send a first message to a first network element, the first message being used to request a first key for a first entity, the first key being used for the first entity to communicate with a first network, or the first key being used for the first entity to communicate with a first network device; and receiving a second message from the first network element, the second message including information about the first key.
[0279] In the second implementation, the communication device 800 can perform the functions of the first terminal and execute the following: a transceiver module 802 is used to receive a second message from a first network element, the second message including information about a first key, the first key being used for communication between the first entity and the first network, or the first key being used for communication between the first entity and the first network device.
[0280] In one possible implementation, the information of the first key may include a random number, or the information of the first key may include a random number and the information of the first entity.
[0281] In one possible implementation, the processing module 801 is further configured to generate the first key based on the information of the first key and the preset key of the first terminal. Optionally, the preset key can be a root key, or a key derived from the root key, or other long-term keys other than the root key, without limitation.
[0282] In one possible implementation, the transceiver module 802 is further configured to send the first key to the first entity; or, the processing module 801 is further configured to configure the first key.
[0283] In one possible implementation, the information of the first key may include the first key and a ticket, the ticket including information of the first entity and the first key, wherein the ticket is encrypted by a second key, the second key being a key of the first network, or the second key being a key of the first network device.
[0284] In one possible implementation, the transceiver module 802 is further configured to send the first key and the ticket to the first entity. Alternatively, the processing module 801 is further configured to configure the first key and the ticket.
[0285] In one possible implementation, the transceiver module 802 is further configured to send a third message to the second network element, the third message including the ticket and information obtained by encrypting the information of the first entity based on the first key, the third message being used by the first entity to request access to the first network, or the third message being used by the first entity to request access to the first network device; and to receive a response message from the second network element for the third message, the response message being used to indicate whether access is allowed. Optionally, the second network element can be the first network element; or it can be other network elements besides the first network element, such as an application server or an application function network element.
[0286] In one possible implementation, processing module 801 is used to obtain a fourth message, the fourth message including the ticket and information obtained by encrypting the information of the first entity based on the first key, the fourth message being used by the first entity to request access to the first network, or the fourth message being used by the first entity to request access to the first network device; transceiver module 802 is used to send the third message to the second network element according to the fourth message.
[0287] In one possible implementation, if the first condition is met, the response message of the third message is used to indicate that access is allowed; or, if the first condition is not met, the response message of the third message is used to indicate that access is not allowed; wherein the first condition includes: the information of the first entity encrypted by the first key is the same as the information of the first entity included in the ticket.
[0288] In one possible implementation, the information obtained by encrypting the information of the first entity based on the first key may include: information obtained by encrypting at least one of the identifier of the first terminal, a first timestamp, a second timestamp, or a first duration, and the information of the first entity based on the first key; wherein, the first timestamp is the timestamp when the first terminal requests the first key, the second timestamp is the timestamp when the first entity uses the first key, and the first duration is used to indicate the effective duration of the first key.
[0289] In one possible implementation, the ticket may further include at least one of the following: an identifier of the first terminal, a first timestamp, or a first duration; wherein the first timestamp is the timestamp at which the first terminal requests the first key, and the first duration is used to indicate the validity period of the first key.
[0290] In one possible implementation, the information of the first key includes at least one of the following: information of the first entity, or a first duration, wherein the first duration is used to indicate the effective duration of the first key.
[0291] In one possible implementation, the first message includes at least one of the following: the identifier of the first terminal, information of the first entity, a first timestamp, or a second duration; wherein the first timestamp is the timestamp at which the first terminal requests the first key, and the second duration is used to indicate the expected validity period of the first key.
[0292] In one possible implementation, the information of the first entity includes the identifier of the first entity and / or the type of the first entity.
[0293] In one possible implementation, the identifier of the first entity is determined by the first terminal, or the identifier of the first entity is determined by the first network element, or the identifier of the first entity is determined by the third network element.
[0294] In the third implementation, the communication device 800 can perform the functions of the first network element, executing the following: a transceiver module 802 is used to receive a first message from a first terminal, the first message being used to request a first key for a first entity, the first key being used for the first entity to communicate with the first network, or the first key being used for the first entity to communicate with a first network device; and to send a second message to the first terminal, the second message including information about the first key.
[0295] In the fourth implementation, the communication device 800 can perform the function of the first network element and execute the following: transceiver module 802 is used to send a second message to the first terminal, the second message including information of a first key, the first key being used for the first entity to communicate with the first network, or the first key being used for the first entity to communicate with the first network device.
[0296] In one possible implementation, the first entity can be a device that supports establishing an association with the first terminal. For example, the device that supports establishing an association with the first terminal can be a smart device or a wearable device, etc., without limitation. Alternatively, the first entity can also be a device in the first terminal. For example, the first entity can be an app installed on the first terminal, different users on the first terminal, virtual identities on the first terminal (e.g., digital humans, or virtual humans, etc.), circuits in the first terminal, modules in the first terminal, or logic modules in the first terminal, etc.
[0297] In one possible implementation, the information of the first key includes a random number, or the information of the first key includes a random number and information of the first entity.
[0298] In one possible implementation, the processing module 801 is further configured to generate the first key based on the information of the first key and the preset key of the first terminal; and the storage module 803 is configured to store the first key.
[0299] In one possible implementation, the transceiver module 802 is further configured to send a fifth message to a third network element, the fifth message being used to request the first key for the first entity; and to receive a response message from the third network element for the fifth message, the response message including information about the first key.
[0300] In one possible implementation, the information of the first key includes the first key and a ticket, the ticket including information of the first entity and the first key, wherein the ticket is encrypted by a second key, the second key being a key of the first network, or the second key being a key of the first network device.
[0301] In one possible implementation, the transceiver module 802 is further configured to receive a third message, the third message being used by the first entity to request access to the first network, or the third message being used by the first entity to request access to the first network device, the third message including the ticket and information obtained by encrypting the information of the first entity based on the first key; and to send a response message to the third message, the response message being used to indicate whether access is allowed.
[0302] In one possible implementation, if the first condition is met, the response message of the third message is used to indicate that access is allowed; or, if the first condition is not met, the response message of the third message is used to indicate that access is not allowed; wherein the first condition includes: the information of the first entity encrypted by the first key is the same as the information of the first entity included in the ticket.
[0303] In one possible implementation, the information obtained by encrypting the information of the first entity based on the first key may include: information obtained by encrypting at least one of the identifier of the first terminal, a first timestamp, a second timestamp, or a first duration, and the information of the first entity based on the first key; wherein, the first timestamp is the timestamp when the first terminal requests the first key, the second timestamp is the timestamp when the first entity uses the first key, and the first duration is used to indicate the effective duration of the first key.
[0304] In one possible implementation, the ticket may further include at least one of the following: an identifier of the first terminal, a first timestamp, or a first duration; wherein the first timestamp is the timestamp at which the first terminal requests the first key, and the first duration is used to indicate the validity period of the first key.
[0305] In one possible implementation, the information of the first key may include at least one of the following: information of the first entity, or a first duration, wherein the first duration is used to indicate the effective duration of the first key.
[0306] In one possible implementation, the first message may include at least one of the following: the identifier of the first terminal, information of the first entity, a first timestamp, or a second duration; wherein the first timestamp is the timestamp at which the first terminal requests the first key, and the second duration is used to indicate the expected validity period of the first key.
[0307] In one possible implementation, the information of the first entity may include the identifier of the first entity and / or the type of the first entity.
[0308] In one possible implementation, the identifier of the first entity is determined by the first terminal, or the identifier of the first entity is determined by the first network element, or the identifier of the first entity is determined by the third network element.
[0309] In the fifth implementation, the communication device 800 can perform the functions of a third network element, executing the following: a transceiver module 802 is used to receive a fifth message from a first network element, the fifth message being used to request a first key for a first entity, the first key being used for the first entity to communicate with a first network, or the first key being used for the first entity to communicate with a first network device; and to send a response message of the fifth message to the first network element, the response message of the fifth message including information about the first key.
[0310] In one possible implementation, the first entity can be a device that supports establishing an association with the first terminal. For example, the device that supports establishing an association with the first terminal can be a smart device or a wearable device, etc., without limitation. Alternatively, the first entity can also be a device in the first terminal. For example, the first entity can be an app installed on the first terminal, different users on the first terminal, virtual identities on the first terminal (e.g., digital humans, or virtual humans, etc.), circuits in the first terminal, modules in the first terminal, or logic modules in the first terminal, etc.
[0311] In one possible implementation, the information of the first key includes a random number, or the information of the first key includes a random number and information of the first entity.
[0312] In one possible implementation, the transceiver module 802 is further configured to generate the first key based on the information of the first key and the preset key of the first terminal; and the storage module 803 is configured to store the first key.
[0313] The implementation process of each of the above modules can be found in the aforementioned method embodiments, and will not be repeated here.
[0314] As shown in Figure 9, this application provides a schematic diagram of the structure of another communication device 900. The communication device 900 may include a processor 920, used to implement or support the communication device 900 in implementing the functions of the first terminal, first network element, or third network element in any method embodiment of this application. For details, please refer to the detailed descriptions in the foregoing method embodiments, which will not be repeated here. For example, the processor 920 is used to read and execute program instructions through a communication interface, so that the communication device 900 implements the corresponding method. The processor 920 may include one or more processors, without limitation.
[0315] It should be noted that the aforementioned functional modules can be implemented by hardware or by a combination of hardware and software, without limitation. Furthermore, when the communication device 900 includes only the processor 920, the communication device 900 can be a chip or a chip system.
[0316] For example, the communication device 900 can be a chip system. The chip system can be composed of chips or may include chips and other discrete components, without limitation.
[0317] Optionally, the communication device 900 may further include a memory 930 for storing program instructions and / or data. The memory 930 is coupled to the processor 920. This coupling can be understood as an indirect coupling or communication connection between devices, units, or modules, and can be electrical, mechanical, or other forms, used for information exchange between devices, units, or modules. The processor 920 may operate in conjunction with the memory 930; the processor 920 and the memory 930 may be integrated together or disposed separately.
[0318] Furthermore, the processor 920 is used to execute program instructions stored in the memory 930 so that the communication device 900 implements the corresponding method.
[0319] One or more of the memories in memory 930 may be included in the processor, or memory 930 may exist independently, such as off-chip memory, and be connected to processor 920 via a communication bus (represented by thick line 940 in Figure 9). Memory 930 and processor 920 may also be integrated together.
[0320] Optionally, the communication device 900 further includes a communication interface 910 (shown as dashed lines in FIG. 9) for communicating with other devices via a transmission medium, thereby enabling the devices in the communication device 900 to communicate with other devices. For example, when the communication device is a first terminal, the other devices may be a first network element, etc. The processor 920 can use the communication interface 910 to send and receive data. For example, the processor 920 can be used to control the communication interface 910 to receive and / or send signals.
[0321] Optionally, the communication interface 910 can specifically be a transceiver. In hardware implementation, the transceiver can be used to implement the functions of the aforementioned transceiver module 802, and the transceiver is integrated into the communication device 900 to form the communication interface 910. Optionally, the communication interface 910 can also be an input / output interface, input / output circuit, or pins.
[0322] It should be noted that the communication interface 910 may have both sending and receiving functions, enabling the transmission and reception of signals; or it may have a sending function but no receiving function, used for transmitting signals; or it may have a receiving function but no sending function, used for receiving signals.
[0323] It should be noted that the specific connection medium between the communication interface 910, processor 920, and memory 930 is not limited in the embodiments of this application. Figure 9 shows the memory 930, processor 920, and communication interface 910 connected via a communication bus 940. The connection methods between other components are merely illustrative and not intended to be limiting. The communication bus 940 can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used in Figure 9, but this does not indicate that there is only one communication bus or one type of communication bus.
[0324] In the embodiments of this application, the processor 920 may be one or more combinations of a CPU, digital signal processor (DSP), application-specific integrated circuit (ASIC), microprocessor unit (MPU), microcontroller unit (MCU), GPU, artificial intelligence processor (AI processor), neural processing unit (NPU), field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. A general-purpose processor may be a microprocessor or any conventional processor. The methods disclosed in the embodiments of this application can be executed by the hardware in the processor, or by a combination of hardware and software in the processor.
[0325] In this embodiment, the memory 930 may be, but is not limited to, a cache, read-only memory (ROM), random access memory (RAM), synchronous dynamic random access memory (SDRAM), hard disk drive (HDD), solid-state drive (SSD), erasable programmable read-only memory (EPROM), or compact disc read-only memory (CD-ROM), etc. Memory is any other medium capable of carrying or storing desired program code having an instruction or data structure form and accessible by a computer, but is not limited thereto. The memory in this embodiment may also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.
[0326] In a first possible implementation, the communication device 900 may be a first terminal, used to implement the relevant methods corresponding to the first terminal in the above embodiments. For specific functions, please refer to the descriptions in the above embodiments.
[0327] In the second possible implementation, the communication device 900 can be a first network element, used to implement the relevant methods corresponding to the first network element in the above embodiments. For specific functions, please refer to the descriptions in the above embodiments.
[0328] In a third possible implementation, the communication device 900 can be a third network element, used to implement the relevant methods corresponding to the third network element in the above embodiments. For specific functions, please refer to the descriptions in the above embodiments.
[0329] For the specific implementation process, please refer to the relevant content in the aforementioned embodiments; it will not be repeated here.
[0330] Based on the same concept, referring to Figure 10, this application embodiment also provides another communication device 1000, including: an input / output interface 1010 and a logic circuit 1020; the input / output interface 1010 is used to receive code instructions and transmit them to the logic circuit 1020; the logic circuit 1020 is used to run the code instructions to execute the method executed by the first terminal, the first network element, or the third network element in any of the above embodiments.
[0331] In the first implementation, the communication device 1000 can be applied to a first terminal to execute the method performed by the first terminal, specifically, for example, the method performed by the first terminal in the aforementioned method embodiments. For example, the communication device 1000 can send a first message to a first network element, the first message being used to request a first key for a first entity, the first key being used for the first entity to communicate with a first network, or the first key being used for the first entity to communicate with a first network device; and receive a second message from the first network element, the second message including information about the first key.
[0332] For example, the communication device 1000 can receive a second message from a first network element, the second message including information about a first key, the first key being used for the first entity to communicate with the first network, or the first key being used for the first entity to communicate with the first network device.
[0333] In the second implementation, the communication device 1000 can be applied to a first network element to execute the method performed by the first network element, specifically, for example, the method performed by the first network element in the aforementioned method embodiments. For example, the communication device 1000 can receive a first message from a first terminal, the first message being used to request a first key for a first entity, the first key being used for the first entity to communicate with a first network, or the first key being used for the first entity to communicate with a first network device; and send a second message to the first terminal, the second message including information about the first key.
[0334] For example, the communication device 1000 may send a second message to the first terminal, the second message including information about a first key, the first key being used by the first entity to communicate with the first network, or the first key being used by the first entity to communicate with the first network device.
[0335] In the third implementation, the communication device 1000 can be applied to a third network element to execute the method performed by the third network element, specifically, for example, the method performed by the third network element in the aforementioned method embodiments. For example, the communication device 1000 can receive a fifth message from a first network element, the fifth message being used to request a first key for a first entity, the first key being used for the first entity to communicate with a first network, or for the first entity to communicate with a first network device; and send a response message to the fifth message to the first network element, the response message including information about the first key.
[0336] This application also provides a communication system, which may include at least one of the following: a first terminal, a first network element, or a third network element. Optionally, the communication system may further include a second network element. The first terminal, first network element, second network element, and third network element are all described in the foregoing method embodiments and will not be repeated here.
[0337] This application also provides a computer-readable storage medium, including program instructions, which, when run on a computer, cause the computer to execute the methods or steps of the first terminal, the first network element, or the third network element in the above embodiments.
[0338] This application also provides a computer program product, including program instructions, which, when run on a computer, cause the computer to execute the methods or steps of the first terminal, the first network element, or the third network element in the above embodiments.
[0339] This application provides a chip system including a processor for implementing the functions of the first terminal, first network element, or third network element in the aforementioned method (e.g., executing corresponding methods or steps). The chip system may be composed of a chip or may include a chip and other discrete devices.
[0340] Optionally, the chip system also includes a memory for storing program instructions that the processor can read and execute to implement the corresponding method.
[0341] It should be understood that in the various embodiments of this application, the order of the above-mentioned processes does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0342] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0343] Those skilled in the art will 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.
[0344] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.
[0345] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.
[0346] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.
[0347] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the essential contributing part of the technical solution of this application, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.
[0348] The above description is merely a specific embodiment of this application, but the protection scope of the embodiments 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 the embodiments of this application should be included within the protection scope of the embodiments of this application. Therefore, the protection scope of the embodiments of this application should be determined by the protection scope of the claims.
Claims
1. A communication method, applicable to a first terminal, characterized in that, The method includes: Send a first message to a first network element. The first message is used to request a first key for a first entity. The first key is used for the first entity to communicate with the first network, or for the first entity to communicate with a first network device. Receive a second message from the first network element, the second message including information about the first key.
2. The method according to claim 1, characterized in that, The information of the first key includes a random number, or the information of the first key includes a random number and information of the first entity.
3. The method according to claim 1 or 2, characterized in that, The method further includes: The first key is generated based on the information of the first key and the preset key of the first terminal.
4. The method according to claim 3, characterized in that, The method further includes: Send the first key to the first entity.
5. The method according to claim 1, characterized in that, The information of the first key includes the first key and the ticket, the ticket including the information of the first entity and the first key, wherein the ticket is encrypted by a second key, the second key being either a key of the first network or a key of the first network device.
6. The method according to claim 5, characterized in that, The method further includes: Send the first key and the ticket to the first entity.
7. The method according to claim 5 or 6, characterized in that, The method further includes: Send a third message to the second network element. The third message includes the ticket and information obtained by encrypting the information of the first entity based on the first key. The third message is used for the first entity to request access to the first network, or the third message is used for the first entity to request access to the first network device. The system receives a response message to the third message from the second network element, the response message of which indicates whether access is permitted.
8. The method according to claim 7, characterized in that, Sending the third message to the second network element includes: Obtain a fourth message, the fourth message including the ticket and information obtained by encrypting the information of the first entity based on the first key, the fourth message being used by the first entity to request access to the first network, or the fourth message being used by the first entity to request access to the first network device; The third message is sent to the second network element according to the fourth message.
9. The method according to claim 7 or 8, characterized in that, If the first condition is met, the response message of the third message is used to indicate that access is permitted; or, If the first condition is not met, the response message of the third message is used to indicate that access is not allowed; The first condition includes: the information of the first entity encrypted by the first key is the same as the information of the first entity included in the ticket.
10. The method according to any one of claims 7 to 9, characterized in that, The information obtained by encrypting the information of the first entity based on the first key includes: Information obtained by encrypting at least one of the identifier of the first terminal, the first timestamp, the second timestamp, or the first duration, and the information of the first entity based on the first key; Wherein, the first timestamp is the timestamp when the first terminal requests the first key, the second timestamp is the timestamp when the first entity uses the first key, and the first duration is used to indicate the effective duration of the first key.
11. The method according to any one of claims 5 to 10, characterized in that, The ticket further includes at least one of the following: the identifier of the first terminal, a first timestamp, or a first duration; wherein the first timestamp is the timestamp at which the first terminal requests the first key, and the first duration is used to indicate the validity period of the first key.
12. A communication method, applicable to a first network element, characterized in that, The method includes: Receive a first message from a first terminal, the first message being used to request a first key for a first entity, the first key being used by the first entity to communicate with a first network, or the first key being used by the first entity to communicate with a first network device; A second message is sent to the first terminal, the second message including information about the first key.
13. The method according to claim 12, characterized in that, The information of the first key includes a random number, or the information of the first key includes a random number and information of the first entity.
14. The method according to claim 12 or 13, characterized in that, The method further includes: The first key is generated based on the information of the first key and the preset key of the first terminal; Store the first key.
15. The method according to claim 12 or 13, characterized in that, The method further includes: Send a fifth message to the third network element, the fifth message being used to request the first key for the first entity; The system receives a response message to the fifth message from the third network element, the response message of which includes information about the first key.
16. The method according to claim 12, characterized in that, The information of the first key includes the first key and the ticket, the ticket including the information of the first entity and the first key, wherein the ticket is encrypted by a second key, the second key being either a key of the first network or a key of the first network device.
17. The method according to claim 16, characterized in that, The method further includes: Receive a third message, the third message being used by the first entity to request access to the first network, or the third message being used by the first entity to request access to the first network device, the third message including the ticket and information obtained by encrypting the information of the first entity based on the first key; Send a response message to the third message, which indicates whether access is allowed.
18. The method according to claim 17, characterized in that, If the first condition is met, the response message of the third message is used to indicate that access is permitted; or, If the first condition is not met, the response message of the third message is used to indicate that access is not allowed; The first condition includes: the information of the first entity encrypted by the first key is the same as the information of the first entity included in the ticket.
19. The method according to claim 17 or 18, characterized in that, The information obtained by encrypting the information of the first entity based on the first key includes: Information obtained by encrypting at least one of the identifier of the first terminal, the first timestamp, the second timestamp, or the first duration, and the information of the first entity based on the first key; Wherein, the first timestamp is the timestamp when the first terminal requests the first key, the second timestamp is the timestamp when the first entity uses the first key, and the first duration is used to indicate the effective duration of the first key.
20. The method according to any one of claims 16 to 19, characterized in that, The ticket further includes at least one of the following: the identifier of the first terminal, a first timestamp, or a first duration; wherein the first timestamp is the timestamp at which the first terminal requests the first key, and the first duration is used to indicate the validity period of the first key.
21. The method according to any one of claims 1 to 20, characterized in that, The information of the first key includes at least one of the following: information of the first entity, or a first duration, wherein the first duration is used to indicate the effective duration of the first key.
22. The method according to any one of claims 1 to 21, characterized in that, The first message includes at least one of the following: the identifier of the first terminal, the information of the first entity, a first timestamp, or a second duration; wherein the first timestamp is the timestamp at which the first terminal requests the first key, and the second duration is used to indicate the expected validity period of the first key.
23. The method according to any one of claims 1 to 22, characterized in that, The information of the first entity includes the identifier of the first entity and / or the type of the first entity.
24. The method according to claim 23, characterized in that, The identifier of the first entity is determined by the first terminal, or by the first network element, or by the third network element.
25. The method according to any one of claims 1 to 24, characterized in that, The first entity is a device that supports establishing an association with the first terminal; or, the first entity is a device within the first terminal.
26. A communication device, characterized in that, It includes a module for performing the method as described in any one of claims 1 to 11, 21 to 25, or includes a module for performing the method as described in any one of claims 12 to 25.
27. A communication device, characterized in that, Includes at least one processor, said at least one processor being configured to, by executing computer programs or instructions, or by executing logic circuits, The communication device is made to perform the method of any one of claims 1 to 11, 21 to 25; or, The communication device is made to perform the method of any one of claims 12 to 25.
28. The communication device according to claim 27, characterized in that, It also includes a memory for storing the computer program or instructions.
29. A computer-readable storage medium, characterized in that, It stores computer programs or instructions, which, when executed, This enables the method as described in any one of claims 1 to 11, 21 to 25 to be implemented; or, This enables the method as described in any one of claims 12 to 25 to be implemented.
30. A computer program product, characterized in that, The computer program product includes a computer program that, when run on a computer,... This enables the method as described in any one of claims 1 to 11, 21 to 25 to be implemented; or, This enables the method as described in any one of claims 12 to 25 to be implemented.
31. A chip system, characterized in that, include: A processor for executing a computer program or instructions in the memory, causing the chip system to implement the method as described in any one of claims 1 to 11, 21 to 25, or causing the chip system to implement the method as described in any one of claims 12 to 25.
Citation Information
Patent Citations
Key negotiation method and device
CN111865569A
Key negotiation method, equipment and computer readable storage medium
CN113852459A
Secure communication method and device, terminal equipment and network equipment
CN117546441A
Secure information push for service applications in communication network
CN118160338A
Secure communication method and apparatus, terminal device, and network device
WO2023283789A1