Network subscriber authentication

Abstract

There is provided techniques for network subscriber authentication for a communication network (100a, 100b). A method is performed by a communication device (200). The method comprises sending (S104) an encoded identifier of the communication device (200) to a network node (300) in the communication network (100a, 100b). The method comprises receiving (S110) information and a digitally signed request for a verifiable presentation (VP) from the network node (300). The method comprises authenticating (S112) the network node (300) by verifying that a digital signature of the digitally signed request belongs to the network node (300). The method comprises sending (S114) a digitally signed VP to the network node (300). The method comprises receiving (S116) a message indicating successful authentication of the communication device (200) from the network node (300).

Description

[0001] NETWORK SUBSCRIBER AUTHENTICATION

[0002] TECHNICAL FIELD

[0003] Embodiments presented herein relate to methods, a communication device, a network node, a computer program, and a computer program product for network subscriber authentication for the communication device in the communication network.

[0004] BACKGROUND

[0005] In fourth generation (4G), and earlier generations, telecommunication networks, subscriber authentication is based on the Authentication and Key Agreement (AKA) protocol. The AKA protocol leverages a shared secret key between the subscriber and the network. This shared secret key is provided by the mobile network provider, or operator, to the subscriber and is securely stored in a communication device, also known as User Equipment (UE), on the Subscriber Identity Module or Subscriber Identification Module (SIM) card, also known as universal integrated circuit card (UICC), or embedded UICC (eUICC), integrated UICC (iUICC), or integrated embedded UICC (ieUICC) with the introduction of embedded SIM (eSIM) and integrated SIM (iSIM). The SIM card also handles all operations involving the shared secret key. The shared secret key is also securely stored by the telecommunication network in the Unified Data Management (UDM), Home Subscriber Server (HSS), Authentication Center (AuC) or Home Location Register (HLR).

[0006] In fifth generation (5G) telecommunication networks (based on 3GPP release 15 or later, where 3GPP is short for the 3rd generation partnership project) subscriber authentication leveraging the Extensible Authentication Protocol (EAP) is also standardized. EAP is an authentication framework frequently used in networks (e.g., wireless local area networks, commonly referred to as WiFi networks) and Internet connections. The EAP is run between an authenticator and a peer. The authenticator sends EAP Requests to the peer and receives EAP Responses in return. One or more Request-Response pairs are exchanged until the authenticator has authenticated the peer (and possibly the peer has also authenticated the authenticator). The authenticator may be in pass-through mode where a (back-end) Authentication Server (e.g., an authentication, authorization, and accounting (AAA) server) performs authentication on behalf of the authenticator. The pass-through mode is used in 5G systems where the UE is the peer, an Access and Mobility Management Function or a Security Anchor Function (AMF / SEAF) is the authenticator in pass-through mode, and an Authentication Server Function (AUSF) is the authentication server.

[0007] In general terms, the EAP allows the use of different EAP methods, in turn relying on different types of authentication mechanisms and credentials. Each EAP method has defined EAP messages that are exchanged within the EAP framework for requests and responses. For public 5G networks, currently only the EAP -AKA’ method is allowed, where AKA’ is short for AKA prime. This method leverages the AKA protocol and a shared secret key between the subscriber and the cellular network. For private 5G networks (so-called non-public networks (NPN)) other EAP methods, such as EAP-TLS (where TLS is short for Transport Layer Security), using alternative credentials such as certificates or verifiable credentials are also possible. The document 3GPP TS 33.501 V18.4.0 discloses 5G AKA and EAP -AKA’ in its clause 6.1.3 and EAP-TLS in, for example, its Annex B.

[0008] However, there is a need for improved network subscriber authentication.

[0009] SUMMARY

[0010] While the authentication procedures based on utilizing the SIM as described above are successful, there is an increasing use of authentication procedures that do use other identity technologies, such as verifiable credentials, that have wider use than only network access and also take into consideration privacy and trust. On the other hand, EAP provides a framework for authentication only, but relies on actual, possibly hardware enabled, identity technologies. Having dedicated hardware only for the purpose of subscriber authentication adds extra cost and naturally makes the communication system more complex. Hence, there is room for improved network subscriber authentication.

[0011] An object of embodiments herein is to enable communication network subscriber authentication that uses alternative credentials which are not based on the shared key stored in the UE for EAP -AKA’ and other 3GPP AKA methods like 5G AKA.

[0012] Authentication using alternative credentials enable authentication flexibility and may also provide improved security with respect to privacy and trust. In this respect, the European Union Digital Identity (EUDI) Wallet verifiable credential referred to as Person Identification Data (PID) was originally designed to identify and authenticate natural persons at public and private services. In further detail, the EUDI Wallet supports verifiable presentations based on verifiable credentials using ISO / IEC 18013-5:2021 involving the ISO / IEC 18013-5:2021 data model and Open ID for Verifiable Presentations (OpenID4VP) involving W3C Verifiable Credentials Data Model 1.1. However, according to The Common Union Toolbox for a Coordinated Approach Towards a European Digital Identity Framework, published as part of The European Digital Identity Wallet Architecture and Reference Framework, April 2023, version 1.1.0, the EUDI Wallet does not support EAP-TLS for use in subscriber authentication, neither does it support any other EAP method. Hence, although the EUDI Wallet potentially could be used for subscriber authentication to a communication network leveraging verifiable credentials of the EUDI Wallet, today it cannot. This is due to its lack of support for EAP-TLS. As a consequence, it is not possible today to use the PID for subscriber authentication.

[0013] A particular object is therefore to provide network subscriber authentication where it is possible to utilize credentials of a digital identity (DI) wallet.

[0014] According to a first aspect there is presented a method for network subscriber authentication for a communication network. The method is performed by a communication device. The method comprises sending an encoded identifier of the communication device to a network node in the communication network. The method comprises receiving information and a digitally signed request for a Verifiable Presentation (VP) from the network node. The information specifies formatting of the VP. The digitally signed request identifies at least one attribute of a VC of the communication device. The Verifiable Credential (VC) is stored in a DI wallet entity residing in the communication device. The method comprises authenticating the network node by verifying that a digital signature of the digitally signed request belongs to the network node. The method comprises sending a digitally signed VP to the network node. The digitally signed VP comprises the at least one attribute of the VC and has been digitally signed by the DI wallet entity and is of a format given by the specified formatting. The method comprises receiving a message indicating successful authentication of the communication device from the network node.

[0015] According to a second aspect there is presented a communication device for network subscriber authentication for a communication network. The communication device comprises processing circuitry. The processing circuitry is configured to cause the communication device to send an encoded identifier of the communication device to a network node in the communication network. The processing circuitry is configured to cause the communication device to receive information and a digitally signed request for a VP from the network node. The information specifies formatting of the VP. The digitally signed request identifies at least one attribute of a VC of the communication device. The VC is stored in a DI wallet entity residing in the communication device. The processing circuitry is configured to cause the communication device to authenticate the network node by verifying that a digital signature of the digitally signed request belongs to the network node. The processing circuitry is configured to cause the communication device to send a digitally signed VP to the network node. The digitally signed VP comprises the at least one attribute of the VC and has been digitally signed by the DI wallet entity and is of a format given by the specified formatting. The processing circuitry is configured to cause the communication device to receive a message indicating successful authentication of the communication device from the network node.

[0016] According to a third aspect there is presented a computer program for network subscriber authentication for a communication network. The computer program comprises computer code which, when run on processing circuitry of a communication device, causes the communication device to perform actions. One action comprises the communication device to send an encoded identifier of the communication device to a network node in the communication network. One action comprises the communication device to receive information and a digitally signed request for a VP from the network node. The information specifies formatting of the VP. The digitally signed request identifies at least one attribute of a VC of the communication device. The VC is stored in a DI wallet entity residing in the communication device. One action comprises the communication device to authenticate the network node by verifying that a digital signature of the digitally signed request belongs to the network node. One action comprises the communication device to send a digitally signed VP to the network node. The digitally signed VP comprises the at least one attribute of the VC and has been digitally signed by the DI wallet entity and is of a format given by the specified formatting. One action comprises the communication device to receive a message indicating successful authentication of the communication device from the network node.

[0017] According to a fourth aspect there is presented a method for network subscriber authentication for a communication device in a communication network. The method is performed by a network node in the communication network. The method comprises receiving an encoded identifier of the communication device from the communication device. The method comprises selecting an authentication process for authenticating the communication device based on an identifier retrieved by the network node from the encoded identifier. The method comprises sending information and a digitally signed request for a VP to the communication device. The information is given by the selected authentication process and at least specifies formatting of the VP. The digitally signed request identifies at least one attribute of a VC of the communication device. The method comprises receiving a digitally signed VP from the communication device. The digitally signed VP comprises the at least one attribute of the VC. The method comprises authenticating the communication device by verifying said at least one attribute, by verifying that a digital signature of the digitally signed VP belongs to the communication device, and by verifying that the VP is of a format given by the specified formatting. The method comprises sending a message indicating successful authentication of the communication device to the communication device.

[0018] According to a fifth aspect there is presented a network node for network subscriber authentication for a communication device in a communication network. The network node comprises processing circuitry. The processing circuitry is configured to cause the network node to receive an encoded identifier of the communication device from the communication device. The processing circuitry is configured to cause the network node to select an authentication process for authenticating the communication device based on an identifier retrieved by the network node from the encoded identifier. The processing circuitry is configured to cause the network node to send information and a digitally signed request for a VP to the communication device. The information is given by the selected authentication process and at least specifies formatting of the VP. The digitally signed request identifies at least one attribute of a VC of the communication device. The processing circuitry is configured to cause the network node to receive a digitally signed VP from the communication device. The digitally signed VP comprises the at least one attribute of the VC. The processing circuitry is configured to cause the network node to authenticate the communication device by verifying said at least one attribute, by verifying that a digital signature of the digitally signed VP belongs to the communication device, and by verifying that the VP is of a format given by the specified formatting. The processing circuitry is configured to cause the network node to send a message indicating successful authentication of the communication device to the communication device.

[0019] According to a sixth aspect there is presented a computer program for network subscriber authentication for a communication device in a communication network. The computer program comprises computer code which, when run on processing circuitry of a network node, causes the network node to perform actions. One action comprises the network node to receive an encoded identifier of the communication device from the communication device. One action comprises the network node to select an authentication process for authenticating the communication device based on an identifier retrieved by the network node from the encoded identifier. One action comprises the network node to send information and a digitally signed request for a VP to the communication device. The information is given by the selected authentication process and at least specifies formatting of the VP. The digitally signed request identifies at least one attribute of a VC of the communication device. One action comprises the network node to receive a digitally signed VP from the communication device. The digitally signed VP comprises the at least one attribute of the VC. One action comprises the network node to authenticate the communication device by verifying said at least one attribute, by verifying that a digital signature of the digitally signed VP belongs to the communication device, and by verifying that the VP is of a format given by the specified formatting. One action comprises the network node to send a message indicating successful authentication of the communication device to the communication device.

[0020] According to a seventh aspect there is presented a computer program product comprising a computer program according to at least one of the third aspect and the sixth aspect and a computer readable storage medium on which the computer program is stored. The computer readable storage medium could be a non-transitory computer readable storage medium.

[0021] According to an eight aspect there is provided a system comprising a communication device according to the second aspect and a network node according to the fifth aspect.

[0022] Advantageously, these aspects enable the digital identity of a natural person, handled by the DI wallet entity of the natural person, to be leveraged for network subscriber authentication.

[0023] Advantageously, these aspects do not require any changes to the DI wallet entity interface.

[0024] Advantageously, these aspects do not require communication devices to support dedicated (additional) tamper-resistant hardware for the purpose of storing and using network authentication credentials.

[0025] Advantageously, these aspects can be used for authentication of a subscriber not only to public mobile networks, but also for enterprise networks.

[0026] Other objectives, features and advantages of the enclosed embodiments will be apparent from the following detailed disclosure, from the attached dependent claims as well as from the drawings.

[0027] Generally, all terms used in the claims are to be interpreted according to their ordinary meaning in the technical field, unless explicitly defined otherwise herein. All references to "a / an / the element, apparatus, component, means, module, step, etc." are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, module, step, etc., unless explicitly stated otherwise. The steps of any method disclosed herein do not have to be performed in the exact order disclosed, unless explicitly stated.

[0028] BRIEF DESCRIPTION OF THE DRAWINGS

[0029] The inventive concept is now described, by way of example, with reference to the accompanying drawings, in which: Figs. 1(a) and 1(b) are schematic diagrams illustrating a communication network according to embodiments;

[0030] Fig. 2 is a signaling diagram of a method according to an embodiment;

[0031] Figs. 3 and 4 are flowcharts of methods according to embodiments;

[0032] Fig. 5, 6, and 7 are signaling diagrams of methods according to embodiments;

[0033] Fig. 8 is a schematic diagram showing structural units of a communication device according to an embodiment;

[0034] Fig. 9 is a schematic diagram showing functional modules of a communication device according to an embodiment;

[0035] Fig. 10 is a schematic diagram showing structural units of a network node according to an embodiment;

[0036] Fig. 11 is a schematic diagram showing functional modules of a network node according to an embodiment; and

[0037] Fig. 12 shows one example of a computer program product comprising computer readable means according to an embodiment.

[0038] DETAILED DESCRIPTION

[0039] The inventive concept will now be described more fully hereinafter with reference to the accompanying drawings, in which certain embodiments of the inventive concept are shown. This inventive concept may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided by way of example so that this disclosure will be thorough and complete, and will fully convey the scope of the inventive concept to those skilled in the art. Like numbers refer to like elements throughout the description. Any step or feature illustrated by dashed lines should be regarded as optional.

[0040] The wording that a certain data item, piece of information, etc. is obtained by a first entity should be construed as that data item or piece of information being retrieved, fetched, received, or otherwise made available to the first entity. For example, the data item or piece of information might either be pushed to the first entity from a second entity or pulled by the first entity from the second entity. Further, in order for the first entity to obtain the data item or piece of information, the first entity might be configured to perform a series of operations, possible including interaction with the second entity. Such operations, or interactions, might involve a message exchange comprising any of a request message for the data item or piece of information, a response message comprising the data item or piece of information, and an acknowledge message of the data item or piece of information. The request message might be omitted if the data item or piece of information is neither explicitly nor implicitly requested by the first entity.

[0041] The wording that a certain data item, piece of information, etc. is provided by a first entity to a second entity should be construed as that data item or piece of information being sent or otherwise made available to the second entity by the first entity. For example, the data item or piece of information might either be pushed to the second entity from the first entity or pulled by the second entity from the first entity. Further, in order for the first entity to provide the data item or piece of information to the second entity, the first entity and the second entity might be configured to perform a series of operations in order to interact with each other. Such operations, or interaction, might involve a message exchange comprising any of a request message for the data item or piece of information, a response message comprising the data item or piece of information, and an acknowledge message of the data item or piece of information. The request message might be omitted if the data item or piece of information is neither explicitly nor implicitly requested by the second entity.

[0042] According to at least some of the herein disclosed embodiments, the DI wallet of a natural person (NP) is leveraged for subscriber authentication when connecting to a cellular network or to a WiFi network that supports a framework for authentication such as EAP for subscriber authentication. In some examples, the Person Identification Data (PID) for establishing the identity of the natural person or legal person is leveraged in the authentication. An attestation protocol supported by the DI wallet is used for providing a VP of attributes of one or more Verifiable Credentials (e.g., PID and / or (Q)EAA) to the cellular or WiFi network, where the cellular or WiFi network takes the role of the verifier. In particular the ISO / IEC 18013-5 protocol leveraging Concise Binary Object Representation (CBOR) encoded messages and Verifiable Credential(s) are in mdoc format (as defined in IS0 / IEC18013-5) can be used. According to at least some of the herein disclosed embodiments, the ISO / IEC 18013-5 protocol is tunneled inside EAP. Alternatively, ISO / IEC 18013-7 maybe leveraged that relies on ISO / IEC 18013-5 request-response exchange of protocol data but where the protocol data leverages JSON encoded messages instead of CBOR encoded messages. Yet alternatively, the OpenlD for VP protocol (OpenlDqVP) supported by the DI wallet is tunneled inside the EAP protocol.

[0043] Figs. 1(a) and 1(b) are schematic diagrams illustrating systems 100a, 100b where embodiments presented herein can be applied. The system 100a here represents a communication network in the form of a cellular communication network. The system 100a comprises a communication device 200, a serving mobile network 120, such as a 5G network, a home mobile network 130 such as a 5G network, and a (Qualified) Trust Service Provider (Q)TSP entity no. In turn, the communication device 200 comprises a DI wallet entity 240 and a cellular modem 250a. The serving mobile network 120 comprises an AMF node or an SEAF node 150. The home mobile network 130 comprises network nodes in terms of an AUSF node 300a and a UDM node 300b. The system 100b represents a WiFi communication network. The system 100b comprises a communication device 200, a WiFi network 160, an AAA server 300c, and a (Q)TSP entity no. In turn, the communication device 200 comprises a DI wallet entity 240 and a WiFi module 250b. The WiFi network 160 comprises an EAP authenticator. Further aspects of these entities will be disclosed in further detail next. In general terms, the AUSF node 300a, the node UDM 300b, and the AAA server 300c will hereinafter collectively be referred to as network nodes 300. It is noted that the cellular communication network in Fig. 1(a) and the WiFi communication network in Fig. 1(b) are only two examples of wireless communication networks where the herein disclosed embodiments apply.

[0044] Additionally, the herein disclosed embodiments are also applicable to other types of communication networks, such as wired communication networks and communication networks that are partly wireless and partly wired.

[0045] The communication device 200 might be an loT device, a networked-equipped sensor device, a network-equipped vehicle, a network-equipped gaming control, a user equipment (UE), a smartphone, a laptop computer, or a tablet computer. The communication device 200 might belong to a natural person (NP), also referred to as the user of the communication device 200. Hence, the terms natural person and user can be used interchangeably. The communication device 200 might be configured to support one or more communication protocols for interacting with other entities in the system 100a, 100b. For this purpose, the communication device 200 might be provided with a communication interface supporting any, or any combination of, WiFi communication, and wireless cellular communication. In the example of Fig. 1(a) the communication interface at least implements a cellular modem 250a. In the example of Fig. 1(b) the communication interface at least implements a WiFi module 250b. Further, the communication interface supports connecting to communication networks using FAP for the authentication of the subscriber. The communication device therefore implements EAP peer support and EAP techniques described below for tunneling of protocols for VP of attestation attributes. The EAP implementation maybe part of the cellular modem or the WiFi module or it maybe located outside of the cellular modem or WiFi module and, e.g., part of the application processor of the communication device 200.

[0046] The DI wallet entity 240 is illustrated as being comprised in the communication device 200. In general terms, the DI wallet entity can be regarded as hardware which comprises a DI wallet in the form of software. An example is a processor which comprises a DI wallet application in the communication device 200. In this respect, the hardware that comprises the DI wallet can be shared with the communication device 200. For example, the processor which comprises the DI wallet application can be used also for other purposes, such as running other types of software, applications, etc., in the communication device 200 that are, and / or are not, related to the DI wallet. The DI wallet (and thus the DI wallet entity) enables the user (i.e., the natural person) to store, manage, and share personal identity and credential information with other entities, functions, nodes, and devices, in a secure manner. Some nonlimiting examples of information that can be stored, managed, and shared by the DI wallet entity are: the identity of the user, the date of birth of the user, nationality of the user, work permits of the user, driver's license details of the user, medical prescription of the user, etc. The DI wallet entity can, for example, be used as a means for identification or confirmation of certain personal attributes for the purpose of enabling the user to access public and / or private digital services. Further in this respect, the DI wallet entity might support different sets of attributes for attestation. For example, the DI wallet entity might support Person Identification Data (PID) for establishing the identity of the natural person. For example, the DI wallet entity might support Electronic Attestation of Attributes (EAA) which are attributes about the natural person or legal person issued by the (Q)TSP. For example, the DI wallet entity might support Qualified Electronic Attestation of Attributes (QEAA) which are EAAs issued by a QTSP. A set of attributes for attestation is also known as a credential or VC. Among other things, the DI wallet entity might be configured to support requesting and receiving VC about the natural person from (Q)TSP entities according to Open ID for VC Issuance (OpenlDqVCI) supporting both ISO / IEC 18013-5 and W3C Verifiable Credentials Data Model. The DI wallet entity might further be configured to support presentation of a combination of attributes from one or more VCs about the natural person, as selected by the natural person, to relying parties in a VP according to the following protocols: OpenlDqVP for remote flows involving W3C Verifiable Credentials Data Model, ISO / IEC 18013-5 for proximity flows involving ISO / IEC 18013-5 data model, ISO / IEC 18013-7 for remote flows involving ISO / IEC 18013-5 data model.

[0047] The PID and / or other (Q)EAA of the DI wallet entity can be leveraged for subscriber authentication to a cellular network or a WiFi network. In one example the DI wallet entity leverages the PID for subscriber authentication and does not have a dedicated (Q)EAA / VC from the mobile network operator. In another example a dedicated (Q)EAA / VC in the DI wallet entity contains subscriber information and information about the cellular network.

[0048] The cellular network can be either a public cellular network or a private (non-public) cellular network and supports the EAP framework for subscriber authentication (so- called primary authentication). The AMF / SEAF takes the role of the pass-through authenticator and the AUSF takes the role of the authentication server. In case of roaming, it is the AMF / SEAF of the serving network and the AUSF of the home network that take these roles. The UDM (of the home network) stores subscriber and subscription data. The AUSF may interact with Certificate Authorities (CAs) and / or (Q)TSP during the authentication of the communication device 200.

[0049] The WiFi network supports the EAP framework for subscriber authentication. The

[0050] WiFi access point (AP) takes the role of the authenticator. The AP is typically in pass- through mode and an AAA server takes the role of the authentication server. The AAA server may interact with CAs and / or (Q)TSP during the authentication of the communication device 200.

[0051] The (Q)TSP entity is configured to provide one or more trust services (TS) either as a qualified or as a non-qualified trust service provider. A qualified trust service provider is a TSP who provides one or more qualified trust services (QTS) and is granted the qualified status by some supervisory body. The decision of the supervisory body to grant the qualified status is reflected in a corresponding Trusted List. In this respect, QTSPs are mandatorily listed in a corresponding Trust List while TSP could be, but are not mandatorily, listed in these Trust Lists. The (Q)TSP is configured to provide the (Q)TS of issuing Verifiable Credentials. In particular, the QTSP may be a PID provider providing PIDs to the DI wallet entity for establishing the identity of a natural person or legal person, but may also be a (Q)EAA provider providing (Q)EAA with attributes relevant for subscriber authentication. The (Q)TSP supports issuance of Verifiable Credentials according to OpenlDqVCI, supporting both ISO / IEC 18013-5, ISO / IEC 18013-7 and W3C Verifiable Credentials Data Model. Specifically, for the PID, other protocols may be used for the issuance and related to the DI wallet provisioning.

[0052] A first example of network subscriber authentication for a communication device 200 in a communication network will be disclosed next with reference to the signaling diagram of Fig. 2. This example shows network subscriber authentication when a communication device attaches to a communication network. The method covers communication networks in terms of public cellular networks, private (non-public) cellular networks, local area networks, other types of communication networks, as well as multiple VP protocols being used and tunneled inside EAP for the authentication. In particular, ISO / IEC 18013-5, ISO / IEC 18013-7, and OpenlDqVP are covered.

[0053] For ISO / IEC 18013-5, the communication network (or more precisely: one or more network node residing in the communication network) takes the role of the mdoc (mDL) verifier and the DI wallet entity in the communication device takes the role of the mdoc (mDL) holder. CBOR encoded messages transported inside EAP protocol messages are exchanged between the communication network and the communication device.

[0054] For ISO / IEC 18013-7, the communication device and the communication network corresponds to the same entities as for ISO / IEC18O-13-5 and essentially the same set of messages as in ISO / IEC 18013-5 is used but JavaScript Object Notation (JSON) encoded instead of CBOR encoded.

[0055] For OpenID4VP, the communication network (or more precisely: one or more network node residing in the communication network) takes the role of the OpenlD / OAuth 2.0 relying party / client and the DI wallet entity in the communication device takes the role of the OpenlD Provider / OAuth 2.0 Authorization server. The communication network can request a VP according to the W3C VC data model or the ISO / IEC mdoc model and a VP is delivered as a JSON Web Token (JWT). In some examples, a selective disclosure JWT, SD-JWT, is used.

[0056] When the procedure starts the DI wallet entity is equipped with a PID, but may also be equipped with (Q)EAAs that are usable in the subscriber authentication.

[0057] Step 10: Prepare encoded identifier based on identifier data from DI wallet entity.

[0058] The communication device receives identifier data from the DI wallet entity. This is either a wallet / VC identifier or device engagement data.

[0059] One way for the communication device to prepare the encoded identifier is by encrypting the identifier from the DI wallet entity. For example, the encoded identifier could be a Subscriber Concealed Identifier (SUCI) created and formatted by following a procedure for SUCI creation, as standardized for the 5G system by 3GPP, where the identifier from the DI wallet replaces the 5G Subscription Permanent Identifier (SUPI), as e.g., represented by an International Mobile Subscriber Identity (IMSI). The SUPI and SUCI may for example be formatted using the Network Access Identifier (NAI) format.

[0060] Another way for the communication device to prepare the encoded identifier is by creating an anonymous encoded identifier that might contain the device engagement data. For example, the format of the encoded identifier could here follow the SUCI format. Another way for the communication device to prepare the encoded identifier is by using the received identifier from the DI wallet entity as the encoded identifier.

[0061] Step 12: Registration request (encoded identifier).

[0062] The communication device sends the encoded identifier to the communication network. The encoded identifier may be sent in a registration request or in an identity response to an identity request from the communication network following a registration request.

[0063] Step 14: Decode encoded identifier, select authentication procedure.

[0064] A network node in the communication network decodes the encoded identifier to obtain the identifier and possibly also device engagement data. The network node uses the retrieved identifier to select authentication procedure. Here, attestation involving any of ISO / IEC 18013-5, ISO / IEC 18013-7, and / or OpenlD VP is selected. In case of an anonymous SUCI either a default authentication procedure is selected, or the anonymous SUCI provides information about the desired authentication procedure.

[0065] Step 16: EAP Request / VP-DE.

[0066] Step 18: Generate device engagement data.

[0067] Step 20: EAP Response / VP-DE.

[0068] If no device engagement data was obtained in step 14 and device engagement data is used, an EAP Request for requesting device engagement data in step 16 is prepared by a network node in the communication network. If a request for device engagement data was received by the communication device, the DI wallet entity generates device engagement data in step 18. The device engagement data is then returned by the communication device in an EAP Response to the communication network in step 20.

[0069] Step 22: Generate VP request using device engagement data.

[0070] A request for a VP is generated by a network node in the communication network.

[0071] The request for a VP is digitally signed using the network private key and may be encrypted leveraging ephemeral key pairs of the communication device (where the ephemeral public key is part of device engagement data, if such data is available) and the network (generated in this step and where the network ephemeral public key is included in the VP request, but not encrypted). The signature covers the network ephemeral public key. In case of OpenlD VP the request for a VP is a JSON encoded Authorization Request.

[0072] Step 24: EAP Request / VP-attest.

[0073] An EAP Request / VP -Attest that comprises the digitally signed VP request (possibly encrypted) is prepared by a network node in the communication network and sent to the communication device.

[0074] Step 26: Verify VP request to authenticate network and generate VP based on VP request.

[0075] The communication device extracts the digitally signed VP request, decrypts it if it was encrypted, and verifies the VP request signature to authenticate the communication network (or more particularly: a network node in the communication network). Upon successful verification, the communication device generates a VP based on the requested attributes of the Verifiable Credential(s) (e.g., comprising the unique identifier of the PID) as specified in the VP request. The VP is signed by the private key of the DI wallet entity. The VP is also encrypted leveraging the ephemeral key pairs. If no device engagement data with an associated ephemeral key pair was sent from the communication device earlier, then a device ephemeral key pair is generated and used in the encryption. The device ephemeral public key is then included in the VP signed data and sent to the communication network with the VP. In case of OpenlD VP the VP is encoded as a JSON Web Token (JWT), e.g., an SD- JWT.

[0076] Step 28: EAP Response / VP-attest.

[0077] The communication device prepares an EAP Response / VP -Attest comprising the encrypted VP and sends the EAP Response / VP -Attest to the communication network.

[0078] Step 30: Revocation information, etc. Step 32: Verify VP to authenticate device.

[0079] A network node in the communication network decrypts the encrypted VP, and verifies the VP signature and included attributes to authenticate the communication device. The network node may interact with the (Q)TSPs that provided the PID / (Q)EAAs or other CAs to obtain revocation information of certificates when verifying the certificates as part of the verification of the VP.

[0080] Step 34: EAP-Success.

[0081] Upon successful verification and authentication of the communication device, an EAP Success message is prepared by a network node in the communication network. The EAP Success message is provided to the communication device to indicate successful authentication.

[0082] Step 36: Derive keys for secure communication.

[0083] Step 38: Derive keys for secure communication.

[0084] The communication device and a network node in the communication network each computes shared key material for use in establishing secure communication. The key material is based on the ephemeral key pairs and exchanged information in the previous steps.

[0085] The set of attributes requested by the communication network in step 22 may vary. For example, if the subscriber authenticates for the first time, the communication network may want to perform attestation of several attributes and in subsequent attestations only one or a few are requested. In case of anonymous identifier being sent to the communication network in step 12, the communication network cannot know if it is the first time for attestation. In this case several rounds of steps 22-32 can be made. The communication network may then perform a first roundtrip of steps 22-32 where only one or a few attributes are requested, including an identifier of the communication device. Then the communication network, based on checking the identifier, can determine whether more roundtrips are needed to retrieve further attributes or not. Reference is next made to Fig. 3 illustrating a method for network subscriber authentication for a communication network as performed by the communication device 200 according to an embodiment.

[0086] S104: The communication device 200 sends an encoded identifier of the communication device 200 to a network node 300 in the communication network. Examples of such an encoded identifier will be disclosed below.

[0087] S110: The communication device 200 receives information and a digitally signed request for a VP from the network node 300. The information specifies formatting of the VP. The digitally signed request identifies at least one attribute of a VC of the communication device 200. The VC is stored in a DI wallet entity residing in the communication device 200.

[0088] S112: The communication device 200 authenticates the network node 300 by verifying that a digital signature of the digitally signed request belongs to the network node 300.

[0089] S114: The communication device 200 sends a digitally signed VP to the network node 300. The digitally signed VP comprises the at least one attribute of the VC (as identified in the request received in S110). The digitally signed VP has been digitally signed by the DI wallet entity. The digitally signed VP is of a format given by the specified formatting.

[0090] S116: The communication device 200 receives a message indicating successful authentication of the communication device 200 from the network node 300.

[0091] Embodiments relating to further details of network subscriber authentication for a communication network as performed by the communication device 200 will now be disclosed with continued reference to Fig. 3.

[0092] There may be different types of encoded identifiers. Different embodiments relating thereto will now be described in turn.

[0093] In some aspects, the encoded identifier is based on data obtained from the DI wallet entity. Therefore, in some embodiments, the communication device 200 is configured to perform (optional) step S102. S102: The communication device 200 obtains identifier data of the communication device 200 from the DI wallet entity. The encoded identifier can then be based on the identifier data obtained from the DI wallet entity.

[0094] The identifier data could here, for example, be the unique identifier of the PID. The encoded identifier of the communication device 200 could be a SUCI in NAI format and where the unique identifier from the PID replaces the 5G Subscription Permanent Identifier (SUPI) and is encrypted. For example, the SUCI could be formatted as typeo.rid<routing_indicator>.schidi.hnkey<hn_key_id>.ecckey<ECC_ephemeral_p ublic_key>.cip<encrypted_id>.mac<MAC_tag_value>@5gc.mnc<MNC>.mcc<MCC >.3gppnetw0rk.0rg, where "<MNC>" and "<MCC>" fields correspond to the mobile network code, MNC, and mobile country code, MCC, of the home mobile network, rid is the routing indicator, schid is the protection scheme identifier, hnkey is the home network key identifier, ecckey is the ephemeral public key of the ephemeral key pair generated by the device for protection of the identifier, cip is the encrypted identifier, and mac is the mac tag value for the integrity protection.

[0095] In other aspects, the identifier data does not reveal any information that is stored by the DI wallet entity. One example of creating such identifier data is to create an anonymous SUCI in NAI format such as typei.rid<routing_indicator>.schido.anonymous_<method_support>@5gc.mnc<M NC>.mcc< MCC >.3gppnetw0rk.0rg, where “<method_support>” is optional and provides information to the network node 300 about supported authentication methods and can be used by the network node 300 in the selection of the authentication process.. Therefor / e, in some embodiments, the encoded identifier is an encoded anonymous identifier.

[0096] As disclosed above with reference to the method in Fig. 2, in some embodiments, the encoded identifier comprises encoded device engagement data of the communication device 200. For example, an encoded identifier with device engagement data could be formatted as follows: typei.rid<routing_indicator>.schido.anonymous_<DE_dataxmethod_support>@ 5gc.mnc<MNC>.mcc<MCC>.3gppnetw0rk.0rg. However, in other embodiments, the encoded identifier does not comprise any such encoded device engagement data. Then, in case the network node 300 requires engagement data, the network node 300 will send a request for engagement data to the communication device 200. Further aspects of this will be disclosed below.

[0097] There could be different stages, or phases, or the authentication process for the communication device 200 to send the encoded identifier. For example, in some embodiments, the encoded identifier is sent to the network node 300 in either a registration request message or an identity response message. The registration request message and the identity response message should here be interpreted as being part of a 3GPP context.

[0098] If a request for device engagement data was received by the communication device 200, then the DI wallet entity should generate this device engagement data. The device engagement data can then be returned to the network (for example in an EAP Response message). In particular, in some embodiments, the communication device 200 is configured to perform (optional) steps S106 and S108.

[0099] S106: The communication device 200 receives a request for device engagement data of the communication device 200 from the network node 300.

[0100] S108: The communication device 200 sends the device engagement data to the network node 300, wherein the device engagement data has been generated by the DI wallet entity.

[0101] As disclosed above, the information received in step S110 specifies formatting of the VP. In this respect, there could be different ways how the VP is formatted and thus also different ways to describe how the VP is to be formatted. As will be further disclosed below, the information that specifies formatting of the VP is given by an authentication process selected by the network node 300. As will also be further disclosed below, in some examples, the authentication process follows any of: ISO / IEC 18013-5, ISO / IEC 18013-7, OpenlDqVP. In this respect, the VP could be either an mdoc according to ISO / IEC 18013-5 (or ISO / IEC 18013-7) or a JSON Web Token according to OpenlDqVP and following the W3C VC data model. Further, in some examples, the formatting of the VP pertains to how the VP is to be signed and / or encoded. That is, in some embodiments, the formatting of the VP pertains to at least one of: how the VP is to be digitally signed before being sent to the network node 300, how the VP is to be encoded before being sent to the network node 300.

[0102] As disclosed above, the digitally signed VP that is sent in S114 comprises the at least one attribute of the VC (as identified in the request received in S110). Examples of such attributes have already been disclosed with reference to the description of the DI wallet entity in Figs. 1(a) and 1(b) and those examples apply here as well. In particular, in some embodiments, the at least one attribute at least specifies a unique identifier of personal identification data (PID) of a VC of the communication device 200. That the identifier is unique here implies that the identifier value in combination with issuing state is unique for each natural person within EU. Further, the digitally signed VP might at least comprise the identifier data of the communication device 200 as attribute.

[0103] In general terms, the messages exchanged between the communication device 200 and the network node 300 could be encrypted using various encryption schemes. For this purpose, in some embodiments, the received digitally signed request is encrypted, and the method comprises decrypting, step S106-2, the encrypted digitally signed request using an encryption key. Likewise, in some embodiments, the digitally signed VP is encrypted, and the method comprises encrypting, step S114-2, the signed VP using an encryption key before it is sent to the network node 200, whereby the signed VP is sent encrypted to the network node 300. In this respect, in some embodiments, the encryption key is derived using a private-public key pair generated by the DI wallet entity of the communication device 200 and a public key of the network node 300. In some examples, the encryption key is derived from an elliptic curve Diffie-Hellman (ECDH) shared secret derived from the private key of the private-public key pair of the DI wallet entity and the public key of the network node 300. In some examples, at least one or both of the private-public key pair and the public key are ephemeral and generated for the subscriber authentication session. A public key of the private-public key pair generated by the DI wallet entity is either provided as part of device engagement data or together with the encrypted digitally signed VP. Hence, one purpose of the device engagement data is to facilitate encryption of the messages exchanged between the communication device 200 and the network node 300. In some other examples, the encryption key is established using a Key Encapsulating Method (KEM) like Module-Lattice-based Key Encapsulation Method (ML-KEM), where a ciphertext is received from the network node 300 along with the (encrypted) VP request and where the DI wallet entity obtains the encryption key from the ciphertext using the private key of the privatepublic key pair generated by the DI wallet entity of the communication device 200. Alternatively, for the encryption of the VP, the encryption key can be established using the ML-KEM where the DI wallet entity of the communication device 200 produces (e.g., randomly generates) the encryption key, and where a public key of the network node 300 is used by the DI wallet entity of the communication device 200 to produce a ciphertext based on the encryption key that is sent to the network node along with the encrypted VP.

[0104] Further in this respect, there might be different types of messages (encrypted or not) that are exchanged between the communication device 200 and the network node 300, and thus different communication protocols that can be utilized for this purpose. In particular, in some embodiments, the information and the request for the VP is received in an EAP-Request message, the VP is sent in an EAP-Response message, and the message indicating successful authentication of the communication device 200 is an EAP-Success message. Further in this respect, the request for device engagement data might be received in an EAP-Request message from the network node 300. Further, the device engagement data might be provided in response to the request being sent in an EAP-Response message to the network node 300.

[0105] There could be different actions taken by the communication device 200 once having received the message in S116 indicating successful authentication of the communication device 200 from the network node 300. In general terms, this is an indication that the communication device 200 could start communicating with the network node 300 for other purposes than for network subscriber authentication. For this purpose, key material for use in establishing secure communication between the communication device 200 and the network node 300 might be derived. The key material could here be based on the information exchanged with the network node 300 in one or more of the preceding steps. Hence, in some embodiments, the communication device 200 is configured to perform (optional) step S118. S118: The communication device 200 computes key material for use in establishing secure communication with the network node 300. The key material is based on key pairs and information exchanged with the network node 300.

[0106] In some aspects, the key material is referred to as shared key material. The term shared here refers to that the communication device 200 and the network node 300 have derived at least one key, which is the same for both the communication device 200 and the network node 300, for use in encryption or integrity protection of data, either directly as, e.g. a session key, or indirectly as a key used for the derivation of further keys used for encryption or integrity protection of data. Further, in some examples, the key material is based on private-public key pairs of the communication device 200 and network node 300. Further, in some examples, at least one or both of the private-public key pairs are ephemeral private-public key pairs generated for the subscriber authentication session. For example, the private-public key pairs are those also used to derive the encryption key used for the encryption of the VP request and the VP as described above.

[0107] Reference is now made to Fig. 4 illustrating a method for network subscriber authentication for a communication device 200 in a communication network as performed by the network node 300 according to an embodiment. The network node 300 might at least partly be implemented in at least one of: an authentication server function (AUSF) node, a UDM node, an authentication, authorization and accounting (AAA) server.

[0108] As disclosed above, the communication device 200 in step S104 sends an encoded identifier of the communication device 200 to the network node 300. It is here assumed that the network node 300 receives this encoded identifier, as in step S202.

[0109] S202: The network node 300 receives an encoded identifier of the communication device 200 from the communication device 200.

[0110] S204: The network node 300 selects an authentication process for authenticating the communication device 200. The authentication process is based on an identifier retrieved by the network node 300 from the encoded identifier. S210: The network node 300 sends information and a digitally signed request for a VP to the communication device 200. The information is given by the selected authentication process and at least specifies formatting of the VP. The digitally signed request identifies at least one attribute of a VC of the communication device 200.

[0111] As disclosed above, the communication device 200 in step S114 sends a digitally signed VP to the network node 300. It is here assumed that the network node 300 receives this digitally signed VP, as in step S212.

[0112] S212: The network node 300 receives a digitally signed VP from the communication device 200. The digitally signed VP comprises the at least one attribute of the VC.

[0113] S214: The network node 300 authenticates the communication device 200 by (i) verifying the at least one attribute, (ii) verifying that a digital signature of the digitally signed VP belongs to the communication device 200, and (iii) verifying that the VP is of a format given by the specified formatting.

[0114] S216: The network node 300 sends a message indicating successful authentication of the communication device 200 to the communication device 200.

[0115] Embodiments relating to further details of network subscriber authentication for a communication device 200 in a communication network as performed by the network node 300 will now be disclosed with continued reference to Fig. 4.

[0116] As specified in S210 the information that specifies formatting of the VP is given by an authentication process selected by the network node 300. In this respect, there could be different ways how the VP is formatted and thus also different ways to describe how the VP is to be formatted. In general terms, the authentication process follows any of: ISO / IEC 18013-5, ISO / IEC 18013-7, OpenID4VP. Further, in some examples, the formatting of the VP pertains to how the VP is to be signed and / or encoded. That is, in some embodiments, the formatting of the VP pertains to at least one of: how the VP is to be digitally signed before being sent to the network node 300, how the VP is to be encoded before being sent to the network node 300.

[0117] Examples of attributes that might be requested by the network node 300 in step S210 have already been disclosed with reference to the description of the DI wallet entity in Figs. 1(a) and 1(b) and those examples apply here as well. In particular, in some embodiments, the at least one attribute at least specifies a unique identifier of PID of a VC of the communication device 200 Further, the digitally signed VP might at least comprise the identifier data of the communication device 200 as attribute.

[0118] If the encoded identifier does not comprise any device engagement data and the network node 300 needs such device engagement data for facilitating encryption of messages exchanged with the communication device 200, then the network node 300 request the device engagement data from the communication device 200. Therefore, in some embodiments, the network node 300 is configured to perform (optional) steps S206 and S208.

[0119] S206: The network node 300 sends a request for device engagement data of the communication device 200 to the communication device 200.

[0120] S208: The network node 300 receives the device engagement data of the communication device 200 from the communication device 200.

[0121] As disclosed above, in general terms, the messages exchanged between the communication device 200 and the network node 300 could be encrypted using various encryption schemes. For this purpose, in some embodiments, the digitally signed request for a VC is encrypted, and the method comprises encrypting, step S210-2, the digitally signed request using an encryption key. Likewise, in some embodiments, the received digitally signed VP is encrypted, and the method comprises decrypting, step S212-2, the encrypted digitally signed VP using an encryption key. The encryption key can be derived using a private-public key pair generated by the network node 300 and a public key of the communication device 200. The public key can either be received as part of device engagement data or be received together with the encrypted digitally signed VP. In some examples, the encryption key is derived from an ECDH shared secret derived from the private key of the private-public key pair of the network node 300 and the public key of the communication device 200. In some examples, at least one or both of the privatepublic key pair and the public key are ephemeral and generated for the subscriber authentication session. In some other examples, the encryption key is established using the ML-KEM in the same manner as disclosed above. As further disclosed above, there might be different types of messages (encrypted or not) that are exchanged between the network node 300 and the communication device 200, and thus different communication protocols that can be utilized for this purpose. In particular, in some embodiments, the information and request for VP is sent in an EAP-Request message, the VP is received in an EAP-Response message, and the message indicating successful authentication of the communication device 200 is an EAP Success message. Further in this respect, the request for device engagement data might be sent in an EAP-Request message from the network node 300. Further, the device engagement data might be provided in response to the request being received in an EAP-Response message by the network node 300.

[0122] In some aspects, if the communication device 300 authenticates for the first time, then the network node 300 may need to perform attestation of several attributes. Then, in subsequent authentication of the same communication device 200, only attestation of one or a few attributes are requested. In particular, in some embodiments, in case the encoded identifier is received in an initial registration request message or an initial identity response from the communication device 200, the digitally signed request identifies a larger number of attributes of the VC than in case the encoded identifier is received in a registration request message or an identity response received subsequently to the initial registration request message or the initial identity response from the communication device 200.

[0123] Further, one round of sending the digitally signed request, receiving the digitally signed VP, and authenticating the communication device 200 might be performed for each attribute (or set of attributes). That is, in some embodiments, the network node 300 repeats (i) sending the digitally signed request, (ii) receiving the digitally signed VP, and (iii) authenticating the communication device 200 for a respective set of attributes. For this purpose, the network node 300 might be configured to determine whether more rounds to retrieve further attributes are needed or not based on the attributes received thus far. That is, in some embodiments, how many times the network node 300 repeats (i) sending the digitally signed request, (ii) receiving the digitally signed VP, and (iii) authenticating the communication device 200 depends on which attributes are received from the communication device 200. There might be different ways for the network node 300 to in S214 verify that the digital signature of the digitally signed VP belongs to the communication device 200. For example, the network node 300 might here interact with the (Q)TSP or another, or other CA, that provided the PID / QEAAs to for the network node 300 obtain revocation information of certificates. Therefore, in some embodiments, the network node 300 is configured to perform (optional) step S214-2 as part of authenticating the communication device 200.

[0124] S214-2: The network node 300 verifies, with a TSP or a QTSP, that the digital signature of the digitally signed VP has not been revoked.

[0125] The message in S116 indicates successful authentication of the communication device 200 from the network node 300. This message could thus be an indication that the communication device 200 could start communicating with the network node 300 for other purposes than for network subscriber authentication. For this purpose, key material for use in establishing secure communication between the network node 300 and the communication device 200 might be derived. Hence, in some embodiments, the communication device 200 is configured to perform (optional) step S218.

[0126] S218: The network node 300 computes key material for use in establishing secure communication with the communication device 200. The key material is based on key pairs and information exchanged with the communication device 200.

[0127] As disclosed above, in some aspects, the key material is referred to as shared key material. The term shared here refers to that the network node 300 and the communication device 200 have derived the same set of keys for use in encryption and integrity protection of data. Further, in some examples, the key material is based on private-public key pairs of the network node 300 and the communication device 200. Further, in some examples, at least one or both of the private-public key pairs are ephemeral private-public key pairs generated for the subscriber authentication session. For example, the private-public key pairs are those also used to derive the encryption key used for the encryption of the VP request and the VP as described above. A first embodiment for network subscriber authentication for a communication device 200 in a communication network based on at least some of the above disclosed embodiments will now be disclosed in detail with reference to the signaling diagram of Fig. 5.

[0128] In this first embodiment subscriber authentication to a cellular communication network (so-called primary authentication) is performed using ISO / IEC 18013-5. The cellular communication network may be a public network or a stand-alone nonpublic network, (SNPN). In the case of public network, the AMF / SEAF may belong to a serving network in case of roaming and otherwise to the home network. The AUSF and UDM belong to the home network in both the roaming and non-roaming case.

[0129] The DI wallet entity is equipped with at least a PID, but may also be equipped with (Q)EAAs that are usable in the subscriber authentication.

[0130] Step 300: Login.

[0131] The natural person, acting as the user of the communication device (e.g., mobile phone) where the DI wallet entity is located, logs in to the DI wallet entity.

[0132] Step 302: Connection establishment trigger.

[0133] The cellular modem is triggered to connect to the communication network and prepares for subscriber authentication. This may be triggered by the natural person or it may be a re-authentication triggered from the communication network. Either an anonymous identifier is sent to the communication network or an encrypted identifier is sent.

[0134] Step 304: Get identifier.

[0135] In case an encrypted identifier is used, the cellular modem requests the identifier from the DI wallet entity.

[0136] Step 306: Identifier.

[0137] The DI wallet entity returns an identifier. This identifier may for example be the unique identifier of the PID. Step 308: Create SUCI.

[0138] The cellular modem creates a SUCI by following a standard procedure for SUCI creation. The SUCI either comprises the identifier in encrypted form or the SUCI is an anonymous SUCI. The creation of the SUCI involves the cellular modem to generate an ephemeral key pair, where the ephemeral public key is used to derive session keys for encryption and integrity protection of the identifier. The SUCI further comprises the ephemeral public key and routing information, such as mobile country code (MCC) plus mobile network code (MNC), or domain name such that, in roaming cases, the serving network can locate the home network in order to authenticate the subscriber. The routing information could be stored by the cellular modem or could be part of a QEAA / EAA / VC stored in the DI wallet entity and obtained together with the identifier in step 306. Even when using an anonymous SUCI, the cellular modem can request and obtain the routing information from the DI wallet entity.

[0139] Step 310: Registration request (SUCI).

[0140] The cellular modem sends a registration request comprising the SUCI to the communication network. The request is routed to a network node implementing an AMF / SEAF.

[0141] Step 312: Nausf_UEAuthentication_Authenticate Request (SUCI, SN name).

[0142] The network node implementing the AMF / SEAF sends an authentication request for the SUCI comprising the SUCI and Serving Communication network (SN) name to a network node implementing an AUSF. In the roaming case the network node implementing the AMF / SEAF uses the routing information to find the home mobile communication network of the subscriber.

[0143] Step 314: Nudm_UEAuthentication_Get Request (SUCI, SN name).

[0144] The network node implementing AUSF forwards the request to a network node implementing a UDM.

[0145] Step 316: [SUCI deconcealment], authentication procedure selection. The network node implementing the UDM deconceals the SUCI and uses the retrieved identifier to select authentication procedure. Here, attestation according to ISO / IEC 18013-5 is selected. In case of an anonymous SUCI, the SUCI may include information on supported authentication procedures that can be leveraged by the network node in the selection of the authentication procedure. In case of an anonymous SUCI without information on supported authentication procedures, a default authentication procedure can be selected.

[0146] Step 318: Nudm_UEAuthentication_Get Response (EAP_VP, [SUPI]).

[0147] The network node implementing the UDM responds to the network node implementing the AUSF with the selected authentication procedure and possibly the identifier, called SUPI, if present.

[0148] Step 320: Prepare EAP Request / VP-DE.

[0149] The network node implementing the AUSF prepares an EAP Request for ISO / IEC 18013-5 device engagement data.

[0150] Step 322: Nausf_UEAuthentication_Authenticate Response (EAP Request / VP-DE).

[0151] Step 324: Authentication Request (EAP Request / VP-DE).

[0152] The network node implementing the AUSF sends the request to the network node implementing the AMF / SEAF that forwards the request to the cellular modem.

[0153] Step 326: ISO18O13-5: request device engagement data.

[0154] Step 328: ISO18O13-5: generate ephemeral key pair, select cipher suite.

[0155] Step 330: Ephemeral public key, cipher suite.

[0156] Step 332: Prepare EAP Response / VP-DE including ephemeral public key, cipher suite.

[0157] The cellular modem requests ISO / IEC 18013-5 device engagement data from the DI wallet entity. The DI wallet entity generates an ephemeral key pair for the session, selects the cipher suite to be used, and provides the ephemeral public key and cipher suite to the cellular modem that prepares an EAP Response with the received data. Step 334: Authentication Response (EAP Response / VP-DE).

[0158] Step 336: Nausf_UEAuthentication_Authenticate Request (EAP Response / VP-DE).

[0159] The EAP Response with ISO / IEC 18013-5 device engagement data is provided from the cellular modem to the network node implementing the AMF / SEAF that forwards it to the network node implementing the AUSF.

[0160] Step 338: ISO18O13-5: generate ephemeral key pair, derive session key, prepare signed mdoc request and encrypt using session key.

[0161] The network node implementing the AUSF follows ISO / IEC 18013-5 and performs the following.

[0162] The network node implementing the AUSF generates an ephemeral key pair and performs the Elliptic Curve Key Agreement - Diffie Hellman (ECKA-DH) algorithm with its ephemeral private key and the ephemeral public of the DI wallet entity to establish a session key for encryption.

[0163] The network node implementing the AUSF prepares the request (called mdoc request) for attributes from PID and / or (Q)EAAs and signs it together with a session transcript hash based on exchanged data including the DI wallet entity ephemeral public key, AUSF ephemeral public key, cipher suite identifier, and elliptic curve identifier. The signature is created using e.g., CBOR Object Signing and Encryption (COSE) and the AUSF private key. The network node implementing the AUSF might further provide its certificate (if not already available at the DI wallet entity) and possibly intermediate certificates chaining back to a certificate / public key trusted by the DI wallet entity.

[0164] The network node implementing the AUSF encrypts the mdoc request using the session encryption key and sends the encrypted mdoc request along with its ephemeral public key.

[0165] Step 340: Prepare EAP Request / VP -Attest.

[0166] Step 342: Nausf_UEAuthentication_Authenticate Response (EAP Request / VP- Attest). Step 344: Authentication Request (EAP Request / VP -Attest).

[0167] The network node implementing the AUSF prepares an EAP Request / VP -Attest including the encrypted mdoc request. The EAP Request is sent to the network node implementing the AMF / SEAF that forwards it to the cellular modem.

[0168] Step 346: Encrypted mdoc request.

[0169] The cellular modem extracts the encrypted mdoc request and provides it to the DI wallet entity.

[0170] Step 348: ISO18O13-5: authenticate network by verifying mdoc request signature using network public key and derive keys for secure session.

[0171] The DI wallet entity performs the Elliptic Curve Key Agreement - Diffie Hellman (ECKA-DH) algorithm with its ephemeral private key and the ephemeral public of the AUSF to derive the session key for encryption and uses it to decrypt the encrypted mdoc request. The DI wallet entity then authenticates the AUSF using the AUSF public key, e.g., obtained from the certificate contained in the request, and validates the mdoc request.

[0172] Step 350: ISO18O13-5: prepare signed mdoc response leveraging DI wallet private key and encrypt mdoc response.

[0173] Step 352: Encrypted mdoc response.

[0174] The DI wallet entity prepares an mdoc response (VP) comprising at least the unique identifier of the PID, possibly further comprising other attributes from the PID and / or (Q)EAAs. Each PID / (Q)EAA in mdoc format comprises a Mobile Security Object (MSO) signed by the issuer that is included in the mdoc response. The mdoc response is signed using the DI wallet entity private key, whose public key is part of the MSO. The signed mdoc response is encrypted using the session encryption key. The DI wallet entity returns the encrypted response to the cellular modem.

[0175] Step 354: Prepare EAP Response / VP -Attest.

[0176] Step 356: Authentication Response (EAP Response / VP -Attest). Step 358: Nausf_UEAuthentication_Authenticate Request (EAP Response / VP- Attest).

[0177] The cellular modem prepares an EAP Response / VP -Attest comprising the encrypted mdoc response. The cellular modem sends the EAP Response to the network node implementing the AMF / SEAF that forwards it to the network node implementing the AUSF.

[0178] Step 360: Extract encrypted mdoc response.

[0179] Step 362: Revocation information, etc.

[0180] Step 364: ISO18O13-5: decrypt mdoc response, authenticate DI wallet, and verify mdoc response.

[0181] The network node implementing the AUSF decrypts the encrypted mdoc response, and verifies the mdoc response by verifying the MSO (i. e. , the VC), extracting the DI wallet entity public key from the MSO, authenticating the DI wallet entity using the DI wallet entity public key by verifying the DI wallet entity signature of the mdoc response. The network node implementing the AUSF could interact with the (Q)TSPs that provided the PID / (Q)EAAs or other CAs to obtain revocation information of certificates (such as the issuer certificate and CA certificates) being part of the MSO, that is used when verifying the certificates as part of the verification of each MSO.

[0182] Step 366: Nausf_UEAuthentication_Authenticate Response (EAP Success 1 1 Anchor key, [SUPI]).

[0183] Upon successful verification and authentication of the DI wallet entity, the network node implementing the AUSF prepares an EAP Success message that is provided to the network node implementing the AMF / SEAF along with the anchor key derived by the network node implementing the AUSF and possibly the SUPI.

[0184] Step 368: Derive keys for secure communication with communication device.

[0185] Step 370: EAP Success.

[0186] The network node implementing the AMF / SEAF derives session keys from the anchor key for use in securing the communication with the communication device. The network node implementing the AMF forwards the EAP Success message to the cellular modem.

[0187] Step 372: Derive keys for secure communication with communication network.

[0188] The cellular modem derives the anchor key and then session keys from the anchor key for use in securing the communication with the communication network.

[0189] The ISO / IEC 18013-5 protocol is using the compact CBOR encoding of messages which is suitable for message exchange with the communication network also for constrained communication devices.

[0190] The set of attributes requested by the network node implementing the AUSF in step 338 may vary. For example, if the subscriber authenticates for the first time, the network node implementing the AUSF may want to perform attestation of several attributes and in subsequent attestations only one or a few are requested. In case of anonymous identifier being sent to the communication network in step 310, the network node implementing the AUSF cannot know if it is the first time for attestation for the communication device. In this case several rounds of steps 338- 36qcan be made. The network node implementing the AUSF might then perform a first roundtrip of steps 338-364where only one or a few attributes are requested, at least comprising an identifier. Then the network node implementing the AUSF, based on checking the identifier, could determine whether more roundtrips are needed or not to retrieve further attributes. To determine this, the network node implementing the AUSF might need to perform further interaction with the network node implementing the UDM to retrieve information about the received identifier.

[0191] A second embodiment for network subscriber authentication for a communication device 200 in a communication network based on at least some of the above disclosed embodiments will now be disclosed in detail with reference to the signaling diagram of Fig. 6.

[0192] In this second embodiment subscriber authentication to a cellular communication network is performed using ISO / IEC 18013-5. The cellular communication network may be a public network or a stand-alone non-public network, SNPN. In this second embodiment, in order to save roundtrips, device engagement data is included as part of the SUCI. In particular, a new anonymous SUPI type leading to an anonymous SUCI containing the device engagement data, such as the DI wallet entity ephemeral public key and cipher suite.

[0193] The DI wallet entity is equipped with at least a PID, but may also be equipped with (Q)EAAs that are usable in the subscriber authentication.

[0194] Step 400: same as step 300.

[0195] Step 402: Connection establishment trigger.

[0196] The modem is triggered to connect to the communication network and prepares for subscriber authentication. This may be triggered by the natural person or it may be a re-authentication triggered from the communication network.

[0197] Step 404: ISO18O13-5: request device engagement data.

[0198] Step 406: ISO18O13-5: generate ephemeral key pair, select cipher suite.

[0199] Step 408: Ephemeral public key, cipher suite.

[0200] The modem requests ISO / IEC 18013-5 device engagement data from the DI wallet entity. The DI wallet entity generates an ephemeral key pair for the session, selects the cipher suite to be used, and provides the ephemeral public key and cipher suite to the modem.

[0201] Step 410: Create anonymous SUCI with device engagement data.

[0202] The modem creates a SUCI, where a new anonymous SUPI type leading to an anonymous SUCI that comprises the device engagement data, i.e., the DI wallet entity ephemeral public key and cipher suite. Routing information is added according to above.

[0203] Step 412: same as step S310.

[0204] Step 414: same as step S312.

[0205] Step 416: same as step S314.

[0206] Step 418: Extract device engagement data, authentication procedure selection. The network node implementing the UDM extracts the device engagement data from the SUCI and selects authentication procedure, in this case attestation according to ISO / IEC 18013-5.

[0207] Step 420: Nudm_UEAuthentication_Get Response (EAP_VP, device engagement data)

[0208] The network node implementing the UDM responds to the network node implementing the AUSF with selected authentication procedure and device engagement data.

[0209] No steps corresponding to steps 320-336 are performed.

[0210] Steps 422-456: same as steps 338-372.

[0211] In the case the communication network is an SNPN, the EAP authentication server may alternatively be an external authentication server such as an AAA server performing the subscriber authentication on behalf of the communication network. The AUSF now becomes essentially a relay between AMF / SEAF and the AAA server. The AUSF communicates to the AAA server via a network slice specific authentication and authorization function, NSSAAF, of the SNPN. The AAA server handles steps 320, 338, 340, and 360-364 in Fig. 5 and steps 422, 424, and 444-448 in Fig. 6 instead of the AUSF. The AAA server also handles part of the key derivation (in steps 366 and 448) and derives the EAP master session key (MSK) that is provided to the AUSF (along with the EAP-Success message and possibly the SUPI) and the AUSF is then responsible for derivation of the 3GPP specific keys including the anchor key.

[0212] Alternatively, in the case the communication network is an SNPN, the EAP authentication server may in yet another alternative be represented by a 5G network AUSF (and a UDM) that are external to the SNPN and that, for example, are accessed via the 5G network roaming interface (denoted N32). The external AUSF performs the subscriber authentication on behalf of the communication network. The UDM within the communication network decides for each subscriber authentication whether the external AUSF and UDM shall be used and the external AUSF and UDM replaces the internal AUSF and UDM in Fig. 5 and Fig. 6. In another example, the communication network is an onboarding network for the purpose of provisioning the communication device with SNPN credentials for subscriber authentication (primary authentication) to enable access to a desired SNPN. Subscriber authentication (primary authentication) is performed for the communication device to access the onboarding network. The onboarding network is connected to an external default credential server consisting either of an (external) AAA server or an (external) AUSF and UDM that perform the subscriber authentication on behalf of the onboarding network according to the above description for the SNPN.

[0213] In yet another example, the communication network is a 5G cellular network (public or private) where the communication device is to access a network slice and where a network slice specific authentication and authorization is required to be performed. The communication device has performed primary authentication where the subscriber is authenticated by the network using some authentication procedure and associated credentials, e.g., EAP-AKA’ using AKA credentials stored on a SIM card. A Single Network Slice Selection Assistance Information (S-NSSAI) is provided by the communication deviceto the network during network attachment to indicate what slice the communication devicerequests to access, and the network determines that network slice specific (additional subscriber) authentication is required to be performed in addition to the primary authentication. The additional subscriber authentication leveraging the DI wallet entity can then be performed for the network slice specific authentication. The following steps are performed after successful completion of the primary authentication and secured non-access stratum, NAS, connection is established between the communication device and the AMF (with reference given to steps of Fig. 5 and Fig. 6).

[0214] The natural person, acting as the user of the communication device (e.g., a mobile phone) where the DI wallet entity is located, logs in to the DI wallet entity (see, step 300 or step 400).

[0215] The AMF sends a request for identity (e.g., EAP-Identity request) to the communication device (modem) over the NAS channel.

[0216] The modem and the DI wallet entity perform steps 304-308 or steps 404 - 410 to prepare the encoded identifier (e.g., SUCI). The encoded identifier is returned (e.g., in an EAP-Identity response message) to the AMF (corresponding to step 310 or step 412). Note that since the NAS channel is encrypted and integrity protected it is not necessary to encrypt the identifier (e.g., a SUCI null-encryption scheme maybe used).

[0217] The steps {312-366, 370} or {414-450, 454} are performed according to Fig. 5 or Fig. 6 where the AUSF and UDM are replaced by an AAA server that performs the decoding of the encoded identifier, authentication procedure selection, and subscriber authentication. The AAA server may be internal or external to the communication network and the communication between the AMF and the AAA server might be via a network slice specific authentication and authorization function, NSSAAF, of the communication network.

[0218] In yet another example, the communication network is a (public or private) 5G cellular network and the communication device has attached to the 5G cellular network and a so-called primary authentication has been performed, where the subscriber is authenticated by the network using some authentication procedure and associated credentials, e.g., FAP -AKA’ using AKA credentials stored on a SIM card. At the following PDU session establishment to a Data Network (DN), a secondary authentication of the subscriber is performed by the DN. Session management function (SMF) policies in this case require that DN authorization based on secondary authentication is required in addition to the primary authentication and the PDU session authorization enforced by SMF with regards to subscription data retrieved from the UDM. The secondary authentication is in this example leveraging the DI wallet entity and the EAP method described in this disclosure. The following steps are performed after successful completion of the primary authentication and secured non-access stratum (NAS) connection is established between the communication device and the AMF (with reference being given to the steps of Fig. 5 and Fig. 6).

[0219] The natural person, acting as the user of the communication device (e.g., a mobile phone) where the DI wallet entity is located, logs in to the DI wallet entity (see, step 300 or step 400).

[0220] The AMF contacts the SMF for the PDU session establishment. In the roaming case this is the SMF of the visited network (V-SMF) that checks its policies and then also contacts the SMF of the home network (H-SMF), that checks its policies. The SMF / H-SMF concludes that secondary authentication is needed for the communication device and initiates the EAP authentication acting as the EAP authenticator instead of the AMF. Hence, the SMF / H-SMF replaces the AMF in Fig. 5 and Fig. 6. The SMF / H-SMF sends a request for identity (e.g., EAP-Identity request) to the communication device (such as to the modem in the communication device), via the AMF over the NAS channel.

[0221] The communication device and the DI wallet entity perform steps 304-308 or steps 404 - 410 to prepare the encoded identifier (e.g., SUCI). The encoded identifier is returned (e.g., in an EAP-Identity response message) to the SMF / H-SMF (corresponding to step 310 or step 412). It is noted that since the NAS channel is encrypted and integrity protected, it is not necessary to encrypt the identifier (e.g., a SUCI null-encryption scheme maybe used).

[0222] The steps {312-366, 370} or {414-450, 454} are performed according to Fig. 5 or Fig. 6 where the AUSF and UDM are replaced by an AAA server of the DN that performs the decoding of the encoded identifier, authentication procedure selection, and the subscriber authentication. The AAA server may be internal or external to the communication network and the communication between the SMF / H-SMF. The AAA server is via a user plane function (UPF), such as a UPF of the home network (H- UPF) in case of roaming, of the communication network.

[0223] A third embodiment for network subscriber authentication for a communication device 200 in a communication network based on at least some of the above disclosed embodiments will now be disclosed in detail with reference to the signaling diagram of Fig. 7. However, specific cryptographic algorithms used in the diagrams can substituted by other algorithms serving the same purpose as often is possible for cryptographic algorithms.

[0224] In this third embodiment subscriber authentication to a WiFi communication network is performed using ISO / IEC 18013-5.

[0225] The DI wallet entity is assumed to be equipped with at least a PID, but may also be equipped with (Q)EAAs that are usable in the subscriber authentication.

[0226] Step 500: Login. The natural person, acting as the user of the communication device (e.g., mobile phone) where the DI wallet entity is located, logs in to the DI wallet entity.

[0227] Step 502: Connection establishment trigger.

[0228] Step 504: Connection request.

[0229] The WiFi module is triggered to connect to the WiFi communication network. This may be triggered by the natural person. The WiFi module sends a connection request to an Access Point (AP) in the WiFi communication network.

[0230] Step 506: EAP Request / identity.

[0231] The AP starts the subscriber authentication by sending an EAP Request / identity to the communication device.

[0232] Step 508: Get identifier.

[0233] Step 510: Identifier.

[0234] Step 512: EAP Response / identity.

[0235] The WiFi module either requests an identifier from the DI wallet entity or uses a special identifier, indicating it is anonymous. The identifier from the DI wallet entity could, for example, be the unique identifier of the PID. The WiFi module sends an EAP Response / identity to the AP comprising the identifier or the anonymous indication.

[0236] Step 514: EAP Response / identity.

[0237] The AP forwards the EAP Response / identity to an AAA server that, based on the returned identifier, selects the EAP method to be used during the authentication.

[0238] Step 516: EAP Request / VP-DE.

[0239] Step 518: EAP Request / VP-DE.

[0240] The AAA server prepares an EAP Request for ISO / IEC 18013-5 device engagement data and sends the request to the AP that forwards the request to the WiFi module. Step 520: ISO18O13-5: request device engagement data.

[0241] Step 522: ISO18O13-5: generate ephemeral key pair, select cipher suite.

[0242] Step 524: Ephemeral public key, cipher suite.

[0243] Step 526: Prepare EAP Response / VP-DE including [identifier], ephemeral public key, cipher suite.

[0244] The WiFi module requests ISO / IEC 18013-5 device engagement data from the DI wallet entity. The DI wallet entity generates an ephemeral key pair for the session, selects the cipher suite to be used, and provides the ephemeral public key and cipher suite to the WiFi module that prepares an EAP Response with the received data.

[0245] Step 528: Authentication Response (EAP Response / VP-DE).

[0246] Step 530: EAP Response / VP-DE.

[0247] The EAP Response with ISO / IEC 18013-5 device engagement data is provided from the WiFi module to AP that forwards it to the AAA server.

[0248] Step 532: ISO18O13-5: generate ephemeral key pair, derive session key, prepare signed mdoc request and encrypt using session key.

[0249] The AAA server follows ISO / IEC 18013-5 and performs the following.

[0250] The AAA server generates an ephemeral key pair and performs the Elliptic Curve Key Agreement - Diffie Hellman (ECKA-DH) algorithm with its ephemeral private key and the ephemeral public of the DI wallet entity to establish a session key for encryption.

[0251] The AAA server prepares the request (called mdoc request) for attributes from PID and / or (Q)EAAs and signs it together with a session transcript based on exchanged data including the DI wallet entity ephemeral public key, AAA server ephemeral public key, cipher suite identifier, and elliptic curve identifier. The signature is created using the AAA server private key.

[0252] The AAA server encrypts the mdoc request using the session encryption key and sends the encrypted mdoc request along with its ephemeral public key. Step 534: Prepare EAP Request / VP -Attest.

[0253] Step 536: EAP Request / VP -Attest.

[0254] Step 538: EAP Request / VP -Attest.

[0255] The AAA server prepares an EAP Request / VP -Attest including the encrypted mdoc request. The EAP Request is sent to the AP that forwards it to the WiFi module.

[0256] Step 540: Encrypted mdoc request.

[0257] The WiFi module extracts the encrypted mdoc request and provides it to the DI wallet entity.

[0258] Step 542: ISO18O13-5: authenticate communication network by verifying mdoc request signature using network public key and derive keys for secure session.

[0259] The DI wallet entity performs the Elliptic Curve Key Agreement - Diffie Hellman (ECKA-DH) algorithm with its ephemeral private key and the ephemeral public of the AAA server to derive the session key for encryption and uses it to decrypt the encrypted mdoc request. The DI wallet entity then authenticates the AAA server using the AAA server public key and validates the mdoc request.

[0260] Step 544: ISO18O13-5: prepare signed mdoc response leveraging DI wallet private key and encrypt mdoc response.

[0261] Step 546: Encrypted mdoc response.

[0262] The DI wallet entity prepares an mdoc response (in terms of a VP) comprising at least the unique identifier of the PID, possibly further compirisng other attributes from the PID and / or (Q)EAAs. Each PID / (Q)EAA in mdoc format comprises an MSO signed by the issuer that is included in the mdoc response. The mdoc response is signed using the DI wallet entity private key whose public key is part of the MSO. The signed mdoc response is encrypted using the session encryption key. The DI wallet entity returns the encrypted response to the WiFi module.

[0263] Step 548: Prepare EAP Response / VP -Attest.

[0264] Step 550: EAP Response / VP -Attest. Step 552: EAP Response / VP -Attest.

[0265] The WiFi module prepares an EAP Response / VP -Attest comprising the encrypted mdoc response. The WiFi module sends the EAP Response to the AP that forwards it to the AAA server.

[0266] Step 554: Extract encrypted mdoc response.

[0267] Step 556: Revocation information, etc.

[0268] Step 558: ISO18O13-5: decrypt mdoc response, authenticate DI wallet, and verify mdoc response.

[0269] The AAA server decrypts the encrypted mdoc response, and verifies the mdoc response by verifying the MSO (i.e., the VC), extracting the DI wallet entity public key from the MSO, authenticating the DI wallet entity using the DI wallet entity public key by verifying the DI wallet entity signature of the mdoc response. The AAA server could interact with the (Q)TSPs that provided the PID / (Q)EAAs or other CAs to obtain revocation information of certificates (such as the issuer certificate and CA certificates) being part of the MSO, that is used when verifying the certificates as part of the verification of each MSO.

[0270] Step 560: EAP Success, EAP-MSK.

[0271] Upon successful verification and authentication of the DI wallet entity, the AAA server prepares an EAP Success message that is provided to the AP along with the EAP-MSK (Master Secret Key) derived by the AAA server.

[0272] Step 562: EAP Success.

[0273] The AP derives session keys from EAP-MSK for use in securing the communication with the communication device. The AMF forwards the EAP Success message to the WiFi module.

[0274] Step 564: Derive EAP-MSK for secure communication. The WiFi module derives an EAP-MSK (where MSK is short for Master Secret Key) and then session keys from the EAP-MSK for use in securing the communication with the communication network.

[0275] As an alternative, the device engagement data may be delivered from the communication device to the AAA server as part of the EAP Response / identity message in order to save one roundtrip. In this case steps 520-524 are performed inbetween steps 510 and 512 and the identity response is a concatenation of the identifier originally sent in step 512 and the device engagement data. Steps 516, 518, and 524-530 are then skipped.

[0276] Fig. 8 schematically illustrates, in terms of a number of structural units, the components of a communication device 200 according to an embodiment. Processing circuitry 210 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 1210a (as in Fig. 12), e.g., in the form of a storage medium 230. The processing circuitry 210 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

[0277] Particularly, the processing circuitry 210 is configured to cause the communication device 200 to perform a set of operations, or steps, as disclosed above. For example, the storage medium 230 may store the set of operations, and the processing circuitry 210 maybe configured to retrieve the set of operations from the storage medium 230 to cause the communication device 200 to perform the set of operations. The set of operations maybe provided as a set of executable instructions. Thus the processing circuitry 210 is thereby arranged to execute methods as herein disclosed.

[0278] The storage medium 230 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory. With respect to Figs. 1(a) and 1(b) the DI wallet 240 might be implemented in the processing circuitry 210, possibly in combination with the storage medium 230.

[0279] The communication device 200 may further comprise a communications (comm.) interface 220 for communications with other entities, functions, nodes, and devices, as in Figs. 1(a) and 1(b). As such the communications interface 220 may comprise one or more transmitters and receivers, comprising analogue and digital components. With respect to Figs. 1(a) and 1(b) the communications interface 220 might comprise a cellular modem 250a and / or a WiFi module 250b.

[0280] The processing circuitry 210 controls the general operation of the communication device 200 e.g., by sending data and control signals to the communications interface 220 and the storage medium 230, by receiving data and reports from the communications interface 220, and by retrieving data and instructions from the storage medium 230. Other components, as well as the related functionality, of the communication device 200 are omitted in order not to obscure the concepts presented herein.

[0281] Fig. 9 schematically illustrates, in terms of a number of functional modules, the components of a communication device 200 according to an embodiment. The communication device 200 of Fig. 9 comprises a number of functional modules; a send module 210a configured to perform step S104, a receive module 2iof configured to perform step S110, an authenticate (Auth.) module 210g configured to perform step S112, a send module 2ioh configured to perform step S114, and a receive module 2ioj configured to perform step S116. The communication device 200 of Fig. 9 may further comprise a number of optional functional module, such as any of an obtain module 210a configured to perform step S102, a receive module 210c configured to perform step S106, a decrypt module configured to perform step S106-2, a send module 2ioe configured to perform step S108, an encrypt module 2ioi configured to perform step S114-2, and a compute module 210k configured to perform step S118.

[0282] In general terms, each functional module 2ioa:2iok maybe implemented in hardware or in software. Preferably, one or more or all functional modules 210a: 210k may be implemented by the processing circuitry 210, possibly in cooperation with the communications interface 220 and / or the storage medium 230. The processing circuitry 210 may thus be arranged to from the storage medium 230 fetch instructions as provided by a functional module 210a: 210k and to execute these instructions, thereby performing any steps of the communication device 200 as disclosed herein. Fig. io schematically illustrates, in terms of a number of structural units, the components of a network node 300 according to an embodiment. Processing circuitry 310 is provided using any combination of one or more of a suitable central processing unit (CPU), multiprocessor, microcontroller, digital signal processor (DSP), etc., capable of executing software instructions stored in a computer program product 1210b (as in Fig. 12), e.g., in the form of a storage medium 330. The processing circuitry 310 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

[0283] Particularly, the processing circuitry 310 is configured to cause the network node 300 to perform a set of operations, or steps, as disclosed above. For example, the storage medium 330 may store the set of operations, and the processing circuitry 310 maybe configured to retrieve the set of operations from the storage medium 330 to cause the network node 300 to perform the set of operations. The set of operations maybe provided as a set of executable instructions. Thus the processing circuitry 310 is thereby arranged to execute methods as herein disclosed.

[0284] The storage medium 330 may also comprise persistent storage, which, for example, can be any single one or combination of magnetic memory, optical memory, solid state memory or even remotely mounted memory.

[0285] The network node 300 may further comprise a communications interface 320 for communications with other entities, functions, nodes, and devices, as in Figs. 1(a) and 1(b). As such the communications interface 320 may comprise one or more transmitters and receivers, comprising analogue and digital components.

[0286] The processing circuitry 310 controls the general operation of the network node 300 e.g., by sending data and control signals to the communications interface 320 and the storage medium 330, by receiving data and reports from the communications interface 320, and by retrieving data and instructions from the storage medium 330. Other components, as well as the related functionality, of the network node 300 are omitted in order not to obscure the concepts presented herein.

[0287] Fig. 11 schematically illustrates, in terms of a number of functional modules, the components of a network node 300 according to an embodiment. The network node 300 of Fig. 11 comprises a number of functional modules; a receive module 310a configured to perform step S202, a select module 310b configured to perform step S204, a send module 3ioe configured to perform step S210, a receive module 310g configured to perform step S212, an authentication (Auth.) module 3ioi configured to perform step S214, and a send module 310k configured to perform step S216. The network node 300 of Fig. 11 may further comprise a number of optional functional modules, such as any of a send module 310c configured to perform step S206, a receive module 3iod configured to perform step S208, an encrypt module 3iof configured to perform step S210-2, a decrypt module 310I1 configured to perform step S212-2, a verify module 3ioj configured to perform step S214-2, and a compute module 310I configured to perform step S218.

[0288] In general terms, each functional module 3103:310! maybe implemented in hardware or in software. Preferably, one or more or all functional modules 3103:310! maybe implemented by the processing circuitry 310, possibly in cooperation with the communications interface 320 and / or the storage medium 330. The processing circuitry 310 may thus be arranged to from the storage medium 330 fetch instructions as provided by a functional module 3103:310! and to execute these instructions, thereby performing any steps of the network node 300 as disclosed herein.

[0289] The network node 300 maybe provided as a standalone device or as a part of at least one further device. For example, the network node 300 maybe provided in a node of a radio access network or in a node of a core network. Alternatively, functionality of the network node 300 maybe distributed between at least two devices, or nodes. These at least two nodes, or devices, may either be part of the same network part (such as the radio access network or the core network) or may be spread between at least two such network parts. In general terms, instructions that are required to be performed in real time may be performed in a device, or node, operatively closer to the cell than instructions that are not required to be performed in real time. Thus, a first portion of the instructions performed by the network node 300 may be executed in a first device, and a second portion of the instructions performed by the network node 300 maybe executed in a second device; the herein disclosed embodiments are not limited to any particular number of devices on which the instructions performed by the network node 300 maybe executed. Hence, the methods according to the herein disclosed embodiments are suitable to be performed by a network node 300 residing in a cloud computational environment. Therefore, although a single processing circuitry 310 is illustrated in Fig. 10 the processing circuitry 310 maybe distributed among a plurality of devices, or nodes. The same applies to the functional modules 3ioa:3iol of Fig. 11 and the computer program 1220b of Fig. 12.

[0290] Fig. 12 shows one example of a computer program product 1210a, 1210b comprising computer readable means 1230. On this computer readable means 1230, a computer program 1220a can be stored, which computer program 1220a can cause the processing circuitry 210 and thereto operatively coupled entities and devices, such as the communications interface 220 and the storage medium 230, to execute methods according to embodiments described herein. The computer program 1220a and / or computer program product 1210a may thus provide means for performing any steps of the communication device 200 as herein disclosed. On this computer readable means 1230, a computer program 1220b can be stored, which computer program 1220b can cause the processing circuitry 310 and thereto operatively coupled entities and devices, such as the communications interface 320 and the storage medium 330, to execute methods according to embodiments described herein. The computer program 1220b and / or computer program product 1210b may thus provide means for performing any steps of the network node 300 as herein disclosed.

[0291] In the example of Fig. 12, the computer program product 1210a, 1210b is illustrated as an optical disc, such as a CD (compact disc) or a DVD (digital versatile disc) or a Blu-Ray disc. The computer program product 1210a, 1210b could also be embodied as a memory, such as a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), or an electrically erasable programmable read-only memory (EEPROM) and more particularly as a non-volatile storage medium of a device in an external memory such as a USB (Universal Serial Bus) memory or a Flash memory, such as a compact Flash memory. Thus, while the computer program 1220a, 1220b is here schematically shown as a track on the depicted optical disk, the computer program 1220a, 1220b can be stored in anyway which is suitable for the computer program product 1210a, 1210b.

[0292] The inventive concept has mainly been described above with reference to a few embodiments. However, as is readily appreciated by a person skilled in the art, other embodiments than the ones disclosed above are equally possible within the scope of the inventive concept, as defined by the appended patent claims.

Claims

CLAIMS1. A method for network subscriber authentication for a communication network (100a, 100b), wherein the method is performed by a communication device (200), and wherein the method comprises: sending (S104) an encoded identifier of the communication device (200) to a network node (300) in the communication network (100a, 100b); receiving (S110) information and a digitally signed request for a verifiable presentation, VP, from the network node (300), wherein the information specifies formatting of the VP, and wherein the digitally signed request identifies at least one attribute of a verifiable credential, VC, of the communication device (200), wherein the VC is stored in a Digital Identity, DI, wallet entity residing in the communication device (200); authenticating (S112) the network node (300) by verifying that a digital signature of the digitally signed request belongs to the network node (300); sending (S114) a digitally signed VP to the network node (300), wherein the digitally signed VP comprises the at least one attribute of the verifiable credential, VC, and has been digitally signed by the DI wallet entity and is of a format given by the specified formatting; and receiving (S116) a message indicating successful authentication of the communication device (200) from the network node (300).

2. The method according to claim 1, wherein the method further comprises: obtaining (S102) identifier data of the communication device (200) from the DI wallet entity, wherein the encoded identifier is based on the identifier data obtained from the DI wallet entity.

3. The method according to claim 1, wherein the encoded identifier is an encoded anonymous identifier.

4. The method according to any preceding claim, wherein the encoded identifier comprises encoded device engagement data of the communication device (200).

5. The method according to any preceding claim, wherein the encoded identifier is sent to the network node (300) in either a registration request message or an identity response message.

6. The method according to any preceding claim, wherein the method further comprises: receiving (S106) a request for device engagement data of the communication device (200) from the network node (300); and sending (S108) the device engagement data to the network node (300), wherein the device engagement data has been generated by the DI wallet entity.

7. The method according to any preceding claim, wherein the received digitally signed request is encrypted, and wherein the method comprises: decrypting (S106-2) the encrypted digitally signed request using an encryption key.

8. The method according to any preceding claim, wherein the digitally signed VP is encrypted, and wherein the method comprises: encrypting (S114-2) the signed VP using an encryption key before it is sent to the network node (200), whereby the signed VP is sent encrypted to the network node (200).

9. The method according to claim 7 or 8, wherein the encryption key is derived using a private-public key pair generated by the DI wallet entity and a public key of the network node (300), wherein a public key of the private-public key pair generated by the DI wallet entity is either provided as part of device engagement data or together with the encrypted digitally signed VP.

10. The method according to any preceding claim, wherein the formatting of the VP pertains to at least one of: how the VP is to be digitally signed before being sent to the network node (300), how the VP is to be encoded before being sent to the network node (300).

11. The method according to any preceding claim, wherein said at least one attribute at least specifies a unique identifier of personal identification data of a verifiable credential, VC, of the communication device (200).

12. The method according to claim 2, wherein the digitally signed VP at least comprises the identifier data of the communication device (200) as attribute.

13. The method according to any preceding claim, wherein the information and the request for the VP is received in an EAP-Request message, wherein the VP is sent in an EAP-Response message, and wherein the message indicating successful authentication of the communication device (200) is an EAP Success message.

14. The method according to any preceding claim, wherein the method further comprises: computing (S118) key material for use in establishing secure communication with the network node (300), wherein the key material is based on key pairs and information exchanged with the network node (300).

15. A method for network subscriber authentication for a communication device (200) in a communication network (100a, 100b), wherein the method is performed by a network node (300) in the communication network (100a, 100b), and wherein the method comprises: receiving (S202) an encoded identifier of the communication device (200) from the communication device (200); selecting (S204) an authentication process for authenticating the communication device (200) based on an identifier retrieved by the network node (300) from the encoded identifier; sending (S210) information and a digitally signed request for a verifiable presentation, VP, to the communication device (200), wherein the information is given by the selected authentication process and at least specifies formatting of the VP, and wherein the digitally signed request identifies at least one attribute of a verifiable credential, VC, of the communication device (200);receiving (S212) a digitally signed VP from the communication device (200), wherein the digitally signed VP comprises the at least one attribute of the VC; authenticating (S214) the communication device (200) by verifying said at least one attribute, by verifying that a digital signature of the digitally signed VP belongs to the communication device (200), and by verifying that the VP is of a format given by the specified formatting; and sending (S216) a message indicating successful authentication of the communication device (200) to the communication device (200).

16. The method according to claim 15, wherein the authentication process follows any of: ISO / IEC 18013-5, ISO / IEC 18013-7, OpenID4VP.

17. The method according to claim 15 or 16, wherein the method further comprises: sending (S206) a request for device engagement data of the communication device (200) to the communication device (200); and receiving (S208) the device engagement data of the communication device (200) from the communication device (200).

18. The method according to any of claims 15 to 17, wherein the digitally signed request for a VP is encrypted, and wherein the method comprises: encrypting (S210-2) the digitally signed request using an encryption key.

19. The method according to any of claims 15 to 18, wherein the received digitally signed VP is encrypted, and wherein the method comprises: decrypting (S212-2) the encrypted digitally signed VP using an encryption key.

20. The method according to any of claim 18 or 19, wherein the encryption key is derived using a private-public key pair generated by the network node (300) and a public key of the communication device (200), wherein the public key is either received as part of device engagement data or together with the encrypted digitally signed VP.

21. The method according to any of claims 15 to 20, wherein the formatting of the VP pertains to at least one of: how the VP is to be digitally signed before being sent to the network node (300), how the VP is to be encoded before being sent to the network node (300).

22. The method according to any of claims 15 to 21, wherein said at least one attribute at least specifies a unique identifier of personal identification data of a verifiable credential, VC, of the communication device (200).

23. The method according to any of claims 15 to 22, wherein the digitally signed VP at least comprises identifier data of the communication device (200) as attribute.

24. The method according to any of claims 15 to 23, wherein, in case the encoded identifier is received in an initial registration request message or an initial identity response from the communication device (200) the digitally signed request identifies a larger number of attributes of the VC than in case the encoded identifier is received in a registration request message or an identity response received subsequently to the initial registration request message or the initial identity response from the communication device (200).

25. The method according to any of claims 15 to 24, wherein the network node (300) repeats sending the digitally signed request, receiving the digitally signed VP, and authenticating the communication device (200) for a respective set of attributes.

26. The method according to claim 25, wherein how many times the network node (300) repeats sending the digitally signed request, receiving the digitally signed VP, and authenticating the communication device (200) depends on which attributes are received from the communication device (200).

27. The method according to any of claims 15 to 26, wherein authenticating the communication device (200) comprises: verifying (S214-2), with a trust service provider, TSP, or a qualified trust service provider, QTSP, that the digital signature of the digitally signed VP has not been revoked.

28. The method according to any of claims 15 to 27, wherein the information and request for VP is sent in an EAP-Request message, wherein the VP is received in an EAP-Response message, and wherein the message indicating successful authentication of the communication device (200) is an EAP Success message.

29. The method according to any of claims 15 to 28, wherein the method further comprises: computing (S218) key material for use in establishing secure communication with the communication device (200), wherein the key material is based on key pairs and information exchanged with the communication device (200).

30. The method according to any of claims 15 to 29, wherein the network node (300) at least partly is implemented in at least one of: an authentication server function, AUSF, node, a unified data management, UDM, node, an authentication, authorization and accounting, AAA, server.

31. A communication device (200) for network subscriber authentication for a communication network (100a, 100b), the communication device (200) comprising processing circuitry (210), the processing circuitry being configured to cause the communication device (200) to: send an encoded identifier of the communication device (200) to a network node (300) in the communication network (100a, 100b); receive information and a digitally signed request for a verifiable presentation, VP, from the network node (300), wherein the information specifies formatting of the VP, and wherein the digitally signed request identifies at least one attribute of a verifiable credential, VC, of the communication device (200), wherein the VC is stored in a Digital Identity, DI, wallet entity residing in the communication device (200); authenticate the network node (300) by verifying that a digital signature of the digitally signed request belongs to the network node (300); send a digitally signed VP to the network node (300), wherein the digitally signed VP comprises the at least one attribute of the verifiable credential, VC, and hasbeen digitally signed by the DI wallet entity and is of a format given by the specified formatting; and receive a message indicating successful authentication of the communication device (200) from the network node (300).

32. A network node (300) for network subscriber authentication for a communication device (200) in a communication network (100a, 100b), the network node (300) comprising processing circuitry (310), the processing circuitry being configured to cause the network node (300) to: receive an encoded identifier of the communication device (200) from the communication device (200); select an authentication process for authenticating the communication device (200) based on an identifier retrieved by the network node (300) from the encoded identifier; send information and a digitally signed request for a verifiable presentation, VP, to the communication device (200), wherein the information is given by the selected authentication process and at least specifies formatting of the VP, and wherein the digitally signed request identifies at least one attribute of a verifiable credential, VC, of the communication device (200); receive a digitally signed VP from the communication device (200), wherein the digitally signed VP comprises the at least one attribute of the VC; authenticate the communication device (200) by verifying said at least one attribute, by verifying that a digital signature of the digitally signed VP belongs to the communication device (200), and by verifying that the VP is of a format given by the specified formatting; and send a message indicating successful authentication of the communication device (200) to the communication device (200).

33. A system (100a, 100b) comprising a communication device (200) according to claim 31 and a network node (300) according to claim 32.34- A computer program (1220a) for network subscriber authentication for a communication network (100a, 100b), the computer program comprising computer code which, when run on processing circuitry (210) of a communication device (200), causes the communication device (200) to: send (S104) an encoded identifier of the communication device (200) to a network node (300) in the communication network (100a, 100b); receive (S110) information and a digitally signed request for a verifiable presentation, VP, from the network node (300), wherein the information specifies formatting of the VP, and wherein the digitally signed request identifies at least one attribute of a verifiable credential, VC, of the communication device (200), wherein the VC is stored in a Digital Identity, DI, wallet entity residing in the communication device (200); authenticate (S112) the network node (300) by verifying that a digital signature of the digitally signed request belongs to the network node (300); send (S114) a digitally signed VP to the network node (300), wherein the digitally signed VP comprises the at least one attribute of the verifiable credential, VC, and has been digitally signed by the DI wallet entity and is of a format given by the specified formatting; and receive (S116) a message indicating successful authentication of the communication device (200) from the network node (300).

35. A computer program (1220b) for network subscriber authentication for a communication device (200) in a communication network (100a, 100b), the computer program comprising computer code which, when run on processing circuitry (310) of a network node (300), causes the network node (300) to: receive (S202) an encoded identifier of the communication device (200) from the communication device (200); select (S204) an authentication process for authenticating the communication device (200) based on an identifier retrieved by the network node (300) from the encoded identifier;send (S210) information and a digitally signed request for a verifiable presentation, VP, to the communication device (200), wherein the information is given by the selected authentication process and at least specifies formatting of the VP, and wherein the digitally signed request identifies at least one attribute of a verifiable credential, VC, of the communication device (200); receive (S212) a digitally signed VP from the communication device (200), wherein the digitally signed VP comprises the at least one attribute of the VC; authenticate (S214) the communication device (200) by verifying said at least one attribute, by verifying that a digital signature of the digitally signed VP belongs to the communication device (200), and by verifying that the VP is of a format given by the specified formatting; and send (S216) a message indicating successful authentication of the communication device (200) to the communication device (200).

36. A computer program product (1210a, 1210b) comprising a computer program (1220a, 1220b) according to at least one of claims 34 and 35, and a computer readable storage medium (1230) on which the computer program is stored.

Images