WO2022090813A1

WO2022090813A1 - Verification of authenticity of a user equipment using puf

Info

Publication number: WO2022090813A1
Application number: PCT/IB2021/056615
Authority: WO
Inventors: Niklas LINDSKOG; Henrik NORMANN; David Castellanos Zamora
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2020-10-30
Filing date: 2021-07-21
Publication date: 2022-05-05

Abstract

A user equipment verifies its authenticity to a network. The user equipment comprises a physically unclonable function (PUF) entity and may be with or without default credentials. The user equipment obtains a PUF response and/or a validation token, where the validation token is a combination of a PUF response and a predefined string, and where the PUF response is obtained from the PUF entity by providing a challenge as input to the PUF entity. The user equipment provides, in a registration request to the network, a SUPI and/or other authentication information of the user equipment, wherein the SUPI comprises the validation token. In response to the registration request, the user equipment obtains a registration accept message from the network.

Description

VERIFICATION OF AUTHENTICITY OF A USER EQUIPMENT USING PUF

TECHNICAL FIELD

[0001] Embodiments presented herein relate to methods, a user equipment, a Default Credential Server (DCS), computer programs, and a computer program product for verifying authenticity of the user equipment.

BACKGROUND

[0002] The third-generation partnership program (3GPP) fifth generation (5G) telecommunication system (5G system) includes features that require introduction of new security mechanisms. For example, the 5G system integrates non-3GPP access (e.g. wireless local area networks, WLAN) alongside 3GPP access networks (e.g., over the 5G New Radio (NR) air interface or the Long-Term Evolution (LTE) air interface) in a seamless manner. More precisely, in 5G systems, the user equipment (UE) can run the usual service access procedure independently of the underlying network access. The security for the Release 15 of the 5G system has been specified in the technical specification 3GPP TS 33.501 entitled “Security architecture and procedures for 5G System”, Version 16.4.0.

[0003] FIG. 1 is a schematic diagram illustrating a communication network 100. The communication network 100 represents a reference architecture of a 5G system and comprises the following entities: and Authentication Server Function (AUSF) 118, an Access and Mobility Management Function (AMF) 120, a Data Network (DN) 132, e.g. operator services, Internet access or third party services, a Network Exposure Function (NEF) 104, a Network Repository Function (NRF) 106, a Network Slice Selection Function (NSSF) 102, a Policy Control Function (PCF) 108, a Session Management Function (SMF) 122, a Unified Data Management (UDM) function 110, a Unified Data Repository (UDR) 116, a User Plane Function (UPF) 130, an Application Function (AF) 112, a (Radio) Access Network ((R)AN) 128, a Network Data Analytics Function (NWDAF) 124, a Binding Support Function (BSF) 114, and a Charging Function (CHF) 126. Service based interfaces are represented by the format Nxyz (e.g., Nnssf, Nnef, etc.) and point to point interfaces are represented by the format Nx (e.g. Nl, N2, etc.). A User Equipment (UE) 200 is served by the (R)AN 128. An external domain (ED) 134 comprising a DCS 300 is operatively connected to the AUSF 118. However, DCS 300 might be operatively connected to also other entities in the network 100. In some embodiments, the (R)AN 128, the AMF 120 and the AUSF 118 represent an onboarding network.

[0004] The communication links between the UE and the network (comprising an Access Network (AN) and a Core Network (CN) part) can be grouped in two different strata. The UE communicates with the CN over the Non-Access Stratum (NAS), and with the AN over the Access Stratum (AS). All the NAS communication takes place between the UE and the AMF in the CN over the NAS protocol (Nl interface in FIG. 1). Protection of the communications over these strata is provided by the NAS protocol for NAS and the Packet Data Convergence Protocol (PDCP) for AS. [0005] Release 16 of the 5G system provides support for Non-Public Network (NPN), as described in the technical specification 3GPP 23.501 entitled “System architecture for the 5G System (5GS)”, Version 16.6.0. This feature is intended to help so-called verticals make use of services in the 5G system by either deploying their own standalone 5G system, a concept denoted by standalone Non-Public Network (SNPN), or via a Public Land Mobile Network (PLMN), called Public Network integrated NPN (PNi-NPN). With NPNs, at least parts of the 5G systems are operated by a private network operator which only allows certain pre-registered parts of UE to attach to it. How the network functionality is split between the private network operator and a public network operator can vary; all functionality can be provided by the private network operator, or parts, e.g. (R)AN and/or control plane functionalities can be provided by the public network operator as a service for the private network operator. The NPN might in some embodiments be regarded as an SNPN, even if the (R)AN is provided by the public network operator.

[0006] For SNPNs, any Extensible Authentication Protocol (EAP) based authentication procedure can be used, and e.g. certificates could be used instead of traditional subscriber credentials. When performing EAP based authentication in a 5G CN, the Security Anchor Function (SEAF) acts as the EAP authenticator and the AUSF acts as the EAP (authentication) server, with the UDM being the credential database. When an NPN is accessed via a public network operator the (radio) access network node of the public network might advertise the network identifier (NID) of the private network(s) reachable through it. Globally unique NIDs can be assigned such that each NID is either globally unique, independent of the PLMN ID used, or so that the combination of each NID and PLMN ID is globally unique. Different combinations of PLMN ID and NID might point towards the same 5G core network. When accessing an SNPN using the (R)AN of a PLMN, the Subscription Permanent Identifier (SUPI) of the communication device can include the NID as the realm part of the Network Access Identifier (NAI). In this way the request can be forwarded by the (R)AN to the SNPN instead of the PLMN.

[0007] Aspects of onboarding and provisioning of credentials to UEs to be served by NPNs have been studied in the 3GPP technical report 3GPP TR 23.700-07 entitled “Study on enhanced support of Non-Public Networks (NPN)”, Version 1.0.0. Onboarding refers to the case where a UE requests to obtain network access to a network without having any specific credentials for the network.

[0008] Terminology and notation as defined next will be used hereinafter. UE Onboarding is a process of provisioning of information, to a UE and within the network, required for the UE to get authorized access and connectivity to an NPN. An Onboarding Network (ON) is the network providing initial registration and/or access to the UE for UE Onboarding. A Provisioning Server (PS) is the server that provisions the authentic ated/authorized UE with the subscription data and optionally other configuration information. A Subscription Owner (SO) is the entity that stores, and as result of the UE onboarding procedures, provides the credentials and optionally other configuration information via the PS to the UE. Default UE credentials define information that the UE have before the actual onboarding procedure to make it uniquely identifiable and verifiably secure. A Default Credential Server (DCS) represents the server that can authenticate a UE with default UE credentials or provide means to another entity to do it. NPN credentials are pieces of information that the UE uses for authentication to access an NPN. NPN credentials may be 3GPP credentials or non-3GPP credentials. A unique UE identifier is an identifier that identifies the UE in the network and the DCS and is assigned and configured by the DCS. [0009] The DCS is the external entity that is expected to authenticate the UE for a given network based on the default UE credentials. One example of such delegated authentication procedure is UE onboarding. The onboarding network might rely on the DCS to grant temporary access and connectivity to pieces of UE for onboarding. Once the UE is provisioning with the necessary credentials, the UE can use the new credentials to access the target NPN. It has been proposed in aforementioned 3GPP TR 23.700-07 that the UE establishes security keys with the onboarding network during execution of primary authentication with the onboarding network, where the onboarding network relies on the DCS to authenticate the UEs.

[0010] In some examples, the UE is provisioned with default credentials which by the UE are used when authenticating with the DCS. However, if not stored properly on the UE, these default credentials might be revealed to an attacker and used by the attacker to clone the UE. It might be difficult for the DCS to protect itself from a counterfeit UE that by the attacker has been cloned from the legitimate UE. Also other credential-stealing attacks, e.g. exploitation of software and hardware bugs, invasive and non- invasive physical attacks are envisioned. Consequently, there is a need for a more secure authentication procedure for the UE.

[0011] In some examples, the UE is a commercial off-the-shelf device that is not provisioned with any default credentials that can be used for authentication. This creates a situation where the network cannot authenticate the UE nor can it establish that the UE is from a legitimate manufacturer. Consequently, there is a need for new approaches to verify authenticity of a UE lacking default credentials.

SUMMARY

[0012] The described embodiments provide various techniques and technologies for verifying the authenticity of a user equipment.

[0013] In some embodiments, a user equipment performs a method to verify its authenticity to a network, where the user equipment comprises a PUF entity and is without default credentials. The method comprises obtaining a validation token. The validation token is a combination of a PUF response and a predefined string. The PUF response is obtained from the PUF entity by providing a challenge as input to the PUF entity. The method comprises providing, in a registration request to the network, a SUPI of the user equipment. The SUPI comprises the validation token. The method comprises, in response thereto, obtaining a registration accept message from the network.

[0014] Potential benefits of such embodiments include providing a lightweight way of adding a layer of security during authentication of the UE for the case where a DCS and a UE have limited resources to authenticate. Other potential benefits may include protecting against cloned and counterfeit UEs impersonating legitimate UEs. An attacker needs to both have knowledge of the Permanent Equipment Identifier of the user equipment and the PUF response, the latter being less susceptible to cloning or remote hacking. Still other potential benefits include protecting against replay attacks. A counterfeit UE which provides a previously observed validation token will not be authenticated by the DCS.

[0015] In some other embodiments, a user equipment performs a method to verify its authenticity to a network. The user equipment comprises a PUF entity. The method comprises obtaining a PUF response from the PUF entity by providing a challenge as input to the PUF entity. The method comprises providing, as part of registering with the network, authenticity information of the user equipment. The authenticity information comprises the PUF response. The method comprises, in response thereto, obtaining a registration accept message from the network.

[0016] Such embodiments can potentially be used in conjunction with authenticating the user equipment and thus enable a more secure authentication procedure for the user equipment. Moreover, some such embodiments may provide an additional layer of security for the case where the UE relies on default credentials for authentication by the DCS. Additionally, such embodiments may protect against cloned and counterfeit UEs impersonating legitimate UEs. A counterfeit UE that to the DCS provides a valid user equipment identifier will not be authenticated by the DCS unless the corresponding PUF response is correct. Still further, such embodiments may protect against replay attacks, since each PUF response may only be used to validate the UE once.

[0017] 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. [0018] 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.

BRIEF DESCRIPTION OF THE DRAWINGS

[0019] The inventive concept is described below, by way of example, with reference to the accompanying drawings.

[0020] FIG. 1 is a schematic diagram illustrating a communication network according to certain embodiments.

[0021] FIG. 2A is a flowchart illustrating a method according to certain embodiments.

[0022] FIG. 2B is a flowchart illustrating a method according to certain embodiments.

[0023] FIG. 3 A is a flowchart illustrating a method according to certain embodiments. [0024] FIG. 3B is a flowchart illustrating a method according to certain embodiments.

[0025] FIG. 4A is a signalling diagram of a method according to certain embodiments.

[0026] FIG. 4B is a signalling diagram of a method according to certain embodiments.

[0027] FIG. 5 A is a flowchart illustrating a method according to certain embodiments.

[0028] FIG. 5B is a flowchart illustrating a method according to certain embodiments.

[0029] FIG. 6A is a schematic illustration of interactions between a user equipment and a DCS according to certain embodiments.

[0030] FIG. 6B is a schematic illustration of interactions between a user equipment and a DCS according to certain embodiments.

[0031] FIG. 7A is a schematic illustration of interactions between a user equipment and a DCS according to certain embodiments.

[0032] FIG. 7B is a schematic illustration of interactions between a user equipment and a DCS according to certain embodiments.

[0033] FIG. 8A is a schematic illustration of interactions between a user equipment and a DCS according to certain embodiments.

[0034] FIG. 8B is a schematic illustration of interactions between a user equipment and a DCS according to certain embodiments.

[0035] FIG. 9A is a schematic illustration of interactions between a user equipment and a DCS according to certain embodiments.

[0036] FIG. 9B is a schematic illustration of interactions between a user equipment and a DCS according to certain embodiments.

[0037] FIG. 10 is a schematic illustration of interactions between a user equipment and a DCS according to certain embodiments.

[0038] FIG. 11 is a schematic diagram showing functional units of a user equipment according to certain embodiments.

[0039] FIG. 12 is a schematic diagram showing functional units of a DCS according to certain embodiments.

[0040] FIG. 13 shows an example of a computer program product comprising computer readable means according to certain embodiments.

DETAILED DESCRIPTION

[0041] The inventive concept is 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, unless otherwise indicated by context or explanation. Any step or feature illustrated by dashed lines should be regarded as optional.

[0042] The wording that a certain data item or piece of information is obtained by a first device should be construed as that data item or piece of information being retrieved, fetched, received, or otherwise made available to the first device. For example, the data item or piece of information might either be pushed to the first device from a second device or pulled by the first device from a second device. Further, for the first device to obtain the data item or piece of information, the first device might be configured to perform a series of operations, possible including interaction with the second device. 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 device.

[0043] The wording that a certain data item or piece of information is provided by a first device to a second device should be construed as that data item or piece of information being sent or otherwise made available to the second device by the first device. For example, the data item or piece of information might either be pushed to the second device from the first device or pulled by the second device from the second device. Further, for the first device to provide the data item or piece of information to the second device, the first device and the second device might be configured to perform a series of operations 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 device.

[0044] The embodiments disclosed herein relate to mechanisms for verifying authenticity of a UE. To obtain such mechanisms there is provided a UE, a method performed by the UE, a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the UE, causes the UE to perform the method. To obtain such mechanisms there is further provided a DCS, a method performed by the DCS, and a computer program product comprising code, for example in the form of a computer program, that when run on processing circuitry of the DCS, causes the DCS to perform the method.

[0045] Certain embodiments relate to a UE to be connected to an onboarding network that utilizes a PUF response created by a PUF entity in the UE to prove authenticity. The UE could be any of e.g.: a wireless device, terminal device, mobile station, mobile phone, handset, wireless local loop phone, smartphone, laptop computer, tablet computer, network equipped sensor, network equipped vehicle, wearable electronic device, Internet of Things device. The PUF entity might be constructed as a component which can be utilized for other purposes (e.g. using SRAM or FPGA logic) or as a fixed structure only intended to function as a PUF (e.g. an ASIC).

[0046] Certain embodiments relate to a UE comprising a PUF entity. In general, a PUF entity is configured to create a unique response, hereinafter denoted PUF response, by using implicit or explicit randomness. The PUF response can by the UE be used for cryptographic purposes or device identity purposes. For example, the PUF response can be used to create a unique device identity or a device unique key, without having to store the key in e.g. a Battery Backed Random Access Memory (BBRAM) or a One-Time Programmable (OTP) memory. Hence, certain types of attack, such as stealing a key from the UE using a PUF entity, are made more difficult, as any created key is never stored on the UE.

[0047] The PUF response is created by exploited implicit or explicit randomness. Implicit randomness can be regarded as unpredictable manufacturing differences in semiconductor devices. Explicit randomness on the other hand implies that the randomness is not there during manufacturing but introduced at a later stage. The PUF entity might comprise, or implement, one or several subfunctions, which each contributes with a part of the PUF response. Non-limiting examples of such subfunctions are arbiters, ring-oscillators and uninitialized Static Random- Access Memory (SRAM) cells. In this respect, arbiters might be regarded as a digital race condition between two or more signal paths on a chip where a so-called arbiter circuit identifies the winning signal. The paths might comprise several switch blocks which can alter the signal paths. The PUF response in this case can be the ID of the winning signal. In terms of ring-oscillators, these might be regarded as an uneven number of signal inverters in a ring which use gate delay propagation as randomness source. The PUF response might then be defined from a comparison between two or more ring-oscillators, where the number of oscillations at a given point is measured. The result (i.e., the PUF response) can e.g. be the identifier of the fastest, or slowest, ring oscillator. In terms of uninitialized SRAM cells, these have two possible states; logic zero and logic one. Prior to being powered up, the SRAM cells are in neither state. At powerup, each memory cell stabilizes in one of the two states. The PUF response is then defined by the entered state.

[0048] In some PUF entities, the same sub-function(s) might generate several outputs by utilizing different parts of the PUF challenge. Each sub-function also has the property that it is physically unclonable, i.e. unique for the device. A PUF may therefore comprise of several subfunctions which can be used as independent PUFs, albeit with less possible challenges and fewer response bits.

[0049] PUF entities can generally be divided into two different categories: strong and weak. The former can produce several different PUF responses by using different challenges (usually a binary string of a fixed length) as input. The latter only allows one or a few challenges. Both types of PUF entities can be used for generating a device identity and to protect cryptographical keys, while only strong PUFs should be used for remote authentication of a device. A PUF entity is considered strong when having many challenge-response pairs (CRPs). Some types of PUF entities additionally require helper data to function properly, i.e. to increase the possibility of recreating the same response given the same challenge. [0050] The UE might comprise Non-Volatile Memory (NVM), which can be embodied as, e.g., One-time programmable memory (OTP) or as an integrity protected Multiple-Time Programmable (MTP) memory. The UE is provided with a Permanent Equipment Identifier (PEI). In the case where the UE is allowed to access 3GPP networks, the PEI takes the form of an International Mobile Equipment Identity (IMEI). The UE is provided with a Realm in terms of a string containing the address of the DCS.

[0051] The UE might further comprise an authenticity counter that is incremented during each onboarding procedure. The counter is typically non-reversable, i.e. not be able to return to a lower value than its current value. The UE might hold a manufacturer certificate. This is a certificate that contains a public key acting as the home network public key of the UE. The UE might hold default UE credentials. These credentials define information which the UE possesses before the actual onboarding procedure to make it uniquely identifiable and verifiably secure. These credentials might e.g. be embodied by a UE certificate. The UE might implement a one-way function (OWF). OWFs are functions that are easy to compute on every input, but hard to invert given the image of a random input. An example of such is a hash function. The OWF might act as a key derivation function (KDF), producing a deterministic random key from a given input, such as a nonce provided from a nonce list 258. Such a random key can be used by a symmetric encryption algorithm, such as the Advanced Encryption Standard (AES).

[0052] In some examples, the UE comprises a cryptographic module. The cryptographic module may be configured to implement one or several symmetric and/or asymmetric cryptographic algorithms. In some examples, the UE comprises a PUF error correction module. This module might be configured to apply error correction algorithms to, using helper data from a helper data database, recreate PUF responses. In some examples, the UE has access to a helper data database. This database stores entries of error correcting codes corresponding to one or several CRPs.

[0053] In some examples, the PUF entity has an interface that can be probed by the manufacturer to extract CRPs. These CRPs can be used for authentication of the UE at a later point in time. The probing interface is permanently disabled when the PUF responses have been extracted. A second interface to the PUF entity, connected exclusively to the OWF is left open. The OWF is in turn exclusively connected to receive the UE identifier and the current value of the authenticity counter as input.

[0054] In some embodiments, during manufacturing the UE is provided with default credentials, e.g. embodied by a certificate. The default credentials typically comprise a UE identifier. The UE is also provided with a manufacturer certificate which contains the home network public key, in this case embodied by the public key of the DCS. The home network public key can be utilized by the UE to provide SUPI privacy.

[0055] The DCS typically comprises an external authentication server having access to authentication vectors for UE from a certain manufacturer. The DCS could be an AAA-S, for example. [0056] In some embodiments, the DCS is configured to obtain UE credentials. The DCS might comprise a PUF response database. This database is configured to stores lists of PUF responses. Each list is stored together with the corresponding UE identifier. In some examples, the list may instead be a mathematical model representing the PUF. The DCS might comprise a validation module. This module might be configured to validate that a received PUF response belongs to a UE with a certain UE identifier. This module might also be configured to validate that the received PUF response has not previously been used for authentication purposes. The DCS might comprise a validation check module that receives input from the validation module.

[0057] In some examples, the DCS comprises a cryptographic module. The cryptographic module might be configured to implement one or several symmetric and/or asymmetric cryptographic algorithms. In some examples, the DCS comprises a PUF error correction module. This module might be configured to apply error correction algorithms to, using helper data, recreate PUF responses. In some examples, the DCS has access to a helper data database. This database stores entries of error correcting codes corresponding to one or several CRPs, where each entry belongs to a specific CRP on a specific PUF.

[0058] In some embodiments, the DCS comprises a validation token database that is configured to store lists of validation token. Each list might be stored together with the corresponding UE identifier, such as the PEI. The DCS might comprise a validation module. This module might be configured to validate that a received validation token response belongs to a UE with a certain UE identifier. In some examples, the UE is identified by its PEI. This module might also be configured to validate that the received validation token has not previously been used for authentication purposes. The DCS might comprise a token in database check module configured to receive input from the validation module.

[0059] FIG. 2A illustrates a method for verifying authenticity of a UE as performed by a UE 200 according to an embodiment. The UE comprises a PUF entity.

[0060] SI 02 A: The UE obtains a PUF response from the PUF entity by providing a challenge as input to the PUF entity.

[0061] SI 04 A: The UE provides, as part of registering with a network 400, authenticity information of the UE. The authenticity information comprises the PUF response.

[0062] S108A: The UE, in response thereto, obtains a registration accept message from the network.

[0063] This method can be used in conjunction with authenticating the UE and thus enable a more secure authentication procedure for the UE, thus providing an extra layer of verification on top of the primary authentication procedure performed with the DCS where, for example, default credentials are used.

[0064] Embodiments relating to further details of verifying authenticity of a UE as performed by UE 200 are discussed below. In some examples the network is an SNPN.

[0065] In some embodiments, the challenge is based on a unique identifier for the UE. The challenge might either preconfigured in the UE or acquired from an external entity. That is, in some embodiments, the challenge is preconfigured in the UE or acquired by the UE from an entity external to the UE. There could be different examples of external entities. For example, the external entity could be a Universal Serial Bus (USB) flash drive or a Secure Digital (SD) card. In some embodiments, the challenge is based on a counter (such as an authenticity counter) which is incremented during each onboarding procedure. In some embodiments, the challenge further is based on a value of a counter, wherein the value of the counter is incremented each time a new challenge is created. In some embodiments, the challenge is supplied to the UE from the DCS during an EAP exchange between the UE and the DCS. In some embodiments, the challenge further is based on information as received from the DCS as part of performing an EAP authentication procedure with the DCS, where the EAP authentication procedure is performed as part of the UE registering with the network. Aspects of the authenticity information are discussed below.

[0066] In some embodiments, the UE sends the PUF response in a registration request. In some embodiments, the authenticity information is in step SI 04 A provided in a registration request to the network. In some embodiments, the PUF response is part of a SUPI 250, 344. In some embodiments, the PUF response in the authenticity information is provided in a SUPI of the UE. In some embodiments, the SUPI is in the NAI format. In some embodiments, the PUF response provided as a part of the username field in the SUPI. That is, in some embodiments, the SUPI has a username field, and the PUF response is provided as a part of the username field in the SUPI. In some embodiments, the SUPI is encrypted. In some embodiments, the SUPI is encrypted using a public key of a DCS before being provided in the registration request. In some embodiments, an encrypted SUPI is a SUCI and thus the PUF response might be provided in a SUCI 256.

[0067] In other aspects, the UE sends the PUF response during EAP authentication with the DCS. In some embodiments, the authenticity information is in step S104A provided as part of performing the EAP authentication procedure with the DCS.

[0068] In some embodiments, the UE is provided with default credentials. These default credentials could then be sent to the DCS during the EAP authentication. That is, in some embodiments, the UE is configured to perform (optional) step S106A:

[0069] S106A: The UE provides, as part of performing an EAP authentication procedure with a

DCS, default credentials of the UE to the DCS, wherein the EAP authentication procedure is performed as part of the UE registering with the network.

[0070] In some embodiments, step S106A is performed after step S104A but before step S108A.

[0071] FIG. 2B illustrates a method for verifying authenticity of UE 200 according to another embodiment. In this embodiment, the UE comprises a PUF entity and is without default credentials. [0072] S102B: The UE obtains a validation token. The validation token is a combination of a PUF response and a predefined string. The PUF response is obtained from the PUF entity by providing a challenge as input to the PUF entity.

[0073] S104B: The UE provides, in a registration request to the network 400, a SUPI of the UE. The

SUPI comprises the validation token.

[0074] S106B: The UE, in response thereto, obtains a registration accept message from the network.

[0075] This method can be used to provide the onboarding network with an indication that a UE is authentic when there are no means to perform primary authentication of the UE. The procedure might thus be performed with the DCS when, for example, default credentials cannot be used. In some examples the network is an SNPN.

[0076] Different examples of predefined strings used in step S102B may be combined with the PUF response for the validation token. The predefined string may be, for example, a permanent equipment identifier (PEI) of the UE or a media access control (MAC) address of the UE.

[0077] In some embodiments, an encrypted validation token is stored on the UE. In some embodiments, the validation token is encrypted when stored in the UE and decrypted before being comprised in the SUPI 254, 342. The validation token might be encrypted with the PUF response as key to form an encrypted token. The encrypted token is then decrypted with the PUF response to recreate the validation token.

[0078] Aspects of different ways in which the PUF response and the predefined string are combined to form the validation token are discussed below. In some embodiments, the combination is defined by an exclusive or (XOR) operation. That is, in some embodiments, the PUF response and the predefined string are combined by performing an XOR operation between the PUF response and the predefined string. The UE might therefore comprise an XOR module 252 configured to implement the XOR operation.

[0079] In some examples, the challenge is based on a predefined binary string or a challenge derived either from the PEI of the UE, or from the MAC address of the UE. The challenge might either be preconfigured in the UE or acquired from an external entity. That is, in some embodiments, the challenge is preconfigured in the UE or acquired by the UE from an entity external to the UE. There could be different examples of external entities. For example, the external entity could be a Universal Serial Bus (USB) flash drive or a Secure Digital (SD) card. In some embodiments, the challenge is based on a counter (such as an authenticity counter) which is incremented during each onboarding procedure. In some embodiments, the challenge further is based on a value of a counter, wherein the value of the counter is incremented each time a new challenge is created.

[0080] The herein disclosed method could be used with PUF responses of various lengths. In some examples though, the PUF response is composed of at least 128 bits.

[0081] In some embodiments, the PUF response is in step S104B provided as a part of username field in the SUPI of the UE. In some embodiments, the SUPI has a username field, and the PUF response is provided as a part of the username field in the SUPI. The SUPI is in NAI format.

[0082] In some embodiments, the SUPI is provided in a SUCI 260, 350 of the UE. In some embodiments, the SUPI in the registration request is provided as cleartext in a SUCI of the UE.

[0083] FIG. 3A illustrates a method for verifying authenticity of a UE as performed by a DCS 300 according to an embodiment. The DCS comprises PUF characteristics of the UE.

[0084] S202A: The DCS obtains, from the network, authenticity information as provided by the UE as part of the UE registering with the network. The authenticity information comprises a PUF response.

[0085] S208A: The DCS verifies authenticity of the UE by comparing the PUF response to the PUF characteristics. [0086] S210A: The DCS provides authentication information and keying material of the UE to the network upon having successfully verified the authenticity of the UE.

[0087] Embodiments relating to further details of verifying authenticity of a UE as performed by DCS 300 are discussed below.

[0088] In some embodiments, the authentication information comprises the validation of default credentials of the UE.

[0089] In some embodiments, the DCS receives the authenticity information, and thus the PUF response, in registration request for the UE. In some embodiments, the authenticity information is obtained in a request from the network to authenticate the UE to the network.

[0090] As disclosed above, in some embodiments, the UE is provided with default credentials. These default credentials could be sent to the DCS during the EAP authentication. That is, in some embodiments, the DCS is configured to perform (optional) step S204A and step S206A:

[0091] S204A: The DCS obtains, as part of performing an EAP authentication procedure with the

UE, default credentials of the UE. The EAP authentication procedure is performed as part of the UE registering with the network.

[0092] S206A: The DCS authenticates, using the default credentials, the UE.

[0093] In some embodiments, steps S204A and S206A are performed after step S202A but before step S210A. Hence, in some embodiments, the EAP authentication procedure is performed before verifying authenticity of the UE.

[0094] As disclosed above, in other aspects, the UE sends the PUF response during EAP authentication with the DCS. This could, for example, be the case where the DCS supplies the challenge to the UE within an EAP exchange between the DCS and the UE. In some embodiments, the PUF response has been created by the DCS providing a challenge as input to a PUF entity in the UE. The challenge is based on at least one of: a unique identifier for the UE and information provided by the DCS as part of performing an EAP authentication procedure with the UE. The EAP authentication procedure is performed as part of the UE registering with the network. The authenticity information might then in step S202A be obtained as part of performing the EAP authentication procedure with the DCS.

[0095] In some embodiments, the received PUF response is compared to PUF responses stored in a database (such as a PUF response database). In some embodiments, the PUF characteristics are defined by entries in a database. Each entry corresponds to a unique PUF response. Authenticity of the UE is then successfully verified only if one of the unique PUF responses fulfils a matching criterion for the PUF response of the UE. In some embodiments, the unique PUF response that fulfils the matching criterion is marked as used or removed from the database. In some embodiments, any unique PUF response that in the database is listed as generated prior to the unique PUF response that fulfils the matching criterion also is marked as used or removed from the database.

[0096] FIG. 3B illustrates a method for verifying authenticity of UE 200 as performed by DCS 300 according to an embodiment. The DCS comprises validation characteristics of the UE. [0097] S202B: The DCS obtains, in a request from the network to authenticate the UE to the network as part of the UE registering with the network, a validation token of the UE. The validation token is a combination of a PUF response and a predefined string.

[0098] S204B: The DCS verifies authenticity of the UE by comparing at least the PUF response to the validation characteristics.

[0099] S206B: The DCS provides authentication information of the UE to the network upon having successfully verified the authenticity of the UE.

[0100] Embodiments relating to further details of verifying authenticity of UE 200 as performed by DCS 300 are discussed below.

[0101] As disclosed above, there could be different examples of predefined strings used in step S102 to combine the PUF response with to for the validation token, and hence the same different examples of predefined strings used in the validation token as obtained by the DCS in step S202. Thus, in some embodiments, the predefined string may be, for example, a permanent equipment identifier of the UE or a media access control address of the UE.

[0102] As disclosed above, in some embodiments, the combination of the PUF response and the predefined string is defined by an XOR operation. That is, in some embodiments, the PUF response and the predefined string in the validation token as obtained in step S202B are combined by means of an XOR operation having been performed by the UE between the PUF response and the predefined string.

[0103] In some embodiments, not only the PUF response is compared to the validation characteristics but also other parts of the validation token are compared to the validation characteristics. That is, in some embodiments, verifying authenticity of the UE as in step S204B comprises comparing the validation token to the validation characteristics.

[0104] In some embodiments, the received PUF response (or validation token) is compared to validation characteristics stored in a database (such as validation token database). In some embodiments, the validation characteristics are defined by entries in a database. In some embodiments, each entry corresponds to a unique validation token. Authenticity of the UE is then successfully verified only if one of the unique validation tokens fulfils a matching criterion for the validation token of the UE. In other embodiments, each entry corresponds to a unique PUF response. Authenticity of the UE is then successfully verified only if one of the unique PUF responses fulfils a matching criterion for the PUF response of the UE. In some embodiments, the entry that fulfils the matching criterion is marked as used or removed from the database. In some embodiments, any entry that in the database is listed as generated prior to the entry that fulfils the matching criterion also is marked as used or removed from the database. [0105] FIG. 4A illustrates signaling for verifying authenticity of UE 200 based on at least some of the above disclosed embodiments.

[0106] S301A: The UE sends a Registration Request message to the SEAF. The UE includes an onboarding indication within the Registration Request. It is assumed here that the UE does not have credentials to be used for primary authentication with the network but rather only default credentials that can be used with the DCS. The UE is configured to create a PUF-based SUPI and a PUF-based SUCI containing an encrypted PUF response as part of the user identifier, e.g. PUFresponse@DCSrealm. [0107] S302A: The network determines that primary authentication with an external entity is to be performed. The network might bypass other procedures, such as AMF registration in the UDM, since the onboarding UE is not a subscriber of the onboarding network.

[0108] S303a-A: The SEAF sends a Nausf_UEAuthentication_Authenticate request with the PUF- based SUCI included to the AUSF.

[0109] The AUSF realizes that an external entity is needed to perform the primary authentication of the UE. NAI format of the SUCI is expected and the home network identifier (HNI) part of the SUCI includes a realm that points to a specific DCS. For example, a SUCI such as encryptedPUFresponse@UEvendorl.com results in the AUSF selecting a DCS corresponding to UEvendorl.

[0110] S303b-A: The DCS decrypts the provided SUCI with its private key.

[0111] S303c-A: An EAP authentication procedure is performed between the UE and the DCS. The

DCS endorses the role of the AAA-S through the AMF. EAP authentication procedure might be a certificate based EAP method e.g. EAP-TLS (where TLS is short for Transport Layer Security).

[0112] S303d-A: If authentication is successful, the DCS checks its database over PUF responses that are valid for the UE identifier provided in the UE certificate. In case the check is successful the authentication procedure continues. Otherwise an error indicating unauthorized user is sent from the DCS to the AUSF.

[0113] The DCS might select to provide the decrypted PUF based SUPI to the onboarding network at successful authentication. Alternatively, the DCS might select to provide a SUPI based on the UE identifier used during the primary authentication procedure.

[0114] S304A: The SEAF sends a registration accept message to the UE.

[0115] FIG. 4B illustrates signaling for verifying authenticity of UE 200 based on at least some of the above disclosed embodiments.

[0116] S301B: The UE sends a Registration Request message to the SEAF. The UE includes an onboarding indication within the Registration Request. The Registration Request message comprises the SUPI of the UE.

[0117] S302B: The network determines that primary authentication with an external entity is to be performed. The network might bypass other procedures, such as AMF registration in the UDM, since the onboarding UE is not a subscriber of the onboarding network.

[0118] S303a-B: The SEAF sends a Nausf_UEAuthentication_Authenticate request with the SUPI included to the AUSF. The AUSF realizes an external entity is needed to perform the primary authentication of the UE. [0119] S303b-B: The DCS decrypts the provided SUPI to check if the PEI is in its validation token database. In addition, the DCS checks that this PEI has not been provided in an earlier authentication request.

[0120] S303c-B: The DCS might select to include the decrypted SUPI, e.g. the PEI, to the onboarding network at a successful validation. This means that the network can uniquely identify the UEs it grants limited network access. In case the validation fails the DCS delivers a message indicating failure to the onboarding network. The network might then reject the UE from obtaining limited network connectivity.

[0121] S304B: The SEAF sends a registration accept message to UE. The UE might then continue the onboarding process with limited network connectivity provided by the onboarding network to connect to a provisioning server.

[0122] FIG. 5A illustrates a method verifying authenticity of UE 200 based on at least some of the above disclosed embodiments.

[0123] The method is preceded by a manufacturing phase. During manufacturing the manufacturer provides the UE with default credentials, which contains a UE identifier, and a manufacturer certificate containing the public key of the DCS. Using the UE identifier and the authenticity counter, the manufacturer creates a pre-defined number of CRPs and store them in an external database. The manufacturer locks the interface to the PUF entity to only receive input from the OWF. The manufacturer supplies the database of PUF responses to the DCS.

[0124] S401A: The UE creates a challenge for the PUF entity using the OWF, where the challenge is a function of the UE identifier and the current value of the authenticity counter. The PUF entity generates a PUF response using the created challenge.

[0125] S402A: The UE creates a SUPI using the PUF response as input for the username field.

This PUF-based SUPI is in the Network Access Identifier (NAI) format “username@realm”, where the “username” corresponds to the PUF response and the realm corresponds to the realm of the DCS.

[0126] S403A: The UE encrypts the PUF-based SUPI using the public key of the DCS to create a

PUF-based SUCI. In the NAI field, only the username is encrypted. The UE might provide a more explicit indication to the onboarding network that the SUPI concealed by the SUCI is a PUF-based SUPI (i.e. that it does not correspond to any real SUPI of any UE) e.g. by using a new SUPI type within the SUCI structure.

[0127] S404A: The UE sends a registration request to the onboarding network using the PUF-based

SUCI.

[0128] S405A: The UE increases the authenticity counter by 1.

[0129] S406A: The onboarding network decides that primary authentication is to be handled by the

DCS. The AUSF forwards the registration request to the DCS. The DCS decrypts the PUF-based SUCI and extracts the SUPI using the DCS private key. [0130] S407A: The DCS commences EAP authentication with the UE. In this process, the UE supplies the UE certificate containing the UE identifier to the DCS. If authentication is successful, the DCS continues to perform validation of the PUF response e.g. based on the new SUPI type indication within the SUCI. The DCS extracts the UE identifier from the UE certificate and searches the database for the PUF response list corresponding to that UE identifier. It is also possible to perform the PUF validation prior to authentication of the default credentials of the UE. The UE must, however, have supplied its certificate prior to validation of the PUF response.

[0131] S408A: The DCS inspects if the PUF response from the PUF-based SUPI, or a closely related PUF response (allowing e.g. some bit of the PUF response to be flipped) is present in the PUF response list. If the received PUF response is present step S410 is entered. Otherwise step S409 is entered.

[0132] S409A: The DCS inspects if the PUF response from the PUF-based SUPI, or a closely related PUF response (allowing e.g. some bits of the PUF response to be flipped) has not previously been used. If the received PUF response has not been used step S411 is entered. Otherwise step S410 is entered.

[0133] S410A: If the response was not found or was used previously, the validation failed. A “not validated” or “unauthorized user”-message can be sent to the AUSF, and the method is aborted.

[0134] S411A: The validation is successful. The PUF response in the database is by the DCS either marked as used or removed from the list. All PUF responses listed previously in the list, i.e. corresponding to lower counter values, are also marked as invalid or removed.

[0135] S412A: In case that the authentication and the validation of the PUF response are successful, the DCS supplies authentication information and keying material to the AUSF of the onboarding network. Otherwise, the DCS supplies the corresponding error to the UE (e.g. “Authentication failure”, “User not authorized”, or the like).

[0136] FIG. 5B illustrates a method verifying authenticity of UE 200 based on at least some of the above disclosed embodiments. The method of FIG. 5B is preceded by a manufacturing phase. During manufacturing the manufacturer provides the UE with a PEI and realm. The manufacturer extracts one or several PUF responses and supplies the PUF response(s) to the DCS.

[0137] S401B: The UE generates a PUF response.

[0138] S402B: The UE creates a SUPI using an XOR combination of the PEI and the PUF response as input for the username in the SUPI. One example of this would be a 56 bit PEI plus a 4 bit check bit: 352099B017614F1, and a 128 bit PUF response: 73367639792FFE26C028482B4D62516A. Assuming the most significant bits of the PUF response are used to combine the PUF response with the PEI, the NAI (username ©realm) becomes: “4616EF896E4EB136C028482B4D62516A@realm”.

[0139] S403B: UE sends the SUPI in a registration request to the onboarding network. [0140] S404B: The onboarding network decides that primary authentication is to be handled by the

DCS. The AUSF forwards the registration request to the DCS identified by the realm part of the SUPI. The DCS receives the SUPI and extracts the validation token.

[0141] S405B: The validation token database is searched for the validation token. The validation token database might store e.g. pairs of validation tokens and PEIs (such that each validation token is explicitly stored with a PEI), or PUF responses (such that a matching is made based on the part of the SUPI not being combined with the PEI). If a match is found in the validation token database, the validation was successful and step S407B is entered. Else step S406B is entered.

[0142] S406B: The validation failed for example if the response was not found or was used previously. A “not validated” or “unauthorized user”-message can be sent to the AUSF, and the method is aborted.

[0143] S407B: A match is found in the validation token database and the validation is successful.

[0144] S408B: If a match is found in the validation token database, an XOR operation is performed between the PUF response and the validation token to extract the PEI. The extracted PEI is checked. If the PEI has a value in a valid range the UE is assumed authenticated by the DCS. The DCS might then store the PEI for the DCS to keep a list of authenticated UEs. The validation token is by the DCS either marked as used or removed from the validation token database.

[0145] S409B: The DCS supplies authentication information and, optionally, the SUPI with a cleartext PEI (i.e. with the PUF response removed) to the AUSF. This communication is assumed to be confidentiality protected.

[0146] In some embodiments, as illustrated in FIG. 6A, to prove authenticity, the UE might construct a Subscriber Permanent Identity (SUPI) comprising the PUF response in the username field. In addition, the UE may be configured to produce a SUCI using the cryptographic module and the public key of the DCS. When the UE is to perform network registration, the UE identifier and the authenticity counter is used to create a challenge for the PUF entity and the PUF response is provided in the SUPI. The UE might thus provide the PUF response within the username of a SUPI in NAI format (i.e. using a PUF-based SUPI). This PUF-based SUPI is then concealed.

[0147] In the case where the challenge for the PUF response requires more bits than what is outputted by the OWF, the output of the OWF may be looped back as input to the OWF until a challenge of a desired length is produced. Other alternatives, such as dividing the OWF output into several partly overlapping challenges or the OWF providing an initial state of a linear feedback shift register (LFSR), and the LFSR creating the actual challenge, are also possible.

[0148] The PUF-based SUPI might be sent in encrypted form, i.e. as a SUCI, to the network. Once the SUCI has been received by the DCS, the DCS commences an authentication procedure with the UE. In this authentication procedure, the UE might supply its default credentials to the DCS.

[0149] The DCS is further configured to verify the UEs authenticity. The DCS has a PUF response database containing PUF responses for all UEs belonging to a certain manufacturer and/or type. This database is queried using the UE identifier extracted from the default credentials to find the next valid PUF response in the database. Validation is performed by comparing the PUF response in the SUPI with the expected PUF response present in the database. If they are a match, the procedure may continue, authentication information and keying material is sent to the onboarding network.

[0150] In some embodiments, as illustrated in FIG. 6B, the UE is provided with a permanent equipment identifier (PEI). The validation token is constructed using an XOR operation between the PUF response and the PEI. One reason for sending the PEI and the validation token in combined form is that an eavesdropper does not have enough information to extract neither the PEI nor the PUF response. Furthermore, the validation token is never stored on the UE. While the PEI is stored in the NVM, the PUF response is only generated when the UE is activated.

[0151] Since the PEI is only 56 bits long (not including the check-digit) and certain parts of it might be easily extracted, the PEI might be vulnerable to brute force attacks trying every combination. For this reason, the PUF response might be longer than the PEI, for example with a minimum of 128 bits.

[0152] The validation token is provided as the Username in the SUPI. The SUPI is sent in a registration request to the onboarding network which relies on the procedure for primary authentication sending the registration request to the DCS. The AUSF routes the registration request to the correct DCS based on the realm part of the SUPI.

[0153] The DCS is further configured to verify the UEs authenticity. The DCS has a validation token database containing PEI, validation tokens and/or PUF responses, all belonging to a certain UE manufacturer and/or UE type. Validation is performed by searching the database for the validation token in the SUPI. If the validation token is found, the validation is successful and an “authentication succeeded” message, optionally containing the PEI, is supplied by the DCS to the onboarding network. To ensure that the authentication is not replayed, the validation tokens is either marked as used or is removed from the validation token database after successful validation.

[0154] Alternatively, in lieu of explicitly storing the validation token and the PEI, the validation token database might store only PUF responses from the UEs. In this case, the validation is performed by matching the validation token on the part not having been subjected to the XOR operation with the PEI. If the correct PUF response is found, the PEI is extracted from the validation token. In some cases, there may be a need to perform additional network registrations of the UE at a later point in time after the initial network registration. To facilitate this, the UE might be provided with a list of challenges, in a challenge list 246, for the PUF entity. This enables the UE to generate several PUF responses which can be used to create validation tokens.

[0155] In some embodiments, as illustrated in Fig. 7A, the UE uses an anonymous SUPI, i.e. excluding the username part and only containing the realm part of the NAI, i.e. “@realm” or “anonymous@realm”. In this case the PUF response might be part of the EAP authentication as illustrated in step S403c. The PUF response might e.g. be provided in an extension field in the UE certificate. The PUF response might be supplied after the default credentials has been provided to the DCS and a secure communication channel has been established between the UE and the DCS. For example, the DCS might supply the UE with a challenge for the PUF entity within the EAP exchange, thereby removing the need for creating and/or storing pre-defined PUF challenges on the UE.

[0156] In some embodiments, as illustrated in FIG. 7B, it is possible to use a single PUF response which is combined with a nonce in an OWF. Each nonce produces a new output from the OWF which can be used as a validation token.

[0157] In some embodiments, as illustrated in FIG. 8A, the PUF entity used is a weak PUF entity, i.e. a PUF entity with only few CRPs. In lieu of using the UE identifier and the authenticity counter to generate a challenge, the challenges might then be predefined and stored on the UE. The predefined challenges could also be stored as certificate extensions in the UE certificate. A standalone list containing explicit challenges might also utilized. Such a standalone list may be stored in the NVM of the UE. It might also be stored in an external memory, e.g. on a Universal Serial Bus (USB) flash drive or a Secure Digital (SD) card, which is accessed by the UE. The standalone list might be created either during manufacturing of the UE or prior to deployment of the UE. In some embodiments, the PUF responses are not saved in a database on the DCS but rather used to create a mathematical model, stored on the DCS. The challenge might e.g. be generated using a (pseudo)-random number generator ((P)RNG) or the DCS might supply the UE with a challenge for the PUF entity within the EAP exchange. In this case, the username field in the SUPI might comprise both PUF challenge and PUF response.

[0158] In some embodiments, as illustrated in FIG. 8B, instead of using the PEI to create the validation token(s), any validation token might be placed in the NVM on the UE. To prevent that the validation token is exposed if the UE is cloned, the validation token is stored in an encrypted form by using the PUF response, for example in an encrypted validation token module 260. For example, the encrypted token can be determined by performing an XOR operation between the validation token and the PUF response. When the registration procedure is to begin, the encrypted token is decrypted prior to creating the SUPI. For example, the validation token can be determined by performing an XOR operation between the encrypted token and the PUF response.

[0159] In some embodiments, as illustrated in FIG. 9A, the cryptographic module is omitted in both the UE and the DCS. Hence, a “null-scheme” protection scheme might be used for the SUCI. The result of this is that the username part of the SUCI corresponds to the username part of the PUF-based SUPI. Since the PUF responses are used for one-time validation of a given UE, there is no resulting issues with privacy when the concealment of the PUF-based SUPI is not applied.

[0160] In some embodiments, as illustrated in FIG. 9B, the UE provides a SUCI to the DCS instead of the SUPI. Since the UE does not have cryptographic keys to encrypt the SUPI, “null-scheme” protection scheme might be used for the SUCI. Hence, the SUPI will be sent in cleartext. The UE may provide an explicit indication to the onboarding network that the SUPI concealed by the SUCI is a PUF- based SUPI (i.e. does not correspond to any real SUPI of any UE) e.g. by using a new SUPI type within the SUCI structure. With the explicit indication from the UE, the onboarding network understands that there will not be any encryption keys derived during the authentication procedure.

[0161] In some embodiments, as illustrated in FIG. 10, only exact matches of the produced PUF responses are accepted. As some factors, such as environmental conditions and variations in supplied voltage levels, can cause PUF entities to generate slightly different PUF responses for the same challenge, error correction can be used to recreate the original PUF response. To enable error correction for a specific PUF response, so-called helper data can be extracted and stored. The helper data might comprise error correcting codes which are used by an error correction algorithm to restore the original PUF response. The error correction can either be implemented by the UE, prior to putting the PUF response in the SUPI, or by the DCS. In the latter case, the error correction is performed by the DCS after having extracted the PUF response from the SUPI but prior to providing the PUF response to the validation module.

[0162] FIG. 11 schematically illustrates, in terms of functional units, the components of a UE 200 according to an embodiment. Processing circuitry 10 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 1510a (as in FIG. 13), e.g. in the form of a storage medium 230. Processing circuitry 210 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

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

[0164] 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.

[0165] UE 200 may further comprise a communications interface 220 for communications with other entities, functions, nodes, and devices of the communication network 100. As such the communications interface 220 may comprise one or more transmitters and receivers, comprising analogue and digital components.

[0166] Processing circuitry 210 controls the general operation of UE 200 e.g. by sending data and control signals to the communications interface 220 and storage medium 230, by receiving data and reports from the communications interface 220, and by retrieving data and instructions from storage medium 230. Other components, as well as the related functionality, of UE 200 are omitted in order not to obscure the concepts presented herein. [0167] FIG. 12 schematically illustrates, in terms of functional units, the components of a DCS 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 1510b (as in FIG. 13), e.g. in the form of a storage medium 330. Processing circuitry 310 may further be provided as at least one application specific integrated circuit (ASIC), or field programmable gate array (FPGA).

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

[0169] 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.

[0170] DCS 300 may further comprise a communications interface 320 for communications with other entities, functions, nodes, and devices of the communication network 100. As such communications interface 320 may comprise one or more transmitters and receivers, comprising analogue and digital components.

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

[0172] FIG. 13 shows one example of a computer program product 1510a, 1510b comprising computer readable means 1530. On this computer readable means 1530, a computer program 1520a can be stored, which computer program 1520a can cause processing circuitry 210 and thereto operatively coupled entities and devices, such as the communications interface 220 and storage medium 230, to execute methods according to embodiments described herein. The computer program 1520a and/or computer program product 1510a may thus provide means for performing any steps of UE 200 as herein disclosed. On this computer readable means 1530, a computer program 1520b can be stored, which computer program 1520b can cause processing circuitry 310 and thereto operatively coupled entities and devices, such as communications interface 320 and storage medium 330, to execute methods according to embodiments described herein. The computer program 1520b and/or computer program product 1510b may thus provide means for performing any steps of DCS 300 as herein disclosed.

[0173] In the example of FIG. 13, the computer program product 1510a, 1510b 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 1510a, 1510b 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 nonvolatile 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 1520a, 1520b is here schematically shown as a track on the depicted optical disk, the computer program 1520a, 1520b can be stored in any way which is suitable for the computer program product 1510a, 1510b.

[0174] 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 list of enumerated embodiments.

Claims

23 CLAIMS:

1. A method for verifying authenticity of a user equipment to a network, the method being performed by the user equipment, wherein the user equipment comprises a PUF entity and is without default credentials, the method comprising: obtaining (S102B) a validation token, wherein the validation token is a combination of a PUF response and a predefined string, wherein the PUF response is obtained from the PUF entity by providing a challenge as input to the PUF entity; providing (S104B), in a registration request to the network, a SUPI of the user equipment, wherein the SUPI comprises the validation token; and in response thereto: obtaining (S106B) a registration accept message from the network.

2. The method according to claim 1, wherein the predefined string is any of: permanent equipment identifier of the user equipment, media access control address of the user equipment.

3. The method according to claim 1, wherein the validation token is encrypted when stored in the user equipment and decrypted before being comprised in the SUPI.

4. The method according to claim 3, wherein the validation token is encrypted with the PUF response to form an encrypted token, and wherein the encrypted token is decrypted with the PUF response to recreate the validation token.

5. The method according to claim 1, wherein the PUF response and the predefined string are combined by performing an exclusive or, XOR, operation between the PUF response and the predefined string.

6. The method according to claim 1, wherein the PUF response is composed of at least 128 bits.

7. The method according to claim 1, wherein the SUPI has a username field, and wherein the PUF response is provided as a part of the username field in the SUPI, and wherein the SUPI is in NAI format.

8. The method according to claim 1, wherein the SUPI in the registration request is provided as cleartext in a SUCI of the user equipment.

9. The method according to claim 1, wherein the challenge is based on a predefined binary string or a challenge derived either from a permanent equipment identifier of the user equipment, or from a media access control address of the user equipment.

10. The method according to claim 1, wherein the challenge is preconfigured in the user equipment or acquired by the user equipment from an entity external to the user equipment.

11. The method according to claim 1, wherein the challenge further is based on a value of a counter, and wherein the value of the counter is incremented each time a new challenge is created.

12. A method for verifying authenticity of a user equipment to a network, the method being performed by a Default Credential Server (DCS), wherein the DCS comprises validation characteristics of the user equipment, the method comprising:

Obtaining (202B), in a request from the network to authenticate the user equipment to the network as part of the user equipment registering with the network, a validation token of the user equipment, wherein the validation token is a combination of a PUF response and a predefined string; verifying (204B) authenticity of the user equipment by comparing at least the PUF response to the validation characteristics; and providing (206B) authentication information of the user equipment to the network upon having successfully verified the authenticity of the user equipment.

13. The method according to claim 12, wherein verifying authenticity of the user equipment comprises comparing the validation token to the validation characteristics.

14. The method according to claim 12, wherein the validation characteristics are defined by entries in a database, wherein each entry corresponds to a unique validation token, and wherein authenticity of the user equipment is successfully verified only if one of the unique validation tokens fulfils a matching criterion for the validation token of the user equipment

15. The method according to claim 12, wherein the validation characteristics are defined by entries in a database, wherein each entry corresponds to a unique PUF response, and wherein authenticity of the user equipment is successfully verified only if one of the unique PUF responses fulfils a matching criterion for the PUF response of the user equipment.

16. The method according to claim 14 or 15, wherein the entry that fulfils the matching criterion is marked as used or removed from the database.

17. The method according to claim 16, wherein any entry that in the database is listed as generated prior to the entry that fulfils the matching criterion also is marked as used or removed from the database.

18. The method according to claim 12, wherein the predefined string is any of: permanent equipment identifier of the user equipment, media access control address of the user equipment.

19. The method according to claim 12, wherein the PUF response and the predefined string are combined by means of an exclusive or, XOR, operation having been performed between the PUF response and the predefined string.

20. The method according to claim 1 or 12, wherein the network is an SNPN.

21. The method according to claim 1 or 12, wherein the DCS is an AAA server.

22. A user equipment for verifying authenticity of the user equipment, the user equipment comprising a PUF entity and is without default credentials, the user equipment further comprising processing circuitry, the processing circuitry being configured to cause the user equipment to: obtain a validation token, wherein the validation token is a combination of a PUF response and a predefined string, wherein the PUF response is obtained from the PUF entity by providing a challenge as input to the PUF entity; provide, in a registration request to the network, a SUPI of the user equipment, wherein the SUPI comprises the validation token; and to in response thereto: obtain a registration accept message from the network.

23. A Default Credential Server (DCS) for verifying authenticity of a user equipment, the DCS comprising validation characteristics of the user equipment, the DCS further comprising processing circuitry, the processing circuitry being configured to cause the DCS to: obtain, in a request from the network to authenticate the user equipment to the network as part of the user equipment registering with the network, a validation token of the user equipment, wherein the validation token is a combination of a PUF response and a predefined string; verify authenticity of the user equipment by comparing at least the PUF response to the validation characteristics; and provide authentication information of the user equipment to the network upon having successfully verified the authenticity of the user equipment.

24. A method for verifying authenticity of a user equipment to a network, the method being performed by the user equipment, wherein the user equipment comprises a PUF entity, the method comprising: obtaining a PUF response from the PUF entity by providing a challenge as input to the PUF entity; 26 providing, as part of registering with the network, authenticity information of the user equipment, wherein the authenticity information comprises the PUF response; and in response thereto: obtaining a registration accept message from the network.

25. The method according to claim 24, wherein the challenge is preconfigured in the user equipment or acquired by the user equipment from an entity external to the user equipment.

26. The method according to claim 24, wherein the challenge further is based on a value of a counter, wherein the value of the counter is incremented each time a new challenge is created.

27. The method according to claim 24, wherein the challenge further is based on information as received from a Default Credential Server (DCS) as part of performing an EAP authentication procedure with the DCS, wherein the EAP authentication procedure is performed as part of the user equipment registering with the network.

28. The method according to claim 24, wherein the authenticity information is provided in a registration request to the network.

29. The method according to claim 24, wherein the PUF response in the authenticity information is provided in a SUPI of the user equipment.

30. The method according to claim 29, wherein the SUPI has a username field, and wherein the PUF response is provided as a part of the username field in the SUPI.

31. The method according to claim 29 or 30, wherein the SUPI is in NAI format.

32. The method according to claim 29 or 30, wherein the SUPI is encrypted using a public key of a Default Credential Server (DCS) before being provided in the registration request.

33. The method according to claim 27, wherein the authenticity information is provided as part of performing the EAP authentication procedure with the DCS.

34. The method according to claim 24, wherein the method further comprises: providing, as part of performing an EAP authentication procedure with a Default Credential Server (DCS), default credentials of the user equipment to the DCS, wherein the EAP authentication procedure is performed as part of the user equipment registering with the network. 27

35. The method according to claim 24, wherein the challenge is based on a unique identifier for the user equipment.

36. A method for verifying authenticity of a user equipment to a network, the method being performed by a Default Credential Server (DCS), wherein the DCS comprises PUF characteristics of the user equipment, the method comprising: obtaining, from the network, authenticity information as provided by the user equipment as part of the user equipment registering with the network, wherein the authenticity information comprises a PUF response; verifying authenticity of the user equipment by comparing the PUF response to the PUF characteristics; and providing authenticity information and keying material of the user equipment to the network upon having successfully verified the authenticity of the user equipment.

37. The method according to claim 36, wherein the PUF characteristics are defined by entries in a database, wherein each entry corresponds to a unique PUF response, and wherein authenticity of the user equipment is successfully verified only if one of the unique PUF responses fulfils a matching criterion for the PUF response of the user equipment.

38. The method according to claim 37, wherein the unique PUF response that fulfils the matching criterion is marked as used or removed from the database.

39. The method according to claim 37, wherein any unique PUF response that in the database is listed as generated prior to the unique PUF response that fulfils the matching criterion also is marked as used or removed from the database.

40. The method according to claim 36, wherein the authenticity information is obtained in a request from the network to authenticate the user equipment to the network.

41. The method according to claim 36, wherein the method further comprises: obtaining, as part of performing an EAP authentication procedure with the user equipment, default credentials of the user equipment, wherein the EAP authentication procedure is performed as part of the user equipment registering with the network; and authenticating, using the default credentials, the user equipment.

42. The method according to claim 41, wherein the EAP authentication procedure is performed before verifying authenticity of the user equipment. 28

43. The method according to claim 36, wherein the PUF response has been created by providing a challenge as input to a PUF entity in the user equipment, and wherein the challenge is based on at least one of: a unique identifier for the user equipment and information provided by the DCS as part of performing an EAP authentication procedure with the user equipment, and wherein the EAP authentication procedure is performed as part of the user equipment registering with the network.

44. The method according to claim 43, wherein the authenticity information is obtained as part of performing the EAP authentication procedure with the DCS.

45. A user equipment for verifying authenticity of the user equipment, the user equipment comprising a PUF entity, the user equipment further comprising processing circuitry, the processing circuitry being configured to cause the user equipment to: obtain a PUF response from the PUF entity by providing a challenge as input to the PUF entity; provide, as part of registering with the network, authenticity information of the user equipment, wherein the authenticity information comprises the PUF response; and to in response thereto: obtain a registration accept message from the network.

46. A Default Credential Server (DCS) for verifying authenticity of a user equipment, the DCS comprising PUF characteristics of the user equipment, the DCS further comprising processing circuitry, the processing circuitry being configured to cause the DCS to: obtain, from the network, authenticity information as provided by the user equipment as part of the user equipment registering with the network, wherein the authenticity information comprises a PUF response; verify authenticity of the user equipment by comparing the PUF response to the PUF characteristics; and provide authenticity information and keying material of the user equipment to the network upon having successfully verified the authenticity of the user equipment.