Method and apparatus for authentication

Abstract

The embodiment of the invention provides a method and a device for authentication. In the application, the authentication ID is introduced for authentication of the authentication server on the device, and the temporary ID of the device is used for anonymous communication between the gateway and the service provider. The authentication ID is only known by the IDM function and the AS, so that anonymous authentication and ID privacy protection of the equipment are realized.

Description

Cross-references to related applications

[0001] This application relates to and claims priority to U.S. Provisional Patent Application No. 63 / 541,521, filed September 29, 2023, entitled "System and methods for anonymous authentication of devices in the future network." The disclosure of the above application is incorporated herein by reference in its entirety. Technical Field

[0002] Embodiments of this application relate to the field of wireless technology, and more specifically, to methods and apparatus for authentication. Background Technology

[0003] The primary authentication and key negotiation process aims to achieve mutual authentication between devices and the network, and to provide key material that can be used to indirectly derive keys to secure communication between devices and the network. In the 3rd Generation Partnership Project (3GPP), the Security Anchor Function (SEAF) can initiate authentication of a device during any signaling connection establishment process. The SEAF should include a subscription concealed identifier (SUCI) carried in a request message and sent to the authentication server function (AUSF). This SUCI is then dehisced by the unified data management (UDM) function to obtain a subscription permanent identifier (SUPI). The SUPI is subsequently sent to the SEAF. The SUPI or SUCI is used for both authentication and communication. However, this may introduce the risk of identifier (ID) privacy breaches. Summary of the Invention

[0004] Embodiments of this application provide methods and apparatus for authentication that can protect ID privacy.

[0005] According to a first aspect, an authentication method is provided, which can be executed by a first device or a chip installed in the first device. The first device may be an identifier management (IDM) function. The method includes: receiving a first message, wherein the first message includes a temporary identifier (ID) of a device, the temporary ID being used for communication between the device and a network; sending a second message, wherein the second message includes an authentication ID corresponding to the temporary ID, the second message further including a certificate or authentication vector (AV) of the device, the authentication ID corresponding to the certificate or the AV of the device, the certificate or the AV of the device being used for mutual authentication between the device and the network; the authentication ID being used for identification / authentication on the device.

[0006] According to the proposed scheme, an authentication ID for the device is introduced for authentication by an authentication server. The authentication ID is obtained from the device's real ID, which is stored in the IDM function and known only to the IDM function and the AS. Furthermore, a temporary ID for anonymous communication between the device and the network is introduced. Therefore, the proposed scheme can protect the device's ID privacy during the authentication process.

[0007] In other words, in the proposed scheme, the functionality of subscribing to a permanent identifier (SUPI) / subscribing to a concealed identifier (SUCI) is divided into device identification / authentication and communication functions. By introducing the network function of IDM (Internet Device Management), the device identification / authentication function is implemented by introducing an authentication ID, and the communication function is implemented by introducing a temporary ID, which enables anonymous communication between the device and the network.

[0008] In one implementation of the first aspect, the method further includes: determining the real ID of the device based on the temporary ID; and determining the authentication ID based on the real ID.

[0009] In this implementation, the authentication ID and the device's temporary ID cannot be directly derived from each other, so as to provide ID privacy protection for the device.

[0010] In one implementation of the first aspect, the AV is generated by the IDM function based on the authentication ID.

[0011] In this implementation, the AV is calculated based on the authentication ID, and the AV is used for mutual authentication between the device and the network based on the AV.

[0012] In the implementation of the first aspect, the certificate of the device comes from a certificate authority (CA).

[0013] In this implementation, the certificate of the device corresponding to the authentication ID is used for mutual authentication between the device and the network.

[0014] The technical effects of any of the second to sixth aspects can be referenced from the technical effects of the first aspect, and will not be repeated below.

[0015] According to a second aspect, an authentication method is provided, which can be executed by a second device or a chip installed in the second device. The second device may be an authentication server (AS). The method includes: sending a first message to an identifier management (IDM) function, wherein the first message includes a temporary identifier (ID) of a device used for communication between the device and a network; and receiving a second message from the IDM function, wherein the second message includes an authentication ID corresponding to the temporary ID, and the second message further includes a certificate or AV of the device, wherein the authentication ID corresponds to the certificate or AV of the device, and the certificate or AV of the device is used for mutual authentication between the device and the network.

[0016] In one implementation of the second aspect, the first message also includes the name of the service gateway (GW).

[0017] In one implementation of the second aspect, the AV included in the second message is a first AV, and the method further includes: using the authentication ID to verify the device through the device's certificate or the first AV; if the verification of the device is successful, sending a third message to the device, wherein the third message includes the AS's certificate or a second AV, the second AV being generated based on the first AV.

[0018] In one implementation of the second aspect, the method further includes: receiving a fourth message indicating that the device has successfully authenticated the AS; generating a shared key used between the device and the network, wherein the shared key is generated based on the certificate of the AS, or the shared key is generated based on a second AV or a third AV, wherein the third AV originates from the device.

[0019] According to a third aspect, an authentication method is provided, which can be executed by a third device or a chip installed in the third device. The third device may be an authentication server (AS). The method includes: receiving a first message from an initial gateway (GW), wherein the first message requests mutual authentication between a device, a provider, and the AS, the first message including a temporary identifier (ID) of the device, a certificate of the provider, and an ID of the provider; obtaining the device's certificate and authentication ID from an identifier management (IDM) function, wherein the device's certificate corresponds to the authentication identifier (ID), the authentication ID being determined by the IDM function based on the device's real ID, the device's real ID being determined based on the device's temporary ID; using the authentication ID, verifying the device using the device's certificate, and verifying the provider using the provider's certificate; and, upon successful verification of the device and the provider, generating an indication associated with the device's temporary ID and the provider's ID.

[0020] In one implementation of the third aspect, after generating the indication associated with the temporary ID of the device and the ID of the provider, the method further includes: sending the indication and first information to the initial GW, wherein the first information is used for the provider and the device to verify the AS.

[0021] In one implementation of the third aspect, the first information includes the AS's certificate or authentication vector (AV).

[0022] In one implementation of the third aspect, the method further includes: after successful verification of the device and the provider, generating a shared key between the device and the AS based on the first information.

[0023] In one implementation of the third aspect, the first message also includes the name of the service gateway (GW).

[0024] According to a fourth aspect, an authentication method is provided, which can be executed by a fourth device or a chip installed in the fourth device. The fourth device may be a device, such as user equipment (UE). The method may include: sending a first message requesting mutual authentication between the device and a network, wherein the first message includes a temporary identifier (ID) of the device for communication between the device and the network; after the AS successfully authenticates the device, verifying the AS based on first information of the AS; and, if the authentication of the AS is successful, generating a shared key based on the first information.

[0025] In one implementation of the fourth aspect, the first information includes the AS’s certificate or authentication vector (AV).

[0026] According to a fifth aspect, an authentication method is provided, which can be executed by a fifth device or a chip installed in the fifth device. The fifth device may be a device, such as user equipment (UE). The method includes: sending a first message to an initial gateway (GW), wherein the first message requests mutual authentication between the device, a provider, and an authentication server (AS), the first message including a temporary identifier (ID) of the device; obtaining first information and an indication, wherein the first information is used for verification by the AS, and the indication indicates that both the device and the provider have been successfully verified by the AS; verifying the AS and the indication using the first information; and, if the AS and the indication are successfully verified, generating a shared key used between the device and the network based on the first information.

[0027] In one implementation of the fifth aspect, the first information includes the certificate of the AS or the vector AV.

[0028] In one implementation of the fifth aspect, obtaining the first information and the indication includes: receiving a second message from the AS via the initial gateway (GW), wherein the second message includes the first information and the indication.

[0029] According to a sixth aspect, an authentication method is provided, which can be performed by a sixth device or a chip installed in the sixth device. The sixth device may be a provider. The method includes: receiving a first message from an initial gateway (GW), wherein the first message requests the provider to authenticate a device and an authentication server (AS), the first message including first information for verifying the AS and an indication associated with a temporary ID of the device and an ID of the provider; verifying the AS using the first information and verifying the indication; and sending a second message to the initial GW, wherein the second message indicates successful verification of the AS and the indication.

[0030] In one implementation of the sixth aspect, the first information includes the AS’s certificate or authentication vector (AV).

[0031] According to a seventh aspect, a communication device is provided, the communication device having functions or modules for performing methods in any one of the first to sixth aspects or any implementation thereof.

[0032] According to an eighth aspect, a chip (or chip system) is provided. The chip includes at least one processor coupled to at least one memory. The at least one memory is used to store one or more instructions and / or executable computer code. The at least one processor is used to invoke the one or more instructions and / or executable computer code to cause a communication device on which the chip is mounted to perform a method of any one of the first to sixth aspects or any possible implementation thereof. Optionally, the chip may further include at least one memory. Optionally, the chip may further include a communication interface for inputting and / or outputting information or data.

[0033] According to a ninth aspect, a communication device is provided. The communication device includes one or more circuits and one or more communication interfaces. The one or more communication interfaces may include a first interface and a second interface, wherein the first interface is used to receive (i.e., input) information and / or data to be processed by the one or more circuits, and the second interface is used to transmit (i.e., output) the information and / or data processed by the one or more circuits. The one or more circuits are used to process the information and / or data to be processed, causing the communication device to perform a method of any one of the first to sixth aspects or any implementation thereof.

[0034] According to a tenth aspect, a communication system is provided. The communication system may include at least one communication device according to any of the preceding aspects.

[0035] According to the eleventh aspect, a computer storage medium is provided that stores executable computer code for performing one or more instructions of the methods in any of the above aspects or any possible implementations of these aspects.

[0036] According to a twelfth aspect, a computer program product is provided, comprising one or more instructions that, when the computer program product is run on a computer, the computer performs the method according to any of the foregoing aspects or any possible implementation thereof. Attached Figure Description

[0037] One or more embodiments have been described by way of example with reference to the accompanying drawings. These exemplary descriptions and drawings are not intended to limit the embodiments. Elements with the same reference numerals in the drawings are shown as similar elements, and the drawings are not limited to scale, wherein: Figure 1 A schematic diagram illustrating the application scenarios provided for embodiments of this application; Figure 2 An example of a communication system is shown; Figure 3 Another example of an electronic device (ED) and a base station is shown; Figure 4 An example of a channel model for a MIMO system; Figure 5 An example of the conceptual architecture of a 6G system; Figure 6 Network scenarios provided for some embodiments of this application; Figure 7 A mutual authentication architecture provided for some embodiments of this application; Figure 8 A schematic flowchart illustrating the authentication method provided for some embodiments of this application; Figure 9 The call flow describes the anonymity and mutual authentication process in use case 1; Figure 10 Examples of mutual authentication based on a first architecture provided for some embodiments of this application; Figure 11 Another example of mutual authentication based on the first architecture provided for some embodiments of this application; Figure 12 Another architecture for mutual authentication provided for some embodiments of this application; Figure 13 The call flow based on the mutual authentication architecture in use case 2 is described; Figure 14 Examples of mutual authentication based on a second architecture provided for some embodiments of this application; Figure 15 Another example of mutual authentication based on a second architecture provided for some embodiments of this application; Figure 16 Example of a call flow for selecting a serving GW for the initial GW; Figure 17 These are schematic block diagrams of communication devices provided in some embodiments of this application; Figure 18 These are schematic block diagrams of communication devices provided in some embodiments of this application. Detailed Implementation

[0038] To gain a detailed understanding of the features and technical content of the embodiments of this application, the implementation methods of the embodiments of this application will be described in detail below with reference to the accompanying drawings. The drawings are for reference and illustration only and are not intended to limit the embodiments of this application. In the following technical description, many details are set forth for ease of explanation, in order to provide a thorough understanding of the disclosed embodiments.

[0039] This application broadly relates to wireless communication. Many emerging trends will trigger considerations and designs for future wireless networks, such as 6th generation (6G) wireless networks. The proposed 6G wireless communication can meet the following requirements: - New network infrastructure capabilities, such as widely deployed cloud-friendly infrastructure; - New (relatively) mature technologies, such as large-scale models of artificial intelligence (AI), data privacy, blockchain, etc., have made significant progress and have had a major impact on society and human life as a whole. - New applications and services, such as AI services, data (sensing) services, digital world services, etc., which are widely used in industries / businesses and by individual customers; - A more globalized / open / collaborative operating trend, namely, more open and collaborative operating models are becoming prevalent in many fields.

[0040] New expectations and more stringent requirements for future networks have also driven a rethinking and development of next-generation wireless networks. These requirements may include: - Privacy and trustworthiness, etc.; - Simplify and standardize; - Rapid deployment; - etc.

[0041] All of the above factors have driven research into 6G network architecture. The proposed 6G network architecture (centered on X) is based on service-based architecture (SBA) (XaaS services) and cloud-native principles. Requirements for 6G system network architecture design may include: - The proposed 6G network architecture needs to support new 6G services, which can be developed / deployed by third parties; - The proposed 6G network architecture needs to embrace a more open ecosystem and be open to third parties with strong technical capabilities; The proposed 6G network architecture requires better trust management.

[0042] A solution is needed to meet the above requirements.

[0043] This application focuses on device anonymity and mutual authentication. The method includes the following steps: (1) the device initially accesses the network; (2) the initial GW can select a serving GW (the serving GW can be the initial GW); (3) the initial GW sends an authentication request to the AS; (4) the AS requests an ID retrieval from the IDM; (5) the AS implements mutual authentication between the device and the network.

[0044] In this application, the key technology is to provide mutual authentication and anonymous communication, because this application introduces an authentication ID for device authentication and a temporary ID for device communication.

[0045] In 3GPP 33.501, the master authentication and key negotiation process is to enable mutual authentication between the UE and the network and to provide key materials, which can be used to indirectly derive keys to securely protect the communication between the UE and the network.

[0046] In 3GPP 33.501, SEAF can initiate UE authentication during any signaling connection establishment process with the UE. SEAF should include the SUCI in the Nausf_UEAuthentication_Authenticate request message sent to AUSF. This SUCI will be dehisced by UDM to obtain the SUPI. The SUPI is then sent to SEAF. In 5G, SUPI or SUCI is used for both authentication and communication. However, this may introduce the risk of ID privacy leakage.

[0047] The separation of ID configuration files and service configuration files (decoupling the functionality of UDM into two separate functions: UDM and IDM) ensures that the real ID is known only to IDM, the auth_ID (representing the authentication ID) is known by both AS and IDM, and the tem_ID (representing the temporary ID) is known by the network function. This protects ID privacy during authentication.

[0048] A device authentication ID is introduced for AS authentication, and a temporary device ID is used for communication between the gateway (GW) and the provider. This protects ID privacy.

[0049] anonymous communication By introducing the concept of IDM, SUPI / SUCI is decoupled into an authentication ID and a temporary ID, which enables anonymous communication between devices and networks.

[0050] refer to Figure 1 This simplified schematic diagram of a communication system is provided as an illustrative example, but not a limitation. Communication system 100 includes a radio access network 120. Radio access network 120 may be a next-generation (e.g., sixth-generation, 6G or later) radio access network, or a traditional (e.g., 5G or 4G) radio access network. One or more electronic devices (EDs) 110a, 110b, 110c, 110d, 110e, 110f, 110g, 110h, 110i, 110j (generally referred to as 110) may interconnect with each other or be connected to one or more network nodes (170a, 170b, generally referred to as 170) in radio access network 120. Core network 130 may be part of the communication system and may depend on or be independent of the radio access technology used in communication system 100. Communication system 100 also includes a public switched telephone network (PSTN) 140, the Internet 150, and other networks 160.

[0051] Figure 2An exemplary communication system 100 is illustrated. Typically, the communication system 100 enables multiple wireless or wired components to transmit data and other content. The purpose of the communication system 100 may be to provide content such as voice, data, video, and / or text via broadcast, multicast, unicast, etc. The communication system 100 can operate by sharing resources (e.g., carrier spectrum bandwidth) among its constituent components. The communication system 100 may include terrestrial communication systems and / or non-terrestrial communication systems. The communication system 100 can provide a wide range of communication services and applications (e.g., earth monitoring, remote sensing, passive sensing and positioning, navigation and tracking, autonomous delivery and mobility, etc.). The communication system 100 can provide high availability and robustness through the joint operation of terrestrial and non-terrestrial communication systems. For example, integrating a non-terrestrial communication system (or components thereof) into a terrestrial communication system can realize a heterogeneous network comprising multiple layers. Compared to traditional communication networks, heterogeneous networks can achieve better overall performance through efficient multi-link joint operation, more flexible function sharing, and faster physical layer link switching between terrestrial and non-terrestrial networks.

[0052] Terrestrial communication systems and non-terrestrial communication systems can be considered subsystems of a communication system. Figure 5 In the example shown, communication system 100 includes electronic devices (EDs) 110a, 110b, 110c, and 110d (generally referred to as ED 110), radio access networks (RANs) 120a and 120b, a non-terrestrial communication network 120c, a core network 130, a public switched telephone network (PSTN) 140, the Internet 150, and other networks 160. RANs 120a and 120b include corresponding base stations (BSs) 170a and 170b, which may generally be referred to as terrestrial transmit and receive points (T-TRPs) 170a and 170b. The non-terrestrial communication network 120c includes access nodes 172, which may generally be referred to as non-terrestrial transmit and receive points (NT-TRPs) 172.

[0053] Alternatively, any ED 110 can be used to connect, access, or communicate with any T-TRP 170a and 170b and NT-TRP 172, Internet 150, core network 130, PSTN 140, other network 160, or any combination thereof. In some examples, ED 110a can perform uplink and / or downlink transmissions with T-TRP 170a via terrestrial air interface 190a. In some examples, ED 110a, 110b, 110c, and 110d can also communicate directly with each other via one or more sidelink air interfaces 190b. In some examples, ED 110d can perform uplink and / or downlink transmissions with NT-TRP 172 via non-terrestrial air interface 190c.

[0054] Air interfaces 190a and 190b can use similar communication technologies, such as any suitable wireless access technology. For example, communication system 100 can implement one or more channel access methods in air interfaces 190a and 190b, such as code division multiple access (CDMA), space division multiple access (SDMA), time division multiple access (TDMA), frequency division multiple access (FDMA), orthogonal FDMA (OFDMA), or single-carrier FDMA (SC-FDMA) (also known as discrete Fourier transform spread OFDMA (DFT-s-OFDMA)). Air interfaces 190a and 190b can utilize other high-dimensional signal spaces, which may involve combinations of orthogonal and / or non-orthogonal dimensions.

[0055] The non-terrestrial air interface 190c enables communication between the ED 110d and one or more NT-TRP 172s via a wireless link, or simply a link. For some examples, the link is a dedicated connection for unicast transmission, a connection for broadcast transmission, or a connection for multicast transmission between a group of ED 110s and one or more NT-TRP 172s.

[0056] RANs 120a and 120b communicate with core network 130 to provide various services, such as voice, data, and other services, to EDs 110a, 110b, and 110c. RANs 120a and 120b and / or core network 130 may communicate directly or indirectly with one or more other RANs (not shown), which may or may not be directly served by core network 130, and may or may not use the same radio access technology as RANs 120a, RAN 120b, or both. Core network 130 may also act as a gateway access between (i) RANs 120a and 120b and / or EDs 110a, 110b, and 110c, and between (ii) other networks (e.g., PSTN 140, Internet 150, and other networks 160). Additionally, some or all of ED110a, 110b, and 110c may include the ability to communicate with different wireless networks via different wireless links using different wireless technologies and / or protocols. Instead of wireless communication (or other than wireless communication), ED 110a, 110b, and 110c may also communicate with service providers or exchanges (not shown) via wired communication channels and with the Internet 150. PSTN 140 may include a circuit-switched telephone network for providing plain old telephone service (POTS). The Internet 150 may include a network of computers and subnets (intranets) or both, incorporating protocols such as Internet Protocol (IP), Transmission Control Protocol (TCP), and User Datagram Protocol (UDP). ED 110a, 110b, and 110c may be multimode devices capable of operating according to multiple wireless access technologies and include multiple transceivers required to support these technologies.

[0057] Figure 3Another example of the ED 110 and base stations 170a, 170b, and / or 170c is shown. The ED 110 is used to connect people, objects, machines, etc. The ED 110 can be widely used in various scenarios, including, for example, cellular communication, device-to-device (D2D), vehicle-to-everything (V2X), peer-to-peer (P2P), machine-to-machine (M2M), machine-type communications (MTC), Internet of Things (IoT), virtual reality (VR), augmented reality (AR), mixed reality (MR), metaverse, digital twins, industrial control, autonomous driving, telemedicine, smart grids, smart furniture, smart offices, smart wearables, smart transportation, smart cities, drones, robots, remote sensing, passive sensing, positioning, navigation and tracking, autonomous delivery and mobility, etc.

[0058] Each ED 110 represents any end-user equipment suitable for wireless operation and may include (or be referred to as): user equipment / device (UE), wireless transmit / receive unit (WTRU), mobile station, fixed or mobile subscriber unit, cellular phone, station (STA), machine type communications (MTC) device, personal digital assistant (PDA), smartphone, laptop, computer, tablet, wireless sensor, consumer electronics device, smartbook, vehicle, automobile, truck, bus, train, or IoT device, wearable device (e.g., watch, glasses, head-mounted device, etc.), industrial equipment, or devices comprising or including the foregoing (e.g., communication module, modem, or chip), etc. Future generations of ED 110 may be referred to using other terms. Base stations 170a and 170b are T-TRPs and will be referred to as T-TRP 170 below. Figure 3As also shown, NT-TRP will be referred to as NT-TRP 172 below. Each ED 110 connected to T-TRP 170 and / or NT-TRP 172 can be dynamically or semi-statically turned on (i.e., established, activated, or enabled), turned off (i.e., released, deactivated, or disabled), and / or configured in response to one or more of the availability and necessity of the connection.

[0059] ED 110 includes a transmitter 201 and a receiver 203 coupled to one or more antennas 204. Only one antenna 204 is shown in the figure to avoid congestion. One, some, or all of the antennas 204 may also be panels. For example, the transmitter 201 and receiver 203 may be integrated as a transceiver. The transceiver is used to modulate data or other content for transmission by at least one antenna 204 or a network interface controller (NIC). The transceiver is also used to demodulate data or other content received through at least one antenna 204. Each transceiver includes any suitable structure for generating signals for wireless or wired transmission and / or for processing signals received wirelessly or wiredly. Each antenna 204 includes any suitable structure for transmitting and / or receiving wireless or wired signals.

[0060] ED 110 includes at least one memory 208. Memory 208 stores instructions and data used, generated, or acquired by ED 110. For example, memory 208 may store software instructions or modules for implementing some or all of the functions and / or embodiments described herein and executed by one or more processing units (e.g., processor 210). Each memory 208 includes any suitable one or more volatile and / or non-volatile storage and retrieval devices. Any suitable type of memory can be used, such as random access memory (RAM), read-only memory (ROM), hard disk, optical disk, subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card, on-processor cache, etc.

[0061] ED 110 may also include one or more input / output devices (not shown) or interfaces (e.g., connected to...). Figure 1 (Wired interface of Internet 150 in the network). Input / output devices or interfaces support interaction with users or other devices in the network. Each input / output device or interface includes any suitable structure for providing or receiving information from the user, and / or for communication on the network interface. For example, suitable structures include speakers, microphones, keypads, keyboards, displays, touchscreens, etc.

[0062] ED 110 includes a processor 210 for performing operations, including operations related to preparing for uplink transmissions to NT-TRP 172 and / or T-TRP 170; operations related to processing downlink transmissions received from NT-TRP 172 and / or T-TRP 170; and operations related to processing sidelink transmissions to and from another ED 110. Processing operations related to preparing for uplink transmissions may include operations such as encoding, modulation, transmit beamforming, and generating symbols for transmission. Processing operations related to processing downlink transmissions may include operations such as receive beamforming, demodulation, and decoding of received symbols. According to an embodiment, the downlink transmission may be received by receiver 203, possibly using receive beamforming, and processor 210 may extract signaling from the downlink transmission (e.g., by detecting and / or decoding signaling). Examples of signaling may be reference signals transmitted by NT-TRP 172 and / or T-TRP 170. In some embodiments, processor 210 performs transmit beamforming and / or receive beamforming based on beam direction indications (e.g., beam angle information (BAI)) received from T-TRP 170. In some embodiments, processor 210 may perform operations related to network access (e.g., initial access) and / or downlink synchronization, such as operations related to detecting synchronization sequences, decoding, and acquiring system information. In some embodiments, processor 210 may perform channel estimation using reference signals received from NT-TRP 172 and / or T-TRP 170.

[0063] Although not shown, processor 210 may form part of transmitter 201 and / or receiver 203. Although not shown, memory 208 may form part of processor 210.

[0064] The processing components of processor 210, transmitter 201, and receiver 203 may be implemented by the same or different processors, which execute instructions stored in memory (e.g., memory 208). Alternatively, some or all of the processing components of processor 210, transmitter 201, and receiver 203 may be implemented using dedicated circuitry, such as a programmable field-programmable gate array (FPGA), application-specific integrated circuit (ASIC), or hardware accelerators such as graphics processing units (GPUs) or artificial intelligence (AI) accelerators.

[0065] The T-TRP 170 may be known by other names in some implementations, such as base station, base-transceiver station (BTS), wireless base station, network node, network device, network-side device, transmit / receive node, NodeB, evolved NodeB (eNodeB or eNB), home eNodeB, next-generation NodeB (gNB), transmission point (TP), site controller, access point (AP), wireless router, relay station, ground node, ground network device, ground base station, base band unit (BBU), remote radio unit (RRU), active antenna unit (AAU), remote radio head (RRH), central unit (CU), distributed unit (DU), positioning node, etc. The T-TRP 170 can be a macro BS, pico BS, relay node, host node, or a combination thereof. T-TRP 170 may refer to the aforementioned device or a component of the aforementioned device (e.g., a communication module, modem, or chip).

[0066] In some embodiments, the various parts of T-TRP 170 may be distributed. For example, some modules of T-TRP 170 may be located remotely from the device housing the antenna 256 of T-TRP 170 and may be coupled to the device housing the antenna 256 via a communication link (not shown) sometimes referred to as a fronthaul (e.g., a common public radio interface, CPRI). Therefore, in some embodiments, the term T-TRP 170 may also refer to modules on the network side that perform processing operations such as determining the location of ED 110, resource allocation (scheduling), message generation, and encoding / decoding; these modules are not necessarily part of the device housing the antenna 256 of T-TRP 170. These modules may also be coupled to other T-TRPs. In some embodiments, T-TRP 170 may actually be multiple T-TRPs that operate together to provide services such as coordinated multicast to ED 110.

[0067] T-TRP 170 includes at least one transmitter 252 and at least one receiver 254 coupled to one or more antennas 256. Only one antenna 256 is shown in the figure to avoid congestion. One, some, or all of the antennas 256 may also be panels. The transmitter 252 and receiver 254 may be integrated as a transceiver. T-TRP 170 also includes a processor 260 for performing operations including operations related to: preparing transmissions for downlink transmission to ED 110, processing uplink transmissions received from ED 110, preparing transmissions for backhaul transmission to NT-TRP 172, and processing transmissions received from NT-TRP 172 via backhaul. Processing operations related to preparing transmissions for downlink or backhaul transmission may include operations such as encoding, modulation, precoding (e.g., multiple-input multiple-output (MIMO) precoding), transmit beamforming, and generating symbols for transmission. Processing operations related to transmissions received in the uplink or via backhaul may include receiving beamforming, demodulating received symbols, and decoding received symbols. Processor 260 may also perform operations related to network access (e.g., initial access) and / or downlink synchronization, such as generating the contents of a synchronization signal block (SSB), generating system information, etc. In some embodiments, processor 260 also generates beam direction indications, such as BAI, that can be scheduled for transmission by scheduler 253. Processor 260 performs other network-side processing operations described herein, such as determining the location of ED 110, determining the deployment location of NT-TRP 172, etc. In some embodiments, processor 260 may generate signaling, such as for configuring one or more parameters of ED 110 and / or one or more parameters of NT-TRP 172. Any signaling generated by processor 260 is transmitted by transmitter 252. It should be noted that the term "signaling" used herein may also be referred to as control signaling. Signaling can be transmitted in physical layer control channels (e.g., physical downlink control channel (PDCCH)). In this case, the signaling can be called dynamic signaling. Signaling transmitted in the downlink physical layer control channel can be called downlink control information (DCI). Signaling transmitted in the uplink physical layer control channel can be called uplink control information (UCI). Signaling transmitted in the sidelink physical layer control channel can be called sidelink control information (SCI).Signaling can be included in higher-layer (e.g., above the physical layer) messages transmitted on physical layer data channels (e.g., physical downlink shared channel, PDSCH). In this case, the signaling can be referred to as higher-layer signaling, static signaling, or semi-static signaling. Higher-layer signaling can refer to radio resource control (RRC) protocol signaling or media access control-control element (MAC-CE) signaling.

[0068] Scheduler 253 may be coupled to processor 260. Scheduler 253 may be included within T-TRP 170 or may operate separately from T-TRP 170. Scheduler 253 may schedule uplink, downlink, lateral link, and / or backhaul transmissions, including issuing scheduling authorizations and / or configuring schedule-free (e.g., "configuration authorization") resources. T-TRP 170 also includes memory 258 for storing information and data. Memory 258 stores instructions and data used, generated, or acquired by T-TRP 170. For example, memory 258 may store software instructions or modules executed by processor 260 for implementing some or all of the functions and / or embodiments described herein.

[0069] Although not shown, processor 260 may form part of transmitter 252 and / or receiver 254. Furthermore, although not shown, processor 260 may implement scheduler 253. Although not shown, memory 258 may form part of processor 260.

[0070] The processing components of processor 260, scheduler 253, transmitter 252, and receiver 254 may be implemented by the same or different processors, which execute instructions stored in memory (e.g., memory 258). Alternatively, some or all of the processing components of processor 260, scheduler 253, transmitter 252, and receiver 254 may be implemented using dedicated circuitry, such as a programmable FPGA, hardware accelerator (e.g., GPU or AI accelerator), or ASIC.

[0071] Although the NT-TRP 172 is shown as an example of a drone only, it can be implemented in any suitable non-terrestrial form, such as satellites and high-altitude platforms, including international mobile communication base stations and unmanned aerial vehicles. Furthermore, the NT-TRP 172 may be known by other names in some implementations, such as a non-terrestrial node, a non-terrestrial network device, or a non-terrestrial base station. The NT-TRP 172 includes a transmitter 272 and a receiver 274 coupled to one or more antennas 280. Only one antenna 280 is shown in the figure to avoid congestion. One, some, or all of the antennas may also be panels. The transmitter 272 and receiver 274 may be integrated as a transceiver. The NT-TRP 172 also includes a processor 276 for performing operations including: preparing transmissions for downlink transmission to ED 110, processing uplink transmissions received from ED 110, preparing transmissions for backhaul transmission to T-TRP 170, and processing transmissions received from T-TRP 170 via backhaul. Processing operations related to preparing a transmission for downlink or backhaul transmission may include operations such as encoding, modulation, precoding (e.g., MIMO precoding), transmit beamforming, and generating symbols for transmission. Processing operations related to processing transmissions received in the uplink or via backhaul may include operations such as receive beamforming, demodulating received symbols, and decoding received symbols. In some embodiments, processor 276 performs transmit beamforming and / or receive beamforming based on beam direction information (e.g., BAI) received from T-TRP 170. In some embodiments, processor 276 may generate signaling, such as for configuring one or more parameters of ED110. In some embodiments, NT-TRP 172 implements physical layer processing but does not implement higher-level functions such as those at the medium access control (MAC) or radio link control (RLC) layers. Since this is only an example, more generally, NT-TRP 172 may implement higher-level functions in addition to physical layer processing.

[0072] The NT-TRP 172 also includes a memory 278 for storing information and data. Although not shown, a processor 276 may form part of the transmitter 272 and / or the receiver 274. Although not shown, the memory 278 may form part of the processor 276.

[0073] The processing components of processor 276, transmitter 272, and receiver 274 may be implemented by the same or different one or more processors, which execute instructions stored in memory (e.g., memory 278). Alternatively, some or all of the processing components of processor 276, transmitter 272, and receiver 274 may be implemented using dedicated circuitry, such as a programmable FPGA, hardware accelerator (e.g., GPU or AI accelerator), or ASIC. In some embodiments, NT-TRP 172 may actually be multiple NT-TRPs operating together to coordinate services such as multicast transmission ED 110.

[0074] T-TRP 170, NT-TRP 172 and / or ED 110 may include other components, but for clarity these components are omitted.

[0075] One or more steps of the methods in the embodiments provided herein can be based on Figure 4 The corresponding unit or module is executed. Figure 4 The diagram illustrates units or modules within a device, such as in ED 110, T-TRP 170, or NT-TRP 172. For example, signals may be transmitted by a transmitting unit or transmitting module. Signals may be received by a receiving unit or receiving module. Signals may be processed by a processing unit or processing module. Other steps may be performed by artificial intelligence (AI) or machine learning (ML) modules. The corresponding units or modules may be implemented using hardware, one or more components or devices executing software, or a combination thereof. For example, one or more units or modules may be circuits such as integrated circuits. Examples of integrated circuits include programmable FPGAs, GPUs, or ASICs. For example, one or more units or modules may be logic, such as a part of a circuit, an integrated circuit, or a logical function executed by software instructions executed by a processor. It should be understood that if these modules are implemented, for example, using software executed by a processor, then these modules may be retrieved by the processor, wholly or partially, individually or collectively, for processing, in one or more instances, as needed, and these modules themselves may include instructions for further deployment and instantiation.

[0076] Additional details regarding ED 110, T-TRP 170, and NT-TRP 172 are known to those skilled in the art. Therefore, these details are omitted herein.

[0077] The solutions described in this application are applicable to next-generation (e.g., sixth-generation, 6G or higher) networks, or traditional (e.g., 5G or 4G) networks.

[0078] The proposed 6G system architecture is defined as supporting 6G XaaS services through the use of technologies such as network function virtualization and network slicing. The 6G system architecture leverages service-based interactions between 6G services.

[0079] The 6G system adopts a service-based architecture and the XaaS concept. XaaS services in the 6G system are categorized into three layers. The conceptual structure of the 6G system is as follows: Figure 5 As shown.

[0080] The infrastructure layer includes the infrastructure that supports 6G services. This includes wireless network infrastructure (such as RAN, CN), cloud / data center infrastructure, satellite networks, storage / database infrastructure, and sensing networks. This infrastructure can be provided by a single provider or by multiple providers.

[0081] Each piece of infrastructure can have its own control and management functions, represented as control and management (C / M) functions, for infrastructure management. Each of these infrastructures is an Infrastructure as a Service.

[0082] The C / M layer includes control and management services for the 6G system. These are developed and deployed using slicing technology and leveraging resources provided by the infrastructure layer. 6G services in the C / M layer may include: Resource management (RM) as a service provides the ability to manage the lifecycle of various slices and allocate over-the-air resources to wireless devices; - A 6G task is defined as a service provided by a 6G system to a customer. A task can be a service type provided by a single 6G XaaS service, or it can be a service type that requires contributions from multiple XaaS services.

[0083] - Mission management (MM) is a service that provides the ability to program XaaS services at the service layer to provide mission services.

[0084] - The Confederation Network (CONET) as a Service provides the ability for multiple partners to jointly deliver 6G services. This capability is provided through protocol negotiation involving alliance formation, mutual authentication, mutual authorization, and the recording and retrospective of selected actions performed by partners, ensuring a trusted environment for the operation of 6G systems.

[0085] Service provisioning management (SPM) refers to the ability of service providers to control and manage customer access to 6G services and configure requested services. This capability is provided through unified mutual authentication, authorization and policies, key management, quality of service (QoS) guarantees, and accounting between any pair of XaaS service providers and customers. Customers include not only end customers in the physical world but also digital representatives in the digital world.

[0086] - Connectivity management (CM) as a service leverages 5G connectivity management capabilities but extends to include the digital world.

[0087] Protocol as a Service (PCA) provides the ability to customize protocol stacks for the design services of the identified interfaces.

[0088] - Protocol stacks can be predefined for selection on demand, or designed on demand.

[0089] Cybersecurity as a Service (CASS) provides infrastructure owners with the ability to detect potential security risks to their infrastructure.

[0090] XaaS services in the C / M layer support the control and management of the 6G system itself and provide support to vertical industries upon request. For example, the RM service can provide air resource management services to the RAN, and can also provide air resource allocation services to end customers in vertical industries. XaaS in the C / M layer can be deployed using slicing technology.

[0091] The service layer includes 6G services provided to customers. In the 6G system conceptual architecture: - AI services are represented as NET4AI as a service. Artificial intelligence services provide AI capabilities to support a wide range of AI applications.

[0092] Data acquisition, data cleansing, data analysis, and data delivery services are referred to as DAM as a service. This service provides the ability to manage the lifecycle of statistical data, including acquiring, de-privatizing, analyzing, and delivering data, which is statistical data from any type of sensor, device, network function, etc.

[0093] - Data storage and sharing services are represented as NET4Data as a Service, which provides the ability to reliably store and share data under the control of the data owner and in accordance with the regulations of recognized authorities on the control of identified data.

[0094] - Providing services for the digital world is represented as NET4DW as a Service. Digital world services provide the ability to build, control, and manage the digital world. The digital world is defined as the digital realization of the physical world.

[0095] - The 6G blockchain service is represented as NET4BC as a service. The 6G connectivity service is represented as NET4Con as a service. This service provides the capability to support 6G blockchain services.

[0096] - Enhanced connectivity services, such as Connection-Oriented Networking (NET4CON) as a Service. This service provides the ability to exchange messages and data between supporting new 6G services.

[0097] All XaaS services in this layer are developed and deployed using resources provided within the infrastructure and leveraging network function virtualization and slicing technologies. The capabilities of each 6G service are provided by its control and management functions, as well as service-specific data processing capabilities.

[0098] In addition to supporting 6G XaaS services at the service layer, the 6G system also leverages the 5G system to configure vertical services. The difference between 6G XaaS services and other vertical industries is that a vertical industry is a pure customer that needs other XaaS services to enable its operation, while each XaaS service provides its capabilities to the 6G customer.

[0099] Any pair of XaaS services in a 6G system can also be customer and provider to each other. Some examples include: the infrastructure owner providing its resources to XaaS services in the service layer and the C / M layer; the RM service possibly requiring the capabilities provided by NET4AI, DAM, and NET4DW to manage its resources for vertical slices; and the CONET and NET4Data services possibly requiring the capabilities provided by NET4BC to function.

[0100] Key concepts of 6G systems may include: - Basic XaaS services are defined by decoupling comprehensive service types into basic XaaS services. Basic XaaS services provide unique capabilities to enable specific types of services, such as NET4AI services, NET4DW services, DAM services, NET4Data services, blockchain services, task management services, etc.

[0101] - Allows multiple partners to jointly operate the 6G system.

[0102] - Define the data plane of the 6G system, including the data plane processing capabilities of XaaS services. Programming the interconnection of these capabilities through task management services supports a variety of customized customer services.

[0103] - Simplify the 6G system architecture by categorizing basic control and management services and combining them into basic XaaS services in the control and management (C / M) layer.

[0104] - Define the C / M plane of the 6G system, including C / M functions in XaaS services, which may include 5GCP (e.g., AMF) depending on the implementation.

[0105] - Define the basic architecture structure (BAS), which is a unified basic structure with a minimal number of interfaces and is independent of the infrastructure type.

[0106] - Use the BAS concept to simplify the standardization, development and deployment of 6G systems, while supporting a variety of infrastructure deployment scenarios.

[0107] - Apply BAS or subsets thereof to infrastructure based on the capabilities, capacity, and requirements of the infrastructure network to adapt to a variety of deployment scenarios.

[0108] - Utilize the SBI interface concept and apply SBI interaction in both the 6G C / M plane and the 6G data plane.

[0109] - Simplify the SBI interface by introducing a trusted GW in the data plane and C / M plane of the 6G system.

[0110] - Improve trustworthiness from the perspective of 6G system operation by introducing CONET capabilities, NET4BC capabilities and anonymity service configurations provided by a trusted GW into the C / M plane and data plane of the 6G system.

[0111] - Enhance trustworthiness from the perspective of end-customer privacy protection by providing unified mutual authentication, IDM, data purification, etc. through SPM service, DAM service and 6G blockchain service.

[0112] - Simplify roaming management of wireless devices in the physical and digital worlds through unified certification that includes all participating partners and customers.

[0113] - By defining multiple architecture options, it supports multiple development paths from 5G systems to 6G systems, requiring less work due to the introduction of the BAS concept.

[0114] - By leveraging the advantages of SBA and its additional features, backward compatibility is supported. 5G users can use 6G systems to access 5G services.

[0115] - Supports future expansion by adding new XaaS services, minimizing the impact on standardization and deployment due to the introduction of anonymous service configuration concepts in the trusted GW of the 6G C / M plane and 6G data plane.

[0116] This section first introduces relevant technologies and concepts to better understand the technical solution proposed in this application.

[0117] As mentioned above, currently, in 3GPP 33.501, the Subscription Concealed Identifier (SUCI) is included in the device's request and can be deconcealed by the IDM function. The IDM function sends the deconcealed SUCI (referred to as the Subscription Permanent Identifier (SUPI)) to the AS for authentication and indirectly transmits the deconcealed SUCI to the GW for communication. The SUCI or SUPI may potentially leak the device's ID privacy.

[0118] To address this issue, this application provides a system and method for anonymous mutual authentication of devices in future networks.

[0119] Figure 6 The network scenarios provided for some embodiments of this application are as follows: Both the initial gateway (GW) and the serving GW are responsible for the connection between the device and the network function (NF). The initial GW and the serving GW can be a single function, with the initial GW having the ability to select the serving GW. The authentication server (AS) is responsible for authenticating the device and / or provider. Identifier management (IDM) is responsible for ID management.

[0120] In this application, the following assumptions are made: (1) When multiple untrusted providers join a network, authentication by the AS is required. When a device accesses a network or accesses a service, there is mutual authentication between the device and the network (such as the AS, provider, etc.).

[0121] (2) The IDM function is trusted and stores the device’s real ID and the device’s certificate.

[0122] (3) The AS or provider registers with the Certificate Authority (CA) and obtains its certificate. The IDM function registers the device with the CA on behalf of the device and obtains the device's certificate.

[0123] (4) AS is interested in the device’s real ID, and the provider is interested in the device’s real ID.

[0124] In the embodiments of this application, consider the following two use cases: Use Case 1: Mutual authentication between devices and the network.

[0125] In this use case, it is assumed that multiple untrusted providers authenticate each other after deployment. In other words, these providers are trusted by the network when devices connect to it.

[0126] Use Case 2: Mutual authentication between devices, providers, and AS.

[0127] In this use case, when a device accesses the network, both the device and the provider should be authenticated by the AS. Simultaneously, the AS should be authenticated by both the device and the provider.

[0128] In this scenario (such as) Figure 6 As shown, when a device sends an initial access request, mutual authentication and key negotiation should be performed. Currently, in 3GPP 33.501, the SUCI is included in the device's request and can be dehidden by the IDM. The IDM sends the dehidden SUCI (referred to as SUPI) to the AS for authentication and indirectly transmits the dehidden SUCI to the GW for communication. This unique SUPI or SUCI may leak the device's ID privacy.

[0129] To address this issue, a system and method for implementing anonymous two-way authentication of devices in future networks are proposed. The proposed scheme can provide anonymous authentication between devices and the network, and offer security protection for anonymous authentication. Furthermore, the proposed scheme can provide ID privacy.

[0130] To reduce the overhead of security context exchange and protect ID privacy, this application proposes a novel anonymous authentication system and method. The basic concepts of this application are as follows.

[0131] (1) Authentication ID To protect ID privacy, this application introduces a device authentication ID used by the AS for device identification / authentication, and a device temporary ID used for anonymous communication between the device, GW, and provider. In the embodiments of this application, only the AS and IDM know the authentication ID. Therefore, the authentication ID and temporary ID are decoupled, and the temporary ID cannot be associated with the authentication ID. This protects the device's ID privacy.

[0132] (2) If there is more than one untrusted provider, the AS needs to authenticate these providers and devices. In addition, these providers need to authenticate the devices and the AS, i.e., mutual authentication between devices, providers and the AS.

[0133] Furthermore, in the embodiments of this application, the basic concept of anonymous authentication is proposed as follows: (1) Divide the functions of UDM into two functions, such as UDM and IDM. IDM is responsible for ID management and maintenance / storage of ID certificates; UDM is responsible for the management of service information (such as the name of the service GW and the name of the service provider). (2) An authentication ID (for simplicity, Auth_ID is used instead of authentication ID) is proposed for authenticating the device, and a temporary ID (for simplicity, Tem_ID is used instead of temporary ID) is used for communication between the device and the network. The device's real ID is stored in the IDM. The AS and the provider are unaware of the real ID. The provider is unaware of the Auth_ID. Only the IDM has a mapping table of the above IDs.

[0134] Based on the basic concepts, the diagram below illustrates an architecture for anonymity and mutual authentication between devices. In this diagram, a key management function (KMF) may not be deployed in the system. When a device first accesses the network, it sends an authentication request to the initial GW. The initial GW may select a serving GW based on the device's location or other information (e.g., the location of the service provider or infrastructure provider). The initial GW forwards this request to the AS. The AS retrieves the ID from the IDM. Mutual authentication exists between the device and the network. After successful mutual authentication, a shared key should be negotiated between the device and the AS. This shared key can be sent to the KMF to derive the endpoint key. If no KMF exists, the shared key is stored in the AS.

[0135] The main functions of the network are as follows: (1) IDM: - Maintain / store IDs.

[0136] - Generate an authentication ID and use the authentication ID to request a certificate for the device from the CA on behalf of the device.

[0137] - ID mapping (2) UDM: - Service configuration file for the storage device.

[0138] (3) Authentication server: - Certified devices and one or more providers.

[0139] (4) Initial GW: - Forward the message.

[0140] - Select Service GW.

[0141] (4) Key Management: - Maintain an extended master session key (called EMSK).

[0142] Figure 7 A mutual authentication architecture is provided for some embodiments of this application. Figure 7 In this process, when a device first accesses the network, it sends an authentication request to the initial GW. The initial GW may select a service GW based on the device's location or other information, such as the location of the service provider or infrastructure provider. The initial GW forwards the authentication request to the AS. The AS requests an ID retrieval from the IDM function. Mutual authentication exists between the device and the network. After successful mutual authentication, the device and the network should negotiate a shared key. The shared key can be sent to the key management function (KMF) for end-key derivation. The KMF may not be deployed in the system. In this case, the shared key is stored in the AS.

[0143] exist Figure 7 In this architecture, the IDM (Integrated Device Manager) function is responsible for maintaining IDs, generating authentication IDs, requesting device certificates from the CA (Certificate Authority) on behalf of the device using the authentication IDs, and handling ID mapping. The UDM (User Device Manager) function is responsible for storing the device's service configuration files, such as the name of the service GW (Generation Gateway) and the provider's name. The authentication server (AS) is responsible for authenticating the device and the provider. The initial GW (Generation Gateway) is responsible for forwarding messages and selecting the service GW. The KMF (Knowledge Management Provider) is responsible for maintaining the shared key, which is referred to as the extended master session key (EMSK) in this embodiment. The provider can be an infrastructure provider or a service provider; there is no limitation on this.

[0144] Figure 8 This is a schematic flowchart illustrating an authentication method 300 provided for an embodiment of this application. Method 300 can be implemented by an IDM function or circuitry installed within an IDM function. The following embodiments use an IDM function as an example.

[0145] In step 310, the IDM function receives the first message from the AS.

[0146] The first message may include a temporary ID of the device, which is used for communication between the device and the network.

[0147] In step 320, IDM sends a second message to AS.

[0148] The second message may include an authentication ID corresponding to the temporary ID. The second message may also include the device's certificate or authentication vector (AV). The authentication ID corresponds to the device's certificate or AV, which is used for mutual authentication between the device and the network.

[0149] The method may also include step 330.

[0150] In step 330, the IDM function determines the authentication ID, and also determines the certificate of the device corresponding to the authentication ID or the AV corresponding to the authentication ID.

[0151] Specifically, the device's temporary ID is mapped to the device's real ID, and then the device's authentication ID is further mapped to the device's real ID. In other words, the IDM function determines the device's real ID based on the temporary ID, and then determines the authentication ID based on the device's real ID. The device's real ID is a unique ID known only to the IDM function. Therefore, the authentication ID and the device's temporary ID cannot be directly derived from each other. The authentication ID is used for device identification / authentication.

[0152] In one embodiment, the IDM function registers the device with the CA on behalf of the device and obtains the device's certificate from the CA. In this embodiment, after determining the authentication ID, the IDM function determines the certificate of the device corresponding to the authentication ID. In another embodiment, the IDM can calculate the AV based on the authentication ID. Therefore, in the embodiments of this application, mutual authentication between the device and the network can be achieved based on the device's certificate or AV.

[0153] The proposed solution protects ID privacy by introducing an authentication ID. The authentication ID is obtained from the device's real ID, which is stored in the IDM function and known only to the IDM function and the AS. The device's temporary ID is used for anonymous communication between the device and the network. Therefore, network functions (e.g., GW) are unaware of the authentication ID.

[0154] The mutual authentication in use case 1 and use case 2 will be described in the following examples.

[0155] Mutual authentication in use case 1 The following text Figure 9 The mutual authentication method in Use Case 1 is described. In Use Case 1, it is assumed that all providers have already mutually authenticated each other before the device initially connects to the network. The purpose of this embodiment is to provide mutual authentication between the device and the network.

[0156] Figure 9The call flow for the anonymity and mutual authentication process in Use Case 1 is described in this diagram. The KMF is not included in the system. The result of this process is that both the device and the AS negotiate a shared key (called the EMSK). This EMSK is stored in the AS. If the system includes a KMF, the EMSK will be sent to the KMF. Figure 8 The details are as follows: (1) The device sends message 1 to the initial GW.

[0157] (2) Initial GW selection of service GW. How to select a service GW is described in Example 3.

[0158] (3) Initially, GW sends message 3 to AS.

[0159] (4) AS sends message 4 to IDM.

[0160] (5) IDM performs the following actions: - Map Tem_ID to Auth_ID.

[0161] - Retrieve the certificate corresponding to Auth_ID.

[0162] - Select authentication method. It should be noted that this application supports two authentication methods: EAP-TLS and EAP-AKA'. Details regarding EAP-TLS and EAP-AKA' can be found in 33.501.

[0163] (6) IDM sends message 6 to AS.

[0164] (7) AS performs the following actions: - Verify the device's certificate. If device verification fails, the AS should treat the authentication as a failure and indicate the failure to the initial GW.

[0165] - Upon successful authentication, when the selected authentication method is EAP-AKA', the AS should generate a vector AV. The method for generating a vector AV is similar to the technology for 5G vector AV in 3GPP 33.501.

[0166] (8) AS sends message 8 to the initial GW.

[0167] (9) Initially, the GW sends message 9 to the device.

[0168] (10) The device verifies the AS using the AS's certificate or vector AV. If the verification of the AS fails, the device should treat the authentication as a failure and indicate the failure to the AS. Otherwise, the device generates an EMSK based on the AS's certificate or vector AV.

[0169] (11) The device sends message 11 to the initial GW.

[0170] (12) Initially, GW sends message 12 to AS.

[0171] (13) AS generates EMSK based on AS’s certificate or vector AV.

[0172] (14) AS sends message 14 to UDM.

[0173] (15) AS sends message 15 to the device via the initial GW.

[0174] This embodiment provides a corresponding Figure 7 The call flow involves anonymity and mutual authentication. Compared to existing technologies (e.g., 3GPP 33.501), the AS generates the Vector AV instead of the IDM (in 3GPP 33.501, the UDM generates the Vector AV). Furthermore, the device's certificate is stored in the IDM. That is, the AS requests the device's certificate from the IDM, rather than requesting the device's certificate from the device itself. These differences enable the IDM to have new functions such as ID mapping and maintaining device certificates. These new features can bring several benefits, such as ID privacy protection and anonymous communication between devices and the network.

[0175] Figure 10 Examples of mutual authentication based on a first architecture provided for some embodiments of this application.

[0176] In step 401, the device sends message 1 to the initial GW.

[0177] Message 1 can be the first authentication request, and it includes the device's temporary ID. Message 1 corresponds to... Figure 9 Message 1.

[0178] In step 402, the initial GW selects a service GW.

[0179] How to select a service GW is described in the process implementation example. Step 402 corresponds to... Figure 9 Step 2 in the process.

[0180] In step 403, the initial GW sends message 2 to the AS.

[0181] Message 2 can be a second authentication request, and it includes the device's temporary ID and the name of the service GW. Message 2 corresponds to... Figure 9 Message 3 in the middle.

[0182] In step 404, AS sends message 3 to the IDM function.

[0183] Message 3 can be `authentication_get_request`, and it includes the device's temporary ID. Message 3 corresponds to... Figure 9Message 4 in the middle.

[0184] In step 405, the IDM function determines the authentication ID corresponding to the temporary ID, and further determines the certificate of the device corresponding to the authentication ID. How to determine the authentication ID and how to obtain the device certificate can be referred to the descriptions in steps 320 to 330, and will not be repeated here. Step 405 corresponds to... Figure 9 Step 5 in the process.

[0185] In addition, IDM selects an authentication method. This application supports at least two authentication methods, including Extensible Authentication Protocol-Transport Level Security (EAP-TLS) and Enhanced Authentication and Key Agreement Prime (EAP-AKA'). Details about EAP-TLS and EAP-AKA' can be found in 3GPP 33.501.

[0186] In step 406, the IDM function sends message 4 to the AS.

[0187] Message 4 can be `authentication_get_response`, and includes the device's certificate, authentication ID, and selected authentication method. Message 4 corresponds to... Figure 9 Message 6 in the middle.

[0188] In step 407, the AS verifies the device.

[0189] The AS verifies the device using the device's certificate and authentication ID. Specifically, the AS calculates the device's certificate using the authentication ID and the selected authentication method. Then, the AS verifies the device by comparing the device's certificate (i.e., the device certificate received from the IDM function) with the calculated device certificate. If the calculated device certificate matches the received device certificate, the device verification is successful. Otherwise, the device verification fails. If the device verification fails, the AS should treat the authentication as a failure and indicate the failure to the initial GW. After successful authentication, the following steps are implemented. Step 407 corresponds to... Figure 9 Step 7 in the process.

[0190] In step 408, AS sends message 5 to the initial GW.

[0191] Message 5 can be a third-party authentication request, and it includes the AS's certificate. The AS obtains its certificate by registering with the CA. Message 5 corresponds to... Figure 9 Message 8 in the middle.

[0192] In step 409, the initial GW sends message 6 to the device.

[0193] Message 6 can be a fourth authentication request; message 6 includes the AS certificate. Message 6 corresponds to... Figure 9 Message 9 in the middle.

[0194] In step 410, the device verifies the AS and generates the EMSK if the AS is successfully verified.

[0195] The device verifies the AS using the AS's certificate. Specifically, the device calculates the AS's certificate and verifies itself by comparing the calculated AS certificate with the received certificate included in message 6. If the verification of the AS fails, the device should treat the authentication as a failure and indicate the failure to the AS. Otherwise, the device generates a shared key, called an EMSK, for use between the device and the network based on the AS's certificate. Step 410 corresponds to... Figure 9 Step 10 in the process.

[0196] In step 411, the device sends message 7 to the initial GW.

[0197] Message 7 can be an authentication response corresponding to the fourth authentication request. Message 7 indicates that the device's authentication was successful. Message 7 corresponds to... Figure 9 Message 11.

[0198] In step 412, the initial GW sends message 8 to the AS.

[0199] Message 8 can be an authentication response corresponding to a third authentication request. Message 8 indicates that the device's authentication was successful. Message 8 corresponds to... Figure 9 Message 12.

[0200] In step 413, AS generates EMSK.

[0201] The EMSK is generated based on the AS certificate. It should be noted that the EMSK generated by the device and the EMSK generated by the AS are the same. Step 413 corresponds to the following... Figure 9 Step 13 in the process.

[0202] In some embodiments, the EMSK is generated by the device or the AS, and the EMSK may be associated with one or more parameters known only to the device or the AS.

[0203] In step 414, AS sends message 9 to the UDM function.

[0204] Message 9 could be a service request update message, and message 9 includes the name of the service GW. Step 414 corresponds to... Figure 9 Step 14 in the process.

[0205] In step 415, AS sends message 10 to the device via the initial GW.

[0206] Message 10 can be an authentication response, indicating successful mutual authentication. Step 415 corresponds to... Figure 9 Steps 16 and 15 in the process.

[0207] Figure 10 The illustrated embodiments provide a process for anonymization and mutual authentication according to the method proposed in this application. In this embodiment, the device's certificate is stored in the IDM (Integrated Device Manager) functionality. That is, the AS (Application System) requests the device's certificate from the IDM, rather than from the device itself. These differences enable the IDM to have new capabilities for ID mapping and maintaining device certificates. These new capabilities may offer benefits such as device ID privacy protection and anonymous communication between the device and the network.

[0208] exist Figure 10 In the illustrated embodiment, the AS uses the authentication ID to verify the device through the device's certificate, while the device verifies the AS through the AS's certificate. As described above, in another embodiment, mutual authentication between the device and the AS can be implemented based on AV, as shown in the figure below.

[0209] Figure 11 Another example of mutual authentication based on a first architecture provided for some embodiments of this application.

[0210] Steps 501 to 504 are the same as steps 401 to 404, so the description of steps 501 to 504 can be referred to the description of steps 401 to 404, and will not be repeated here.

[0211] In step 505, the IDM generates an authentication ID corresponding to the temporary ID of the device, and generates an AV based on the authentication ID.

[0212] To clearly describe the proposed scheme, the AV generated by the IDM function is referred to as the first AV. The method for generating the AV is similar to the technique used for 5G vector AVs in 3GPP 33.501. The first AV may include several elements associated with the authentication ID.

[0213] In addition, IDM selects an authentication method. This application supports at least two authentication methods, including Extensible Authentication Protocol-Transport Level Security (EAP-TLS) and Enhanced Authentication and Key Agreement Prime (EAP-AKA'). Details about EAP-TLS and EAP-AKA' can be found in 3GPP 33.501.

[0214] In step 506, the IDM function sends message 4 to the AS.

[0215] Message 4 can be authentication_get_response, and message 4 includes the first AV, the authentication ID, and the selected authentication method.

[0216] In step 507, the AS verifies the device.

[0217] The AS uses the authentication ID to verify the device via the first AV. Verification depends on how the first AV is constructed. For example, the AS calculates an element based on the authentication ID and then compares the calculated element with the elements included in the received first AV. If verification of the device fails, the AS should treat the authentication as failed and indicate the failure to the initial GW.

[0218] After successful authentication, AS should generate a second AV. In fact, the second AV is an update or regeneration of the first AV. For example, the second AV is generated by updating one or more elements in the first AV.

[0219] In step 508, AS sends message 5 to the initial GW.

[0220] Message 5 can be a third authentication request, and message 5 includes a second authentication request.

[0221] In step 509, the initial GW sends message 6 to the device.

[0222] Message 6 can be a fourth authentication request, and message 6 includes a second authentication request.

[0223] In step 510, the device verifies AS.

[0224] Specifically, the device verifies the AS via the second AV. If verification with the AS fails, the device should treat the authentication as failed and indicate the failure to the AS. Otherwise, the device generates a new AV, such as a third AV, and an EMSK. The EMSK is generated based on either the second or third AV, depending on the strategy used to generate the EMSK. It is important that the device and the AS use the same AV to generate the EMSK.

[0225] In step 511, the device sends message 7 to the initial GW.

[0226] Message 7 can be an authentication response corresponding to the fourth authentication request. Message 7 indicates that the device's authentication was successful. Message 7 includes the third AV.

[0227] In step 512, the initial GW sends message 8 to the AS.

[0228] Message 8 may be an authentication response corresponding to the third authentication request. Message 8 indicates that the device's authentication was successful. Message 8 includes the third AV. Through steps 511 to 512, the third AV generated by the device is sent to the AS via the initial GW.

[0229] In step 513, AS generates EMSK.

[0230] The EMSK is generated based on either the second or third AV. It's important to note that the EMSK generated by the device and the EMSK generated by the AS (Automatic Support Panel) are the same. As mentioned above, the EMSK generated by the AS is based on the same AV used by the device. In other words, if the EMSK generated by the device is based on the second AV, then the EMSK generated by the AS is also based on the second AV. Similarly, if the EMSK generated by the device is based on the third AV, then the EMSK generated by the AS is also based on the third AV.

[0231] In step 514, AS sends message 9 to the UDM function.

[0232] Message 9 can be a service request update message, which includes the name of the service GW.

[0233] In step 515, AS sends message 10 to the device via the initial GW.

[0234] Message 10 can be an authentication response, indicating that mutual authentication was successful.

[0235] Mutual authentication in use case 2 The diagram below illustrates the anonymity and mutual authentication methods in Use Case 2. In Use Case 2, it is assumed that the provider is untrusted. The provider can be an infrastructure provider or a service provider. The purpose of this embodiment is to provide mutual authentication between devices, providers, and the network. Two issues arise during the mutual authentication process: If there are more than one untrusted provider, how does the initial GW select a serving GW? What information should be exchanged during the mutual authentication process? Since authentication uses an authentication ID and communication uses a temporary ID, how does the provider authenticate the device? Does the AS (Authentication Server) authenticate the device on behalf of the provider? Figure 12 This is another mutual authentication architecture provided by some embodiments of this application. Figure 13 Described according to Figure 12 The call flow. Figure 12 In this process, the system does not include a KMF. The result is that both the device and the AS negotiate a shared key (called an EMSK). This EMSK is stored in the AS. If the system includes a KMF, the EMSK will be sent to the KMF.

[0236] Figure 13 The details are as follows: (1) The device sends message 1 to the initial GW.

[0237] (2) Initial GW selection of service GW. How to select a service GW in... Figure 11 As described in the text.

[0238] (3) Initially, GW sends message 3 to AS.

[0239] (4) The process of AS implementing ID retrieval. For details on ID retrieval, please refer to [link to documentation]. Figure 9 Steps 4 to 6 in the process.

[0240] (5) AS performs the following actions: - Verify the device's certificate. If device verification fails, the AS should treat the authentication as a failure and indicate the failure to the initial GW.

[0241] - Verify the provider's certificate. If the verification of the provider fails, the AS should indicate the failure of the provider's authentication to the initial GW.

[0242] - Upon successful authentication, an indication is generated that both the device and the provider have been successfully authenticated by AS. This indication is associated with the device's Tem_ID and the provider's ID.

[0243] - Upon successful authentication, when the selected authentication method is EAP-AKA', the AS should generate a vector AV. The method for generating a vector AV is similar to the technology for 5G vector AV in 3GPP 33.501.

[0244] (6) AS sends message 6 to the initial GW.

[0245] (7) The initial GW sends message 7 to the provider.

[0246] (8) The provider verifies the AS's certificate using the AS's certificate. The provider then verifies the instruction. If the verification of the AS fails, the provider should indicate the failure of the AS's authentication to the initial GW.

[0247] (9) The provider sends message 9 to the initial GW.

[0248] (10) Initially, the GW sends message 10 to the device.

[0249] (11) The device verifies the AS using the AS's certificate or vector AV. If the verification of the AS fails, the device should treat the authentication as a failure and indicate the failure to the AS. Device verification indication. The device generates an EMSK based on the AS's certificate or vector AV.

[0250] (12) The device sends message 12 to the initial GW.

[0251] (13) AS generates EMSK based on AS’s certificate or vector AV.

[0252] (14) AS sends message 14 to UDM.

[0253] (15) AS sends message 15 to the device via the initial GW.

[0254] Figure 14 Examples of mutual authentication based on a second architecture provided for some embodiments of this application.

[0255] In step 601, the device sends message 1 to the initial GW. Message 1 includes the device's temporary ID. Message 1 corresponds to the above... Figure 13 Message 1.

[0256] In step 602, the initial GW selects a serving GW. Step 602 corresponds to... Figure 13 Step 2 in the process.

[0257] In step 603, the initial GW sends message 2 to the AS.

[0258] Message 2 includes the device's temporary ID, the provider's certificate, and the provider's ID. Additionally, message 2 may include the name of the service gateway (GW). Message 2 corresponds to... Figure 13 Message 3 in the middle.

[0259] In step 604, AS performs the ID retrieval process.

[0260] Step 604 can be referred to steps 404 to 406, and will not be repeated here. Based on step 604, the AS determines the authentication ID corresponding to the device's real ID, and then determines the certificate of the device corresponding to the authentication ID. Therefore, after steps 601 to 604, the AS obtains the authentication ID, the device's certificate, the provider's ID, and the provider's certificate. Step 604 corresponds to... Figure 13 Step 4 in the process.

[0261] In step 605, AS verifies the equipment and the provider.

[0262] Step 605 corresponds to Figure 13 Step 5 in the process. Specifically, the AS verifies the device using the device's certificate and authentication ID, as described in step 407 above. If device verification fails, the AS should treat the authentication as failed and indicate the failure to the initial GW. For example, the AS indicates to the initial GW that the device authentication failed.

[0263] In addition, the AS verifies the provider using the provider's certificate. The AS calculates the provider's certificate and then verifies the provider by comparing the provider's certificate received from the IDM function with the calculated provider's certificate. If the calculated provider's certificate is the same as the received provider's certificate, the verification of the provider is successful. Otherwise, the verification of the provider fails. If the verification of the provider fails, the AS should indicate the failure to the initial GW; for example, the AS indicates to the initial GW that the authentication of the provider has failed.

[0264] Upon successful authentication, AS generates an indication that both the device and the provider have been successfully authenticated by AS. This indication is associated with the device's temporary ID and the provider's ID.

[0265] In step 606, AS sends message 3 to the initial GW.

[0266] Message 3 includes instructions and the AS certificate. Message 3 corresponds to... Figure 13 Message 6 in the middle.

[0267] In step 607, the initial GW sends message 4 to the provider.

[0268] Message 4 includes the AS's certificate and instructions. Message 4 corresponds to... Figure 13 Message 7.

[0269] In step 608, the provider verifies the instruction and AS.

[0270] Step 608 corresponds to Figure 13 Step 8. The provider verifies the AS using the AS's certificate. Specifically, the provider verifies the AS using the received AS certificate and the calculated AS certificate. Additionally, the provider verifies the indication. The indication is generated by the AS based on the device's temporary ID and the provider's ID. In some embodiments, the indication may be signed by the AS. In some embodiments, the indication may be associated with information from the AS (e.g., the AS's ID). If the indication is signed by the AS, the provider needs to verify the signed indication using the AS's public key. If the indication is associated with information from the AS, the provider needs to calculate a new indication based on the AS's information (e.g., the AS's ID) and compare the new indication with the received indication. If they are equal, the verification of the indication is successful. If the verification of the AS and / or the indication fails, the provider should indicate the failure of AS authentication to the initial GW. After successful verification, the provider proceeds to step 609.

[0271] In step 609, the provider sends message 5 to the initial GW.

[0272] Message 5 indicates that the provider has successfully verified the device and AS. Message 5 corresponds to... Figure 13 Message 9 in the middle.

[0273] In step 610, the initial GW sends message 6 to the device.

[0274] Message 6 includes the AS's certificate and instructions. In step 606, the initial GW obtains the AS's certificate and instructions via message 3. Message 6 corresponds to... Figure 13 Message 10.

[0275] In step 611, the device verification instruction and AS are provided.

[0276] Step 611 corresponds to Figure 13 Step 11 in the process.

[0277] Specifically, the device verifies the AS using the AS's certificate and also verifies the indication. If verification of the AS or the indication fails, the device should treat the authentication as a failure and indicate the failure to the AS. If verification of both the AS and the indication succeeds, the device generates an EMSK based on the AS's certificate.

[0278] In step 612, the device sends message 7 to the AS via the initial GW.

[0279] Message 7 indicates that the device and provider have successfully authenticated the AS. Message 7 corresponds to... Figure 13 Message 12.

[0280] In step 613, AS generates EMSK.

[0281] AS generates EMSK based on AS's certificate. Step 613 corresponds to... Figure 13 Step 13 in the process.

[0282] In step 614, AS sends message 9 to the UDM function.

[0283] Message 9 includes the name of the service GW and the name of the provider. Step 614 corresponds to... Figure 13 Step 14 in the process.

[0284] In step 615, AS sends message 10 to the device via the initial GW.

[0285] Message 10 indicates that mutual authentication between the device, provider, and AS was successful. Step 615 corresponds to... Figure 13 Step 15 in the process.

[0286] This example illustrates how a provider can authenticate a device by introducing an authentication ID. The provider can indirectly verify the device with the help of the AS (Automatic System).

[0287] Figure 11 The mutual authentication between the device, provider, and AS shown is based on certificates, such as the device's certificate, the provider's certificate, and the AS's certificate. Similar to the embodiment in Use Case 1, mutual authentication between the device, provider, and AS can also be implemented using the AV in Use Case 2.

[0288] Figure 15 Examples of mutual authentication based on a second architecture provided for some embodiments of this application.

[0289] Figure 15 The description of steps 701 to 704 is consistent with Figure 14The descriptions of steps 601 to 604 are similar. The difference between steps 701 to 704 and steps 601 to 604 is that the AS obtains the AV (referred to as the first AV in subsequent steps) from the IDM function through steps 701 to 704 instead of the device's certificate. In some embodiments, the first AV may include one or more elements associated with the device ID and the provider ID.

[0290] In step 705, AS verifies the equipment and the provider.

[0291] Specifically, the AS verifies the device using the first AV and the authentication ID, as described in step 507 above. If device verification fails, the AS should treat the authentication as failed and indicate the failure to the initial GW. For example, the AS indicates to the initial GW that the device authentication failed.

[0292] In addition, the AS verifies the provider using the provider's certificate. The AS calculates the provider's certificate, and then verifies the provider by comparing the received provider certificate included in message 2 with the calculated provider certificate. If the calculated provider certificate is the same as the received provider certificate, the provider verification is successful. Otherwise, the provider verification fails. If the provider verification fails, the AS should indicate the failure to the initial GW; for example, the AS indicates to the initial GW that the provider authentication has failed.

[0293] Upon successful authentication, the AS generates an indication that both the device and the provider have been successfully authenticated by the AS. This indication is associated with the device's temporary ID and the provider's ID. Furthermore, the AS generates a second AV based on the first AV.

[0294] In step 706, AS sends message 3 to the initial GW.

[0295] Message 3 includes instructions and a second AV.

[0296] In step 707, the initial GW sends message 4 to the provider.

[0297] Message 4 includes a second AV and instructions.

[0298] In step 608, the provider verifies the instruction and AS.

[0299] The provider verifies the AS via the second AV, referring to step 510 above. Additionally, the provider verifies the indication. If verification of the AS or indication fails, the provider should indicate the authentication failure of the AS to the initial GW. Upon successful authentication, the provider generates a third AV based on the second AV and executes step 709.

[0300] In step 709, the provider sends message 5 to the initial GW.

[0301] Message 5 indicates that the provider has successfully verified the device and AS. Message 5 includes a third AV.

[0302] In step 710, the initial GW sends message 6 to the device.

[0303] Message 6 includes a third AV and an indication. The third AV is obtained by the initial GW through step 610, and the indication is obtained through message 3 in step 706.

[0304] In step 711, the device verification instruction and AS are performed.

[0305] Specifically, the device verifies the AS via the third AV and the indication. If verification of the AS or the indication fails, the device should treat the authentication as a failure and indicate the failure to the AS. If verification of the AS and the indication succeeds, the device generates a fourth AV and an EMSK. Similar to the embodiment in Use Case 1, the EMSK is generated based on either the third or fourth AV in Use Case 2, depending on the strategy used to generate the EMSK. It is important that the device and the AS use the same AV to generate the EMSK.

[0306] In step 712, the device sends message 7 to the AS via the initial GW.

[0307] Message 7 indicates that the device and provider have successfully verified AS.

[0308] In step 713, AS generates EMSK.

[0309] AS generates EMSK. As described in step 711, AS and AS use the same AV to generate EMSK.

[0310] In step 714, AS sends message 9 to the UDM function.

[0311] Message 9 includes the name of the service GW and the name of the provider.

[0312] In step 715, AS sends message 10 to the device via the initial GW.

[0313] Message 10 indicates that mutual authentication between the device, provider, and AS has been successful.

[0314] Some of the above embodiments relate to the process of selecting a service GW implemented by an initial GW. Figure 16 The example illustrates the details of this process of selecting a service GW.

[0315] Figure 16 The call flow for the initial GW to select a serving GW is shown.

[0316] In step 801, the initial GW selects a provider. How to select a provider is beyond the scope of this application.

[0317] In step 802, the initial GW sends message 1 to the selected provider.

[0318] Message 1 may include the device ID, such as a temporary device ID, and / or service requests.

[0319] In step 803, the selected provider sends message 2 to the initial GW.

[0320] Message 2 may include the provider's ID and the provider's certificate.

[0321] In step 804, the initial GW selects a service GW based on the location of the device and the location of the provider.

[0322] In step 805, the initial GW sends message 3 to the selected service GW.

[0323] Message 4 may include the provider's ID.

[0324] In step 806, the service GW can send message 4 to the initial GW, which is a response to message 3.

[0325] The methods proposed in the embodiments of this application have been described in detail above. The communication device provided in this application will be described in detail below.

[0326] Figure 17 This is a schematic block diagram of a communication device 10 provided in some embodiments of this application. The communication device may be a communication apparatus or a device applied to a communication apparatus, capable of implementing the corresponding function of any network function in the embodiments of this application. For example, the device may be a chip, a chip system, or a circuit, without limitation. The communication apparatus may be an IDM function, an AS, a terminal device, a provider, or a chip installed in any of these network functions.

[0327] The communication device 10 includes a processing module 1001. The processing module 1001 may be a processor, processing circuit, processing board, processing unit, or processing device, etc. The processing module 1001 is used to perform processing and / or operations within the communication device, excluding transmission and reception actions.

[0328] The communication device 10 may further include a communication module 1002. The communication module 1002 is used to implement sending and / or receiving operations. The communication module 1002 may also be called a transceiver module, transceiver, or transceiver device, etc., and is used to implement receiving (which may be called input) and / or sending (which may be called output) operations.

[0329] For example, if communication device 10 corresponds to Figure 8If the communication device 10 corresponds to the IDM, then the communication module 1002 is used to receive the first message from the AS. The communication module 1002 is also used to send the second message to the AS. The processing module 1001 is used to implement step 320. If the communication device 10 corresponds to Figure 8 In the AS, the communication module 1002 is used to send a first message to the IDM function and further receive a second message from the IDM function.

[0330] For example, if communication device 10 corresponds to Figure 10 In the AS, the communication module 1002 is used to send message 3 and receive message 4. The processing module 1001 is used to implement steps 407 and 413.

[0331] For example, if communication device 10 corresponds to Figure 10 If the device is in the middle, then the communication module 1002 is used to send message 1 or message 7, and further receive message 6. The processing module 1001 is used to implement step 410.

[0332] For example, if communication device 10 corresponds to Figure 14 If the provider is in the network, then the communication module 1002 is used to receive message 4 from the initial GW and further send message 5. The processing module 1001 is used to implement step 608.

[0333] In short, the operation and / or function of device 10 are for implementing the corresponding steps of the above method embodiments.

[0334] Figure 18 This is a schematic block diagram of a communication device provided in some embodiments of this application. The communication device 20 includes at least one processor 21. The at least one processor 21 is coupled to at least one memory 22. The at least one memory 22 is used to store one or more instructions and / or executable computer code. The at least one processor 21 is used to invoke one or more instructions and / or executable computer code to cause the communication device 20 to implement the methods provided in the embodiments of this application. Optionally, the communication device 20 may further include at least one memory 22. Optionally, the communication device 20 may further include at least one communication interface 23, which is used for inputting and / or outputting information or data.

[0335] In one implementation, the communication device 20 can be any of the network functions in the method embodiments. For example, the communication device 20 can be an AS, an IDM function, a terminal device, or a provider. In this implementation, the processor 21 can be a baseband device, and the communication interface 23 can be a radio frequency device.

[0336] In another implementation, the communication device 20 can be a chip (or chip system) installed in a communication device such as a first network function, an IDM function, a second network function, or a third network function. In this implementation, the processor 21 can be a circuit, such as a logic circuit, an integrated circuit, etc. The communication interface 13 can be a transceiver, interface circuit, input / output interface, bus, module, pin, or other type of interface.

[0337] Embodiments of this application also provide a communication system. The communication system may include any communication device according to any method embodiment. For example, the communication system may include one or more of the following network functions: AS, IDM, terminal equipment, and provider. The communication system may also include other network functions, such as GW, without limitation.

[0338] Embodiments of this application also provide a computer storage medium that can store one or more instructions for performing any of the methods described above.

[0339] Embodiments of this application also provide a computer program product that can store one or more instructions for performing any of the methods described above.

[0340] In the embodiments of this application, "and / or" describes the association relationship between associated objects, indicating that three relationships may exist. For example, A and / or B can represent the following three cases: only A exists, both A and B exist, and only B exists. The character " / " generally represents an "OR" relationship between associated objects. "At least one" refers to one or more. "At least one of A and B," similar to "A and / or B," describes the association relationship between associated objects, indicating that three relationships may exist. For example, at least one of A and B can represent the following three cases: only A exists, both A and B exist, and only B exists.

[0341] Furthermore, unless the context clearly indicates otherwise, the use of the singular forms of “a” and “the” in the embodiments of this application and the appended claims is also intended to include the plural forms.

[0342] Those skilled in the art will recognize that the various examples described in conjunction with the embodiments disclosed in this specification, the units and algorithm steps, can be implemented by electronic hardware or by a combination of computer software and electronic hardware. Whether the function is executed by 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 embodiments should not be considered beyond the scope of this application.

[0343] Those skilled in the art will clearly understand that, for convenience and brevity, the specific working process of the above-described systems, devices, and units can be referred to the corresponding process in the above-described method embodiments, and will not be repeated here.

[0344] In the several embodiments provided in this application, the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the described apparatus embodiments are merely exemplary. For example, the units are divided into logical functional divisions, and other division methods may be used in actual embodiments. For example, multiple units or components may be merged or integrated into another system, or some features may be ignored or not performed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be implemented using various communication interfaces. Indirect coupling or communication connection between devices or units can be implemented electronically, mechanically, or otherwise.

[0345] In addition, the functional units in the embodiments of this application can be integrated into a processing unit, each of which can exist physically separately, or two or more units can be integrated into a unit.

[0346] When these functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. The technical solution of this application can be implemented as a software product. The software product is stored in a storage medium and includes several instructions to instruct 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 embodiments of this application. The aforementioned storage medium includes any medium capable of storing program code, such as a USB flash drive, portable hard drive, ROM, RAM, magnetic disk, optical disk, etc.

[0347] 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; they may be located in one place or distributed across multiple network units. Some or all of the units can be selected based on actual needs to achieve the purpose of the embodiment. Furthermore, the functional units in the embodiments of this application may be integrated into one processing unit, or each unit may exist physically independently, or two or more units may be integrated into one unit.

[0348] The above description is merely a specific implementation of this application and is not intended to limit the scope of protection of this application. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. An authentication method executed by an identifier management (IDM) function, characterized in that, include: Receive a first message, wherein the first message includes a temporary identifier ID of the device, the temporary ID being used for communication between the device and the network; Send a second message, wherein the second message includes an authentication ID corresponding to the temporary ID, and the second message also includes the device's certificate or authentication vector (AV), the authentication ID corresponding to the device's certificate or the AV, the device's certificate or the AV being used for mutual authentication between the device and the network; the authentication ID being used for identification / authentication on the device.

2. The method according to claim 1, characterized in that, The method further includes: The real ID of the device is determined based on the temporary ID; The authentication ID is determined based on the real ID.

3. The method according to claim 1 or 2, characterized in that, The AV is generated by the IDM function based on the authentication ID.

4. The method according to any one of claims 1 to 3, characterized in that, The device's certificate comes from a Certificate Authority (CA).

5. An authentication method executed by an authentication server AS, characterized in that, include: Send a first message to the Identifier Management (IDM) function, wherein the first message includes a temporary identifier ID of the device, the temporary ID being used for communication between the device and the network; The second message is received from the IDM function, wherein the second message includes an authentication ID corresponding to the temporary ID, and the second message also includes the device's certificate or AV, the authentication ID corresponding to the device's certificate or AV, the device's certificate or AV being used for mutual authentication between the device and the network.

6. The method according to claim 5, characterized in that, The first message also includes the name of the service gateway (GW).

7. The method according to claim 5 or 6, characterized in that, The AV included in the second message is the first AV, and the method further includes: Using the authentication ID, the device is verified through the device's certificate or the first AV; If the verification of the device is successful, a third message is sent to the device, wherein the third message includes the AS certificate or a second AV, the second AV being generated based on the first AV.

8. The method according to any one of claims 5 to 7, characterized in that, The method further includes: A fourth message is received, indicating that the device has successfully verified the AS; Generate a shared key used between the device and the network, wherein the shared key is generated based on the certificate of the AS, or the shared key is generated based on the second AV or the third AV, wherein the third AV comes from the device.

9. An authentication method executed by an authentication server AS, characterized in that, include: Receive a first message from the initial gateway GW, wherein the first message requests mutual authentication between the device, the provider, and the AS, and the first message includes the device's temporary identifier ID, the provider's certificate, and the provider's ID; The device's certificate and authentication ID are obtained from the IDM (Identifier Management) function, wherein the device's certificate corresponds to the authentication identifier ID, and the authentication ID is determined by the IDM function based on the device's real ID, which is determined based on the device's temporary ID. Using the authentication ID, the device is verified through the device's certificate, and the provider is verified through the provider's certificate; If the verification of the device and the verification of the provider are successful, an indication associated with the temporary ID of the device and the ID of the provider is generated.

10. The method according to claim 9, characterized in that, After generating the indication associated with the temporary ID of the device and the ID of the provider, the method further includes: The instruction and first information are sent to the initial GW, wherein the first information is used for the provider and the device to verify the AS.

11. The method according to claim 9 or 10, characterized in that, The first information includes the AS's certificate or authentication vector AV.

12. The method according to any one of claims 9 to 11, characterized in that, The method further includes: After successful verification of the device and the provider, a shared key for use between the device and the AS is generated based on the first information.

13. The method according to any one of claims 9 to 12, characterized in that, The first message also includes the name of the service gateway (GW).

14. An authentication method performed by a device, characterized in that, include: Send a first message, the first message requesting mutual authentication between the device and the network, wherein the first message includes a temporary identifier ID of the device for communication between the device and the network; After the authentication server AS successfully verifies the device, the AS is verified based on the first information of the AS; If the verification of the AS is successful, a shared key is generated based on the first information.

15. The method according to claim 14, characterized in that, The first information includes the AS's certificate or authentication vector AV.

16. An authentication method, characterized in that, include: Send a first message to the initial gateway GW, wherein the first message requests mutual authentication between the device, the provider and the authentication server AS, and the first message includes the device's temporary identifier ID; Obtain first information and indication, wherein the first information is used for the verification of the AS, and the indication indicates that both the device and the provider have been successfully verified by the AS; The AS and the instruction are verified using the first information; If the AS and the indication are successfully verified, a shared key for use between the device and the network is generated based on the first information.

17. The method according to claim 16, characterized in that, The first information includes the AS's certificate or vector AV.

18. The method according to claim 16 or 17, characterized in that, Obtaining the first information and the instruction includes: The second message is received from the AS via the initial gateway GW, wherein the second message includes the first information and the indication.

19. An authentication method performed by a provider, characterized in that, include: Receive a first message from the initial gateway GW, wherein the first message requests the provider to authenticate the device and the authentication server AS, and the first message includes first information for the authentication of the AS and an indication associated with the device's temporary ID and the provider's ID; Use the first information to verify the AS and verify the indication; A second message is sent to the initial GW, wherein the second message indicates that the verification of the AS and the indication was successful.

20. The method according to claim 19, characterized in that, The first information includes the AS's certificate or authentication vector AV.

21. An authentication method executed in a communication system, characterized in that, The system includes an identifier management (IDM) function and an authentication server (AS); the method includes: The AS receives a first message, wherein the first message includes a temporary identifier ID of the device, the temporary ID being used for communication between the device and the network; The AS sends a second message to the IDM function, wherein the second message includes the temporary ID; The IDM receives the second message and sends a third message to the IDM function, wherein the third message includes an authentication ID corresponding to the temporary ID, and the third message also includes the device's certificate or authentication vector (AV), the authentication ID corresponding to the device's certificate or the AV, and the device's certificate or the AV being used for mutual authentication between the device and the network; The AS uses the authentication ID to verify the device through the device's certificate or the AV.

22. An authentication method executed in a communication system, characterized in that, The system includes an identifier management (IDM) function, a provider, devices, an initial gateway (GW) for the devices, and an authentication server (AS); the method includes: The AS receives a first message, wherein the first message requests mutual authentication between the device, the provider, and the AS, and the first message includes the device's temporary identifier ID, the provider's certificate, and the provider's ID; The AS obtains the device's certificate and authentication ID from the IDM function, wherein the device's certificate corresponds to the authentication identifier ID, and the authentication ID is determined by the IDM function based on the device's real ID, which is determined based on the device's temporary ID. The AS uses the authentication ID to verify the device using the device's certificate, and to verify the provider using the provider's certificate. If the verification of the device and the verification of the provider are successful, it generates an indication associated with the temporary ID of the device and the ID of the provider. The AS sends the instruction and first information to the provider, wherein the first information is used by the provider to verify the AS and the device; The provider uses the first information to verify the AS and the instruction; The provider indicates to the initial gateway that the provider's verification of the device and the AS was successful; The initial GW sends the first information and the indication to the device, wherein the first information and the indication are obtained by the initial GW from the AS; The device verifies the instruction and verifies the AS based on the first information.

23. A communication device, characterized in that, The communication device includes a processor for executing one or more instructions stored in a memory to cause the communication device to implement the method according to any one of claims 1 to 4, any one of claims 5 to 13, any one of claims 14 to 18, or the method according to claim 19 or 20.

24. The communication device according to claim 23, characterized in that, The communication device also includes the memory.

25. The communication device according to claim 23 or 24, characterized in that, The communication device includes a communication interface, which is used to input and / or output information or data.

26. A communication device, characterized in that, The communication device includes functions or units for performing the method according to any one of claims 1 to 4, or the method according to any one of claims 5 to 13, or the method according to any one of claims 14 to 18, or the method according to claim 19 or 20.

27. A communication device, characterized in that, The communication device includes a circuit and a communication interface, the communication interface being used to receive information and / or data to be processed by the circuit and to send the information and / or data to the circuit; the circuit being used to perform the method according to any one of claims 1 to 4, or to perform the method according to any one of claims 5 to 13, or to perform the method according to any one of claims 14 to 18, or to perform the method according to claim 19 or 20.

28. The communication device according to claim 27, characterized in that, The communication interface is also used to output information and / or data processed by the circuit.

29. A communication system, characterized in that, Includes one or more of the following communication devices: A communication device for performing the method according to any one of claims 1 to 4; A communication apparatus for performing the method according to any one of claims 5 to 13; A communication apparatus for performing the method according to any one of claims 14 to 18; A communication device that performs the method according to claim 19 or 20.

30. A computer-readable storage medium, characterized in that, It includes one or more instructions, wherein when the one or more instructions are executed on a computer, the computer performs the method according to any one of claims 1 to 4, or the method according to any one of claims 5 to 13, or the method according to any one of claims 14 to 18, or the method according to claim 19 or 20.

31. A computer program product, characterized in that, It includes one or more instructions, wherein when the one or more instructions are executed on a computer, the computer performs the method according to any one of claims 1 to 4, or the method according to any one of claims 5 to 13, or the method according to any one of claims 14 to 18, or the method according to claim 19 or 20.

Images