Method and apparatus for authentication

Abstract

Embodiments of the present application provide a method and an apparatus for authentication. In the present application, an authentication ID is introduced for authentication of a device by an authentication server, and a device's temporary ID is used for anonymous communication among gateways and service providers. The authentication ID is only known by an IDM function and the AS, thereby achieving anonymous authentication and device's ID privacy protection.

Description

METHOD AND APPARATUS FOR AUTHENTICATION

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] The present application is related to, and claims priority to, United States provisional patent application serial No. 63 / 541,521, entitled “SYSTEM AND METHODS FOR ANONYMOUS AUTHENTICATION FOR DEVICE IN THE FUTURE NETWORK” , and filed on September 29, 2023. The disclosure of the aforementioned application is hereby incorporated by reference in their entireties.TECHNICAL FIELD

[0003] Embodiments of the present application relate to the field of wireless technologies, and more specifically, to a method and an apparatus for authentication.BACKGROUND

[0004] A primary authentication and key agreement procedure are to enable mutual authentication between a device and a network, and to provide key materials that can be used for indirect derivation keys for security protection on communications between the device and the network. In the 3rd generation partnership project (3GPP) , the security anchor function (SEAF) may initiate authentication with the device during any procedure establishing a signaling connection with the device. The SEAF shall include a subscription concealed identifier (SUCI) that is in a request message and sent to an authentication server function (AUSF) . This SUCI will be de-concealed to gain a subscription permanent identifier (SUPI) by a unified data management (UDM) function. The SUPI will be sent to the SEAF. The SUPI or SUCI is used in both authentication and communications. This could bring a risk of identifier (ID) privacy leakage.SUMMARY

[0005] Embodiments of the present application provide a method and an apparatus for authentication, which can protect ID privacy.

[0006] According to a first aspect, there is provided a method for authentication, and the method may be performed by  a first apparatus or a chip installed in the first apparatus. The first apparatus may be an identifier management (IDM) function. The method includes: receiving a first message, where the first message includes a temporary identifier (ID) of a device, and the temporary ID is used for communication between the device and a network; and sending a second message, where the second message includes an authentication ID corresponding to the temporary ID, the second message further includes a device’s certificate or an authentication vector (AV) , the authentication ID corresponds to the device’s certificate or the AV, the device’s certificate or the AV is used for mutual authentication between the device and the network, and the authentication ID is used for identification / authentication on the device.

[0007] According to the proposed solution of the present application, a device’s authentication ID used for authentication on a device by an authentication server is introduced. The authentication ID is obtained according to a device’s real ID that is stored in the IDM function and only known by the IDM function and the AS. Further, a device’s temporary ID used for anonymous communication between the device and a network is introduced. Thus, the proposed solution can protect device’s ID privacy during an authentication procedure.

[0008] In other words, in the proposed solution, functionalities of a subscription permanent identifier (SUPI)  / subscription concealed identifier (SUCI) are divided into a functionality of identification / authentication of a device and a functionality of communication. By introducing a network function of the IDM function, the functionality of the identification / authentication of the device is implemented by introduction of an authentication ID and the functionality of the communication is implemented by introduction of a temporary ID, which could achieve anonymous communications between a device and a network.

[0009] In an implementation of the first aspect, the method further includes: determining a real ID of the device according to the temporary ID; and determining the authentication ID according to the real ID.

[0010] In this implementation, the authentication ID and the device’s temporary ID can’t be directly derived from each other so that device’s ID privacy protection can be provided.

[0011] In an implementation of the first aspect, the AV is generated by the IDM function according to the authentication ID.

[0012] In this implementation, an AV is computed according to an authentication ID, and the AV is used for mutual authentication between a device and a network based on the AV.

[0013] In an implementation of the first aspect, the device’s certificate is from a certificate authority (CA) .

[0014] In this implementation, a device’s certificate corresponding to an authentication ID is used for mutual authentication between a device and a network.

[0015] The technical effect of any one of the second aspect to the sixth aspect can refer to that of the first aspect, and it  will not be repeated in the following.

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

[0017] In an implementation of the second aspect, the first message further includes a name of a serving gateway (GW) .

[0018] In an implementation of the second aspect, the AV included in the second message is a first AV, and the method further includes: validating the device via the device’s certificate or the first AV using the authentication ID; and sending a third message to the device in a case that the validation of the device is successful, where the third message includes an AS’s certificate or a second AV, the second AV is generated based on the first AV.

[0019] In an implementation of the second aspect, where the method further includes: receiving a fourth message indicating successful validation of the AS by the device; generating a shared key used between the device and the network, where the shared key is generated according to the AS’s certificate, or the shared key is generated according to the second AV or a third AV, where the third AV is from the device.

[0020] According to a third aspect, there is provided a method for authentication, and the method may be performed by a third apparatus or a chip installed in the third apparatus. The third apparatus may be an authentication server (AS) . The method includes: receiving a first message from an initial gateway (GW) , where the first message requests for mutual authentication between a device, a provider and the AS, and the first message includes a device’s temporary identifier (ID) , a provider’s certificate and a provider’s ID; obtaining a device’s certificate and an authentication ID from an identifier management (IDM) function, where the device’s certificate corresponds to the authentication identifier (ID) , the authentication ID is determined by the IDM function according to a device’s real ID and the device’s real ID is determined according to the device’s temporary ID; validating the device via the device’s certificate using the authentication ID and validating the provider via the provider’s certificate; and generating an indication associated with the device’s temporary ID and the provider’s ID in a case that the validation of the device and the validation of the provider are successful.

[0021] In an implementation of the third aspect, after generating the indication associated with the device’s temporary ID and the provider’s ID, the method further includes: sending the indication and first information to the initial GW, where the  first information is used for validation of the AS by the provider and the device.

[0022] In an implementation of the third aspect, the first information includes an AS’s certificate or an authentication vector (AV) .

[0023] In an implementation of the third aspect, the method further includes: generating a shared key used between the device and the AS according to the first information after successful validation of the device and the provider.

[0024] In an implementation of the third aspect, the first message further includes a name of a serving gateway (GW) .

[0025] According to a fourth aspect, there is provided a method for authentication, and the method may be performed by a fourth apparatus or a chip installed in the fourth apparatus. The fourth apparatus may be a device, for example, a user equipment (UE) . The method may include: sending a first message requesting for mutual authentication between a device and a network, where the first message includes a device’s temporary identifier (ID) used for communication between the device and the network; validating the AS according to first information of the AS after successful validation of the device by the AS; and generating a shared key according to the first information in a case that the validation of the AS is successful.

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

[0027] According to a fifth aspect, there is provided a method for authentication, and the method may be performed by a fifth apparatus or a chip installed in the fifth apparatus. The fifth apparatus may be a device, for example, a user equipment (UE) . The method includes: sending a first message to an initial gateway (GW) , where the first message requests for mutual authentication between a device, a provider and an authentication server (AS) , and the first message includes a device’s temporary identifier (ID) ; obtaining first information and an indication, where the first information is used for validation of the AS and the indication indicates both the device and the provider are successfully validated by the AS; validating the AS via the first information and validating the indication; and generating a shared key used between the device and a network according to the first information in a case that the AS and the indication are successfully validated.

[0028] In an implementation of the fifth aspect, the first information includes an AS’s certificate or a vector AV.

[0029] In an 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) , where the second message includes the first information and the indication.

[0030] According to a sixth aspect, there is provided a method for authentication, and the method may be performed by a sixth apparatus or a chip installed in the sixth apparatus. The sixth apparatus may be a provider. The method includes: receiving a first message from an initial gateway (GW) , where the first message requests for an authentication of a device and an authentication server (AS) by the provider, and the first message includes first information used for validation of the AS and  an indication associated with a device’s temporary ID and a provider’s ID; validating the AS using the first information and validating the indication; sending a second message to the initial GW, where the second message indicates successful validation of the AS and the indication.

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

[0032] According to a seventh aspect, there is provided a communication apparatus having a function or module to perform the method in the any one of the first aspect to the sixth aspect or any one of the implementations in these aspects.

[0033] According to an eighth aspect, there is provided a chip (or a chip system) . The chip includes at least one processor, the at least one processor is coupled to at least one memory. The at least one memory is configured to store one or more instructions and / or executable computer code. The at least one processor is configured to invoke the one or more instructions and / or executable computer code, so that a communication apparatus installed the chip performs the method in any one of the first aspect to sixth aspect or any one of possible implementations in these aspects. Optionally, the chip may further include the at least one memory. Optionally, the chip may further include a communication interface, and the communication interface is configured to input and / or output information or data.

[0034] According to a ninth aspect, there is provided a communication apparatus. The communication apparatus includes one or more circuits and one or more communication interfaces. The one or more communication interfaces may include a first interface for receiving (that is, inputting) information and / or data that is to be processed by the one or more circuits and a second interface for transmitting (that is, outputting) information and / or data processed by the one or more circuit. The one or more circuits are configured to process the information and / or data that is to be processed so that the communication apparatus performs the method in any one of the first aspect to the sixth aspect or any one of the implementations in these aspects.

[0035] According to a tenth aspect, there is provided a communication system. The communication system may include at least one communication apparatus according to any one of above aspects.

[0036] According to an eleventh aspect, there is provided a computer storage medium that stores executable computer code, and the executable computer code is used to execute one or more instructions for the method according to any one of the above aspects or any possible implementation of these aspects.

[0037] According to a twelfth aspect, there is provided a computer program product including one or more instructions, and when the computer product program runs on a computer, the computer performs the method according to any one of the above aspects or any possible implementation of these aspects.DESCRIPTION OF DRAWINGS

[0038] One or more embodiments are exemplarily described by corresponding accompanying drawings, and these exemplary illustrations and accompanying drawings constitute no limitation on the embodiments. Elements with the same reference numerals in the accompanying drawings are illustrated as similar elements, and the drawings are not limited to scale, in which:

[0039] FIG. 1 is a schematic diagram of an application scenario according to an embodiment of the present application.

[0040] FIG. 2 illustrates an example of a communication system.

[0041] FIG. 3 illustrates another example of an electronic device (ED) and a base station.

[0042] FIG. 4 is an example of a channel model of a MIMO system.

[0043] FIG. 5 is an example of 6G system conceptual structure.

[0044] FIG. 6 is a network scenario according to some embodiments of the present application.

[0045] FIG. 7 is an architecture of mutual authentication according to some embodiments of the present application.

[0046] FIG. 8 is a schematic flow chart of a method for authentication according to some embodiments of the present application.

[0047] FIG. 9 describes a call flow of a procedure on an anonymous and mutual authentication in use case 1.

[0048] FIG. 10 is an example of mutual authentication based on a first architecture according to some embodiments of the present application.

[0049] FIG. 11 is another example of mutual authentication based on a first architecture according to some embodiments of the present application.

[0050] FIG. 12 is another architecture of mutual authentication according to some embodiments of the present application.

[0051] FIG. 13 describes a call flow according to an architecture of mutual authentication in use case 2.

[0052] FIG. 14 is an example of mutual authentication based on a second architecture according to some embodiments of the present application.

[0053] FIG. 15 is another example of mutual authentication based on a second architecture according to some embodiments of the present application.

[0054] FIG. 16 is an example of a call flow of an initial GW to select a serving GW.

[0055] FIG. 17 is a schematic block diagram of a communication apparatus according to some embodiments of the present application.

[0056] FIG. 18 is a schematic block diagram of a communication apparatus according to some embodiments of the present application.DESCRIPTION OF EMBODIMENTS

[0057] In order to understand features and technical contents of embodiments of the present application in detail, implementations of the embodiments of the present application will be described in detail below with reference to the accompanying drawings, and the attached drawings are only for reference and illustration purposes, and are not intended to limit the embodiments of the present applications. In the following technical descriptions, for ease of explanation, numerous details are set forth to provide a thorough understanding of the disclosed embodiments.

[0058] The present application relates generally to wireless communications. Many new trends will trigger the consideration and design of a future wireless network, for example, a 6th generation (6G) wireless network. The 6G wireless communication proposed may meet the following requirements:

[0059] -new network infrastructure capability, e.g., cloud natured / friendly infrastructures that are broadly deployed;

[0060] -new (relative) matured techniques, e.g., artificial intelligence (AI) large scale models, data de-privacy, block chain, etc. that have made significant progresses and significantly impact on the entire society and human life;

[0061] -new apps and services, e.g., AI services, data (sensing) service, digital world service, etc. that are broadly applied in industry / business and used by individual customers;

[0062] -more global / open / collaborative operation trend, i.e., a more open and more collaborative operation mode are becoming common practice in many fields.

[0063] New expectation and stricter requirements on future networks also drive rethinking and development of new generation of wireless networks. These requirements may include:

[0064] -privacy and trustworthiness, etc;

[0065] -simplified standardization;

[0066] -rapid deployment;

[0067] -etc.

[0068] All of the above drives 6G network architecture research work. The proposed 6G network architecture (X-centric) are service-based architectures (SBA) (XaaS service) based and Cloud-native. Requirements to 6G system network architecture design may include:

[0069] -the proposed 6G network architecture needs to support new 6G services which could be developed / deployed by 3rd parties;

[0070] -the proposed 6G network architecture needs to embrace more open ecosystem to open door to technical capable 3rd parties; and

[0071] -the proposed 6G network architecture needs to enable better trustworthiness management.

[0072] A solution to enable above requirements is needed.

[0073] The present application focuses on an anonymous and mutual authentication for a device. The method includes the following steps: (1) A device initial accesses to a network; (2) an initial GW may select a serving GW (aserving GW may be the initial GW) ; (3) The initial GW sends an authentication request to a AS. (4) The AS requests for ID retrieve from an IDM. (5) the AS implements mutual authentication between the device and the network.

[0074] In the present application, the key technique is to provide mutual authentication and anonymous communication since the present application introduces an authentication ID for device authentication and a temporary ID for device communications.

[0075] In 3GPP 33.501, a primary authentication and key agreement procedure is to enable mutual authentication between the UE and the network, and to provide key materials that can be used for indirect derivation keys for security protection on communications between the UE and the network.

[0076] In 3GPP 33.501, the SEAF may initiate an authentication with the UE during any procedure establishing a signaling connection with the UE. The SEAF shall include SUCI in the Nausf_UEAuthentication_Authenticate Request message to AUSF. This SUCI will be de-concealed to gain SUPI by UDM. SUPI will be sent to the SEAF. In 5G, SUPI or SUCI is used in both of authentication and communications. This could bring a risk of ID privacy leakage.

[0077] Separation of an ID profile and a service profile (decouple the functionalities of UDM into two functions of UDM and IDM) , real ID is only known by IDM, auth_ID (which denotes the authentication ID) is known by AS and IDM, and Tem_ID (which denotes the temporary ID) is known by network functions. This could protect ID privacy during authentication.

[0078] We introduce a device’s authentication ID used for authentication by a AS, and a device’s temporary ID used for communications among gateways (GWs) and providers. That could protect ID privacy.

[0079] Anonymous communication

[0080] We decouple SUPI / SUCI into authentication ID and temporary ID with an introduction of the concept of the IDM, this could bring anonymous communications between the device and the network.

[0081] Referring to FIG. 1, as an illustrative example without limitation, a simplified schematic illustration of a communication system is provided. The communication system 100 comprises a radio access network 120. The radio access network 120 may be a next generation (e.g. sixth generation (6G) or later) radio access network, or a legacy (e.g. 5G or 4G, ) radio access network. One or more communication electronic devices (ED) 110a, 110b, 110c, 110d, 110e, 110f, 110g, 110h, 110i, 110j (generically referred to as 110) may be interconnected to one another or connected to one or more network nodes  (170a, 170b, generically referred to as 170) in the radio access network 120. A core network 130 may be a part of the communication system and may be dependent or independent of the radio access technology used in the communication system 100. The communication system 100 also includes a public switched telephone network (PSTN) 140, the internet 150, and other networks 160.

[0082] FIG. 2 illustrates an example communication system 100. In general, the communication system 100 enables multiple wireless or wired elements to communicate 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, groupcast, unicast, etc. The communication system 100 may operate by sharing resources, such as carrier spectrum bandwidth, between its constituent elements. The communication system 100 may include a terrestrial communication system and / or a non-terrestrial communication system. The communication system 100 may provide a wide range of communication services and applications (such as earth monitoring, remote sensing, passive sensing and positioning, navigation and tracking, autonomous delivery and mobility, etc. ) . The communication system 100 may provide a high degree of availability and robustness through a joint operation of a terrestrial communication system and a non-terrestrial communication system. For example, integrating a non-terrestrial communication system (or components thereof) into a terrestrial communication system can result in what may be considered a heterogeneous network comprising multiple layers. Compared to conventional communication networks, the heterogeneous network may achieve better overall performance through efficient multi-link joint operation, more flexible functionality sharing, and faster physical layer link switching between terrestrial networks and non-terrestrial networks.

[0083] The terrestrial communication system and the non-terrestrial communication system could be considered sub-systems of the communication system. In the example shown in FIG. 5, the communication system 100 includes electronic devices (ED) 110a, 110b, 110c, 110d (generically referred to as ED 110) , radio access networks (RANs) 120a, 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. The RANs 120a, 120b include respective base stations (BSs) 170a, 170b, which may be generically referred to as terrestrial transmit and receive points (T-TRPs) 170a, 170b. The non-terrestrial communication network 120c includes an access node 172, which may be generically referred to as a non-terrestrial transmit and receive point (NT-TRP) 172.

[0084] Any ED 110 may be alternatively or additionally configured to interface, access, or communicate with any T-TRP 170a, 170b and NT-TRP 172, the Internet 150, the core network 130, the PSTN 140, the other networks 160, or any combination of the preceding. In some examples, ED 110a may communicate an uplink and / or downlink transmission over a terrestrial air interface 190a with T-TRP 170a. In some examples, the EDs 110a, 110b, 110c, and 110d may also communicate directly with one another via one or more sidelink air interfaces 190b. In some examples, ED 110d may communicate an uplink  and / or downlink transmission over a non-terrestrial air interface 190c with NT-TRP 172.

[0085] The air interfaces 190a and 190b may use similar communication technology, such as any suitable radio access technology. For example, the communication system 100 may implement one or more channel access methods, 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) in the air interfaces 190a and 190b. The air interfaces 190a and 190b may utilize other higher dimension signal spaces, which may involve a combination of orthogonal and / or non-orthogonal dimensions.

[0086] The non-terrestrial air interface 190c can enable communication between the ED 110d and one or multiple NT-TRPs 172 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 between a group of EDs 110 and one or multiple NT-TRPs 172 for multicast transmission.

[0087] The RANs 120a and 120b are in communication with the core network 130 to provide the EDs 110a 110b, and 110c with various services such as voice, data, and other services. The RANs 120a and 120b and / or the core network 130 may be in direct or indirect communication 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 employ the same radio access technology as RAN 120a, RAN 120b or both. The core network 130 may also serve as a gateway access between (i) the RANs 120a and 120b or EDs 110a 110b, and 110c or both, and (ii) other networks (such as the PSTN 140, the Internet 150, and the other networks 160) . In addition, some or all of the EDs 110a 110b, and 110c may include functionality for communicating with different wireless networks over different wireless links using different wireless technologies and / or protocols. Instead of wireless communication (or in addition thereto) , the EDs 110a 110b, and 110c may communicate via wired communication channels to a service provider or switch (not shown) , and to the Internet 150. PSTN 140 may include circuit switched telephone networks for providing plain old telephone service (POTS) . Internet 150 may include a network of computers and subnets (intranets) or both, and incorporate protocols, such as Internet Protocol (IP) , Transmission Control Protocol (TCP) , User Datagram Protocol (UDP) . EDs 110a 110b, and 110c may be multimode devices capable of operation according to multiple radio access technologies, and incorporate multiple transceivers necessary to support such.

[0088] FIG. 3 illustrates another example of an ED 110 and a base station 170a, 170b and / or 170c. The ED 110 is used to connect persons, objects, machines, etc. The ED 110 may be widely used in various scenarios including, for example, cellular communications, 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 twin, industrial control, self-driving, remote medical, smart grid, smart furniture, smart office, smart  wearable, smart transportation, smart city, drones, robots, remote sensing, passive sensing, positioning, navigation and tracking, autonomous delivery and mobility, etc.

[0089] Each ED 110 represents any suitable end user device for wireless operation and may include such devices (or may be referred to) as a user equipment / device (UE) , a wireless transmit / receive unit (WTRU) , a mobile station, a fixed or mobile subscriber unit, a cellular telephone, a station (STA) , a machine type communication (MTC) device, a personal digital assistant (PDA) , a smartphone, a laptop, a computer, a tablet, a wireless sensor, a consumer electronics device, a smart book, a vehicle, a car, a truck, a bus, a train, or an IoT device, wearable devices (such as a watch, a pair of glasses, head mounted equipment, etc. ) , an industrial device, or an apparatus in (e.g. communication module, modem, or chip) or comprising the forgoing devices, among other possibilities. Future generation EDs 110 may be referred to using other terms. The base station 170a and 170b is a T-TRP and will hereafter be referred to as T-TRP 170. Also shown in FIG. 3, a NT-TRP will hereafter be referred to as NT-TRP 172. 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 of more of: connection availability and connection necessity.

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

[0091] The ED 110 includes at least one memory 208. The memory 208 stores instructions and data used, generated, or collected by the ED 110. For example, the memory 208 could store software instructions or modules configured to implement some or all of the functionality and / or embodiments described herein and that are executed by one or more processing unit (s) (e.g., a processor 210) . Each memory 208 includes any suitable volatile and / or non-volatile storage and retrieval device (s) . Any suitable type of memory may be used, such as random access memory (RAM) , read only memory (ROM) , hard disk, optical disc, subscriber identity module (SIM) card, memory stick, secure digital (SD) memory card, on-processor cache, and the like.

[0092] The ED 110 may further include one or more input / output devices (not shown) or interfaces (such as a wired interface to the Internet 150 in FIG. 1) . The input / output devices or interfaces permit interaction with a user or other devices in the network. Each input / output device or interface includes any suitable structure for providing information to or receiving information from a user, and / or for network interface communications. Suitable structures include, for example, a speaker,  microphone, keypad, keyboard, display, touch screen, etc.

[0093] The ED 110 includes the processor 210 for performing operations including those operations related to preparing a transmission for uplink transmission to the NT-TRP 172 and / or the T-TRP 170; those operations related to processing downlink transmissions received from the NT-TRP 172 and / or the T-TRP 170; and those operations related to processing sidelink transmission to and from another ED 110. Processing operations related to preparing a transmission for uplink transmission may include operations such as encoding, modulating, transmit beamforming, and generating symbols for transmission. Processing operations related to processing downlink transmissions may include operations such as receive beamforming, demodulating and decoding received symbols. Depending upon the embodiment, a downlink transmission may be received by the receiver 203, possibly using receive beamforming, and the processor 210 may extract signaling from the downlink transmission (e.g. by detecting and / or decoding the signaling) . An example of signaling may be a reference signal transmitted by the NT-TRP 172 and / or by the T-TRP 170. In some embodiments, the processor 210 implements the transmit beamforming and / or the receive beamforming based on the indication of beam direction, e.g. beam angle information (BAI) , received from the T-TRP 170. In some embodiments, the processor 210 may perform operations relating to network access (e.g. initial access) and / or downlink synchronization, such as operations relating to detecting a synchronization sequence, decoding and obtaining the system information, etc. In some embodiments, the processor 210 may perform channel estimation, e.g. using a reference signal received from the NT-TRP 172 and / or from the T-TRP 170.

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

[0095] The processor 210, the processing components of the transmitter 201, and the processing components of the receiver 203 may each be implemented by the same or different one or more processors that are configured to execute instructions stored in a memory (e.g. in the memory 208) . Alternatively, some or all of the processor 210, the processing components of the transmitter 201, and the processing components of the receiver 203 may each be implemented using dedicated circuitry, such as a programmed field-programmable gate array (FPGA) , an application-specific integrated circuit (ASIC) , or a hardware accelerator such as a graphics processing unit (GPU) or an artificial intelligence (AI) accelerator.

[0096] The T-TRP 170 may be known by other names in some implementations, such as a base station, a base transceiver station (BTS) , a radio base station, a network node, a network device, a device on the network side, a transmit / receive node, a Node B, an evolved NodeB (eNodeB or eNB) , a Home eNodeB, a next Generation NodeB (gNB) , a transmission point (TP) , a site controller, an access point (AP) , a wireless router, a relay station, a terrestrial node, a terrestrial network device, a terrestrial base station, a base band unit (BBU) , a remote radio unit (RRU) , an active antenna unit (AAU) , a remote radio head (RRH) , a central unit (CU) , a distributed unit (DU) , a positioning node, among other possibilities. The T- TRP 170 may be a macro BS, a pico BS, a relay node, a donor node, or the like, or combinations thereof. The T-TRP 170 may refer to the forgoing devices or refer to apparatus (e.g. a communication module, a modem, or a chip) in the forgoing devices.

[0097] In some embodiments, the parts of the T-TRP 170 may be distributed. For example, some of the modules of the T-TRP 170 may be located remote from the equipment that houses the antennas 256 for the T-TRP 170, and may be coupled to the equipment that houses the antennas 256 over a communication link (not shown) sometimes known as front haul, such as 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 the ED 110, resource allocation (scheduling) , message generation, and encoding / decoding, and that are not necessarily part of the equipment that houses the antennas 256 of the T-TRP 170. The modules may also be coupled to other T-TRPs. In some embodiments, the T-TRP 170 may actually be a plurality of T-TRPs that are operating together to serve the ED 110, e.g. through the use of coordinated multipoint transmissions.

[0098] The 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 illustrated to avoid congestion in the drawing. One, some, or all of the antennas 256 may alternatively be panels. The transmitter 252 and the receiver 254 may be integrated as a transceiver. The T-TRP 170 further includes a processor 260 for performing operations including those related to: preparing a transmission for downlink transmission to the ED 110, processing an uplink transmission received from the ED 110, preparing a transmission for backhaul transmission to the NT-TRP 172, and processing a transmission received over backhaul from the NT-TRP 172. Processing operations related to preparing a transmission for downlink or backhaul transmission may include operations such as encoding, modulating, precoding (e.g. multiple input multiple output (MIMO) precoding) , transmit beamforming, and generating symbols for transmission. Processing operations related to processing received transmissions in the uplink or over backhaul may include operations such as receive beamforming, demodulating received symbols, and decoding received symbols. The processor 260 may also perform operations relating to network access (e.g. initial access) and / or downlink synchronization, such as generating the content of synchronization signal blocks (SSBs) , generating the system information, etc. In some embodiments, the processor 260 also generates an indication of beam direction, e.g. BAI, which may be scheduled for transmission by a scheduler 253. The processor 260 performs other network-side processing operations described herein, such as determining the location of the ED 110, determining where to deploy the NT-TRP 172, etc. In some embodiments, the processor 260 may generate signaling, e.g. to configure one or more parameters of the ED 110 and / or one or more parameters of the NT-TRP 172. Any signaling generated by the processor 260 is sent by the transmitter 252. Note that “signaling” , as used herein, may alternatively be called control signaling. Signaling may be transmitted in a physical layer control channel, e.g. a physical downlink control channel (PDCCH) , in which case the signaling may be known as dynamic signaling. Signaling transmitted in a downlink  physical layer control channel may be known as Downlink Control Information (DCI) . Siganling transmitted in an uplink physical layer control channel may be known as Uplink Control Information (UCI) . Signaling transmitted in a sidelink physical layer control channel may be known as Sidelink Control Information (SCI) . Signaling may be included in a higher-layer (e.g., higher than physical layer) packet transmitted in a physical layer data channel, e.g. in a physical downlink shared channel (PDSCH) , in which case the signaling may be known as higher-layer signaling, static signaling, or semi-static signaling. Higher-layer signaling may also refer to Radio Resource Control (RRC) protocol signaling or Media Access Control –Control Element (MAC-CE) signaling.

[0099] The scheduler 253 may be coupled to the processor 260. The scheduler 253 may be included within or operated separately from the T-TRP 170. The scheduler 253 may schedule uplink, downlink, sidelink, and / or backhaul transmissions, including issuing scheduling grants and / or configuring scheduling-free (e.g., “configured grant” ) resources. The T-TRP 170 further includes a memory 258 for storing information and data. The memory 258 stores instructions and data used, generated, or collected by the T-TRP 170. For example, the memory 258 could store software instructions or modules configured to implement some or all of the functionality and / or embodiments described herein and that are executed by the processor 260.

[0100] Although not illustrated, the processor 260 may form part of the transmitter 252 and / or part of the receiver 254. Also, although not illustrated, the processor 260 may implement the scheduler 253. Although not illustrated, the memory 258 may form part of the processor 260.

[0101] The processor 260, the scheduler 253, the processing components of the transmitter 252, and the processing components of the receiver 254 may each be implemented by the same or different one or more processors that are configured to execute instructions stored in a memory, e.g. in the memory 258. Alternatively, some or all of the processor 260, the scheduler 253, the processing components of the transmitter 252, and the processing components of the receiver 254 may be implemented using dedicated circuitry, such as a programmed FPGA, a hardware accelerator (e.g., a GPU or AI accelerator) , or an ASIC.

[0102] Although the NT-TRP 172 is illustrated as a drone only as an example, the NT-TRP 172 may be implemented in any suitable non-terrestrial form, such as satellites and high altitude platforms, including international mobile telecommunication base stations and unmanned aerial vehicles, for example. Also, 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 illustrated to avoid congestion in the drawing. One, some, or all of the antennas may alternatively be panels. The transmitter 272 and the receiver 274 may be integrated as a transceiver. The NT-TRP 172 further includes a processor 276 for performing operations including those related to: preparing a transmission for downlink transmission to the ED 110, processing an uplink transmission received from the ED 110, preparing a transmission for backhaul transmission to T-TRP 170, and processing a  transmission received over backhaul from the T-TRP 170. Processing operations related to preparing a transmission for downlink or backhaul transmission may include operations such as encoding, modulating, precoding (e.g. MIMO precoding) , transmit beamforming, and generating symbols for transmission. Processing operations related to processing received transmissions in the uplink or over backhaul may include operations such as receive beamforming, demodulating received symbols, and decoding received symbols. In some embodiments, the processor 276 implements the transmit beamforming and / or receive beamforming based on beam direction information (e.g. BAI) received from the T-TRP 170. In some embodiments, the processor 276 may generate signaling, e.g. to configure one or more parameters of the ED 110. In some embodiments, the NT-TRP 172 implements physical layer processing, but does not implement higher layer functions such as functions at the medium access control (MAC) or radio link control (RLC) layer. As this is only an example, more generally, the NT-TRP 172 may implement higher layer functions in addition to physical layer processing.

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

[0104] The processor 276, the processing components of the transmitter 272, and the processing components of the receiver 274 may each be implemented by the same or different one or more processors that are configured to execute instructions stored in a memory, e.g. in the memory 278. Alternatively, some or all of the processor 276, the processing components of the transmitter 272, and the processing components of the receiver 274 may be implemented using dedicated circuitry, such as a programmed FPGA, a hardware accelerator (e.g., a GPU or AI accelerator) , or an ASIC. In some embodiments, the NT-TRP 172 may actually be a plurality of NT-TRPs that are operating together to serve the ED 110, e.g. through coordinated multipoint transmissions.

[0105] The T-TRP 170, the NT-TRP 172, and / or the ED 110 may include other components, but these have been omitted for the sake of clarity.

[0106] One or more steps of the embodiment methods provided herein may be performed by corresponding units or modules, according to FIG. 4. FIG. 4 illustrates units or modules in a device, such as in the ED 110, in the T-TRP 170, or in the NT-TRP 172. For example, a signal may be transmitted by a transmitting unit or by a transmitting module. A signal may be received by a receiving unit or by a receiving module. A signal may be processed by a processing unit or a processing module. Other steps may be performed by an artificial intelligence (AI) or machine learning (ML) module. The respective units or modules may be implemented using hardware, one or more components or devices that execute software, or a combination thereof. For instance, one or more of the units or modules may be a circuit such as an integrated circuit. Examples of an integrated circuit includes a programmed FPGA, a GPU, or an ASIC. For instance, one or more of the units or modules may  be logical such as a logical function performed by a circuit, by a portion of an integrated circuit, or by software instructions executed by a processor. It will be appreciated that where the modules are implemented using software for execution by a processor for example, the modules may be retrieved by a processor, in whole or part as needed, individually or together for processing, in single or multiple instances, and that the modules themselves may include instructions for further deployment and instantiation.

[0107] Additional details regarding the EDs 110, the T-TRP 170, and the NT-TRP 172 are known to those of skill in the art. As such, these details are omitted here.

[0108] The solution described in the present application is applicable to a next generation (e.g. sixth generation (6G) or later) network, or a legacy (e.g. 5G or 4G) network.

[0109] The proposed 6G system architecture is defined to support 6G XaaS services by using techniques such as network function virtualization and network slicing. The 6G system architecture utilizes service-based interactions between 6G services.

[0110] The 6G system leverages service-based architecture and XaaS concept. XaaS services in the 6G system are categorized into three layers. The 6G system conceptual structure is shown in FIG. 5.

[0111] Infrastructure Layer includes infrastructures supporting 6G services. Among them are wireless networks infrastructures (for example, RAN, CN) , cloud / data center infrastructures, satellite networks, storage / database infrastructures, and sensing networks, and etc. These infrastructures can be provided by a single provider or by multiple providers.

[0112] Each of the infrastructures could have its control and management functions, denoted as control and management (C / M) functions, for infrastructure management. Each of these infrastructures is one type of infrastructure as a service.

[0113] The C  / M layer includes control and management services of the 6G system. They are developed and deployed by using slicing techniques and utilizing resource provided by infrastructure layer. The 6G services in the C / M layer may include:

[0114] -resource management (RM) as a service provides a capability of life-cycle management of a variety of slices and over-the-air resource assignment to wireless devices;

[0115] -a 6G mission is defined as a service provided to customers by the 6G system. A mission can be a type of services which is provided by a single 6G XaaS service or a type of services that needs contributions from multiple XaaS services.

[0116] -mission management (MM) as a service provides a capability to program provisioning of XaaS services at service layer to provide mission services.

[0117] -confederation network (CONET) as a Service provides a capability to enable multiple partners jointly provide 6G services. This capability is provided by confederation formation, mutual authentication, mutual authorization among partners and negotiation of agreement on recording and retracing of selected actions performed by partners, in order to assure a trustworthy environment of 6G system operations.

[0118] -service provisioning management (SPM) as a service provides a capability of control and management of 6G service access by customers and provisioning of requested services. The capability is provided by unified mutual authentication, authorization and policy, key management, quality of service (QoS) assurance and charging between any pair of XaaS service provider and customer. The customers include end-customers not only in physical world, but also digital representatives in digital world.

[0119] -connectivity management (CM) as a service leverages 5G connectivity management functions, but with extension to include digital world.

[0120] -protocol as a service provides a capability to design service customized protocol stacks for identified interfaces.

[0121] -the protocol stacks could be pre-defined for on-demand selection, or could be on-demand designed.

[0122] -network security as a service provides a capability for owners of infrastructures to detect potential security risks of their infrastructures.

[0123] -XaaS services in C / M layer support control and management of the 6G system itself and also provide support to verticals if requested. One example is that RM service can serve RAN for over-the-air resource management and can also provide service to a vertical for the vertical’s over-the-air resource allocation to its end-customers. The XaaS in C / M layer can be deployed by using slicing technique.

[0124] Service layer includes 6G services which provide services to customers. In the 6G system conceptual structure:

[0125] -AI service is denoted as NET4AI as a Service. Artificial Intelligence service provides AI capability to support a variety of AI applications.

[0126] -service of data collection, data sanitization, data analysis and data delivery are denoted as DAM as a service, this service provides a capability of lifecycle management of statistic data, including acquisition, de-privatization, analysis and delivery of data which are information statistic data from any types of sensors, devices, network functions, and etc.

[0127] -service of storage and sharing of data is denoted as NET4 Data as a Service, this service provides a capability to trustworthily storage and share data under the control of owners of data and following recognized authorities’ regulations on control of identified data.

[0128] -service to provide digital world is denoted as NET4DW as a Service, digital world service provides a capability to construct, control and manage digital world. Digital world is defined as digital realization of physical world.

[0129] -6G block chain service is denoted as NET4BC as a Service. 6G connectivity service is denoted as NET4Con as a Service. This service provides a capability to support 6G block chain services.

[0130] -enhanced connectivity service, e.g., network for connectivity (NET4CON) as a service. This service provides a capability to support exchange of messages and data among new 6G services.

[0131] All XaaS services at this Layer are developed and deployed by using resource provided in infrastructure and utilizing Network Function Virtualization and Slicing techniques. The capability of each of 6G services is provided by its control and management functions and service specific data process functions.

[0132] In addition to support 6G XaaS services at service layer, 6G system leverages 5G System for provisioning of vertical services. The difference between 6G XaaS services and other verticals are that a vertical is a pure customer which needs other XaaS services to enable its operation, while each of XaaS services provide their capabilities to 6G customers.

[0133] Any pair of XaaS services of the 6G system could also be mutual customer and provider of each other. Some of example are that an infrastructure owner provides its resource to XaaS services in Service Layer and C / M Layer; RM services may need the capabilities provided by NET4AI, DAM and NET4DW for its resource management for vertical slicing; CONET service and NET4Data service may need the capability provided by NET4BC for their operation.

[0134] The key concepts of 6G system may include:

[0135] -define basic XaaS services by decoupling comprehensive types of services into basic XaaS services. A basic XaaS service provides unique capability to enable a specific type of service, such as NET4AI service, NET4DW service, DAM service, NET4Data service, Block chain service, mission management service, etc.

[0136] -allow joint operation of the 6G system by multiple partners.

[0137] -define data plane of the 6g system which includes processing functions of data plane of XaaS services. Programing the interconnection of these functions, by mission management service, enables to support a variety of customized customer services.

[0138] -simplify 6G system architecture by categorizing basic control services and management services and combining them as basic XaaS services in Control and Management (C / M) Layer.

[0139] -define C / M plane of the 6G system which includes C / M functions in XaaS services and may include 5G CP (e.g., AMF) depending on implementation options.

[0140] -define a basic architecture structure (BAS) which is a unified basic structure with minimized number of interfaces and is independent of types of infrastructures.

[0141] -simplify standardization, development and deployment of the 6G system using the BAS concept, while supporting a variety of infrastructure deployment scenarios.

[0142] -adapt to a variety of deployment scenarios by applying the BAS or a subset of it to infrastructures based on capability, capacity and requirement of the infrastructure networks.

[0143] -leverage SBI interface concept and apply SBI interaction in both 6G C / M plane and 6G data plane.

[0144] -simplify SBI interfaces by introducing trustworthy GWs in data plane and C / M plane of the 6G system.

[0145] -improve trustworthiness from perspectives of operation of the 6G system by introducing CONET capability, NET4BC capability and anonymous service provisioning provided by the trustworthy GWs in the C / M plane and data plane of the 6G system.

[0146] -improve trustworthiness from perspective of end customer privacy protection by unified mutual authentication, IDM, data sanitization and etc. provided by SPM service, DAM service and 6G block chain service.

[0147] -simplify roaming management of wireless devices, in physical world and digital world, by unified authentication including all participated partners and customers.

[0148] -support multiple development paths from 5G System to 6G system by defining multiple architecture options without incurring much efforts due to the introduction of the BAS concept.

[0149] -support backward compatibility by utilizing benefits of SBA and its add-on feature. 5G users can use the 6g system to access 5G services.

[0150] -support future extension by adding new XaaS services with minimized impact on standardization and deployment, due to the introduced anonymous service provisioning concept implemented in trustworthy GWs in 6G C / M plane and in 6G data plane.

[0151] Related technologies and concepts are introduced here firstly in order to have a better understanding of technical solutions proposed by the present application.

[0152] As stated above, currently, in the 3rd generation partnership project (3GPP) 33.501, a subscription concealed identifier (SUCI) is included in a request from the device, and can be de-concealed by the IDM function. The IDM function sends a de-concealed SUCI (we call it a subscription permanent identifier (SUPI) ) to the AS for authentication, and indirectly delivers the de-concealed SUCI to the GW for communications. The SUCI or SUPI could leak the device’s ID privacy.

[0153] To solve this problem, the present application provides a system and method for anonymous mutual authentication for a device in a future network.

[0154] FIG. 6 is a network scenario according to some embodiments of the present application. Both an initial gateway (GW) and a serving GW are responsible for connection between a device and network functions (NFs) . The initial GW and the  serving GW may be one function, the initial GW has a capability to select a serving GW. An authentication server (AS) is responsible for authentication of a device and / or a provider. An identifier management (IDM) is responsible for ID management.

[0155] In the present application, there are the following assumptions:

[0156] (1) Multiple un-trust providers join a network, and they need to be authenticated by the AS. When a device accesses the network or accesses services, there is mutual authentication between the device and the network (for example, the AS, providers, etc. ) .

[0157] (2) The IDM function is trusted and keeps a device’s real ID and the device’s certificate.

[0158] (3) The AS or providers register with a certificate authority (CA) , and obtain their certificates. The IDM function, on behalf of a device, registers with a CA and obtains the device’s certificate.

[0159] (4) The AS is curious about the device’s real ID, and providers are curious about the device’s real ID.

[0160] In the embodiments of the present application, the following two use cases are considered:

[0161] Use case 1: mutual authentication between the device and the network.

[0162] In this use case, assuming that the multiple un-trust providers are mutually authenticated after a deployment. In other words, these providers are trusted by the network when a device accesses to the network.

[0163] Use case 2: mutual authentication among the device, the provider and the AS.

[0164] In this use case, when the device accesses to the network, the device and the provider should be authenticated by the AS. At the same time, the AS should be authenticated by the device and the provider.

[0165] In this scenario (as shown in FIG. 6) , when a device sends an initial access request, the mutual authentication and key agreement shall be implemented. Currently, in 3GPP 33.501, SUCI is included in the request from the device, and can be de-concealed by the IDM. The IDM sends a de-concealed SUCI (we call it as a SUPI) to the AS for authentication, and indirectly deliver the de-concealed SUCI to the GW for communications. This unique SUPI or SUCI could reveal the device’s ID privacy.

[0166] To solve it, we provide a system and methods on an anonymous mutual authentication for device in the future network. the proposed solution could provide an anonymous authentication between a device and a network, and provide security protection on the anonymous authentications. What’s more, the proposed solution could provide ID privacy.

[0167] To reduce overhead of exchanges of security contexts, and to protect ID privacy, the present application proposes a new system and method on anonymous authentication. The basic concepts of the present application are as follows.

[0168] (1) Authentication ID

[0169] In order to protect ID privacy, the present application introduces a device’s authentication ID used for identification / authentication on the device by an AS, and a device’s temporary ID used for anonymous communications among  the device, GWs and the providers. In embodiments of the present application, only the AS and the IDM know the authentication ID. Thus, the authentication ID and the temporary ID are decoupled and the temporary ID cannot be linked to the authentication ID. This could protect the device’s ID privacy.

[0170] (2) If there is more than one un-trusted provider, the AS needs to authenticate these providers and the device. What is more, these providers need to authenticate the device and the AS, that is, mutual authentication among the device, the provider and the AS.

[0171] In addition, in embodiments of the present application, basic concepts of anonymous authentication are proposed as follows:

[0172] 1) Separate functionalities of UDM into two functions, such as UDM and IDM, where IDM is responsible for ID managements and maintaining / storing ID certificates; UDM is responsible for managements of service information (e.g. name of a serving GW, name of a serving provider) ; and

[0173] 2) An authentication ID (to be simple, we use Auth_ID to replace authentication ID) is proposed for authenticating the device, and a temporary ID (to be simple, we use Tem_ID to replace temporary ID) is used for communications between the device and the network. The device’s real ID is kept in the IDM. AS and providers have no any knowledge of the real ID. Providers have no any knowledge of the Auth_ID. Only IDM has a mapping table of the above IDs.

[0174] According to the basic concepts, we provide an architecture of anonymous and mutual authentication for device in the following figure. In this figure, Key Management Function (KMF) may not be deployed into the system. A device sends an authentication request to an initial GW when the device initially accesses to a network. The initial GW may select a serving GW based to the device’s location, or other information (e.g., service provider’s location, or infrastructure provider’s location) . The initial GW forwards this request to a AS. The AS requests for ID retrieves from an IDM. There is mutual authentication between the device and the network. After a successful mutual authentication, a shared key shall be negotiated between the device and the AS. This shared key may be sent to a KMF for derivation for terminal keys. Without the KMF, the shared key is kept in the AS.

[0175] The main functionalities of network functions are as followers:

[0176] 1) IDM:

[0177] -maintain / store IDs.

[0178] -generate an authentication ID and requests for a device’s certificate using the authentication ID from a CA on behalf of the device.

[0179] -ID mapping.

[0180] 2) UDM:

[0181] -store a device’s service profile.

[0182] 3) Authentication Server:

[0183] -authenticate a device and provider (s) .

[0184] 4) Initial GW:

[0185] -forward messages.

[0186] -select a serving GW.

[0187] 4) Key Management:

[0188] -maintain an extended master session key (which is called EMSK) .

[0189] FIG. 7 is an architecture of mutual authentication according to some embodiments of the present application. In FIG. 7, a device sends an authentication request to an initial GW when the device is initially accessed to a network. The initial GW may select a serving GW based on the device’s location, or other information, for example, a service provider’s location or an infrastructure provider’s location. The initial GW forwards the authentication request to an AS. The AS requests ID retrieves from an IDM function. There is mutual authentication between the device and the network. After successful mutual authentication, a shared key shall be negotiated between the device and the network. The shared key may be sent to a key management function (KMF) for derivation for terminal keys. The KMF may not be deployed into the system. In this case, the shared key is stored in the AS.

[0190] In FIG. 7, The IDM function is responsible for maintaining IDs, generating an authentication ID and requesting a device’s certificate using the authentication ID from a CA on behalf of the device, and ID mapping. The UDM function is responsible for keeping a device’s service profile. For example, a name of the serving GW, a name of the provider, and so on. The authentication server (AS) is responsible for authenticating a device and providers. The Initial GW is responsible for forwarding messages and selecting a serving GW. The KMF is responsible for maintaining the shared key that is called an extended master session key (EMSK) in the embodiments of the present application. The provider may be an infrastructure provider or a service provider, which is not limited.

[0191] FIG. 8 is a schematic flow chart of a method 300 for authentication according to an embodiment of the present application. The method 300 may be implemented by an IDM function or a circuit installed in the IDM function. The IDM function is taken as an example in the following embodiments.

[0192] At step 310, an IDM function receives a first message from an AS.

[0193] The first message may include a device’s temporary ID that is used for communication between the device and the network.

[0194] At step 320, the IDM sends a second message to the AS.

[0195] The second message may include an authentication ID corresponding to the temporary ID. The second message further includes a device’s certificate or an authentication vector (AV) . The authentication ID corresponds to the device’s certificate or the AV, and the device’s certificate or the AV is used for mutual authentication between the device and the network.

[0196] The method may further include step 330.

[0197] At step 330, the IDM function determines an authentication ID, and further determines a device’s certificate corresponding to the authentication ID or an AV corresponding to the authentication ID.

[0198] 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 according to the device’s temporary ID, and then determines the authentication ID according to the device’s real ID. The device’s real ID is a unique ID of the device and is only known by the IDM function. Therefore, the authentication ID and the device’s temporary ID can’t be directly derived from each other. The authentication ID is used for identification / authentication on the device.

[0199] In an embodiment, the IDM function, on behalf of the device, registers the device with the CA, and obtains a device’s certificate from the CA. In this embodiment, the IDM function determines the device’s certificate corresponding to the authentication ID after determining the authentication ID. In another embodiment, the IDM may compute an AV according to the authentication ID. Therefore, the mutual authentication between the device and the network can be implemented based on the device’s certificate or the AV in embodiments of the present application.

[0200] The solution proposed by the present application can protect ID privacy by introducing the authentication ID. The authentication ID is obtained according to the device’s real ID that is stored in the IDM function and only known by the IDM function and the AS. The device’s temporary ID is used for anonymous communication between the device and the network. Thus, the network functions (e.g. GWs) have no knowledge of the authentication ID.

[0201] The mutual authentication in use case 1 and use case 2 are elaborated separately in following embodiments.

[0202] Mutual authentication in use case1

[0203] The following FIG. 9 addresses the mutual authentication method in the use case1. In this use case1, it is assumed that all providers are already authenticated each other before a device initially accesses to the network. The purpose of this embodiment is to provide mutual authentication between a device and a network.

[0204] FIG. 9 describes a call flow of a procedure on an anonymous and mutual authentication in use case 1. In this figure, a KMF is not included in the system. The results of the procedure are that both of a device and an AS has negotiated a shared key (we call it as an EMSK) . This EMSK is kept in the AS. If a KMF is included in the system, the EMSK will be sent to the KMF. Details of the FIG. 8 are as followers:

[0205] (1) A device sends a message1 to an initial GW.

[0206] (2) The initial GW selects a serving GW. How to select a serving GW is addressed in the embodiment3.

[0207] (3) The initial GW sends a message3 to a AS.

[0208] (4) The AS sends a message4 to an IDM

[0209] (5) The IDM implements the following actions:

[0210] -mapping Tem_ID to an Auth_ID.

[0211] -querying for a certificate corresponding to the Auth_ID.

[0212] -selecting an authentication method. Note that, the present application supports two authentication methods, one is EAP-TLS and another is EAP-AKA’. The details about EAP-TLS and EAP-AKA’ can be seen 33.501.

[0213] (6) The IDM sends a message6 to the AS.

[0214] (7) The AS implements the following actions:

[0215] -Validation the device’s certificate. If the validation of the device fails, the AS shall consider the authentication as failed, and indicate a failure to the initial GW.

[0216] -Upon a successful authentication, the AS shall generate a vector AV, when the selected authentication method is EAP-AKA’. How to generate a vector AV is similar to the technique of the 5G vector AV in 3GPP 33.501.

[0217] (8) The AS sends a message8 to the initial GW.

[0218] (9) The initial GW sends a message9 to the device.

[0219] (10) The device validates the AS via the AS’s certificate or the vector AV. If the validation of the AS fails, the device shall consider the authentication as failed, and indicate a failure to the AS. Else, the device generates an EMSK based on the AS’s certificate or the vector AV.

[0220] (11) The device sends a message11 to the initial GW.

[0221] (12) The initial GW sends a message12 to the AS.

[0222] (13) The AS generates an EMSK based on the AS’s certificate or the vector AV.

[0223] (14) The AS sends a message14 to a UDM.

[0224] (15) The AS sends a message15 to the device via the initial GW.

[0225] This embodiment provides a call flow of a procedure on anonymous and mutual authentication corresponding to the Figure 7. Compared to prior arts (e.g., 3GPP 33.501) , the AS generates a vector AV instead of the IDM (in 3GPP, 33.501, UDM generates the vector AV. ) . In addition, the device’s certificate is kept in the IDM. That means, the AS requests for the device’s certificate from the IDM instead of the device’s certificate from the device. These differences enable the IDM to have new features of ID mapping and maintaining the device’s certificate. These new features could bring some benefits, e.g., ID privacy protection, anonymous communications between a device and the network.

[0226] FIG. 10 is an example of mutual authentication based on a first architecture according to some embodiments of the present application.

[0227] At step 401, a device sends a message 1 to an initial GW.

[0228] The message 1 may be a first authentication request, and the message 1 includes a device’s temporary ID. The message 1 corresponds to a message 1 in FIG. 9.

[0229] At step 402, the initial GW selects a serving GW.

[0230] How to select the serving GW is addressed in the flowing embodiments. The step 402 corresponds to a step 2 in FIG. 9.

[0231] At step 403, the initial GW sends a message 2 to an AS.

[0232] The message 2 may be a second authentication request, and the message 2 includes the device’s temporary ID, and a name of the serving GW. The message 2 corresponds to a message 3 in FIG. 9.

[0233] At step 404, the AS sends a message 3 to an IDM function.

[0234] The message 3 may be an authentication_get_request, and the message 3 includes the device’s temporary ID. The message 3 corresponds to a message 4 in FIG. 9.

[0235] At step 405, the IDM function determines an authentication ID corresponding to the temporary ID, and further determines a device’s certificate corresponding to the authentication ID. How to determine the authentication ID and how to obtain the device’s certificate can refer to the description of the steps 320～330, which is not repeated. The step 405 corresponds to a step 5 in FIG. 9.

[0236] Further, the IDM selects an authentication method. The present application supports at least two authentication methods that include extensible authentication protocol-transport level security (EAP-TLS) and enhanced authentication and key agreement prime (EAP-AKA’) . The details about the EAP-TLS and EAP-AKA’ can be seen in 3GPP 33.501.

[0237] At step 406, the IDM function sends a message 4 to the AS.

[0238] The message 4 may be an authentication_get_response, and the message 4 includes the device’s certificate, the authentication ID and the selected authentication method. The message 4 corresponds to a message 6 in FIG. 9.

[0239] At step 407, the AS validates the device.

[0240] The AS validates the device via the device’s certificate and the authentication ID. Specifically, the AS calculates a device’s certificate using the authentication ID and the selected authentication method. Then, the AS validates the device by comparing the device’s certificate, i.e., a received device’s certificate from the IDM function, and the calculated device’s certificate. If the calculated device’s certificate and the received device’s certificate are the same, the validation of the device is successful. Otherwise, the validation of the device fails. If the validation of the device fails, the AS shall consider the  authentication as failed, and indicate a failure to the initial GW. Upon successful authentication, the following steps are implemented. The step 407 corresponds to a step 7 in FIG. 9.

[0241] At step 408, the AS sends a message 5 to the initial GW.

[0242] The message 5 may be a third authentication request, and the message 5 includes an AS’ certificate. The AS’s certificate is obtained by the AS itself by registering itself to the CA. The message 5 corresponds to a message 8 in FIG. 9.

[0243] At step 409, the initial GW sends a message 6 to the device.

[0244] The message 6 may be a fourth authentication request, and the message 6 includes the AS’ certificate. The message 6 corresponds to a message 9 in FIG. 9.

[0245] At step 410, the device validates the AS, and generates an EMSK in a case that the validation of the AS is successful.

[0246] The device validates the AS via the AS’s certificate. Specifically, the device calculates an AS’s certificate, and validates the device by comparing a calculated AS’s certificate and a received one included in the message 6. If the validation of the AS fails, the device shall consider the authentication as failed, and indicate a failure to the AS. Otherwise, the device generates a shared key used between the device and the network that is called the EMSK based on the AS’s certificate. The step 410 corresponds to a step 10 in FIG. 9.

[0247] At step 411, the device sends a message 7 to the initial GW.

[0248] The message 7 may be an authentication response corresponding to the fourth authentication request. The message 7 indicates successful authentication on the device. The message 7 corresponds to a message 11 in FIG. 9.

[0249] At step 412, the initial GW sends a message 8 to the AS.

[0250] The message 8 may be an authentication response corresponding to the third authentication request. The message 8 indicates the successful authentication on the device. The message 8 corresponds to a message 12 in FIG. 9.

[0251] At step 413, the AS generates the EMSK.

[0252] The EMSK is generated based on the AS’s certificate. Note that, the EMSK generated by the device is the same as the one generated by the AS. The step 413 corresponds to a step 13 in following FIG. 9.

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

[0254] At step 414, the AS sends a message 9 to the UDM function.

[0255] The message 9 may be a serving request update message, and the message 9 includes the name of the serving GW. The step 414 corresponds to a step 14 in FIG. 9.

[0256] At step 415, the AS sends a message 10 to the device via the initial GW.

[0257] The message 10 may be an authentication response, and the message indicates successful mutual authentication. The step 415 corresponds to a step 16 and a step 15 in FIG. 9.

[0258] The embodiment shown in FIG. 10 provides a procedure for anonymous and mutual authentication according to the method proposed by the present application. In this embodiment, the device’s certificate is stored in the IDM function. That is to say, the AS requests for the device’s certificate from the IDM instead of from the device. These differences enable the IDM to have new features of ID mapping and maintaining the device’s certificate. These new features could bring some benefits, for example, device’s ID privacy protection, anonymous communication between the device and the network.

[0259] In the embodiment shown in FIG. 10, the AS validates the device via the device’s certificate using the authentication ID, and the device validates the AS via the AS’s certificate. As stated above, in another embodiment, the mutual authentication between the device and the AS can be implemented based on the AV, which is shown in following figures.

[0260] FIG. 11 is another example of mutual authentication based on a first architecture according to some embodiments of the present application.

[0261] Steps 501～504 are the same as the steps 401～404, therefore, the description of the steps 501～504 can be referred to that of the steps 401～404, which is not repeated here.

[0262] At step 505, the IDM generates an authentication ID corresponding to the device’s temporary ID, and generates an AV according to the authentication ID.

[0263] The AV generated by the IDM function is called a first AV in order to describe the proposed solution clearly. How to generate an AV is similar to the technique of the 5G vector AV in 3GPP 33.501. The first AV may include several elements that are associated with the authentication ID.

[0264] Further, the IDM selects an authentication method. The present application supports at least two authentication methods that include extensible authentication protocol-transport level security (EAP-TLS) and enhanced authentication and key agreement prime (EAP-AKA’) . The details about the EAP-TLS and EAP-AKA’ can be seen in 3GPP 33.501.

[0265] At step 506, the IDM function sends a message 4 to the AS.

[0266] The message 4 may be an authentication_get_response, and the message 4 includes, the first AV, the authentication ID and the selected authentication method.

[0267] At step 507, the AS validates the device.

[0268] The AS validates the device via the first AV using the authentication ID. The validation 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 a one included in the received first AV. If the validation of the device fails, the AS shall consider the authentication as failed, and indicate a failure to the initial GW.

[0269] Upon successful authentication, the AS shall generate a second AV. Actually, 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.

[0270] At step 508, the AS sends a message 5 to the initial GW.

[0271] The message 5 may be a third authentication request, and the message 5 includes the second AV.

[0272] At step 509, the initial GW sends a message 6 to the device.

[0273] The message 6 may be a fourth authentication request, and the message 6 includes the second AV.

[0274] At step 510, the device validates the AS.

[0275] Specifically, the device validates the AS via the second AV. If the validation of the AS fails, the device shall consider the authentication as failed, and indicate a failure to the AS. Otherwise, the device generates a new one, for example, a third AV, and an EMSK. The EMSK is generated based on the second AV or the third AV, which depends on a policy for generating the EMSK. What matters is the device and the AS use the same AV to generate the EMSK.

[0276] At step 511, the device sends a message 7 to the initial GW.

[0277] The message 7 may be an authentication response corresponding to the fourth authentication request. The message 7 indicates an authentication success of the device. The message 7 includes the third AV.

[0278] At step 512, the initial GW sends a message 8 to the AS.

[0279] The message 8 may be an authentication response corresponding to the third authentication request. The message 8 indicates an authentication success of the device. The message 8 includes the third AV. By steps 511～512, the third AV generated by the device is sent to the AS via the initial GW.

[0280] At step 513, the AS generates the EMSK.

[0281] The EMSK is generated based on the second AV or the third AV. Note that, the EMSK generated by the device is the same as the one generated by the AS. As stated 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 devices is based on the second AV, the EMSK generated by the AS is based on the second AV. If the EMSK generated by the devices is based on the third AV, the EMSK generated by the AS is based on the third AV.

[0282] At step 514, the AS sends a message 9 to the UDM function.

[0283] The message 9 may be a serving request update message, and the message 9 includes the name of the serving GW.

[0284] At step 515, the AS sends a message 10 to the device via the initial GW.

[0285] The message 10 may be an authentication response, and the message indicates successful mutual authentication.

[0286] Mutual authentication in use case2

[0287] The following figure addresses an anonymous and mutual authentication method in the use case2. In this use case2, we assume that a provider is not trust. This provider may be an infrastructure provider, or a service provider. The purpose of this embodiment is to provide mutual authentication among a device, a provider and the network. There have two following issues during the mutual authentication procedure: If there have more than one un-trust providers, how does an initial GW select a serving GW? What information should be exchanged during the mutual authentication procedure? Since we use an authentication ID for authentication and a temporary ID for communication, so how does the provider authenticate the device? Does the AS authenticate the device, on behalf of the provider?

[0288] FIG. 12 is another architecture of mutual authentication according to some embodiments of the present application, and FIG. 13 describes a call flow according to the FIG. 12. In FIG. 12, a KMF is not included in the system. The results of the procedure are that both of a device and an AS has negotiated a shared key (we call it as an EMSK) . This EMSK is stored in the AS. If a KMF is included in the system, the EMSK will be sent to the KMF.

[0289] Details of the FIG. 13 are as followers:

[0290] (1) A device sends a message1 to an initial GW.

[0291] (2) The initial GW selects a serving GW. How to select a serving GW is addressed in the Figure 11.

[0292] (3) The initial GW sends a message3 to a AS.

[0293] (4) The AS implements a procedure of ID retrieve. How to ID retrieve can be seen steps 4 to 6 in the FIG. 9.

[0294] (5) The AS implements the following actions:

[0295] -Validation the device’s certificate. If the validation of the device fails, the AS shall consider the authentication as failed, and indicate a failure to the initial GW.

[0296] -Validation the provider’s certificate. If the validation of the provider fails, the AS shall indicate a failure of authentication on the provider to the initial GW.

[0297] -Upon a successful authentication, generate an indication that indicates both of the device and the provider are successfully authenticated by the AS. This indication is associated with the device’s Tem_ID, and the provider’s ID.

[0298] -Upon a successful authentication, the AS shall generate a vector AV, when the selected authentication method is EAP-AKA’. How to generate a vector AV is similar to the technique of the 5G vector AV in 3GPP 33.501.

[0299] (6) The AS sends a message6 to the initial GW.

[0300] (7) The initial GW sends a message7 to the provider.

[0301] (8) The provider validates the AS’s certificate via the AS’s certificate. Then, the provider validates the indication. If the validation of the AS fails, the provider shall indicate a failure of authentication on the AS to the initial GW.

[0302] (9) The provider sends a message9 to the initial GW.

[0303] (10) The initial GW sends a message10 to the device.

[0304] (11) The device validates the AS via the AS’s certificate or the vector AV. If the validation of the AS fails, the device shall consider the authentication as failed, and indicate a failure to the AS. The device validates the indication. The device generates an EMSK based on the AS’s certificate or the vector AV.

[0305] (12) The device sends a message12 to the initial GW

[0306] (13) The AS generates an EMSK based on the AS’s certificate or the vector AV.

[0307] (14) The AS sends a message14 to a UDM.

[0308] (15) The AS sends a message15 to the device via the initial GW.

[0309] FIG. 14 is an example of mutual authentication based on a second architecture according to some embodiments of the present application.

[0310] At step 601, a device sends a message 1 to an initial GW. The message 1 includes a device’s temporary ID. The message 1 corresponds to a message 1 in FIG. 13 above.

[0311] At step 602, the initial GW selects a serving GW. The step 602 corresponds to a step 2 in FIG. 13.

[0312] At step 603, the initial GW sends a message 2 to an AS.

[0313] The message 2 includes the device’s temporary ID, a provider’s certificate and a provider’s ID. Further, the message 2 may include a name of the serving GW. The message 2 corresponds to a message 3 in FIG. 13.

[0314] At step 604, the AS implements a procedure of ID retrieval.

[0315] The step 604 can refer to steps 404～406, which will not be described once more. Based on step 604, the AS determines an authentication ID corresponding to the device’s real ID, and further, a device’s certificate corresponding to the authentication ID. Therefore, the AS obtains the authentication ID, the device’s certificate, and the provider’s ID and the provider’s certificate after steps 601～604. The step 604 corresponds to a step 4 in FIG. 13.

[0316] At step 605, the AS validates the device and the provider.

[0317] The step 605 corresponds to a step 5 in FIG. 13. Specifically, the AS validates the device via the device’s certificate and the authentication ID, which can refer to the previous step 407. If the validation of the device fails, the AS shall consider the authentication as failed, and indicate a failure to the initial GW. For example, the AS indicates a failure of authentication on the device to the initial GW.

[0318] In addition, the AS validates the provider via the provider’s certificate. The AS calculates a provider’s certificate, then, the AS validates the provider by comparing a received provider’s certificate from the IDM function and a calculated provider’s certificate. If the calculated provider’s certificate and the received provider’s certificate are the same, the validation of the provider is successful. Otherwise, the validation of the provider fails. If the validation of the provider fails, the AS shall  indicate a failure to the initial GW, for example, the AS indicates a failure of authentication on the provider to the initial GW.

[0319] Upon successful authentication, the AS generates an indication that indicates both the device and the provider are successfully authenticated by the AS. This indication is associated with the device’s temporary ID and the provider’s ID.

[0320] At step 606, the AS sends a message 3 to the initial GW.

[0321] The messages 3 includes the indication and an AS’s certificate. The message 3 corresponds to a message 6 in FIG. 13.

[0322] At step 607, the initial GW sends a message 4 to the provider.

[0323] The message 4 includes the AS’s certificate and the indication. The message 4 corresponds to a message 7 in FIG. 13.

[0324] At step 608, the provider validates the indication and the AS.

[0325] The step 608 corresponds to a step 8 in FIG. 13. The provider validates the AS via the AS’s certificate. Specifically, the provider validates the AS using the received AS’s certificate and a calculated AS’s certificate. In addition, the provider validates the indication. The indication is generated by the AS according to 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 the AS’s information (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 the AS’s information, the provider needs to calculate a new indication according to the AS’s information (e.g. the AS’s ID) and compare the new indication with the received indication. If they are equal, it means the verification of the indication is successful. If the validation of the AS and / or the indication fails, the provider shall indicate a failure of authentication on the AS to the initial GW. Upon successful validation, the provider implements step 609.

[0326] At step 609, the provider sends a message 5 to the initial GW.

[0327] The message 5 indicates successful validation of the device and the AS by the provider. The message 5 corresponds to a message 9 in FIG. 13.

[0328] At step 610, the initial GW sends a message 6 to the device.

[0329] The message 6 includes the AS’s certificate and the indication. The AS’s certificate and the indication are obtained by the initial GW via the message 3 in step 606. The message 6 corresponds to a message 10 in FIG. 13.

[0330] At step 611, the device validates the indication and the AS.

[0331] The step 611 corresponds to a step 11 in FIG. 13.

[0332] Specifically, the device validates the AS via the AS’s certificate, and validates the indication. If the validation of the AS or the indication fails, the device shall consider the authentication as failed, and indicate a failure to the AS. If the  validation of the AS and the indication is successful, the device generates an EMSK based on the AS’s certificate.

[0333] At step 612, the device sends a message 7 to the AS via the initial GW.

[0334] The message 7 indicates validation of the AS by the device and the provider is successful. The message 7 corresponds to a message 12 in FIG. 13.

[0335] At step 613, the AS generates the EMSK.

[0336] The AS generates the EMSK according to the AS’s certificate. The step 613 corresponds to a step 13 in FIG. 13.

[0337] At step 614, the AS sends a message 9 to a UDM function.

[0338] The message 9 includes the name of the serving GW and a name of the provider. The step 614 corresponds to a step 14 in FIG. 13.

[0339] At step 615, the AS sends a message 10 to the device via the initial GW.

[0340] The message 10 indicates successful mutual authentication among the device, the provider and the AS. The step 615 corresponds to a step 15 in FIG. 13.

[0341] This embodiment illustrates how to authenticate a device by a provider with the introduction of the authentication ID. The provider could validate the device indirectly with the help of the AS.

[0342] The mutual authentication among the device, the provider and the AS shown in FIG. 11 is implemented based on certificates, for example, the device’s certificate, the provider’s certificate and the AS’s certificate. It is similar to the embodiments in the use case 1 that the mutual authentication among the device, the provider and the AS can also be achieved using an AV in use case 2.

[0343] FIG. 15 is an example of mutual authentication based on a second architecture according to some embodiments of the present application.

[0344] The description of steps 701～704 in FIG. 15 is similar to that of steps 601～604 in FIG. 14, and a difference between step 701～704 and steps 601～604 is that the AS obtains an AV (we call it a first AV in the following steps) instead of the device’s certificate from the IDM function by the steps 701～704. In some embodiments, the first AV may include one or more elements that are associated with the device ID and the provider ID.

[0345] At step 705, the AS validates the device and the provider.

[0346] Specifically, the AS validates the device via the first AV and the authentication ID, which can refer to the previous step 507. If the validation of the device fails, the AS shall consider the authentication as failed, and indicate a failure to the initial GW. For example, the AS indicates a failure of authentication on the device to the initial GW.

[0347] In addition, the AS validates the provider via the provider’s certificate. The AS calculates a provider’s certificate, then, the AS validates the provider by comparing a received provider’s certificate included in the message 2 and a calculated  provider’s certificate. If the calculated provider’s certificate and the received provider’s certificate are the same, the validation of the provider is successful. Otherwise, the validation of the provider fails. If the validation of the provider fails, the AS shall indicate a failure to the initial GW, for example, the AS indicates a failure of authentication on the provider to the initial GW.

[0348] Upon successful authentication, the AS generates an indication that indicates both the device and the provider are successfully authenticated by the AS. This indication is associated with the device’s temporary ID and the provider’s ID. In addition, the AS generates a second AV based on the first AV.

[0349] At step 706, the AS sends a message 3 to the initial GW.

[0350] The messages 3 includes the indication and the second AV.

[0351] At step 707, the initial GW sends a message 4 to the provider.

[0352] The message 4 includes the second AV and the indication.

[0353] At step 608, the provider validates the indication and the AS.

[0354] The provider validates the AS via the second AV, which can be referred to the previous step 510. In addition, the provider validates the indication. If the validation of the AS or the indication fails, the provider shall indicate a failure of authentication on the AS to the initial GW. Upon successful authentication, the provider generates a third AV according to the second AV, and implements step 709.

[0355] At step 709, the provider sends a message 5 to the initial GW.

[0356] The message 5 indicates successful validation of the device and the AS by the provider. The message 5 includes the third AV.

[0357] At step 710, the initial GW sends a message 6 to the device.

[0358] The message 6 includes the third AV and the indication. The third AV is obtained by the initial GW via step 610 and the indication is via the message 3 in step 706.

[0359] At step 711, the device validates the indication and the AS.

[0360] Specifically, the device validates the AS via the third AV, and validates the indication. If the validation of the AS or the indication fails, the device shall consider the authentication as failed, and indicate a failure to the AS. If the validation of the AS and the indication is successful, the device generates a fourth AV and an EMSK. Similar to the embodiments in the use case 1, the EMSK is generated according to the third AV or the fourth AV in the uses case 2, which depends on a policy for generating the EMSK. What matters is a same AV is used for generating the EMSK by the device and the AS.

[0361] At step 712, the device sends a message 7 to the AS via the initial GW.

[0362] The message 7 indicates validation of the AS by the device and the provider is successful.

[0363] At step 713, the AS generates the EMSK.

[0364] The AS generates the EMSK. As stated in step 711, a same AV is used for generating the EMSK by the AS and the AS.

[0365] At step 714, the AS sends a message 9 to a UDM function.

[0366] The message 9 includes the name of the serving GW and a name of the provider.

[0367] At step 715, the AS sends a message 10 to the device via the initial GW.

[0368] The message 10 indicates successful mutual authentication among the device, the provider and the AS.

[0369] Some embodiments described above involve a procedure of selecting the serving GW implemented by the initial GW.Details of this procedure for selecting the serving GW are given as an example in FIG. 16.

[0370] FIG. 16 illustrates a call flow of an initial GW to select a serving GW.

[0371] At step 801, the initial GW selects a provider. How to select the provider is out of the scope of the present application.

[0372] At step 802, the initial GW sends a message 1 to the selected provider.

[0373] The message 1 may include a device’s ID, for example, a device’s temporary ID, and / or service requirements.

[0374] At step 803, the selected provider sends a message 2 to the initial GW.

[0375] The message 2 may include a provider’s ID and a provider’s certificate.

[0376] At step 804, the initial GW selects a serving GW according to the device’s location and the provider’s location.

[0377] At step 805, the initial GW sends a message 3 to the selected serving GW.

[0378] The message 4 may include the provider’s ID.

[0379] At step 806, the serving GW may send a message 4, which is a response to the message 3, to the initial GW.

[0380] The method proposed in embodiments of the present application is described in detail above, and a communication apparatus provided by the present application will be described in detail below.

[0381] FIG. 17 is a schematic block diagram of a communication apparatus 10 according to some embodiments of the present application. The communication apparatus may be a communication device or an apparatus applied to the communication device and capable of realizing corresponding functions of any one of the network functions in the embodiments of the present application, for example, the apparatus may be a chip, a chip system or a circuit, which is not limited. The communication device may be the IDM function, the AS, the terminal device, the provider, or the chip installed in any one of these network functions.

[0382] The communication apparatus 10 includes a processing module 1001. The processing module 1001 may be a processor, a processing circuit, a processing board, a processing unit, or a processing device, et al. The processing module 1001 is configured to implement processing and / or operations implemented inside the communication apparatus except sending the  receiving actions.

[0383] The communication apparatus 10 may further include a communication module 1002. The communication unit 1002 is configured to implement a sending action and / or a receiving action. The communication module 1002 also may be called as a transceiver module, a transceiver, or a transceiver device, et al, and is configured to implement operations of receiving (which may be referred to as inputting) and / or sending (which may be referred to as outputting) .

[0384] For example, if the communication apparatus 10 corresponds to the IDM in FIG. 8, the communication module 1002 is configured to receive a first message from the AS. The communication module 1002 is further configured to send a second message to the AS. The processing module 1001 is configured to implement the step 320. If the communication apparatus 10 corresponds to the AS in FIG. 8, the communication module 1002 is configured to send a first message to the IDM function, and further receive a second message from the IDM function.

[0385] For example, if the communication apparatus 10 corresponds to the AS in FIG. 10, the communication module 1002 is configured to send the message 3, and receive the message 4. The processing module 1001 is configured to implement a step 407 and a step 413.

[0386] For example, if the communication apparatus 10 corresponds to the device in FIG. 10, the communication module 1002 is configured to send the message 1 or message 7, and further receive the message 6. The processing module 1001 is configured to implement a step 410.

[0387] For example, if the communication apparatus 10 corresponds to the provider in FIG. 14, the communication module 1002 is configured to receive the message 4 from the initial GW, and further sends the message 5. The processing module 1001 is configured to implement a step 608.

[0388] Briefly, the operations and / or functions of the apparatus 10 are intended to implement corresponding steps of the foregoing method embodiments.

[0389] FIG. 18 is a schematic block diagram of a communication apparatus according to some embodiments of the present application. The communication apparatus 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 configured to store one or more instructions and / or executable computer code. The at least one processor 21 is configured to invoke the one or more instructions and / or executable computer code, so that the communication apparatus 20 implements the method provided in the embodiments of the present application. Optionally, the communication apparatus 20 may further include the at least one memory 22. Optionally, the communication apparatus 20 may further include at least one communication interface 23, and the at least one communication interface 23 is configured to input and / or output information or data.

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

[0391] In another implementation, the communication apparatus 20 may be a chip (or a chip system) installed at a communication device such as the first network function, the IDM function, the second network function or the third network function. In this implementation, the processor 21 may be a circuit, for example, a logic circuit, an integrated circuit, etc. The communication interface 13 may be a transceiver, an interface circuit, an input / output interface, a bus, a module, a pin, or other types of interfaces.

[0392] An embodiment of the present application further provides a communication system. The communication system may include any one of the communication apparatuses according to any one of the method embodiments. For example, the communication system may include one or more of the following network functions: an AS, an IDM a terminal device and provider. The communication system may further include other network functions, for example, a GW, which is not limited.

[0393] An embodiment of the present application further provides a computer storage medium, and the computer storage medium may store one or more instructions for executing any of the foregoing methods.

[0394] An embodiment of the present application further provides a computer program product, and the computer program product may store one or more instructions for executing any of the foregoing methods.

[0395] In the embodiments of this application, “and / or” describes an association relationship between associated objects and represents that three relationships may exist. For example, A and / or B may represent the following three cases: Only A exists, both A and B exist, and only B exists. The character “ / ” generally indicates an “or” relationship between the associated objects. “At least one” means one or more. “At least one of A and B” , similar to “A and / or B” , describes an association relationship between associated objects and represents that three relationships may exist. For example, at least one of A and B may represent the following three cases: Only A exists, both A and B exist, and only B exists.

[0396] Besides, the use of a singular form of “a” , “an” and “the” in the embodiments of the present application and the claims appended hereto is also intended to include a plural form, unless otherwise clearly indicated herein by context.

[0397] A person of ordinary skill in the art will be aware that, in combination with the examples described in the embodiments disclosed in this specification, units and algorithm steps may be implemented by using electronic hardware or a combination of computer software and electronic hardware. Whether the functions are performed by using hardware or software depends on particular applications and design constraint conditions of the technical solutions. A person skilled in the art may use different methods to implement the described functions for each particular application, but it should not be considered that the embodiment goes beyond the scope of this application.

[0398] It would be understood by a person skilled in the art that, for the purpose of convenience and brevity, in a detailed working process of the foregoing system, apparatus, and unit, reference may be made to a corresponding process in the foregoing method embodiments, and details are not described herein again.

[0399] In the several embodiments provided in this application, the disclosed system, apparatus, and method may be implemented in other manners. For example, the described apparatus embodiment is merely an example. For example, the unit division is a logical function division and other methods of division may be used in an actual embodiment. For example, a plurality of units or components may be combined or integrated into another system, or some features may be ignored or not performed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections may be implemented using various communication interfaces. The indirect couplings or communication connections between the apparatuses or units may be implemented in electronic, mechanical, or other forms.

[0400] In addition, function units in the embodiments of this application may be integrated into one processing unit, each of the units may exist alone physically, or two or more units may be integrated into one unit.

[0401] When the functions are implemented in the form of a software functional unit and sold or used as an independent product, the functions may be stored in a computer-readable storage medium. The technical solutions of this application may be implemented in the form of a software product. The software product is stored in a storage medium, and includes several instructions for instructing a computer device (which may be a personal computer, a server, a network device, or the like) to perform all or some of the steps of the methods described in the embodiments of this application. The foregoing storage medium includes any medium that can store program code, such as a USB flash drive, a removable hard disk, a ROM, a RAM, a magnetic disk, an optical disc or the like.

[0402] The units described as separate parts may be or may not be physically separate, and parts displayed as units may be or may not be physical units, may be located in one position, or may be distributed on a plurality of network units. Some or all of the units may be selected based on actual requirements to achieve the objectives of the solutions of the embodiments. In addition, functional units in the embodiments of this application may be integrated into one processing unit, or each of the units may exist alone physically, or two or more units are integrated into one unit.

[0403] The foregoing descriptions are merely specific implementations of this application, but are not intended to limit the protection scope of this application. Any variation or replacement readily figured out by a person skilled in the art within the technical scope disclosed in this application shall fall within the protection scope of this application. Therefore, the protection scope of this application shall be subject to the protection scope of the claims.

Claims

A method for authentication, performed by an identifier management (IDM) function, comprising:receiving a first message, wherein the first message comprises a temporary identifier (ID) of a device, and the temporary ID is used for communication between the device and a network; andsending a second message, wherein the second message comprises an authentication ID corresponding to the temporary ID, the second message further comprises a device’s certificate or an authentication vector (AV) , the authentication ID corresponds to the device’s certificate or the AV, the device’s certificate or the AV is used for mutual authentication between the device and the network, and the authentication ID is used for identification / authentication on the device.The method according to claim 1, wherein the method further comprises:determining a real ID of the device according to the temporary ID; anddetermining the authentication ID according to the real ID.The method according to claim 1 or claim 2, wherein the AV is generated by the IDM function according to the authentication ID.The method according to any one of claims 1 to 3, wherein the device’s certificate is from a certificate authority (CA) .A method for authentication, performed by an authentication server (AS) , comprising:sending a first message to an identifier management (IDM) function, wherein the first message comprises a temporary identifier (ID) of a device, and the temporary ID is used for communication between the device and a network; andreceiving a second message from the IDM function, wherein the second message comprises an authentication ID corresponding to the temporary ID, the second message further comprises a device’s certificate or AV, the authentication ID corresponds to the device’s certificate or the AV, and the device’s certificate or the AV is used for mutual authentication between the device and the network.The method according to claim 5, the first message further comprises a name of a serving gateway (GW) .The method according to claim 5 or 6, wherein the AV comprised in the second message is a first AV, and the method further comprises:validating the device via the device’s certificate or the first AV using the authentication ID; andsending a third message to the device in a case that the validation of the device is successful, wherein the third message comprises an AS’s certificate or a second AV, and the second AV is generated based on the first AV.The method according to any one of claims 5 to 7, wherein the method further comprises:receiving a fourth message indicating successful validation of the AS by the device;generating a shared key used between the device and the network, wherein the shared key is generated according to the AS’s certificate, or the shared key is generated according to the second AV or a third AV, wherein the third AV is from the device.A method for authentication, performed by an authentication server (AS) , comprising:receiving a first message from an initial gateway (GW) , wherein the first message requests for mutual authentication between a device, a provider and the AS, and the first message comprises a device’s temporary identifier (ID) , a provider’s certificate and a provider’s ID;obtaining a device’s certificate and an authentication ID from an identifier management (IDM) function, wherein the device’s certificate corresponds to the authentication identifier (ID) , the authentication ID is determined by the IDM function according to a device’s real ID and the device’s real ID is determined according to the device’s temporary ID;validating the device via the device’s certificate using the authentication ID and validating the provider via the provider’s certificate; andgenerating an indication associated with the device’s temporary ID and the provider’s ID in a case that the validation of the device and the validation of the provider are successful.The method according to claim 9, wherein after generating the indication associated with the device’s temporary ID and the provider’s ID, the method further comprises:sending the indication and first information to the initial GW, wherein the first information is used for validation of the AS by the provider and the device.The method according to claim 9 or 10, wherein the first information comprises an AS’s certificate or an authentication vector (AV) .The method according to claim any one of claims 9 to 11, wherein the method further comprises:generating a shared key used between the device and the AS according to the first information after successful validation of the device and the provider.the method according to any one of claims 9 to 12, wherein the first message further comprises a name of a serving gateway (GW) .A method for authentication, performed by a device, comprising:sending a first message requesting mutual authentication between a device and a network, wherein the first message comprises a device’s temporary identifier (ID) used for communication between the device and the network;validating an authentication server (AS) according to first information of the AS after successful validation of the device by the AS; andgenerating a shared key according to the first information in a case that the validation of the AS is successful.The method according to claim 14, wherein the first information comprises an AS’s certificate or an authentication vector (AV) .A method for authentication, comprising:sending a first message to an initial gateway (GW) , wherein the first message requests mutual authentication between a device, a provider and an authentication server (AS) , and the first message comprises a device’s temporary identifier (ID) ;obtaining first information and an indication, wherein the first information is used for validation of the AS and the indication indicates both the device and the provider are successfully validated by the AS;validating the AS via the first information and validating the indication; andgenerating a shared key used between the device and a network according to the first information in a case that the AS and the indication are successfully validated.The method according to claim 16, wherein the first information comprises an AS’s certificate or a vector AV.The method according to claim 16 or 17, wherein obtaining the first information and the indication, comprises:receiving a second message from the AS via the initial gateway (GW) , wherein the second message comprises the first information and the indication.A method for authentication, performed by a provider, comprising:receiving a first message from an initial gateway (GW) , wherein the first message requests authentication of a device and an authentication server (AS) by the provider, and the first message comprises first information used for validation of the AS and an indication associated with a device’s temporary ID and a provider’s ID;validating the AS using the first information and validating the indication; andsending a second message to the initial GW, wherein the second message indicates successful validation of the AS and the indication.The method according to claim 19, wherein the first information comprises an AS’s certificate or an authentication vector (AV) .A method for authentication, performed in a communication system, wherein the system comprises an identifier management (IDM) function, and an authentication server (AS) ; and the method comprises:receiving, by the AS, a first message, wherein the first message comprises a temporary identifier (ID) of a device, and the temporary ID is used for communication between the device and a network;sending, by the AS, a second message to the IDM function, wherein the second message comprises the temporary ID;receiving, by the IDM, the second message and sending a third message to the IDM function, wherein the third message comprises an authentication ID corresponding to the temporary ID, and the third message further comprises a device’s certificate or an authentication vector (AV) , the authentication ID corresponds to the device’s certificate or the AV, and the device’s certificate or the AV is used for mutual authentication between the device and the network; andvalidating, by the AS the device via the device’s certificate or the AV using the authentication ID.A method for authentication, performed in a communication system, wherein the system comprises an identifier management (IDM) function, a provider, a device, an initial gateway (GW) of the device, and an authentication server (AS) ; and the method comprises:receiving, by the AS, a first message, wherein the first message requests mutual authentication between the device, the provider and the AS, and the first message comprises a device’s temporary identifier (ID) , a provider’s certificate and a provider’s ID;obtaining, by the AS, a device’s certificate and an authentication ID from the IDM function, wherein the device’s certificate corresponds to the authentication identifier (ID) , the authentication ID is determined by the IDM function according to a device’s real ID and the device’s real ID is determined according to the device’s temporary ID;validating, by the AS, the device via the device’s certificate using the authentication ID, validating the provider via the provider’s certificate, and generating an indication associated with the device’s temporary ID and the provider’s ID in a case that validation of the device and the validation of the provider are successful; andsending, by the AS, the indication and first information to the provider, wherein the first information is used for validation of the AS by the provider and the device;validating, by the provider, the AS using the first information and validating the indication;indicating, by the provider, successful validation of the device and the AS by the provider to the initial gateway;sending, by the initial GW, 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; andvalidating, by the device, the indication, and validating the AS according to the first information.A communication apparatus, wherein the communication apparatus comprises a processor, the processor is configured to execute one or more instructions stored in a memory, to enable the communication apparatus to implement the method according to any one of claims 1-4, or any one of claims 5-13, or any one of claims 14-18, or the method according to claim 19 or 20.The communication apparatus according to claim 23, wherein the communication apparatus further comprises the memory.The communication apparatus according to claim 23 or 24, wherein the communication apparatus comprises a communication interface, and the communication interface is configured to input and / or output information or data.A communication apparatus, wherein the communication apparatus comprises a function or unit to perform the method according to any one of claims 1-4, or perform the method according to any one of claims 5-13, or perform the method according to any one of claims 14-18, or perform the method according to the claim 19 or 20.A communication apparatus, wherein the communication apparatus comprises a circuit and a communication interface, the communication interface is configured to receive information and / or data that is to be processed by the circuit, and transmit the information and / or data to the circuit; and the circuit is configured to perform the method according to any one of claims 1-4, or perform the method according to any one of claims 5-13, or perform the method according to any one of claims 14-18, or perform the method according to claim 19 or 20.The communication apparatus according to claim 27, wherein the communication interface is further configured to output information and / or data processed by the circuit.A communication system, comprising one or more communication apparatuses of:a communication apparatus that performs the method according to any one of claims 1-4;a communication apparatus that performs the method according to any one of claims 5-13;a communication apparatus that performs the method according to any one of claims 14-18; anda communication apparatus that performs the method according to claim 19 or 20.A computer readable storage medium, comprising one or more instructions, wherein when the one or more instructions are run on a computer, the computer performs the method according to any one of claims 1-4, or the method according to any one of claims 5-13, or the method according to any one of claims 14-18, or the method according to claim 19 or 20.A computer program product, comprising one or more instructions, wherein when the one or more instructions are run on a computer, the computer performs the method according to any one of claims 1-4, or the method according to any one of claims 5-13, or the method according to any one of claims 14-18, or the method according to claim 19 or 20.

Images