Biometric enabled primary authentication

Abstract

Method comprising: receiving, from a device, a biometric template along with a device identifier; generating a long-term key by a hash function applied to the biometric template; storing the long-term key for a subscription identifier; receiving a request comprising the subscription identifier from an AUSF; retrieving the long-term key based on the subscription identifier; generating a parameter of a challenge and an expected response based on the long- term key; providing the parameter of the challenge and the expected response to the AUSF in response to the request; checking whether an information informing that a authentication response received by the AUSF from the device is the same as the expected response is received from the AUSF; designating the device as authenticated in response to checking that the information informing that the authentication response received by the AUSF from the device is the same as the expected response is received from the AUSF.

Description

[0001] BIOMETRIC ENABLED PRIMARY AUTHENTICATION

[0002] Technical Field

[0003] The present disclosure relates to authentication, in particular in an XR environment.

[0004] Abbreviations

[0005] 3G / 4G / 5G / 6G 3rd / 4th / 5th / 6thGeneration

[0006] 3GPP 3rdGeneration Partnership Project

[0007] 5GC 5G Core Network

[0008] 5G-GUTI 5G Globally Unique Temporary Identifier

[0009] 5G HE 5G Home Environment

[0010] ABBA Anti-Bidding down Between Architectures

[0011] AKA Authentication and Key Agreement

[0012] AKMA Authentication and Key Agreement for Applications

[0013] AMF Access and Mobility Management Function

[0014] ARPF Access Credential Repository and Processing Function

[0015] AUSF Authentication Server Function

[0016] AV Authentication Vector

[0017] DSL Digital Subscriber Line

[0018] EAP AKA Extensible Authentication Protocol - Authentication and Key Agreement

[0019] EAP TLS Extensible Authentication Protocol - Transport Layer Security

[0020] ETSI European Telecommunications Standards Institute

[0021] HW Hardware

[0022] ID Identifier

[0023] IMEI International Mobile Equipment Identity

[0024] ISEF Infinite Symmetrical Exponential Filter

[0025] KDF Key Derivative Function

[0026] LTE Long Term Evolution

[0027] LAN Local Area Network

[0028] ME Mobile Equipment

[0029] N5GC Non-5G Capable

[0030] N5CW Non-5G Capable over WLAN NAS Non Access Stratum ngKSI next generation Key Set Identifier

[0031] SEAF Security Anchor Function

[0032] SIDF Subscription Identifier De-concealing Function

[0033] SN Serving Network

[0034] SNN Serving Network Name

[0035] SUCI Subscription Concealed Identifier

[0036] SUPI Subscription Permanent Identifier

[0037] TEE Trusted Execution Environment

[0038] UDM User Data Management

[0039] UDR User Data Repository

[0040] UE User Equipment

[0041] USIM Universal Subscriber Identity Module

[0042] WLAN Wireless LAN

[0043] WiMAX Worldwide Interoperability for Microwave Access

[0044] XR Extended Reality

[0045] Background

[0046] In the last years, an increasing extension of communication networks, e.g. of wire based communication networks, such as the Integrated Services Digital Network (ISDN), Digital Subscriber Line (DSL), or wireless communication networks, such as the cdma2000 (code division multiple access) system, cellular 3rdgeneration (3G) like the Universal Mobile Telecommunications System (UMTS), fourth generation (4G) communication networks or enhanced communication networks based e.g. on Long Term Evolution (LTE) or Long Term Evolution-Advanced (LTE-A), fifth generation (5G) communication networks, cellular 2ndgeneration (2G) communication networks like the Global System for Mobile communications (GSM), the General Packet Radio System (GPRS), the Enhanced Data Rates for Global Evolution (EDGE), or other wireless communication system, such as the Wireless Local Area Network (WLAN), Bluetooth or Worldwide Interoperability for Microwave Access (WiMAX), took place all over the world. Various organizations, such as the European Telecommunications Standards Institute (ETSI), the 3rdGeneration Partnership Project (3GPP), Telecoms & Internet converged Services & Protocols for Advanced Networks (TISPAN), the International Telecommunication Union (ITU), 3rdGeneration Partnership Project 2 (3GPP2), Internet Engineering Task Force (IETF), the IEEE (Institute of Electrical and Electronics Engineers), the WiMAX Forum and the like are working on standards or specifications for telecommunication network and access environments.

[0047] Summary

[0048] It is an object to improve the prior art.

[0049] According to a first aspect, there is provided an apparatus comprising: at least at least one processor, and at least one memory storing instructions that, when executed by the at least at least one processor, cause the apparatus at least to perform: providing, by a device, a first biometric template of a first user to an authentication function of a network along with a device identifier; storing the first biometric template at the device; generating a first long-term key by a first hash function applied to the first biometric template; storing the first long-term key along with a subscription identifier for the first user at the device; receiving an attempt to register a second user at the device using a second biometric template; checking whether the second biometric template is the same as the first biometric template; retrieving the subscription identifier stored along with the first biometric template in response to checking that the first biometric template is the same as the second biometric template; sending a request comprising the retrieved subscription identifier to the authentication function; receiving a parameter of a challenge from the authentication function in response to the sending the request; generating an authentication response based on the first long-term key and the parameter of the challenge; providing the authentication response in response to the receiving the parameter of the challenge, wherein the request is a registration request or an authentication request. The instructions, when executed by the at least one processor, may further cause the apparatus to perform generating an anchor key based on the first long-term key and the parameter of the challenge; communicating with the network based on the anchor key.

[0050] The instructions, when executed by the at least one processor, may further cause the apparatus to perform providing, by the device, multiple biometric templates of the first user including the first biometric template to the authentication function; generating the first long-term key by the first hash function applied to the multiple biometric templates of the first user.

[0051] The instructions, when executed by the at least one processor, may further cause the apparatus to perform providing, by the device, multiple biometric templates of the first user including the first biometric template to the authentication function; receiving, from the authentication function, an indication that the first long-term key is to be generated based on the first biometric template; generating the first long-term key by the first hash function applied to the first biometric template and not based on the multiple biometric templates of the first user different from the first biometric template.

[0052] The instructions, when executed by the at least one processor, may further cause the apparatus to perform indicating, to the authentication function, plural hash functions including the first hash function the device is capable of; receiving, from the authentication function, an indication that the first hash function is to be used for the generating the first long-term key.

[0053] It may be predefined that the first hash function is to be used for the generating the first longterm key.

[0054] The subscription identifier may be the same as a device identifier predefined for the device. The instructions, when executed by the at least one processor, may further cause the apparatus to perform retrieving a second long-term key from a subscriber identity module on the device, wherein the second long-term key is related to the subscription identifier; the generating the authentication response based on the first long-term key, the second long-term key, and the parameter of the challenge, wherein the device identifier is the same as the subscription identifier.

[0055] The instructions, when executed by the at least one processor, may further cause the apparatus to perform receiving the subscription identifier from the authentication function in response to the providing the first biometric template; storing the subscription identifier associated with the device identifier; the retrieving the subscription identifier by

[0056] - retrieving the device identifier in response to checking that the first biometric template is the same as the second biometric template, and

[0057] - deriving the subscription identifier from the retrieved device identifier based on the stored association between the subscription identifier and the device identifier; wherein the device identifier is predefined for the device.

[0058] The instructions, when executed by the at least one processor, may further cause the apparatus to perform the providing, by the device, the first biometric template to the authentication function along with the device identifier via a secure channel; the sending the request to the authentication function, the receiving the parameter of the challenge, and the providing the authentication response via a second channel different from the secure channel.

[0059] The apparatus may comprise a user equipment or may be comprised in a user equipment.

[0060] According to a second aspect, there is provided an apparatus comprising: at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform: receiving, from a device, a first biometric template of a first user along with a device identifier; generating a first long-term key by a first hash function applied to the first biometric template; storing the first long-term key for a subscription identifier; receiving a request from a authentication server function, wherein the request comprises the subscription identifier; retrieving the first long-term key based on the subscription identifier comprised in the request; generating a parameter of a challenge and an expected response based on the retrieved first long-term key; providing the parameter of the challenge and the expected response to the authentication server function in response to the request; checking whether an information informing that a authentication response received by the authentication server function from the device is the same as the expected response is received from the authentication server function; designating the device as authenticated in response to checking that the information informing that the authentication response received by the authentication server function from the device is the same as the expected response is received from the authentication server function, wherein the request is a registration request or an authentication request.

[0061] The instructions, when executed by the at least one processor, may further cause the apparatus to perform generating an anchor key based on the first long-term key and the parameter of the challenge; forwarding the anchor key to the authentication server function.

[0062] The instructions, when executed by the at least one processor, may further cause the apparatus to perform receiving, for the device from the authentication server function, multiple biometric templates of the first user including the first biometric template of the first user; generating the first long-term key by the first hash function applied to the multiple biometric templates of the first user. The instructions, when executed by the at least one processor, may further cause the apparatus to perform receiving, for the device from the authentication server function, multiple biometric templates of the first user including the first biometric template of the first user; providing, to the authentication server function, an indication that the first long-term key is to be generated based on the first biometric template; generating the first long-term key by the first hash function applied to the first biometric template and not based on the multiple biometric templates of the first user different from the first biometric template.

[0063] The instructions, when executed by the at least one processor, may further cause the apparatus to perform receiving, from the authentication server function, a capability indication, wherein the capability indication indicates plural hash functions including the first hash function the device is capable of; informing the authentication server function that the first hash function is to be used for the generating the first long-term key.

[0064] It may be predefined that the first hash function is to be used for the generating the first longterm key.

[0065] The subscription identifier may be the same as the device identifier.

[0066] The instructions, when executed by the at least one processor, may further cause the apparatus to perform retrieving a second long-term key from a data repository based on the subscription identifier; generating the parameter of the challenge and the expected response based on the retrieved first long-term key and the retrieved second long-term key.

[0067] The instructions, when executed by the at least one processor, may further cause the apparatus to perform generating the subscription identifier in response to the receiving the first biometric template along with the device identifier; providing the generated subscription identifier to the authentication server function in response to the request.

[0068] The instructions, when executed by the at least one processor, may further cause the apparatus to perform the receiving the first biometric template along with the device identifier via a secure channel; the receiving the request, the providing the parameter of the challenge and the expected response, and the receiving the information informing that the authentication response received by the authentication server function from the device is the same as the expected response via a second channel different from the secure channel.

[0069] The apparatus may comprise a user data management or may be comprised in a user data management.

[0070] According to a third aspect, there is provided an apparatus comprising: at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform: receiving a request from a device, wherein the request comprises a subscription identifier and an identifier of the device; forwarding the request to a user data management; receiving a parameter of a challenge and an expected response in response to the forwarding the request to the user data management; providing the parameter of the challenge to the device in response to the received request; receiving an authentication response from the device in response to the providing the parameter of the challenge; checking whether the received authentication response is the same as the expected response; providing an information informing that the received authentication response is the same as the expected response to the user data management in response to checking that the received authentication response is the same as the expected response, wherein the request is a registration request or an authentication request. The instructions, when executed by the at least one processor, may further cause the apparatus to perform receiving an anchor key from the user data management; allowing a network to communicate with the device based on the anchor key.

[0071] The instructions, when executed by the at least one processor, may further cause the apparatus to perform receiving, from the device, multiple biometric templates of the first user including the first biometric template of the first user; forwarding the multiple biometric templates to the user data management.

[0072] The instructions, when executed by the at least one processor, may further cause the apparatus to perform receiving a capability indication from the device, wherein the capability indication indicates plural hash functions including the first hash function the device is capable of; forwarding the capability indication to the user data management; receiving, from the user data management, an information that the first hash function is to be used for the generating the first long-term key; informing the device that the first hash function is to be used for the generating the first long-term key.

[0073] The subscription identifier may be the same as the device identifier.

[0074] The instructions, when executed by the at least one processor, may further cause the apparatus to perform receiving the subscription identifier in response to the forwarding the request to the user data management; providing the generated subscription identifier to the device.

[0075] The apparatus may comprise an authentication server function or may be comprised in a authentication server function.

[0076] According to a fourth aspect, there is provided a system, comprising at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the system at least to perform: receiving, from a device, a first biometric template of a first user along with a device identifier; generating a first long-term key by a first hash function applied to the first biometric template; storing the first long-term key for a subscription identifier; receiving a request from a device, wherein the request comprises the subscription identifier; retrieving the first long-term key based on the subscription identifier comprised in the request; generating a parameter of a challenge and an expected response based on the retrieved first long-term key; providing the parameter of the challenge to the device in response to the request; receiving an authentication response from the device in response to the providing the parameter of the challenge; checking whether the received authentication response is the same as the expected response; designating the device as authenticated in response to checking that the received authentication response is the same as the expected response, wherein the request is a registration request or an authentication request.

[0077] According to a fifth aspect, there is provided a method comprising: providing, by a device, a first biometric template of a first user to an authentication function of a network along with a device identifier; storing the first biometric template at the device; generating a first long-term key by a first hash function applied to the first biometric template; storing the first long-term key along with a subscription identifier for the first user at the device; receiving an attempt to register a second user at the device using a second biometric template; checking whether the second biometric template is the same as the first biometric template; retrieving the subscription identifier stored along with the first biometric template in response to checking that the first biometric template is the same as the second biometric template; sending a request comprising the retrieved subscription identifier to the authentication function; receiving a parameter of a challenge from the authentication function in response to the sending the request; generating an authentication response based on the first long-term key and the parameter of the challenge; providing the authentication response in response to the receiving the parameter of the challenge, wherein the request is a registration request or an authentication request.

[0078] The method may further comprise generating an anchor key based on the first long-term key and the parameter of the challenge; communicating with the network based on the anchor key.

[0079] The method may further comprise providing, by the device, multiple biometric templates of the first user including the first biometric template to the authentication function; generating the first long-term key by the first hash function applied to the multiple biometric templates of the first user.

[0080] The method may further comprise providing, by the device, multiple biometric templates of the first user including the first biometric template to the authentication function; receiving, from the authentication function, an indication that the first long-term key is to be generated based on the first biometric template; generating the first long-term key by the first hash function applied to the first biometric template and not based on the multiple biometric templates of the first user different from the first biometric template.

[0081] The method may further comprise indicating, to the authentication function, plural hash functions including the first hash function the device is capable of; receiving, from the authentication function, an indication that the first hash function is to be used for the generating the first long-term key. It may be predefined that the first hash function is to be used for the generating the first longterm key.

[0082] The subscription identifier may be the same as a device identifier predefined for the device.

[0083] The method may further comprise retrieving a second long-term key from a subscriber identity module on the device, wherein the second long-term key is related to the subscription identifier; wherein the generating the authentication response may be performed based on the first longterm key, the second long-term key, and the parameter of the challenge, wherein the device identifier may be the same as the subscription identifier.

[0084] The method may further comprise receiving the subscription identifier from the authentication function in response to the providing the first biometric template; storing the subscription identifier associated with the device identifier; wherein the retrieving the subscription identifier may be performed by

[0085] - retrieving the device identifier in response to checking that the first biometric template is the same as the second biometric template, and

[0086] - deriving the subscription identifier from the retrieved device identifier based on the stored association between the subscription identifier and the device identifier; wherein the device identifier may be predefined for the device.

[0087] 70. The method according to any of claims 61 to 69, wherein, by the device, the first biometric template may be provided to the authentication function along with the device identifier via a secure channel; the sending the request to the authentication function, the receiving the parameter of the challenge, and the providing the authentication response may be performed via a second channel different from the secure channel.

[0088] The method may be performed by a user equipment or a module of the user equipment.

[0089] According to a sixth aspect, there is provided a method comprising: receiving, from a device, a first biometric template of a first user along with a device identifier; generating a first long-term key by a first hash function applied to the first biometric template; storing the first long-term key for a subscription identifier; receiving a request from a authentication server function, wherein the request comprises the subscription identifier; retrieving the first long-term key based on the subscription identifier comprised in the request; generating a parameter of a challenge and an expected response based on the retrieved first long-term key; providing the parameter of the challenge and the expected response to the authentication server function in response to the request; checking whether an information informing that a authentication response received by the authentication server function from the device is the same as the expected response is received from the authentication server function; designating the device as authenticated in response to checking that the information informing that the authentication response received by the authentication server function from the device is the same as the expected response is received from the authentication server function, wherein the request is a registration request or an authentication request.

[0090] The method may further comprise generating an anchor key based on the first long-term key and the parameter of the challenge; forwarding the anchor key to the authentication server function.

[0091] The method may further comprise receiving, for the device from the authentication server function, multiple biometric templates of the first user including the first biometric template of the first user; generating the first long-term key by the first hash function applied to the multiple biometric templates of the first user.

[0092] The method may further comprise receiving, for the device from the authentication server function, multiple biometric templates of the first user including the first biometric template of the first user; providing, to the authentication server function, an indication that the first long-term key is to be generated based on the first biometric template; generating the first long-term key by the first hash function applied to the first biometric template and not based on the multiple biometric templates of the first user different from the first biometric template.

[0093] The method may further comprise receiving, from the authentication server function, a capability indication, wherein the capability indication indicates plural hash functions including the first hash function the device is capable of; informing the authentication server function that the first hash function is to be used for the generating the first long-term key.

[0094] It may be predefined that the first hash function is to be used for the generating the first longterm key.

[0095] The subscription identifier may be the same as the device identifier.

[0096] The method may further comprise retrieving a second long-term key from a data repository based on the subscription identifier; generating the parameter of the challenge and the expected response based on the retrieved first long-term key and the retrieved second long-term key.

[0097] The method may further comprise generating the subscription identifier in response to the receiving the first biometric template along with the device identifier; providing the generated subscription identifier to the authentication server function in response to the request.

[0098] The first biometric template may be received along with the device identifier via a secure channel; the request may be received, the parameter of the challenge and the expected response may be provided, and the information informing that the authentication response received by the authentication server function from the device is the same as the expected response may be received via a second channel different from the secure channel.

[0099] The method may be performed by a user data management or a module of the user data management.

[0100] According to a seventh aspect, there is provided a method comprising: receiving a request from a device, wherein the request comprises a subscription identifier and an identifier of the device; forwarding the request to a user data management; receiving a parameter of a challenge and an expected response in response to the forwarding the request to the user data management; providing the parameter of the challenge to the device in response to the received request; receiving an authentication response from the device in response to the providing the parameter of the challenge; checking whether the received authentication response is the same as the expected response; providing an information informing that the received authentication response is the same as the expected response the user data management by in response to checking that the received authentication response is the same as the expected response, wherein the request is a registration request or an authentication request.

[0101] The method may further comprise receiving an anchor key from the user data management; allowing a network to communicate with the device based on the anchor key.

[0102] The method may further comprise receiving, from the device, multiple biometric templates of the first user including the first biometric template of the first user; forwarding the multiple biometric templates to the user data management.

[0103] The method may further comprise receiving a capability indication from the device, wherein the capability indication indicates plural hash functions including the first hash function the device is capable of; forwarding the capability indication to the user data management; receiving, from the user data management, an information that the first hash function is to be used for the generating the first long-term key; informing the device that the first hash function is to be used for the generating the first long-term key.

[0104] The subscription identifier may be the same as the device identifier.

[0105] The method may further comprise receiving the subscription identifier in response to the forwarding the request to the user data management; providing the generated subscription identifier to the device.

[0106] The method may be performed by an authentication server function or a module of an authentication server function.

[0107] According to an eighth aspect, there is provided a method, comprising receiving, from a device, a first biometric template of a first user along with a device identifier; generating a first long-term key by a first hash function applied to the first biometric template; storing the first long-term key for a subscription identifier; receiving a request from a device, wherein the request comprises the subscription identifier; retrieving the first long-term key based on the subscription identifier comprised in the request; generating a parameter of a challenge and an expected response based on the retrieved first long-term key; providing the parameter of the challenge to the device in response to the request; receiving an authentication response from the device in response to the providing the parameter of the challenge; checking whether the received authentication response is the same as the expected response; designating the device as authenticated in response to checking that the received authentication response is the same as the expected response, wherein the request is a registration request or an authentication request.

[0108] Each of the methods of the fifth to eighth aspects may be a method of authentication.

[0109] According to a ninth aspect, there is provided a computer program comprising instructions for causing an apparatus to perform at least the method of any of the fifth to eighth aspects.

[0110] According to a tenth aspect, there is provided a non-transitory computer readable medium comprising program instructions for causing an apparatus to perform at least the method of any of the fifth to eighth aspects.

[0111] According to an eleventh aspect, there is provided a computer readable medium comprising program instructions for causing an apparatus to perform at least the method of any of the fifth to eighth aspects.

[0112] According to some example embodiments, at least one of the following advantages may be achieved:

[0113] • a user of a XR device may be safely authenticated by the network;

[0114] • existing 3GPP algorithms are exploited.

[0115] Brief description of the drawings

[0116] Further details, features, objects, and advantages are apparent from the following detailed description of the preferred example embodiments which is to be taken in conjunction with the appended drawings, wherein:

[0117] Fig. 1 (comprising Figs. 1A to 1 C) shows a message flow according to the prior art;

[0118] Fig. 2 shows biometric processing according to the prior art;

[0119] Fig. 3 shows generation of Kb according to some example embodiments;

[0120] Fig. 4 shows details of a preparation action according to some example embodiments;

[0121] Fig. 5 (comprising Figs. 5A to 50) shows a message sequence chart according to some example embodiments;

[0122] Fig. 6 (comprising Figs. 6A to 60) shows a message sequence chart according to some example embodiments; Fig. 7 shows an apparatus according to an example embodiment;

[0123] Fig. 8 shows a method according to an example embodiment;

[0124] Fig. 9 shows an apparatus according to an example embodiment;

[0125] Fig. 10 shows a method according to an example embodiment;

[0126] Fig. 11 shows an apparatus according to an example embodiment;

[0127] Fig. 12 shows a method according to an example embodiment;

[0128] Fig. 13 shows a system according to an example embodiment;

[0129] Fig. 14 shows a method according to an example embodiment; and

[0130] Fig. 15 shows an apparatus according to an example embodiment.

[0131] Detailed description of certain example embodiments

[0132] Herein below, certain example embodiments are described in detail with reference to the accompanying drawings, wherein the features of the example embodiments can be freely combined with each other unless otherwise described. However, it is to be expressly understood that the description of certain example embodiments is given by way of example only, and that it is by no way intended to be understood as limiting the disclosure to the disclosed details.

[0133] Moreover, it is to be understood that the apparatus is configured to perform the corresponding method, although in some cases only the apparatus or only the method are described.

[0134] Basically, for properly establishing and handling a communication between two or more endpoints (e.g. communication stations or elements, such as terminal devices, user equipments (UEs), or other communication network elements, a database, a server, host etc.), one or more network elements or functions (e.g. physical nodes or virtualized network functions), such as communication network control elements or functions, for example access network elements like access points, radio base stations, relay stations, eNBs, gNBs etc., and core network elements or functions, for example control nodes, support nodes, service nodes, gateways, user plane functions, access and mobility functions etc., may be involved, which may belong to one communication network system or different communication network systems. However, it is to be noted that also a communication without intermediate network element is basically possible. In communication networks, such as 3GPP based networks, an important feature for each communication is communication security. 3GPP has developed different security mechanisms for communication network types. For example, security features in 5G based networks comprises authentication and key management for applications (AKMA) which enables applications to leverage the authentication of the UE performed by a PLMN and to use it for further authentication and authorization by an application and to bootstrap the necessary application security keys to the UE.

[0135] Basically, when a UE registers with the 5G PLMN for the first time, the network performs a primary authentication of the UE. Only after the successful primary authentication of the UE, the UE is authorized for additional network services. 3GPP has specified two protocols 5G- AKA and EAP-AKA for primary authentication, both of which can be executed over 3GPP access and non-3GPP access. In the primary authentication, the subscription credentials and the shared secret stored in the USIM of the UE and the same stored in the UDM / UDR of the operator network is verified. At the end of a successful primary authentication, the UE is admitted to network and the connection is secured using the derived session keys.

[0136] Fig. 1 illustrates a successful primary authentication procedure for UEs in 5G. The details of the actions 6, 9, 13, and 19 are shown in Fig. 10. The primary authentication procedure has to be performed when the UE registers the first time with the 5G network. Here, the “first time” includes not only the very first registration, but also the first registration after e.g. a reboot of the UE.

[0137] The procedure of Fig. 1 comprises the following basic phases:

[0138] • UE initiating registration procedure

[0139] • Home network computes AKA challenge

[0140] • Network authenticated by UE

[0141] • UE authenticated by serving network

[0142] • UE authenticated by home network

[0143] • Authentication result storage

[0144] The actions are as follows:

[0145] UE initiating registration procedure Action 1. When the user wants to access the 5G network, the UE performs a random access procedure and the RRC connection is setup between the UE and gNB. At the ME or USIM, the SUCI concealment (concealing of SUPI to obtain SUCI) is performed.

[0146] Action 2. The UE sends either the SUCI or 5G-GUTI (if assigned previously) in the Registration request message to the serving network AMF / SEAF.

[0147] Action 3. The AMF / SEAF initiates the authentication by sending the Authenticate Request message with SUCI or SUPI (in case of valid 5G-GUTI) and the serving network name (SNN) to the home network entity AUSF.

[0148] Action 4. The AUSF checks the received serving network name with the expected serving network name. If authorized, the AUSF sends the Authentication Get Request message with the SUCI or SUPI and the serving network name to the UDM.

[0149] Action 5. The UDM invokes the SIDF if the SUCI is received. The SIDF will de-conceal the SUCI to gain the SUPI before the UDM processes the request. Based on the SUPI (subscription information), the UDM will give the inputs for invoking the authentication method (5G AKA, EAP-AKA’ or EAP-TLS) by the AUSF.

[0150] Home network computes AKA challenge

[0151] Action 6. The UDM / ARPF using cryptographic functions (f1 ,f2,f3,f4,f5) computes a message authentication code MAC, response XRES, a cipher key CK, an integrity key IK and an anonymity key AK by considering the inputs like the Long term key K, the generated new random number RAND, the authentication & key management field AMF and the freshly generated sequence number SQN (created by incrementing the stored non time based SQN or time based SQN generation or partial time based SQN generation). The UDM / ARPF using key derivative functions KDF, computes the key KAusFfrom the cipher key CK, integrity key IK, SNN and “XOR” of Sequence Number SQN and Anonymity Key AK. The UDM / ARPF also calculates expected response XRES* from RES, RAND, SNN with concatenated input keys CK and IK. Finally, the UDM / ARPF creates a 5G home environment authentication vector (5G HE AV) containing RAND, AUTN, XRES* and KAUSF. The authentication vector may be considered as a challenge to the UE.

[0152] Action 7. The UDM / ARPF sends the Authenticate Get Response message to the AUSF with 5G HE AV, SUPI and AKMA indication (if AKMA subscription is present).

[0153] Action 8. The AUSF stores the received KAUSF and XRES* temporarily together with the received SUPI. The AUSF computes the hashed expected response HXRES* by using the SHA-256 algorithm with the concatenated inputs RAND and XRES*. Action 9. The ALISF generates the KSEAF using key derivative function with the KALISF and serving network name as inputs. The generated KSEAF is stored in the ALISF temporarily. The ALISF returns the 5G Serving Environment Authentication vector (5G SE AV) containing the RAND, AUTN and HXRES*.

[0154] Action 10. The ALISF sends the Authenticate Response with the 5G Serving Environment Authentication vector to the AMF / SEAF.

[0155] Action 11. The AMF / SEAF stores the received hashed expected response HXRES*.

[0156] Action 12. The AMF / SEAF sends the RAND, the AUTN along with the next generation key set identifier (ngKSI) and Anti-Bidding down Between Architectures (ABBA) parameter in NAS message Authentication Request to the UE.

[0157] Network authenticated by UE

[0158] Action 13. At receipt of this message, the USIM verifies the freshness of the authentication vector by checking whether the AUTN can be accepted. If verification is successful, the USIM computes a response RES. The USIM also computes CK and IK which are sent to the ME. The KAUSF, RES* (like the XRES* generation) and KSEAF are computed in the ME, similar to generation at the UDM / ARPF.

[0159] Action 14. The UE responds with RES* in the NAS message Authentication Response to the SEAF.

[0160] UE authenticated by serving network

[0161] Action 15. The AMF / SEAF computes the HRES* using the SHA-256 hashing algorithm with the received response RES* and compares the HRES* with the expected hash value HXRES*. Authentication is considered as successful from the serving network point of view, if compared values are equal.

[0162] Action 16. The AMF / SEAF sends the RES*, as received from the UE in the Authenticate Request message to the AUSF.

[0163] UE authenticated by home network

[0164] Action 17. The AUSF considers that Authentication is successful from the home network point of view, if the received RES* is equal to the stored and expected response from the XRES*. Action 18. The ALISF sends the Authenticate Response with the resulting key KsEAr and SlIPI to the SEAF. The ALISF in parallel will inform the UDM about the authentication results (containing the SLIPI, timestamp of authentication, authentication type and serving network name) in the Authentication Result confirmation Request message.

[0165] Action 19. The SEAF generates the key KAMF with received KSEAF, I MSI and ABBA parameter. The SEAF shares the generated KAMF, ngKSI to the AMF entity.

[0166] Authentication results storage

[0167] Action 20. The UDM stores the authentication status of the UE.

[0168] Action 21. The UDM replies to the AUSF with the Authentication Result Confirmation Response message.

[0169] Metaverse enabled applications (which may be supported by 6G) may use Avatars. The increasing number of social engineering attacks and other security threats severely impact how businesses authenticate and authorize their users online. In the case of metaverse, the risks might be even higher since cybercriminals may target weak lines of authentication security. Unless the real-world users have a unique mapping with their Avatars, and the authentication procedures include some biometric verifications, there is scope for attackers to launch various kinds of attacks like masquerading, eavesdropping, etc. These can lead to security and privacy issues.

[0170] The consumer-facing malware could lead to compromised identities if a business leaves a loophole in the overall authentication process. Although many businesses are concerned about the underlying security and authentication risks in the metaverse, some of them aren’t taking appropriate steps to mitigate them.

[0171] The metaverse ecosystem is rapidly growing, but this growth comes with associated risks.

[0172] • First, there is an increased risk of identity theft and fraud as users interact with one another in virtual spaces.

[0173] • Second, cybercriminals may target metaverse networks in order to steal personal information or access sensitive company data.

[0174] • Third, there’s always the possibility that hackers will use phishing tactics to gain access to sensitive information or even bring down the entire system by attacking an individual game or server. As shown in Error! Reference source not found., existing primary authentication mechanism standardized in 5G requires a pre-shared key “K” (pre-shared between UE (IISIM) and UDM), which is used to derive multiple keys for authentication and subsequently establishing security context. This “K” is provisioned in IISIM and operator’s UDM, and has a mapping with subscriber ID (or phone number). XR / VR devices supporting metaverse may not have a USIM. In such scenarios, the existing authentication procedures cannot be applied as such.

[0175] Biometric authentication uses biometric images such as finger print, iris, face images for authentication purposes. Biometric data can be used to

[0176] • Identify and verify a person.

[0177] • Authenticate a person to give appropriate rights of system operations.

[0178] • Keep the system safe from unethical handling.

[0179] Error! Reference source not found, illustrates a biometric processing mechanism. The biometric sensors capture the biometric data from the user, and the processing unit extracts the features and converts it into a digital reference with the distinct characteristics extracted from the biometric image. This digital reference may be called ‘biometric template’.

[0180] For metaverse enabled 6G applications, traditional key based authentication mechanisms won’t suffice. Biometric authentication is an essential enabler for metaverse applications.

[0181] Some example embodiments take care of one or more of the following problems specific to primary authentication for metaverse devices (or more general: XR devices such as avatars):

[0182] • XR devices may or may not have a USIM. In both scenarios, primary authentication will need to consider the user’s biometric data and ensure secure mapping between actual users and their XR devices.

[0183] • XR devices may be shared by multiple users. In such scenarios, the authentication should happen for the user currently using the device.

[0184] • If an XR device is stolen, an un-authenticated user should not be able to use the device, even by forcing a factory recovery.

[0185] • If an XR device is sold by the owner of the device, there should be a re-registration procedure which allows transfer of ownership to a new master user. Some example embodiments provide methods and / or apparatuses for biometric-enabled primary authentication for XR devices with and without IISIM. Basically, the operation is as follows:

[0186] • During XR device registration with operator’s network, as a preparation, individual’s biometric template is shared with UDM, preferably via a secure channel (e.g. offline). This individual’s biometric template is assigned as the master-user’s biometric template. In some example embodiments, there may be plural masterusers.

[0187] • Subsequently, a symmetric hash function is used to generate a unique “Kb” (a key (“first long-term key”) similar as the long-term key K (“second long-term key”) on the IISIM) from the biometric template(s). The UE stores Kb in the TEE for further usage o This “Kb” can be used as the “K” as input to the cryptographic functions (f1...f5) if the device does not have a IISIM or does not use the IISIM for the authentication although it is present in the device. o This “Kb” can be used as an additional input to the cryptographic functions if the device uses IISIM for the authentication (in addition to the biometric template). I.e., K and Kb (e.g. a function based on K and Kb such as their concatenation) are input to the cryptographic functions (f1...f5).

[0188] Error! Reference source not found, illustrates generation of a biometric key (Kb) by symmetric hashing from a biometric template which is stored in the device and UDM during a preparation procedure (see Fig. 4). The preparation procedure is preferably performed via a secure channel (e.g. offline).

[0189] Symmetric hashing may be described as follows:

[0190] A small change in the input (missing information, noise or a change in the order of the input etc.) can cause a significant change in the hash value. A certain class of hash functions can, however, be formulated that are invariant to the order in which the input pattern is presented to the hash function. Such hash functions are known as order-independent or symmetric hash functions.

[0191] Consider an input sequence X = x1x2x3. . .xn and the following two hash functions (examples):

[0192] If the order of the input is changed to X = x2x3xn. . ,x1 , the first function yields a different hash value, whereas the second remains unchanged. There are more hash functions (like (2)) that are symmetric. Moreover, arbitrary combinations of more than one hash function yield new hash functions. Thus, one may obtain a whole family of symmetric hash functions by combining the elementary symmetric functions.

[0193] Multiple biometric data of the same user (or even of plural users) may be shared and stored at device as well as at UDM. For example,

[0194] • Multiple fingerprint images per user can be collected, and the corresponding biometric templates can be stored in the UE and the UDM.

[0195] • along with finger-prints, retina scan and heartbeat patterns may also be other forms of biometrics collected, and corresponding multiple biometric templates may be stored for multi-factor authentication, if desired.

[0196] Typically, actual biometrics are not shared or stored in the device and / or at the UDM. Instead, one or more biometric templates are shared and stored. A biometric template is a representation of a biometric image (or some other biometric function), as shown in Fig. 2. Popular feature extraction algorithms to form a biometric template are:

[0197] • ISEF Edge detection

[0198] • CANNY Edge Detection And SIFT Based Algorithm

[0199] In some example embodiments, the device may support re-registration with operator’s network, or provide a functionality to add one or more users. In such scenarios, a master user authenticates at the network using his / her biometric template as a pre-requisite for reregistration or user addition.

[0200] For factory recovery, initial authentication should happen with the pre-shared biometric information (one or more biometric templates of the master-user). Only if the initial authentication succeeds, a subsequent re-registration should succeed. The biometric template(s) may be mapped to the device ID. Thus, it may be ensured that someone is not able to steal the device and misuse it. That is, even if the device is stolen, the biometric info needs to be shared freshly each time and with stolen device, the biometric info (biometric template) provided by the thief (or another person different from a genuine user) will not be the one expected at UDM. Due to the mismatch biometric template and device id, the initial steps of authentication will fail. Even in absence of this mapping between device ID and biometric, the privacy sensitive information cannot be stolen even if device is stolen because of biometric-enabled primary authentication.

[0201] As another option, when user registers his biometric template to the network, network assigns an ID (a kind of “subscription ID” such as a temporary SlIPI or GPSI) and provides it to the UE and AMF for usage of the “subscription ID” in further communication. In this way, UDM creates a subscription ID for the device. This allows a flexibility as follows: If the user changes the device, still the same subscription may be used in the network. Also, UDM may register the device ID along with the created subscription ID.

[0202] As a still further option, if the device has a USIM and the user is authenticated with the USIM (i.e. , the USIM belongs to the user), the subscription identifier of the USIM (e.g. SUPI) or an identifier derived therefrom (e.g. SUCI) may be associated to the biometric template.

[0203] After the device gets registered with a master user, master user can share the biometric data of one or more other users with whom the device may be shared. This may be useful e.g. when family members plan to share the same device. Once the master user has added one or more other users, the primary authentication can succeed even when other users are using the device, based on the biometric template of the respective other user.

[0204] Error! Reference source not found, illustrates the details of the preparation procedure (Action 0 in Figs. 5 and 6).

[0205] • User / XR device shares one or more biometric templates (BT[1..K][1..N]) with UDM, preferably using a secure channel (e.g. offline). For each type of the biometrics 1..K, there may be 1..N samples taken and the corresponding biometric templates can be shared. This template array is stored both at device side and at UDM.

[0206] • Also, the device shares with UDM XR device ID (predefined for the device, such as an IMEI). In addition, the device may share with UDM information about some of its capabilities (like supported hash functions). Preferably, these pieces of information are shared using the secure channel, too.

[0207] • If the device shares information about its supported hash functions, UDM selects the hash function to be used (from the hash functions supported by the device. In some example embodiments, the hash function to be used is predefined. In some example embodiments, the hash function to be used is predefined but if the device provides information about its supported hash functions, the selection by UDM from the supported hash functions may overrule the predefinition of the hash function to be used. UDM applies the selected or predefined hash function to the biometric template array comprising the one or more biometric templates and generates an array of one or more keys.

[0208] In some example embodiments, UDM may select a single biometric template of the plural biometric templates to generate Kb (“first long-term key”). In some example embodiments, the entire array of keys generated from plural biometric templates may be considered as Kb (“first long-term key”).

[0209] As an option, UDM may select different hash functions for different biometric templates.

[0210] • In some example embodiments, UDM assigns a subscription ID for the device which can be used like SUPI in further steps. In some example embodiments, the device ID may be used as the subscription ID. In some example embodiments, the device ID is already a subscription ID which the device retrieved from a USIM on the device.

[0211] • Then UDM provisions the XR device with the ID of the hash function(s) which has(have) to be applied to the one or more biometric templates to generate Kb at device side. If UDM selects a single biometric template among plural biometric templates, UDM informs the device about the selected biometric template. If UDM assigns the subscription ID, the Subscription ID is also shared with the device.

[0212] Fig. 5 shows a message sequence chart according to some example embodiments. The details of the actions 6, 9, 13, and 19 are shown in Fig. 5C. In Fig. 5, the preparation action 0 is the preparation action described in detail with respect to Fig. 4. In Fig. 5, the device does not have a USIM or does not use a present USIM for the authentication.

[0213] The following actions are substantially the same as those described for Fig. 1 , where the key K shared between USIM and UDM is replaced by the key Kb (or one of the keys Kb, or the array of keys Kb) generated in the preparation action 0. Therefore, the following description of Fig. 5 highlights the differences to Fig. 1. For the other details, it is referred to the description of Fig. 1.

[0214] UE initiating registration procedure

[0215] Action 1. When a user wants to access the 5G network, he / she authenticates towards the device by some biometrics and the matching biometric template is determined. The device performs a random access procedure and the RRC connection is setup between the device and gNB. As another option, the device may access the network by a non-3GPP wireless access (e.g. WLAN) or by a wired access (e.g. LAN). The device ID (predefined for the device, similar to an I M El) may be concealed (corresponding to concealing of SUPI to obtain SUCI). Instead of (or in addition to) the device ID, the subscription ID received from UDM in the preparation action 0, if any, may be used. I.e., the subscription ID plays the same role as the device ID for the next actions. For simplicity, the following description is based on the device ID.

[0216] Action 2. The device sends the (concealed) device ID in the Registration request message to the AMF / SEAF. In addition, if plural biometric templates are stored, the device sends an ID of the biometric template (also called “biometric info”) matching the biometric template of the actual user to AMF / SEAF. In particular if the template ID of the biometric template is not unique in the device but only unique in the device per biometric type, the template ID may additionally comprise an indication of the biometric type, as shown in the example of Fig. 5. By sending only the template ID (with or without the biometric type) instead of the biometric template (or even the biometric image), a man in the middle is prevented from retrieving the original biometric template.

[0217] Action 3. The AMF / SEAF initiates the authentication by sending the Authenticate Request message with the concealed device ID, the ID of the matching biometric template, if any, and the serving network name (SNN) to the AUSF.

[0218] Action 4. The AUSF checks the received serving network name with the expected serving network name. If authorized, the AUSF sends the Authentication Get Request message with the (concealed) device ID, the ID of the matching biometric template, if any, and the serving network name to the UDM.

[0219] Action 5. The UDM invokes the SIDF if the received device ID is concealed. The SIDF will deconceal the device to gain the device ID before the UDM processes the request. Based on the device ID, the UDM will give the inputs for invoking the authentication method (5G AKA, BARAKA’ or EAP-TLS) by the AUSF. I.e., the long-term key K used in the conventional message sequence chart of Fig. 1 is replaced by the biometrical long-term key Kb related to the device ID.

[0220] Home network computes AKA challenge

[0221] Action 6. The UDM / ARPF calculates the authentication vector (and the anchor key KAUSF) as described in Fig. 1 , wherein the long-term key K used in the conventional message sequence chart of Fig. 1 is replaced by the biometrical long-term key Kb related to the device ID. The authentication vector may be considered as a challenge to the UE.

[0222] Action 7. The UDM / ARPF sends the Authenticate Get Response message to the AUSF with 5G HE AV, device ID, and AKMA indication (if AKMA subscription is present).

[0223] Action 8. The AUSF stores the received KAUSF and XRES* temporarily together with the received device ID. The AUSF computes the hashed expected response HXRES* by using the SHA-256 algorithm with the concatenated inputs RAND and XRES*.

[0224] Action 9. The AUSF generates the KSEAF using key derivative function with the KAUSF and serving network name as inputs. The generated KSEAF is stored in the AUSF temporarily. The AUSF returns the 5G Serving Environment Authentication vector (5G SE AV) containing the RAND, AUTN and HXRES*.

[0225] Action 10. The AUSF sends the Authenticate Response with the 5G Serving Environment Authentication vector to the AMF / SEAF.

[0226] Action 11. The AMF / SEAF stores the received hashed expected response HXRES*.

[0227] Action 12. The AMF / SEAF sends the RAND, the AUTN along with the next generation key set identifier (ngKSI) and Anti-Bidding down Between Architectures (ABBA) parameter in NAS message Authentication Request to the UE.

[0228] Network authenticated by UE

[0229] Action 13. At receipt of this message, the device verifies the freshness of the authentication vector by checking whether the AUTN can be accepted (i.e. whether XMAC and SQN are in the correct range). If verification is successful, the device computes a response RES* and an anchor key KSEAF using the biometric key Kb, similar to generation at the UDM / ARPF. If plural keys Kb based on different biometric templates were generated in the preparation action 0, the device uses the biometric key Kb corresponding to the biometric template indicated to UDM in actions 2 to 4. Action 14. The UE responds with RES* in the NAS message Authentication Response to the SEAF.

[0230] UE authenticated by serving network

[0231] Action 15. The AMF / SEAF computes the HRES* using the SHA-256 hashing algorithm with the received response RES* and compares the HRES* with the expected hash value HXRES*. Authentication is considered as successful from the serving network point of view, if compared values are equal.

[0232] Action 16. The AMF / SEAF sends the RES*, as received from the UE in the Authenticate Request message to the AUSF.

[0233] UE authenticated by home network

[0234] Action 17. The AUSF considers that Authentication is successful from the home network point of view, if the received RES* is equal to the stored and expected response from the XRES*.

[0235] Action 18. The AUSF sends the Authenticate Response with the resulting key KSEAF and SUPI to the SEAF. The AUSF in parallel will inform the UDM about the authentication results (containing the device ID, timestamp of authentication, authentication type and serving network name) in the Authentication Result confirmation Request message.

[0236] Action 19. The SEAF generates the key KAMF with received KSEAF, I MSI and ABBA parameter. The SEAF shares the generated KAMF, ngKSI to the AMF entity.

[0237] Authentication results storage

[0238] Action 20. The UDM stores the authentication status of the device (i.e. device is authenticated if the procedure was successful).

[0239] Action 21. The UDM replies to the AUSF with the Authentication Result Confirmation Response message.

[0240] If the device collects more than 1 biometric of the same type (N>1), the authentication procedure of Figs. 5 and 6 may be modified as follows: In particular in fingerprint or face biometric (but not only for these biometrics), device may collect multiple images of the face / finger and store the same in the device. For example, 30 images (biometric templates) are stored. Each of the images (biometric templates) has a template ID. When user tries to login in the device, the image (biometric template) of his finger or face should match with one of the images (biometric templates) stored in the device to consider the user authenticated at the device. Then, the device provides the template ID of the matching image (biometric template) to UDM. Then, Kb generated based on this biometric template is used to generate the challenge at UDM and solve the challenge at the device.

[0241] In case only a single Kb. is generated, each time during the authentication, matched biometric template and hash function are provisioned between device and UDM, a new key BTj based on the matched biometric template is generated and used it along Kb.

[0242] Fig. 6 shows a message sequence chart according to some example embodiments. The details of the actions 6, 9, 13, and 19 are shown in Fig. 6C. In Fig. 6, the device has a USIM and uses the USIM for the authentication. Otherwise, Fig. 6 corresponds to Fig. 5 with the following differences:

[0243] Instead of or in addition to the device ID, the subscription ID retrieved from the USIM (e.g. SUPI or its concealed version SUCI) is provided from the device to UDM in actions 2 to 5. Based on the SUPI, UDM retrieves the long-term key K (“second long-term key”) from its repository. In actions 6 and 13, the key input into the cryptographic functions (f1..f5) is based on both the biometric key (Kb) (“first long-term key”) and the long-term key K (“second longterm key”) shared between the USIM and UDM. For example, the key input into the cryptographic functions (f1..f5) may be a concatenation of K and Kb. The key may be derived by any other function based on K and Kb, such as a sum of K and Kb, a product of K and Kb, an absolute value of a difference of K and Kb, XOR (K, Kb), etc. In some example embodiments, both keys K and Kb are input into the cryptographic functions f1 ...f5. The function is predefined in UDM and the device. In some example embodiments, plural of such functions may be predefined in UDM and the device, UDM selects one of these functions, and informs the device on the selected function when it provides the challenge to the device (actions 7 to 12).

[0244] In some example embodiments, based on the message sequence of any of Figs. 5 and 6, one of the biometric template BTi or the biometric key Kb may be combined with some other input parameter into the cryptographic functions f1...f5 such that only one key is input into the cryptographic functions f1...f5 in actions 6 and 13. Thus, conventional cryptographic functions may be used. For example, one of the keys may be combined with another parameter be an XOR function. The other parameter may be e.g. the other key (i.e. Kb may be combined with BTi before it is input into the cryptographic functions f1 ...f5).

[0245] In some example embodiments, based on the message sequence of any of Figs. 5 and 6, the biometric template BTi may not be passed from UE to UDM in actions 1 to 5. In these embodiments, the biometric key Kb may be derived based on the device ID or subscription ID, respectively, and only the biometric key Kb but not the biometric template BTj is input into the cryptographic functions f1...f5 in actions 6 and 13.

[0246] Some example embodiments are described with a certain worksplit between ALISF and UDM. However, in some example embodiments, the worksplit between AUSF and UDM may be different from that described hereinabove. For example, UDM may receive the authentication request directly from the UE, or UDM may perform the check whether the authentication response from the UE is equal to the expected response. In some example embodiments, the functions of AUSF and UDM are provided by one system.

[0247] Fig. 7 shows an apparatus according to an example embodiment. The apparatus may be a device (such as a XR device) or an element thereof. Fig. 8 shows a method according to an example embodiment. The apparatus according to Fig. 7 may perform the method of Fig. 8 but is not limited to this method. The method of Fig. 8 may be performed by the apparatus of Fig. 7 but is not limited to being performed by this apparatus.

[0248] The apparatus comprises first means for providing 110, first means for storing 120, first means for generating 130, second means for storing 140, first means for receiving 150, means for checking 160, means for retrieving 170, means for sending 180, second means for receiving 190, second means for generating 200, and second means for providing 210. The first means for providing 110, first means for storing 120, first means for generating 130, second means for storing 140, first means for receiving 150, means for checking 160, means for retrieving 170, means for sending 180, second means for receiving 190, second means for generating 200, and second means for providing 210 may be a first providing means, first storing means, first generating means, second storing means, first receiving means, checking means, retrieving means, sending means, second receiving means, second generating means, and second providing means, respectively. The first means for providing 110, first means for storing 120, first means for generating 130, second means for storing 140, first means for receiving 150, means for checking 160, means for retrieving 170, means for sending 180, second means for receiving 190, second means for generating 200, and second means for providing 210 may be a first provider, first storage device, first generator, second storage device, first receiver, checker, retriever, sender, second receiver, second generator, and second provider, respectively. The first means for providing 110, first means for storing 120, first means for generating 130, second means for storing 140, first means for receiving 150, means for checking 160, means for retrieving 170, means for sending 180, second means for receiving 190, second means for generating 200, and second means for providing 210 may be a first providing processor, first storing processor, first generating processor, second storing processor, first receiving processor, checking processor, retrieving processor, sending processor, second receiving processor, second generating processor, and second providing processor, respectively.

[0249] The first means for providing 110 provides, by a device, a first biometric template of a first user to an authentication function (UDM, ALISF) of a network (S110). Along with the first biometric template, the first means for providing 110 provides a device identifier. The device identifier may be predefined for the device, or it may be (or may comprise) actually a subscription identifier (e.g. retrieved from a IISIM on the device, if any). The first means for storing 120 stores the first biometric template at the device (S120).

[0250] The first means for generating 130 generates a first long-term key (Kb) by a first hash function applied to the first biometric template (S130). The second means for storing 140 stores the first long-term key along with a subscription identifier for the first user at the device (S140). The subscription identifier may be actually the device identifier, a subscription identifier received from the authentication function, or the subscription identifier retrieved from IISIM, if any.

[0251] S110 to S140 correspond to the preparation action 0 of Figs. 4 to 6. After the preparation action 0 is performed, the following actions may be performed.

[0252] The first means for receiving 150 receives an attempt to register a second user at the device using a second biometric template (S150). The second user may be the same as the first user or different therefrom. The means for checking 160 checks whether the second biometric template is the same as the first biometric template (S160). If the second biometric template is the same as the first biometric template, it is assumed that the first user is the same as the second user, otherwise it is assumed that the first user is different from the second user. In response to checking that the first biometric template is the same as the second biometric template (S160 = yes), the means for retrieving 170 retrieves the subscription identifier stored in S140 along with the first biometric template (S170). The means for sending 180 sends a request (such as an authentication request or a registration request) comprising the retrieved subscription identifier to the authentication function (S180).

[0253] In response to the sending the request in S180, the second means for receiving 190 receives a parameter of a challenge (for example: the parameters provided in action 12 of Figs. 5 and 6) from the authentication function (S190). Based on the first long-term key stored in S140 and the parameter of the challenge received in S190, the second means for generating 200 generates an authentication response (S200). The second means for providing 210 provides the authentication response in response to the receiving the parameter of the challenge (S210).

[0254] Fig. 9 shows an apparatus according to an example embodiment. The apparatus may be a user data management (such as a UDM ) or an element thereof. Fig. 10 shows a method according to an example embodiment. The apparatus according to Fig. 9 may perform the method of Fig. 10 but is not limited to this method. The method of Fig. 10 may be performed by the apparatus of Fig. 9 but is not limited to being performed by this apparatus.

[0255] The apparatus comprises a first means for receiving 510, first means for generating 520, means for storing 530, second means for receiving 540, means for retrieving 550, second means for generating 560, means for providing 570, means for checking 580, and means for designating 590. The first means for receiving 510, first means for generating 520, means for storing 530, second means for receiving 540, means for retrieving 550, second means for generating 560, means for providing 570, means for checking 580, and means for designating 590 may be a first receiving means, first generating means, storing means, second receiving means, retrieving means, second generating means, providing means, checking means, and designating means, respectively. The first means for receiving 510, first means for generating 520, means for storing 530, second means for receiving 540, means for retrieving 550, second means for generating 560, means for providing 570, means for checking 580, and means for designating 590 may be a first receiver, first generator, storage device, second receiver, retriever, second generator, provider, checker, and designator, respectively. The first means for receiving 510, first means for generating 520, means for storing 530, second means for receiving 540, means for retrieving 550, second means for generating 560, means for providing 570, means for checking 580, and means for designating 590 may be a first receiving processor, first generating processor, storing processor, second receiving processor, retrieving processor, second generating processor, providing processor, checking processor, and designating processor, respectively.

[0256] The first means for receiving 510 receives, from a device, a first biometric template of a first user along with a device identifier (S510). The first means for generating 520 generates a first long-term key by a first hash function applied to the first biometric template (S520). The means for storing 530 stores the first long-term key for a subscription identifier. The subscription identifier may be actually the device identifier, a subscription identifier generated by the apparatus, or a subscription identifier received along with the first biometric template, if any.

[0257] S510 to S530 correspond to the preparation action 0 of Figs. 4 to 6. After the preparation action 0 is performed, the following actions may be performed.

[0258] The second means for receiving 540 receives a request from a authentication server function (S540). The request may be a registration request or an authentication request. The request comprises the subscription identifier. Based on the subscription identifier comprised in the request, the means for retrieving 550 retrieves the first long-term key (S550).

[0259] The second means for generating 560 generates a parameter of a challenge and an expected response based on the retrieved first long-term key (S560). In response to the request of S540, the means for providing 570 provides the parameter of the challenge and the expected response to the authentication server function (S570).

[0260] The means for checking 580 checks whether an information is received from the authentication server function (S580). The information informs that a authentication response received by the authentication server function from the device is the same as the expected response.

[0261] In response to checking that the information (i.e. the information informing that the authentication response received by the authentication server function from the device is the same as the expected response) is received from the authentication server function (S580 = yes), the means for designating 590 designates the device as authenticated (S590). Fig. 11 shows an apparatus according to an example embodiment. The apparatus may be a authentication server function (such as a ALISF ) or an element thereof. Fig. 12 shows a method according to an example embodiment. The apparatus according to Fig. 11 may perform the method of Fig. 12 but is not limited to this method. The method of Fig. 12 may be performed by the apparatus of Fig. 11 but is not limited to being performed by this apparatus.

[0262] The apparatus comprises a first means for receiving 610, means for forwarding 620, second means for receiving 630, first means for providing 640, third means for receiving 650, means for checking 660, and second means for providing 670. The first means for receiving 610, means for forwarding 620, second means for receiving 630, first means for providing 640, third means for receiving 650, means for checking 660, and second means for providing 670 may be a first receiving means, first forwarding means, second receiving means, first providing means, third receiving means, checking means, and second providing means, respectively. The first means for receiving 610, means for forwarding 620, second means for receiving 630, first means for providing 640, third means for receiving 650, means for checking 660, and second means for providing 670 may be a first receiver, forwarder, second receiver, first provider, third, receiver, checker, and second provider, respectively, first means for receiving 610, means for forwarding 620, second means for receiving 630, first means for providing 640, third means for receiving 650, means for checking 660, and second means for providing 670 may be a first receiving processor, first forwarding processor, second receiving processor, first providing processor, third receiving processor, checking processor, and second providing processor, respectively.

[0263] The first means for receiving 610 receives a request from a device (S610). The request comprises a subscription identifier and an identifier of the device. The request may be a registration request or an authentication request. The means for forwarding 620 forwards the request to a user data management (S620).

[0264] In response to the forwarding the request to the user data management in S620, the second means for receiving 630 receives a parameter of a challenge and an expected response (S630). In response to the request received in S610, the first means for providing 640 provides the parameter of the challenge to the device (S640). The expected response is not provided to the device. In response to the providing the parameter of the challenge in S640, the third means for receiving 650 receives an authentication response from the device (S650). The means for checking 660 checks whether the authentication response received in S650 is the same as the expected response. In response to checking that the received authentication response is the same as the expected response (S660 = yes), the second means for providing 670 provides an information to the user data management (S670). The information informs that the received authentication response is the same as the expected response.

[0265] Fig. 13 shows a system according to an example embodiment. The system may be an authentication function (such as a combination of UDM and ALISF) or an element thereof. Fig. 14 shows a method according to an example embodiment. The system according to Fig. 13 may perform the method of Fig. 14 but is not limited to this method. The method of Fig. 14 may be performed by the apparatus of Fig. 13 but is not limited to being performed by this system.

[0266] The system comprises first means for receiving 310, first means for generating 320, means for storing 330, second means for receiving 340, means for retrieving 350, second means for generating 360, means for providing 370, third means for receiving 380, means for checking 390, and means for designating 400. The first means for receiving 310, first means for generating 320, means for storing 330, second means for receiving 340, means for retrieving 350, second means for generating 360, means for providing 370, third means for receiving 380, means for checking 390, and means for designating 400 may be a first receiving means, first generating means, storing means, second receiving means, retrieving means, second generating means, providing means, third receiving means, checking means, and designating means, respectively. The first means for receiving 310, first means for generating 320, means for storing 330, second means for receiving 340, means for retrieving 350, second means for generating 360, means for providing 370, third means for receiving 380, means for checking 390, and means for designating 400 may be a first receiver, first generator, storage device, second receiver, retriever, second generator, provider, third receiver, checker, and designator, respectively. The first means for receiving 310, first means for generating 320, means for storing 330, second means for receiving 340, means for retrieving 350, second means for generating 360, means for providing 370, third means for receiving 380, means for checking 390, and means for designating 400 may be a first receiving processor, first generating processor, storing processor, second receiving processor, retrieving processor, second generating processor, providing processor, third receiving processor, checking processor, and designating processor, respectively. The first means for receiving 310 receives, from a device, a first biometric template of a first user along with a device identifier (S310). The device identifier may be predefined for the device, or it may be (or may comprise) actually a subscription identifier (e.g. retrieved from a USIM on the device, if any). The first means for generating 320 generates a first long-term key by a first hash function applied to the first biometric template (S320). The means for storing 330 stores the first long-term key for a subscription identifier (S330). The subscription identifier may be actually the device identifier, a subscription identifier generated by the apparatus (authentication function), or the subscription identifier received along with the first biometric template, if any.

[0267] S310 to S330 correspond to the preparation action 0 of Figs. 4 to 6. After the preparation action 0 is performed, the following actions may be performed.

[0268] The second means for receiving 340 receives a request (such as an authentication request or a registration request) comprising the subscription identifier (S340). The means for retrieving 350 retrieves the first long-term key stored in S330 based on the subscription identifier comprised in the request received in S340 (S350).

[0269] The second means for generating 360 generates a parameter of a challenge and an expected response based on the retrieved first long-term key (S360). In response to the request received in S340, the means for providing 370 provides the parameter of the challenge to the device (S370). The expected response is not provided to the device.

[0270] In response to the providing the parameter of the challenge in S370, the third means for receiving 380 receives an authentication response from the device (S380). The means for checking 390 checks whether the received authentication response is the same as the expected response generated in S360 (S390). In response to checking that the received authentication response is the same as the expected response (S390 = yes), the means for designating 400 designates the device as authenticated (S400).

[0271] Fig. 15 shows an apparatus according to an example embodiment. The apparatus comprises at least one processor 810, at least one memory 820 storing instructions that, when executed by the at least one processor 810, cause the apparatus at least to perform the method according to at least one of the following figures and related description: Fig. 8, or Fig. 10, or Fig. 12, or Fig. 14.

[0272] Some example embodiments are explained with respect to 5GC. However, other example embodiments may be employed in other 3GPP generations, such as 4G, 6G, 7G, etc., or in other environments where the user of a XR device is to be authenticated.

[0273] Some example embodiments are based on the 5G authentication procedure explained with respect to Fig. 1 . However, some example embodiments are not limited to being based on this authentication procedure as long as the following basic phases are achieved:

[0274] • UE initiating registration procedure

[0275] • Home network computes AKA challenge

[0276] • UE authenticated by home network (based on AKA challenge)

[0277] • Authentication result storage

[0278] For example, the task split between the entities may be different from that of Fig. 1. One entity may take over tasks from another entity, or the tasks assigned to one entity may be split onto two or more entities. Also, the details of the algorithms may be different from those currently defined by 3GPP. For example:

[0279] • The user identity (SUPI) may not be concealed into a SUCI.

[0280] • AUSF may not check whether the received serving network name is the same as the expected serving network name (e.g. in a non-roaming scenario).

[0281] • The cryptographic functions and the used number of cryptographic functions may be different from those currently defined by 3GPP. Accordingly, input and / or output of the cryptographic functions and KDF may by different from those currently defined by 3GPP.

[0282] • The hashing algorithm may be different from SHA-256.

[0283] • USIM may not verify the freshness of the authentication vector.

[0284] According to current 3GPP standards and some example embodiments, UDM generates the anchor key KAUSF for establishing the security context along with the generating the challenge (the authentication vector) for the authentication of the device (UE). However, in some example embodiments, UDM may generate the anchor key separately from the generating the challenge (e.g. after the authentication of the device), or the UDM may not be involved in generating such an anchor key (e.g., if the communication between the device and the network is not encrypted, or if a predefined key is used for this communication).

[0285] Some example embodiments are described with respect to a XR device. However the device need not to be a XR device. The device may be any device which allows to generate a biometric template of the user of the device.

[0286] One piece of information may be transmitted in one or plural messages from one entity to another entity. Each of these messages may comprise further (different) pieces of information.

[0287] Names of network elements, network functions, protocols, and methods are based on current standards, or are current proposals. These names are not limiting. For example, in other versions or other technologies, the names of these network elements and / or network functions and / or protocols and / or methods may be different, as long as they provide a corresponding functionality. The same applies correspondingly to the terminal.

[0288] If not otherwise stated or otherwise made clear from the context, the statement that two entities are different means that they perform different functions. It does not necessarily mean that they are based on different hardware. That is, each of the entities described in the present description may be based on a different hardware, or some or all of the entities may be based on the same hardware. It does not necessarily mean that they are based on different software. That is, each of the entities described in the present description may be based on different software, or some or all of the entities may be based on the same software. Each of the entities described in the present description may be deployed in the cloud.

[0289] According to the above description, it should thus be apparent that example embodiments provide, for example, a XR device or an element thereof (which may or may not be actually integrated in the XR device), an apparatus embodying the same, a method for controlling and / or operating the same, and computer program(s) controlling and / or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s). According to the above description, it should thus be apparent that example embodiments provide, for example, an authentication function (such as an ALISF with a UDM) or an element thereof (which may or may not be actually integrated in the authentication function), an apparatus embodying the same, a method for controlling and / or operating the same, and computer program(s) controlling and / or operating the same as well as mediums carrying such computer program(s) and forming computer program product(s).

[0290] Implementations of any of the above described blocks, apparatuses, systems, techniques or methods include, as non-limiting examples, implementations as hardware, software, firmware, special purpose circuits or logic, general purpose hardware or controller or other computing devices, or some combination thereof. Each of the entities described in the present description may be embodied in the cloud.

[0291] It is to be understood that what is described above is what is presently considered the preferred example embodiments. However, it should be noted that the description of the preferred example embodiments is given by way of example only and that various modifications may be made without departing from the scope of the disclosure as defined by the appended claims.

[0292] The terms “first X” and “second X” include the options that “first X” is the same as “second X” and that “first X” is different from “second X”, unless otherwise specified. As used herein, “at least one of the following: ” and “at least one of ” and similar wording, where the list of two or more elements are joined by “and” or “or”, mean at least any one of the elements, or at least any two or more of the elements, or at least all the elements. The term "or" refers to a non-exclusive “or” unless otherwise indicated (e.g., use of “or else” or “or in the alternative”).

Claims

Claims:

1. Apparatus comprising: at least at least one processor, and at least one memory storing instructions that, when executed by the at least at least one processor, cause the apparatus at least to perform: providing, by a device, a first biometric template of a first user to an authentication function of a network along with a device identifier; storing the first biometric template at the device; generating a first long-term key by a first hash function applied to the first biometric template; storing the first long-term key along with a subscription identifier for the first user at the device; receiving an attempt to register a second user at the device using a second biometric template; checking whether the second biometric template is the same as the first biometric template; retrieving the subscription identifier stored along with the first biometric template in response to checking that the first biometric template is the same as the second biometric template; sending a request comprising the retrieved subscription identifier to the authentication function; receiving a parameter of a challenge from the authentication function in response to the sending the request; generating an authentication response based on the first long-term key and the parameter of the challenge; providing the authentication response in response to the receiving the parameter of the challenge, wherein the request is a registration request or an authentication request.

2. The apparatus according to claim 1 , wherein the instructions, when executed by the at least one processor, further cause the apparatus to perform generating an anchor key based on the first long-term key and the parameter of the challenge; communicating with the network based on the anchor key.

3. The apparatus according to any of claims 1 and 2, wherein the instructions, when executed by the at least one processor, further cause the apparatus to perform providing, by the device, multiple biometric templates of the first user including the first biometric template to the authentication function; generating the first long-term key by the first hash function applied to the multiple biometric templates of the first user.

4. The apparatus according to any of claims 1 and 2, wherein the instructions, when executed by the at least one processor, further cause the apparatus to perform providing, by the device, multiple biometric templates of the first user including the first biometric template to the authentication function; receiving, from the authentication function, an indication that the first long-term key is to be generated based on the first biometric template; generating the first long-term key by the first hash function applied to the first biometric template and not based on the multiple biometric templates of the first user different from the first biometric template.

5. The apparatus according to any of claims 1 to 4, wherein the instructions, when executed by the at least one processor, further cause the apparatus to perform indicating, to the authentication function, plural hash functions including the first hash function the device is capable of; receiving, from the authentication function, an indication that the first hash function is to be used for the generating the first long-term key.

6. The apparatus according to any of claims 1 to 5, wherein it is predefined that the first hash function is to be used for the generating the first long-term key.

7. The apparatus according to any of claims 1 to 6, wherein the subscription identifier is the same as a device identifier predefined for the device.

8. The apparatus according to any of claims 1 to 6, wherein the instructions, when executed by the at least one processor, further cause the apparatus to perform retrieving a second long-term key from a subscriber identity module on the device, wherein the second long-term key is related to the subscription identifier;the generating the authentication response based on the first long-term key, the second long-term key, and the parameter of the challenge, wherein the device identifier is the same as the subscription identifier.

9. The apparatus according to any of claims 1 to 6, wherein the instructions, when executed by the at least one processor, further cause the apparatus to perform receiving the subscription identifier from the authentication function in response to the providing the first biometric template; storing the subscription identifier associated with the device identifier; the retrieving the subscription identifier by- retrieving the device identifier in response to checking that the first biometric template is the same as the second biometric template, and- deriving the subscription identifier from the retrieved device identifier based on the stored association between the subscription identifier and the device identifier; wherein the device identifier is predefined for the device.

10. The apparatus according to any of claims 1 to 9, wherein the instructions, when executed by the at least one processor, cause the apparatus to perform the providing, by the device, the first biometric template to the authentication function along with the device identifier via a secure channel; the sending the request to the authentication function, the receiving the parameter of the challenge, and the providing the authentication response via a second channel different from the secure channel.11 . The apparatus according to any of claims 1 to 10, wherein the apparatus comprises or is comprised in a user equipment.

12. Apparatus comprising: at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform: receiving, from a device, a first biometric template of a first user along with a device identifier; generating a first long-term key by a first hash function applied to the first biometric template;storing the first long-term key for a subscription identifier; receiving a request from a authentication server function, wherein the request comprises the subscription identifier; retrieving the first long-term key based on the subscription identifier comprised in the request; generating a parameter of a challenge and an expected response based on the retrieved first long-term key; providing the parameter of the challenge and the expected response to the authentication server function in response to the request; checking whether an information informing that a authentication response received by the authentication server function from the device is the same as the expected response is received from the authentication server function; designating the device as authenticated in response to checking that the information informing that the authentication response received by the authentication server function from the device is the same as the expected response is received from the authentication server function, wherein the request is a registration request or an authentication request.

13. The apparatus according to claim 12, wherein the instructions, when executed by the at least one processor, further cause the apparatus to perform generating an anchor key based on the first long-term key and the parameter of the challenge; forwarding the anchor key to the authentication server function.

14. The apparatus according to any of claims 12 and 13, wherein the instructions, when executed by the at least one processor, further cause the apparatus to perform receiving, for the device from the authentication server function, multiple biometric templates of the first user including the first biometric template of the first user; generating the first long-term key by the first hash function applied to the multiple biometric templates of the first user.

15. The apparatus according to any of claims 12 and 13, wherein the instructions, when executed by the at least one processor, further cause the apparatus to perform receiving, for the device from the authentication server function, multiple biometric templates of the first user including the first biometric template of the first user;providing, to the authentication server function, an indication that the first long-term key is to be generated based on the first biometric template; generating the first long-term key by the first hash function applied to the first biometric template and not based on the multiple biometric templates of the first user different from the first biometric template.

16. The apparatus according to any of claims 12 to 15, wherein the instructions, when executed by the at least one processor, further cause the apparatus to perform receiving, from the authentication server function, a capability indication, wherein the capability indication indicates plural hash functions including the first hash function the device is capable of; informing the authentication server function that the first hash function is to be used for the generating the first long-term key.

17. The apparatus according to any of claims 12 to 16, wherein it is predefined that the first hash function is to be used for the generating the first long-term key.

18. The apparatus according to any of claims 12 to 17, wherein the subscription identifier is the same as the device identifier.

19. The apparatus according to claim 18, wherein the instructions, when executed by the at least one processor, further cause the apparatus to perform retrieving a second long-term key from a data repository based on the subscription identifier; generating the parameter of the challenge and the expected response based on the retrieved first long-term key and the retrieved second long-term key.

20. The apparatus according to any of claims 12 to 17, wherein the instructions, when executed by the at least one processor, further cause the apparatus to perform generating the subscription identifier in response to the receiving the first biometric template along with the device identifier; providing the generated subscription identifier to the authentication server function in response to the request.

21. The apparatus according to any of claims 12 to 20, wherein the instructions, when executed by the at least one processor, further cause the apparatus to perform the receiving the first biometric template along with the device identifier via a secure channel; the receiving the request, the providing the parameter of the challenge and the expected response, and the receiving the information informing that the authentication response received by the authentication server function from the device is the same as the expected response via a second channel different from the secure channel.

22. The apparatus according to any of claims 12 to 21 , wherein the apparatus comprises or is comprised in a user data management.

23. Apparatus comprising: at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the apparatus at least to perform: receiving a request from a device, wherein the request comprises a subscription identifier and an identifier of the device; forwarding the request to a user data management; receiving a parameter of a challenge and an expected response in response to the forwarding the request to the user data management; providing the parameter of the challenge to the device in response to the received request; receiving an authentication response from the device in response to the providing the parameter of the challenge; checking whether the received authentication response is the same as the expected response; providing an information informing that the received authentication response is the same as the expected response to the user data management in response to checking that the received authentication response is the same as the expected response, wherein the request is a registration request or an authentication request.

24. The apparatus according to claim 23, wherein the instructions, when executed by the at least one processor, further cause the apparatus to perform receiving an anchor key from the user data management; allowing a network to communicate with the device based on the anchor key.

25. The apparatus according to any of claims 23 and 24, wherein the instructions, when executed by the at least one processor, further cause the apparatus to perform receiving, from the device, multiple biometric templates of the first user including the first biometric template of the first user; forwarding the multiple biometric templates to the user data management.

26. The apparatus according to any of claims 23 to 25, wherein the instructions, when executed by the at least one processor, further cause the apparatus to perform receiving a capability indication from the device, wherein the capability indication indicates plural hash functions including the first hash function the device is capable of; forwarding the capability indication to the user data management; receiving, from the user data management, an information that the first hash function is to be used for the generating the first long-term key; informing the device that the first hash function is to be used for the generating the first long-term key.

27. The apparatus according to any of claims 23 to 26, wherein the subscription identifier is the same as the device identifier.

28. The apparatus according to any of claims 23 to 26, wherein the instructions, when executed by the at least one processor, further cause the apparatus to perform receiving the subscription identifier in response to the forwarding the request to the user data management; providing the generated subscription identifier to the device.

29. The apparatus according to any of claims 23 to 28, wherein the apparatus comprises or is comprised in a authentication server function.

30. A system, comprising at least one processor, and at least one memory storing instructions that, when executed by the at least one processor, cause the system at least to perform: receiving, from a device, a first biometric template of a first user along with a device identifier; generating a first long-term key by a first hash function applied to the first biometric template;storing the first long-term key for a subscription identifier; receiving a request from a device, wherein the request comprises the subscription identifier; retrieving the first long-term key based on the subscription identifier comprised in the request; generating a parameter of a challenge and an expected response based on the retrieved first long-term key; providing the parameter of the challenge to the device in response to the request; receiving an authentication response from the device in response to the providing the parameter of the challenge; checking whether the received authentication response is the same as the expected response; designating the device as authenticated in response to checking that the received authentication response is the same as the expected response, wherein the request is a registration request or an authentication request.

Images