WO2024178660A1

WO2024178660A1 - Validation of one-time passwords in two-factor authentication

Info

Publication number: WO2024178660A1
Application number: PCT/CN2023/078939
Authority: WO
Inventors: Lu Zhou; Jian Luo; Huanbiao JIANG
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2023-03-01
Filing date: 2023-03-01
Publication date: 2024-09-06

Abstract

A method for validating a one-time password, OTP, is disclosed: an OTP module receives a request for an OTP to be generated for a target phone number, then provides the OTP towards a user equipment of the target phone number. The OTP module receives from the user equipment, the OTP and a signature. It then confirms that the OTP as received from the user equipment matches the OTP as provided towards the user equipment. The OTP module provides towards a validator module, a request to validate that the signature received with the OTP is associated with the target phone number of the user equipment.

Description

VALIDATION OF ONE-TIME PASSWORDS IN TWO-FACTOR AUTHENTICATION

TECHNICAL FIELD

Embodiments presented herein relate to methods, a one-time password (OTP) module, a user equipment, a validator module, computer programs, and a computer program product for validating an OTP.

BACKGROUND

Some Internet services (such as some websites or web-based applications) use two-factor authentication (2FA) for secure user login and authentication. 2FA is an example of a group of electronic authentication methods referred to as multi-factor authentication (MFA) according to which a user is granted access to a requested Internet service only after successfully presenting two or more pieces of evidence (or factors) to an authentication mechanism: knowledge (something only the user knows) , possession (something only the user has) , and inherence (something only the user is) . In one example of 2FA, the user provides some login credentials (such as a username and a password) and a short messaging service passcode.

In this respect, one-time passwords (OTPs) can be used as passcodes. Once the authenticator has generated the OTP (such as a random 6-8 digit code) , the OTP is provided, via a short messaging service, to the specific phone number of end-user via a Communication Service Provider network. Once the end-user receives the OTP, the end-user manually inputs the received OTP into an application or web browser. In other examples the OTP is automatically entered into the application or web browser. The authenticator can then compare the OTP as provided to the OTP as received.

The basic logic behind the use of OTPs for 2FA is that the Internet service account is bound to a subscription that in turn is bound to a user equipment, physical Subscriber Identity Module (SIM) card, or embedded SIM profile; these examples will hereinafter be represented by the user equipment. Further, it is assumed that the user equipment is owned by the end-user of that Internet service account. Thus, the assumption is that the owner of the internet service account is the only person who can receive the OTP and input it for the 2FA. However, there are sceneries where the OTP can be eavesdropped by an attacker. Hence, these assumptions might no longer always be valid.

According to a first example, traffic in some cellular networks can be intercepted. In this way, the attacker might sniff the OTP over-the-air. According to a second example, security vulnerability at the user equipment might allow for the attacker to eavesdrop the OTP from the user equipment. This could be accomplished through the use of, for example, trojans that can receive the OTP and forward it to the attacker from the user equipment.

In view of the above, when OTPs are used for 2FA, it might not be possible for the authenticator to verify that the OTP actually comes from the user equipment to which the target phone number that activated for 2FA was bound, or from the user equipment of an attacker that intercepted the OTP. This reduces the security of 2FA based on OTPs.

SUMMARY

An objective of embodiments herein is to address the shortcomings of existing technology as disclosed above.

A particular objective is to enable increased security of 2FA based on OTPs.

A yet further objective is to enable verification that a target phone number belongs to a specific user equipment.

These objectives and more are fulfilled by the hereinafter disclosed methods, OTP modules, user equipment, validator modules, computer programs, and computer program products.

According to a first aspect there is presented a method for validating an OTP. The method is performed by an OTP module. The method comprises receiving a request for an OTP to be generated for a target phone number. The method comprises providing, towards a user equipment of the target phone number, the OTP. The method comprises receiving, from the user equipment, the OTP and a signature. The method comprises confirming that the OTP as received from the user equipment matches the OTP as provided towards the user equipment. The method comprises providing, towards a validator module in a CSP network, a request to validate that the signature is associated with the target phone number of the user equipment.

According to a second aspect there is presented an OTP module for validating an OTP. The OTP module comprises processing circuitry. The processing circuitry is configured to cause the OTP module to receive a request for an OTP to be generated for a target phone number. The processing circuitry is configured to cause the OTP module to provide, towards a user equipment of the target phone number, the OTP. The processing circuitry is configured to cause the OTP module to receive, from the user equipment, the OTP and a signature. The processing circuitry is configured to cause the OTP module to confirm that the OTP as received from the user equipment matches the OTP as provided towards the user equipment. The processing circuitry is configured to cause the OTP module to provide, towards a validator module in a CSP network, a request to validate that the signature is associated with the target phone number of the user equipment.

According to a third aspect there is presented a computer program for validating an OTP, the computer program comprising computer program code which, when run on processing circuitry of an OTP module, causes the OTP module to perform actions. One action comprises the OTP module to receive a request for an OTP to be generated for a target phone number. One action comprises the OTP module to provide, towards a user equipment of the target phone number, the OTP. One action comprises the OTP module to receive, from the user equipment, the OTP and a signature. One action comprises the OTP module to confirm that the OTP as received from the user equipment matches the OTP as provided towards the user equipment. One action comprises the OTP module to provide, towards a validator module in a CSP network, a request to validate that the signature is associated with the target phone number of the user equipment.

According to a fourth aspect there is presented a method for validating an OTP. The method is performed by a user equipment. The user equipment comprises an eUICC. The method comprises receiving the OTP. The OTP originates from an OTP module. The method comprises generating, by the eUICC, a signature for the OTP based on credentials of the eUICC. The method comprises providing, towards the OTP module, the OTP and the signature.

According to a fifth aspect there is presented a user equipment for validating an OTP. The user equipment comprises an eUICC. The user equipment further comprises processing circuitry. The processing circuitry is configured to cause the user equipment to receive the OTP. The OTP originates from an OTP module. The processing circuitry is configured to cause the user equipment to generate, by the eUICC, a signature for the OTP based on credentials of the eUICC. The processing circuitry is configured to cause the user equipment to provide, towards the OTP module, the OTP and the signature.

According to a sixth aspect there is presented a computer program for validating an OTP, the computer program comprising computer program code which, when run on processing circuitry of a user equipment, causes the user equipment to perform actions. One action comprises the user equipment to receive the OTP. The OTP originates from an OTP module. One action comprises the user equipment to generate, by the eUICC, a signature for the OTP based on credentials of the eUICC. One action comprises the user equipment to provide, towards the OTP module, the OTP and the signature.

According to a seventh aspect there is presented a method for validating an OTP. The method is performed by a validator module. The method comprises receiving, from an OTP module, a request to validate that a signature is associated with a target phone number of a user equipment. The method comprises validating the signature and the target phone number in accordance with a mapping between listed phone numbers and eUICC credentials. The target phone number is validated by confirming that the target phone number matches the listed phone number associated with the eUICC credentials of the user equipment. The signature is validated by confirming that the signature is obtainable from the eUICC credentials associated with the target phone number.

According to an eighth aspect there is presented a validator module for validating an OTP. The validator module comprises processing circuitry. The processing circuitry is configured to cause the validator module to receive, from an OTP module, a request to validate that a signature is associated with a target phone number of a user equipment. The processing circuitry is configured to cause the validator module to validate the signature and the target phone number in accordance with a mapping between listed phone numbers and eUICC credentials. The target phone number is validated by confirming that the target phone number matches the listed phone number associated with the eUICC credentials of the user equipment. The signature is validated by confirming that the signature is obtainable from the eUICC credentials associated with the target phone number.

According to a ninth aspect there is presented a computer program for validating an OTP, the computer program comprising computer program code which, when run on processing circuitry of a validator module, causes the validator module to perform actions. One action comprises the validator module to receive, from an OTP module, a request to validate that a signature is associated with a target phone number of a user equipment. One action comprises the validator module to validate the signature and the target phone number in accordance with a mapping between listed phone numbers and eUICC credentials. The target phone number is validated by confirming that the target phone number matches the listed phone number associated with the eUICC credentials of the user equipment. The signature is validated by confirming that the signature is obtainable from the eUICC credentials associated with the target phone number.

According to a tenth aspect there is presented a computer program product comprising a computer program according to at least one of the third aspect, the sixth aspect, and the ninth aspect and a computer readable storage medium on which the computer program is stored. The computer readable storage medium can be a non-transitory computer readable storage medium.

According to an eleventh aspect there is presented a system comprising an OTP module according to the second aspect, a user equipment according to the fifth aspect, and the validator module according to the eight aspect.

Advantageously, these aspects may overcome or mitigate the shortcomings of existing technology as disclosed above.

Advantageously, these aspects may enable increased security of 2FA based on OTPs. This is since these aspects enable the authenticator to ensure that the OTP is indeed sent from the user equipment to which the target phone number is bound.

Advantageously, these aspects enable verification that a target phone number belongs to a specific user equipment.

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.

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

The inventive concept is now described, by way of example, with reference to the accompanying drawings, in which:

Figs. 1, 5, and 6 are block diagrams according to embodiments;

Figs. 2, 3, and 4 are flowcharts of methods according to embodiments;

Figs. 7 and 8 are signaling diagrams according to embodiments;

Fig. 9 is a schematic diagram showing functional units of an OTP module according to an embodiment;

Fig. 10 is a schematic diagram showing functional modules of an OTP module according to an embodiment;

Fig. 11 is a schematic diagram showing functional units of a user equipment according to an embodiment;

Fig. 12 is a schematic diagram showing functional modules of a user equipment according to an embodiment;

Fig. 13 is a schematic diagram showing functional units of a validator module according to an embodiment;

Fig. 14 is a schematic diagram showing functional modules of a validator module according to an embodiment; and

Fig. 15 shows one example of a computer program product comprising computer readable means according to an embodiment.

DETAILED DESCRIPTION

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.

Fig. 1 is a block diagram illustrating a system 10 where embodiments presented herein can be applied. The system 10 comprises a first user equipment 200, a (optional) second user equipment 200, an application server (ASP) 14, a communications service providers (CSP) network 20, an enhanced Subscription Management Data Preparation (SM-DP+) server 18, and an OTP module 100.

Aspects of the first user equipment 200 will be disclosed next. The first user equipment runs a native application (in a Local Profile Assistant; LPA 248) that communicates with the eUICC 240 of the first user equipment to generate signatures for an OTP received by the first user equipment to prove that the OTP actually originated from the device with a certain target phone number, such as a Mobile Station International Subscriber Directory Number (MSISDN) , activated. The operating system (OS) of the first user equipment encapsulates and exposes the API to a third-party application 246 or a dedicated authentication application 242, which allows the invoker to submit an OTP for which a signature is to be generated, see below. In this respect, the authentication application is a dedicated APP provided by the OTP module for the end-user to enter an OTP, as received from the OTP module, in the user equipment with a target phone number activated. The authentication application is used if the 2FA is initiated at the second user equipment. Likewise, the third-party application is an APP for the end-user to enter an OTP, as received from the OTP module, in the user equipment with a target phone number activated. The third-party application is used if the 2FA is initiated at the first user equipment. Further, for the case 2FA authentication only is allowed to be performed on the user equipment with the target phone number activated, the authentication application is not needed.

The first user equipment comprises an embedded universal integrated circuit card (eUICC) 240 which enables remote and/or local management of subscription profiles in a secure way. The eUICC contains the unique eUICC Controlling Authority Security Domain (ECASD) , and is provided with a subscription profile associated with the phone number of the first user equipment. Personalized data of the ECASD might comprise the unique identify of the eUICC (EID) , the eUICC’s Private Key (s) (SK. EUICC. ECDSA) for creating ECDSA signatures, the eUICC’s Certificate (s) for eUICC authentication (CERT. EUICC. ECDSA) containing the eUICC’s public key (PK. EUICC. ECDSA) , the Certificate (s) of the eUICC manufacture (CERT. EUM. ECDSA) , the GSMA Certificate Issuer’s (CI) Public Key (s) , . The ECASD is configured for eUICC signature creation on material provided by an Issuer Security Domain Root (ISD-R) , and verification of the off-card entities Certificates (for example: SM-DP+server, see below) , provided by the ISD-R, with the CI public key (PK. CI. ECDSA) .

Aspects of the second user equipment 12 will be disclosed next. The second user equipment runs a web application for which authentication of the end-user 16 is performed via the first user equipment.

Aspects of the ASP 14 will be disclosed next. The ASP might provide the third-party application that is run in the first user equipment. Alternatively, the ASP runs a backend for the third-party application as provided by another entity. The ASP is configured to contact the OTP module to trigger an OTP to be sent towards the first user equipment and to validate the OTP as received from the first user equipment.

Aspects of the OTP module 100 will be disclosed next. The OTP module provides the authentication application that is run in the first user equipment. The OTP module is configured to send an OTP towards the first user equipment and to validate the OTP as received from the first user equipment. In further detail, the OTP module is configured to communicate with the exposure function for OTPs to be sent to target phone numbers and validate if received OTPs match the target phone number activated.

In some examples, the functionality of the OTP module is integrated with the functionality of the ASP. Hence, in some examples, the functionality of the OTP module resides within the ASP.

Aspects of the CSP network 20 will be disclosed next. The CSP network comprises an exposure function 24 configured to expose the API for OTP sending and signature validation to the OTP module. The CSP network further comprises a validator module 300 configured to validate signatures, and thus that the signature is actually generated by a user equipment with a specific EID associated to a specific phone number. Further, the validator module is configured to maintain an association between EID and phone numbers. In some examples the validator module is provided in an Entitlement Configuration Server (ECS) Business Support System (BSS) . The CSP network further comprises a short message service center (SMSC) 22. The SMSC is configured to send OTPs via short text messages to target phone numbers.

Aspects of the SM-DP+server 18 will be disclosed next. The SM-DP+server is configured to prepares subscription profile packages, to secure the subscription profile packages with a subscription profile protection key, to store the subscription profile protection keys in a secure manner, to store the protected subscription profile packages in a subscription profile package repository, and to allocate the protected subscription profile packages to specified EIDs. The SM-DP+server is further configured to bind protected subscription profile packages to the respective EID and securely download bound subscription profile packages to the LPA of the respective eUICC.

Methods for validating an OTP as performed by the OTP module 100, the user equipment 200, and the validator module 300, will be disclosed next.

In general terms, whenever the third-party application or the web application needs to run a validation procedure for some service, the third-party application or the dedicated authentication application requests the native application for the eUICC to sign an OTP received from the OTP module. Details of the signature as well as how it can be generated will be disclosed below.

Once the third-party application or the dedicated authentication application obtains the signature, the third-party application or the dedicated authentication application triggers a request to the OTP module, either directly or via the application server, for validation.

The OTP module provides OTPs to user equipment associated with a target phone number and validates the OTP received by the OTP module together with signature. The validator module then validates if the signature is actually originating from the user equipment with the target phone number activated.

Reference is now made to Fig. 2 illustrating a method for validating an OTP as performed by the OTP module 100 according to an embodiment.

S102: The OTP module 100 receives a request for an OTP to be generated for a target phone number.

S104: The OTP module 100 provides, towards a user equipment 200 of the target phone number, the OTP.

S106: The OTP module 100 receives, from the user equipment 200, the OTP and a signature.

S108: The OTP module 100 confirms that the OTP as received from the user equipment 200 matches the OTP as provided towards the user equipment 200.

S110: The OTP module 100 provides, towards a validator module 300 in a CSP network, a request to validate that the signature is associated with the target phone number of the user equipment 200.

Embodiments relating to further details of validating an OTP as performed by the OTP module 100 will now be disclosed with continued reference to Fig. 2.

Depending on the scenario at hand, the request as received in S102 is received either from the user equipment 200 towards which the OTP is provided in S104, or from another user equipment (above referred to as second user equipment) . That is, in the latter case, the user equipment 200 is a first user equipment 200, and the request is received from a second user equipment 200, different from the first user equipment 200. Examples of the former will be disclosed with reference to Figs. 5 and 7whereas examples of the latter will be disclosed with reference to Figs. 6 and 8. Further, the second user equipment might not be provided with a subscription to a cellular network service. The second user equipment might not even be capable of communicating with a cellular network.

There could be different purposes as to why the request is provided and hence received by the OTP module in S102.

One purpose is for an end-user to perform F2A. That is, in some embodiments, the request pertains to a request for 2FA to be performed for the user equipment 200. Another purpose is for an end-user to validate a phone number (of the user equipment 200) . That is, in some embodiments, the request pertains to a request for the target phone number to be verified. That the target phone number is verified means that it is verified that the target phone number is of subscription profile that belongs to the user equipment 200.

In some examples, the OTP is provided towards the user equipment 200 via the CSP network.

In some examples, the OTP module receives result of the validation from the validator module. That is, in some embodiments, the OTP module is configured to perform (optional) step S112:

S112: The OTP module 100 receives, from the validator module 300, a result of validation that the signature is associated with the target phone number.

Reference is now made to Fig. 3 illustrating a method for validating an OTP as performed by the user equipment 200 according to an embodiment. The user equipment 200 comprises an eUICC.

S204: The user equipment 200 receives the OTP. The OTP originates from an OTP module 100.

S208: The eUICC generates a signature for the OTP based on credentials of the eUICC.

S210: The user equipment 200 provides, towards the OTP module 100, the OTP and the signature.

Embodiments relating to further details of validating an OTP as performed by the user equipment 200 will now be disclosed with continued reference to Fig. 3.

As disclosed above, in some examples, the request as received in S102 is received from the user equipment 200 towards which the OTP is provided in S104. Therefore, in some embodiments, the user equipment 200 is configured to perform (optional) step S202:

S202: The user equipment 200 provides a request towards the OTP module for the OTP to be generated for a target phone number for a subscription associated with the eUICC.

As disclosed above, one purpose is for an end-user to perform F2A. Therefore, in some embodiments, the signature is generated as part of performing two-factor authentication for the user equipment 200. As further disclosed above, another purpose is for an end-user to validate a phone number (of the user equipment 200) . Therefore, in some embodiments, the signature is generated as part of verifying the target phone number for the user equipment 200.

In some examples the OTP as received is automatically entered into the user equipment 200 before it is provided towards the OTP module 100 in S210. In Other examples, the OTP is entered into the user equipment 200 via user input. Therefore, in some embodiments, the user equipment 200 is configured to perform (optional) step S206:

S206: The user equipment 200 receives user input for entering the OTP into the user equipment 200. The OTP as provided towards the OTP module is then the OTP as entered into the user equipment 200.

Further, in some examples, the OTP as originating from the OTP module is received in a first application module inside the user equipment 200. The OTP as received by the user input being entered is received in a second application module, different from the first application module, inside the user equipment 200. In some examples, the first application module implements a Short Messaging Service in the user equipment 200. In some examples, the second application is the third-party application or the authentication application, depending on the scenario.

Further aspects of how the signature can be generated will be provided next.

In some examples, the credentials of the eUICC comprises a private key and a eUICC certificate. The signature can then be generated using the private key and the eUICC certificate. In some examples, the signature further comprises signed data in terms of the OTP, and a signing certificate chain. In some examples, the signing certificate chain comprises the eUICC certificate (CERT. EUICC. ECDSA) , a certificate (CERT. EUM. ECDSA) of a manufacturer of the eUICC, and a public key of a certificate issuer. In some examples, the eUICC certificate comprises a public key (PK. EUICC. ECDSA) of the eUICC and the EID.

An example of a procedure for generating the signature is provided in Table 1. This procedure, with command name “GenerateSignature” , can be introduced to the ES10x interface (i.e., the interface between the LPA and the eUICC) according to the specification SGP. 22 v3.0 (Remote SIM Provisioning (RSP) Architecture for consumer Devices) for the interaction between the LPA and the eUICC.

Table 1: Example procedure for generating signature

Reference is now made to Fig. 4 illustrating a method for validating an OTP as performed by the validator module 300 according to an embodiment.

S302: The validator module 300 receives, from an OTP module, a request to validate that a signature is associated with a target phone number of a user equipment 200.

S304: The validator module 300 validates the signature and the target phone number in accordance with a mapping between listed phone numbers and eUICC credentials. The target phone number is validated by confirming that the target phone number matches the listed phone number associated with the eUICC credentials of the user equipment 200. The signature is validated by confirming that the signature is obtainable from the eUICC credentials associated with the target phone number.

Embodiments relating to further details of validating an OTP as performed by the validator module 300 will now be disclosed with continued reference to Fig. 4.

In some embodiments, the request comprises an OTP as generated by the OTP module. The signature further is validated by the validator module 300 confirming that the signature is obtainable from the eUICC credentials in combination with the OTP.

In some examples, when the subscription profile is installed in the user equipment and the phone number of the user equipment is activated, the CSP network, and hence the validator module, can obtain the EID of the user equipment and maintain a one-to-one mapping between EIDs and phone numbers (i.e., a mapping with one unique phone number per each unique EID) . Each EID has a PKI (key pairs, private/public) inside the ECDSA, and the ECDSA can generate the signature using the private key for the OTP. The public key is embedded in the certificate of the eUICC. The validator module can validate the signature using the public key and the original OTP, to prove that the signature was actually generated by the specific EID.

The validator module can also check the maintained EID and phone number mapping to verify that the EID is actually linked to the target phone number.

As disclosed above, in some examples, the validator module 300 is provided in a CSP network.

As disclosed above, in some examples, the validator module 300 provides a result of the validation towards the OTP module. Hence, in some embodiments, the validator module 300 is configured to perform (optional) step S306:

S306: The validator module 300 provides, towards the OTP module, a result of the signature and the target phone number having been validated.

A first particular embodiment for validating an OTP based on at least some of the above disclosed embodiments will now be disclosed in detail with reference to the block diagram of Fig. 5.

The block diagram of Fig. 5 represents a scenario where the third-party application is designed to only allow the end-user to perform the 2FA on the user equipment (above referred to as first user equipment) associated with the phone number for 2FA. Therefore, the user equipment receiving the OTP should be the same as the user equipment on which the third-party application is running. It is assumed that when the subscription profile is installed via the SM-DP+server, the association between EID and CSP subscription (integrated circuit card identifier (ICCID) , international mobile subscriber identity (IMSI) , MSISDN) has been provided to the validator module.

S401: An end-user starts to perform a 2FA using a third-party application (APP) hosted by a user equipment. As a result, the third-party APP triggers an ASP to validate the phone number registered to the end-user’s service account.

S402: The ASP request the OTP module to validate that the phone number really belongs to the end-user that triggered the 2FA.

S403: The OTP module generates an OTP and requests the CSP network to send the OTP to the user equipment of the target phone number.

S404: The CSP network delivers the OTP to the user equipment of the target phone number.

S405: The end-user reads the received OTP and enters the received OTP into the third-party APP.

S406: The third-party APP requests the eUICC to generate a signature for the OTP using the private key and certificate associated to the EID.

S407: The OTP, phone number, and signature is by the user equipment sent back to the OTP module for validation.

S408: The OTP module checks if the OTP as received from the user equipment is valid. If the received OTP is valid, the OTP module, by providing the signature and the phone number to the validator module, requests the validator module to validate that the OTP actually originated from the target phone number.

A second particular embodiment for validating an OTP based on at least some of the above disclosed embodiments will now be disclosed in detail with reference to the block diagram of Fig. 6.

The block diagram of Fig. 6 represents a scenario where the end-user is using a service via a web browser run at a user equipment (above referred to as second user equipment) different from the user equipment (above referred to as first user equipment) having the target phone number for 2FA. The OTP is therefore sent to a device (i.e., the first user equipment) different from the device (i.e., the second user equipment) the end-user used that triggered the 2FA. In this scenario a dedicated authentication application (provided by the OTP module) as run in the first user equipment is used for the end-user to enter the OTP. It is assumed that when the subscription profile is installed via the SM-DP+server, the association between EID and CSP subscription (ICCID, IMSI, MSISDN) has been provided to the validator module.

S501: An end-user starts to perform a 2FA using a web-based application (APP) , for example by using a web browser, run on a second user equipment.

S502: The web-based APP triggers the ASP to validate the phone number registered to the end-user’s service account for 2FA.

S503: The ASP request the OTP module to validate that the phone number really belongs to the end-user that triggered the 2FA.

S504: The OTP module generates an OTP and requests the CSP network to send the OTP to the user equipment of the target phone number. In this case, this is the first user equipment that is not the same as the second user equipment in S501 at which the 2FA was activated.

S505: The CSP network delivers the OTP to the user equipment of the target phone number.

S506: The OTP module sends a notification to wake up a dedicated authentication APP on the user equipment of the target phone number (i.e., the user equipment receiving the OTP) . The notification indicates that the 2FA is ongoing and that the user equipment should wait for the end-user to enter the OTP.

S507: The end-user reads the OTP as received by the first user equipment and enters the received OTP into the authentication APP in the first user equipment.

S508: The authentication APP requests the eUICC to generate a signature for the OTP using the private key and certificate associated to the EID

S509: The OTP, phone number, and signature is by the first user equipment sent back to the OTP module for validation.

S510: The OTP module checks if the OTP as received from the first user equipment is valid. If the received OTP is valid, the OTP module, by providing the signature and the phone number to the validator module, requests the validator module to validate that the OTP actually originated from the target phone number.

A third particular embodiment for validating an OTP based on at least some of the above disclosed embodiments will now be disclosed in detail with reference to the signalling diagram of Fig. 7. This embodiment can be regarded as an extended version of the embodiment disclosed above with reference to the block diagram of Fig. 5.

1: The LPA installs a subscription profile in the user equipment as provided from the CSP network. This subscription profile is associated with the phone number registered for 2FA for a service provided by a third-party APP.

2: The LPA sends a “HandleNotification” message with the “ProfileInstallationResult” to the SM-DP+once the subscription profile is successfully installed.

3: The SM-DP+server send a “handleDownloadProgressInfo” message with the EID and ICCID association to the ECS/BSS in the CSP network.

4: The BSS/ECS is made aware of, and maintains, the association between EID and phone number according to the<EID, ICCID, IMSI, MSISDN>mapping received from the SM-DP+.

5: The end-user logs into the third-party APP. The APP queries the end-user for 2FA for the user to gain access to the service provided by the third-party APP.

6: The third-party APP obtains the phone number registered for the 2FA and sends a request to the application server to start OTP based authentication.

7: The application server sends a request to the OTP module to start the OTP based authentication for the target phone number and the third-party APP’s specific application name.

8: The OTP module generates the OTP for the target phone number and application name.

9: The OTP module sends the OTP, the target phone number and the application name to an exposure function in the CSP network for the OTP to be delivered to the target phone number.

10: The exposure function sends a short text message addressed to the target phone number and comprising the OTP to an SMSC.

11: The short text message is delivered to the native short text message application at the user equipment with the target phone number activated. This is the same device where the third-party APP is running.

12: The end-user reads the OTP from the native short text message application.

13: The end-user enters the OTP to the third-party APP for 2FA.

14: The third-party APP calls an API exposed by the OS (native App/LPA) to generate a signature for the OTP entered by the end-user.

15: The native App/LPA invokes the API exposed by the eUICC to generate the signature for the OTP.

16: Once having obtained the signature, the third-party APP sends the phone number for 2FA, the OTP, and the signature to the application server for validation.

17: The application server forwards the validation request to the OTP module for validation.

18: The OTP module validates if the OTP as sent in 9 matches the OTP as received in 17. If there is no match, the 2FA is aborted. Otherwise, step 19 is entered.

19: The OTP module sends a request to the exposure function to validate if the signature was really generated by the user equipment with the target phone number.

20: The exposure function performs the validation and sends the validation result to the application server.

21: The application server sends the validation result to the third-party APP. If the validation is successful, the end-user gains access to the service of the third-party application

A fourth particular embodiment for validating an OTP based on at least some of the above disclosed embodiments will now be disclosed in detail with reference to the signalling diagram of Fig. 8. This embodiment can be regarded as an extended version of the embodiment disclosed above with reference to the block diagram of Fig. 6.

1: The LPA installs a subscription profile in the user equipment as provided from the CSP network. This subscription profile is associated with the phone number registered for 2FA for a service provided by a web application.

5: The end-user logs into a web application and the web application queries the end-user for 2FA to the service.

6: The web application obtains the phone number registered for the 2FA and sends a request to the application server to start OTP based authentication.

7: The application server sends a request to the OTP module to start the OTP based authentication for the target phone number and the service’s specific application name.

9: The OTP module sends the OTP, the target phone number and the application name to an exposure function in the CSP network for the OTP to be delivered to the target phone number

10: The OTP module sends a notification to an authentication application installed on the user equipment with the target phone number for 2FA to wake up the authentication application.

11: The authentication application displays a message to the end-user that indicates that the authentication application is required for 2FA.

12: The exposure function sends a short text message addressed to the target phone number and comprising the OTP to an SMSC.

13: The short text message is delivered to the native short text message application at the user equipment with the target phone number activated. This is not the same device where the web application is running.

14: The end-user reads the OTP from the native short text message application.

15: The end-user enters the OTP to the authentication application for 2FA.

16: The authentication application calls an API exposed by the OS (native App/LPA) to generate a signature for the OTP entered by the end-user.

17: The native App/LPA invokes the API exposed by the eUICC to generate the signature for the OTP.

18: Once having obtained the signature, the authentication application sends the phone number for 2FA, the OTP, and the signature to the application server for validation.

19: The OTP module validates if the OTP as sent in 9 matches the OTP as received in 18. If there is no match, the 2FA is aborted. Otherwise, step 20 is entered.

20: The OTP module sends a request to the exposure function to validate if the signature was really generated by the user equipment with the target phone number.

21: The exposure function performs the validation and sends the validation result to the application server.

22: The application server sends the validation result to the web application. If the validation is successful, the end-user gains access to the service of the web application.

Fig. 9 schematically illustrates, in terms of a number of functional units, the components of an OTP module 100 according to an embodiment. Processing circuitry 110 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. 15) , e.g. in the form of a storage medium 130. The processing circuitry 110 may further be provided as at least one application specific integrated circuit (ASIC) , or field programmable gate array (FPGA) .

Particularly, the processing circuitry 110 is configured to cause the OTP module 100 to perform a set of operations, or steps, as disclosed above. For example, the storage medium 130 may store the set of operations, and the processing circuitry 110 may be configured to retrieve the set of operations from the storage medium 130 to cause the OTP module 100 to perform the set of operations. The set of operations may be provided as a set of executable instructions. Thus, the processing circuitry 110 is thereby arranged to execute methods as herein disclosed.

The storage medium 130 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.

The OTP module 100 may further comprise a communications (comm. ) interface 120 for communications with other entities, functions, nodes, and devices, as in Fig. 1. As such the communications interface 120 may comprise one or more transmitters and receivers, comprising analogue and digital components.

The processing circuitry 110 controls the general operation of the OTP module 100 e.g. by sending data and control signals to the communications interface 120 and the storage medium 130, by receiving data and reports from the communications interface 120, and by retrieving data and instructions from the storage medium 130. Other components, as well as the related functionality, of the OTP module 100 are omitted in order not to obscure the concepts presented herein.

Fig. 10 schematically illustrates, in terms of a number of functional modules, the components of an OTP module 100 according to an embodiment. The OTP module 100 of Fig. 10 comprises a number of functional modules; a receive module 110a configured to perform step S102, a provide module 110b configured to perform step S104, a receive module 110c configured to perform step S106, a confirm module 110d configured to perform step S108, and a provide module 110e configured to perform step S110. The OTP module 100 of Fig. 10 may further comprise a number of optional functional modules, such as a receive module 110f configured to perform step S112. In general terms, each functional module 110a: 110f may be implemented in hardware or in software. Preferably, one or more or all functional modules 110a: 110f may be implemented by the processing circuitry 110, possibly in cooperation with the communications interface 120 and the storage medium 130. The processing circuitry 110 may Thus, be arranged to from the storage medium 130 fetch instructions as provided by a functional module 110a: 110f and to execute these instructions, thereby performing any steps of the OTP module 100 as disclosed herein.

Fig. 11 schematically illustrates, in terms of a number of functional units, the components of a user equipment 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 1510b (as in Fig. 15) , 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) .

Particularly, the processing circuitry 210 is configured to cause the user equipment 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 may be configured to retrieve the set of operations from the storage medium 230 to cause the user equipment 200 to perform the set of operations. The set of operations may be provided as a set of executable instructions. Thus, the processing circuitry 210 is thereby arranged to execute methods as herein disclosed.

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.

The user equipment 200 may further comprise a communications interface 220 for communications with other entities, functions, nodes, and devices, as in Fig. 1. As such the communications interface 220 may comprise one or more transmitters and receivers, comprising analogue and digital components.

The processing circuitry 210 controls the general operation of the user equipment 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 user equipment 200 are omitted in order not to obscure the concepts presented herein.

Fig. 12 schematically illustrates, in terms of a number of functional modules, the components of a user equipment 200 according to an embodiment. The user equipment 200 of Fig. 12 comprises a number of functional modules; a receive module 210b configured to perform step S204, a generate module 210d configured to perform step S208, and a provide module 210e configured to perform step S210. The user equipment 200 of Fig. 12 may further comprise a number of optional functional modules, such as any of a provide module 210a configured to perform step S202 and a receive module 210c configured to perform step S206. In general terms, each functional module 210a: 210e may be implemented in hardware or in software. Preferably, one or more or all functional modules 210a: 210e may be implemented by the processing circuitry 210, possibly in cooperation with the communications interface 220 and 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: 210e and to execute these instructions, thereby performing any steps of the user equipment 200 as disclosed herein.

Fig. 13 schematically illustrates, in terms of a number of functional units, the components of a validator module 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 1510c (as in Fig. 15) , 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) .

Particularly, the processing circuitry 310 is configured to cause the validator module 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 may be configured to retrieve the set of operations from the storage medium 330 to cause the validator module 300 to perform the set of operations. The set of operations may be provided as a set of executable instructions. Thus, the processing circuitry 310 is thereby arranged to execute methods as herein disclosed.

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.

The validator module 300 may further comprise a communications interface 320 for communications with other entities, functions, nodes, and devices, as in Fig. 1. As such the communications interface 320 may comprise one or more transmitters and receivers, comprising analogue and digital components.

The processing circuitry 310 controls the general operation of the validator module 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 validator module 300 are omitted in order not to obscure the concepts presented herein.

Fig. 14 schematically illustrates, in terms of a number of functional modules, the components of a validator module 300 according to an embodiment. The validator module 300 of Fig. 14 comprises a number of functional modules; a receive module 310a configured to perform step S302, and a validate module 310b configured to perform step S304. The validator module 300 of Fig. 14 may further comprise a number of optional functional modules, such as a provide module 310c configured to perform step S306. In general terms, each functional module 310a: 310c may be implemented in hardware or in software. Preferably, one or more or all functional modules 310a: 310c may be implemented by the processing circuitry 310, possibly in cooperation with the communications interface 320 and 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 310a: 310c and to execute these instructions, thereby performing any steps of the validator module 300 as disclosed herein.

The OTP module 100 and/or validator module 300 may be provided as a standalone device or as a part of at least one further device. For example, the OTP module 100 and/or validator module 300 may be provided in a node of the radio access network or in a node of the core network. Alternatively, functionality of the OTP module 100 may be distributed between at least two devices, or nodes. These at least two nodes, or devices, may either be part of the same network part or may be spread between at least two such network parts. Thus, a first portion of the instructions performed by the OTP module 100 and/or validator module 300 may be executed in a first device, and a second portion of the of the instructions performed by the OTP module 100 and/or validator module 300 may be 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 OTP module 100 and/or validator module 300 may be executed. Hence, the methods according to the herein disclosed embodiments are suitable to be performed by an OTP module 100 and/or validator module 300 residing in a cloud computational environment. Therefore, although a single processing circuitry 110, 310 is illustrated in Figs. 9 and 13 the processing circuitry 110, 310 may be distributed among a plurality of devices, or nodes. The same applies to the functional modules 110a: 110f, 310a: 310c of Figs. 10 and 14 and the computer programs 1520a, 1520c of Fig. 15.

Fig. 15 shows one example of a computer program product 1510a, 1510b, 1510c comprising computer readable means 1530. On this computer readable means 1530, a computer program 1520a can be stored, which computer program 1520a can cause the processing circuitry 110 and thereto operatively coupled entities and devices, such as the communications interface 120 and the storage medium 130, 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 the OTP module 100 as herein disclosed. On this computer readable means 1530, a computer program 1520b can be stored, which computer program 1520b 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 1520b and/or computer program product 1510b may Thus, provide means for performing any steps of the user equipment 200 as herein disclosed. On this computer readable means 1530, a computer program 1520c can be stored, which computer program 1520c 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 1520c and/or computer program product 1510c may Thus, provide means for performing any steps of the validator module 300 as herein disclosed.

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

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

A method for validating a one-time password, OTP, the method being performed by an OTP module (100) , the method comprising:

receiving (S102) a request for an OTP to be generated for a target phone number;

providing (S104) , towards a user equipment (200) of the target phone number, the OTP;

receiving (S106) , from the user equipment (200) , the OTP and a signature;

confirming (S108) that the OTP as received from the user equipment (200) matches the OTP as provided towards the user equipment (200) ; and

providing (S110) , towards a validator module (300) in a CSP network, a request to validate that the signature is associated with the target phone number of the user equipment (200) .
The method according to claim 1, wherein the request is received from the user equipment (200) .
The method according to claim 1, wherein the user equipment (200) is a first user equipment (200) , and wherein the request is received from a second user equipment (200) , different from the first user equipment (200) .
The method according to any of claims 1 to 3, wherein the request pertains to a request for a two-factor authentication to be performed for the user equipment (200) .
The method according to any of claims 1 to 3, wherein the request pertains to a request for the target phone number to be verified.
The method according to any of claims 1 to 5, wherein the OTP is provided towards the user equipment (200) via the CSP network.
The method according to any of claims 1 to 6, wherein the method further comprises:

receiving (S112) , from the validator module (300) , a result of validation that the signature is associated with the target phone number.
A method for validating a one-time password, OTP, the method being performed by a user equipment (200) , the user equipment (200) comprising an eUICC, the method comprising:

receiving (S204) the OTP, wherein the OTP originates from an OTP module (100) ;

generating (S208) , by the eUICC, a signature for the OTP based on credentials of the eUICC; and

providing (S210) , towards the OTP module (100) , the OTP and the signature.
The method according to claim 8, wherein the method further comprises: receiving (S206) user input for entering the OTP into the user equipment (200) , and wherein the OTP as provided towards the OTP module (100) is the OTP as entered into the user equipment (200) .
The method according to claim 8 or 9, wherein the method further comprises:

providing (S202) a request towards the OTP module (100) for the OTP to be generated for a target phone number for a subscription associated with the eUICC.
The method according to claim 8, 9, or 10, wherein the signature is generated as part of performing two-factor authentication for the user equipment (200) .
The method according to claim 8, 9 or 10, wherein the signature is generated as part of verifying the target phone number for the user equipment (200) .
The method according to claim 9, wherein the OTP as originating from the OTP module (100) is received in a first application module inside the user equipment (200) , and wherein the OTP as received by the user input being entered is received in a second application module, different from the first application module, inside the user equipment (200) .
The method according to claim 13, wherein the first application module implements a Short Messaging Service in the user equipment (200) .
The method according to any of claims 8 to 14, wherein the credentials of the eUICC comprises a private key and a eUICC certificate, and wherein the signature is generated using the private key and the eUICC certificate.
The method according to any of claims 8 to 15, wherein the signature further comprises signed data in terms of the OTP, and a signing certificate chain.
The method according to claim 16, wherein the signing certificate chain comprises the eUICC certificate, a certificate of a manufacturer of the eUICC, and a public key of a certificate issuer.
The method according to any of claims 8 to 17, wherein the eUICC certificate comprises a public key and unique identify, EID, of the eUICC.
A method for validating a one-time password, OTP, the method being performed by a validator module (300) , the method comprising:

receiving (S302) , from an OTP module (100) , a request to validate that a signature is associated with a target phone number of a user equipment (200) ; and

validating (S304) the signature and the target phone number in accordance with a mapping between listed phone numbers and eUICC credentials, wherein the target phone number is validated by confirming that the target phone number matches the listed phone number associated with the eUICC credentials of the user equipment (200) , and wherein the signature is validated by confirming that the signature is obtainable from the eUICC credentials associated with the target phone number.
The method according to claim 19, wherein the request comprises an OTP as generated by the OTP module (100) , and wherein the signature further is validated by the validator module (300) confirming that the signature is obtainable from the eUICC credentials in combination with the OTP.
The method according to claim 19 or 20, wherein the validator module (300) is provided in a CSP network.
The method according to any of claims 19 to 21, wherein the method further comprises:

providing (S306) , towards the OTP module (100) , a result of the signature and the target phone number having been validated.
A method for validating a one-time password, OTP, the method comprising:

receiving (S102) , by an OTP module (100) , a request for an OTP to be generated for a target phone number;

providing (S104) , by the OTP module (100) and towards a user equipment (200) of the target phone number, the OTP;

generating (S208) , by an eUICC comprised in the user equipment (200) , asignature for the OTP as entered based on credentials of the eUICC;

providing (S210) , by the user equipment (200) and towards the OTP module (100) , the OTP as entered into the user equipment (200) and the signature;

confirming (S108) , by the OTP module (100) , that the OTP as received from the user equipment (200) matches the OTP as provided towards the user equipment (200) ;

providing (S110) , by the OTP module (100) and towards a validator module (300) in a CSP network, a request to validate that the signature is associated with the target phone number of the user equipment (200) ; and

validating (S304) , by the validator module (300) , the signature and the target phone number in accordance with a mapping between listed phone numbers and eUICC credentials, wherein the target phone number is validated by confirming that the target phone number matches the listed phone number associated with the eUICC credentials of the user equipment (200) , and wherein the signature is validated by confirming that the signature is obtainable from the eUICC credentials associated with the target phone number.
A one-time password, OTP, module (100) for validating an OTP, the OTP module (100) comprising processing circuitry (110) , the processing circuitry being configured to cause the OTP module (100) to:

receive a request for an OTP to be generated for a target phone number;

provide, towards a user equipment (200) of the target phone number, the OTP;

receive, from the user equipment (200) , the OTP and a signature;

confirm that the OTP as received from the user equipment (200) matches the OTP as provided towards the user equipment (200) ; and

provide, towards a validator module (300) in a CSP network, a request to validate that the signature is associated with the target phone number of the user equipment (200) .
A user equipment (200) for validating an OTP, the user equipment (200) comprising an eUICC, the user equipment (200) further comprising processing circuitry (210) , the processing circuitry being configured to cause the user equipment (200) to:

receive the OTP, wherein the OTP originates from an OTP module (100) ;

generate, by the eUICC, a signature for the OTP based on credentials of the eUICC; and

provide, towards the OTP module (100) , the OTP and the signature.
A validator module (300) for validating an OTP, the validator module (300) comprising processing circuitry (310) , the processing circuitry being configured to cause the validator module (300) to:

receive, from an OTP module (100) , a request to validate that a signature is associated with a target phone number of a user equipment (200) ; and

validate the signature and the target phone number in accordance with a mapping between listed phone numbers and eUICC credentials, wherein the target phone number is validated by confirming that the target phone number matches the listed phone number associated with the eUICC credentials of the user equipment (200) , and wherein the signature is validated by confirming that the signature is obtainable from the eUICC credentials associated with the target phone number.
A system comprising the OTP module (100) according to claim 24, the user equipment (200) according to claim 25, and the validator module (300) according to claim 26.
A computer program (1520a) for validating a one-time password, OTP, the computer program comprising computer code which, when run on processing circuitry (110) of an OTP module (100) , causes the OTP module (100) to:

receive (S102) a request for an OTP to be generated for a target phone number;

provide (S104) , towards a user equipment (200) of the target phone number, the OTP;

receive (S106) , from the user equipment (200) , the OTP and a signature;

confirm (S108) that the OTP as received from the user equipment (200) matches the OTP as provided towards the user equipment (200) ; and

provide (S110) , towards a validator module (300) in a CSP network, a request to validate that the signature is associated with the target phone number of the user equipment (200) .
A computer program (1520b) for validating a one-time password, OTP, the computer program comprising computer code which, when run on processing circuitry (210) of a user equipment (200) comprising an eUICC, causes the user equipment (200) to:

receive (S204) the OTP, wherein the OTP originates from an OTP module (100) ;

generate (S208) , by the eUICC, a signature for the OTP based on credentials of the eUICC; and

provide (S210) , towards the OTP module (100) , the OTP and the signature.
A computer program (1520c) for validating a one-time password, OTP, the computer program comprising computer code which, when run on processing circuitry (310) of a validator module (300) , causes the validator module (300) to:

receive (S302) , from an OTP module (100) , a request to validate that a signature is associated with a target phone number of a user equipment (200) ; and

validate (S304) the signature and the target phone number in accordance with a mapping between listed phone numbers and eUICC credentials, wherein the target phone number is validated by confirming that the target phone number matches the listed phone number associated with the eUICC credentials of the user equipment (200) , and wherein the signature is validated by confirming that the signature is obtainable from the eUICC credentials associated with the target phone number.
A computer program product (1510a, 1510b, 1510c) comprising a computer program (1520a, 1520b, 1520c) according to at least one of claims 27, 28 and 29, and a computer readable storage medium (1530) on which the computer program is stored.