A method for informing a mobile network operator server which profile of the Profile Type should be downloaded from the SM-DP+ to the secure element

Abstract

The present invention relates to a method for informing a mobile network operator (21) server which profile should be downloaded from SM-DP+ (22) to a secure element cooperating with a device (23), wherein SM-DP+ (22) stores profiles classified into three categories: - Preferred profile type, which is a profile type that has been successfully downloaded to a previous secure element; - Authorized profile type, which is a profile type approved by the MNO providing the profile type to the secure element for download; - Forbidden profile type, which is a profile type prohibited by the MNO providing the profile to the secure element for download, and the method comprises: - Generating an EligibilityId, sharing it between the mobile network operator server (21) and SM-DP+ (22), and transmitting the EligibilityId from the device (23) to SM-DP+ (22) together with information about the secure element and the device (23); - Transmitting information about the profile to be downloaded to the secure element from SM-DP+ (22) to the mobile network operator (21) server based on the EligibilityId and information about the secure element and the device (23).

Description

Technical Field

[0001] The present invention relates to telecommunications, and more precisely to the download of a Mobile Network Operator (MNO) profile in a secure element that collaborates with a device.

Background Art

[0002] The secure element can be, for example, a Sim card, a UICC, an embedded UICC (eUICC), or an integrated UICC (iUICC).

[0003] The device can be, for example, a mobile phone, a smartphone, a PDA, an M2M, or an IoT device. Thanks to the SM-DP+ defined by the GSMA specifications, it is known that profiles (including subscriptions, keys, files, applets, basic files, ...) can be downloaded to the secure element in the field. SM-DP stands for Subscription Manager Data Preparation.

[0004] More precisely, in the eUICC domain, the profile is downloaded from the server SM-DP+ (a Solution server for managing the remotely downloaded eSIM) to the eUICC through the device in which the eUICC is embedded.

[0005] Hereinafter, the procedure defined by SGP.22 from the GSMA will be described.

[0006] When the user signs the contract or buys a prepaid subscription, the profile associated with this contract is downloaded from a server on the network. This server is the SM-DP+. The SM-DP+ is contacted by the LPA (Local Profile Assistant) application to initiate the download of the profile. In the subsequent process, the SM-DP+ is contacted directly by the eUICC (through an encrypted data channel) with the help of the LPA to download the new profile.

[0007] The SM-DP+ also communicates with the network operator's provisioning system in scenarios such as: The user purchases a prepaid subscription (online or in a store). The network operator then links the contract to a profile that the network operator knows already exists on the SM-DP+. The network operator then gives a MatchingID to the profile and notifies the SM-DP+ that a specific MatchingID has been assigned to a specific profile. The MatchingID is then also given to the user as part of a 2D barcode or QR code scanned by the LPA application. The MatchingID is then sent by the LPA to the SM-DP+ when the user wants to download the profile, so that the SM-DP+ can find the profile assigned to the user by the network operator's provisioning system.

[0008] Since downloading a profile requires user interaction, the LPA is an application on the device that allows the user to manage his virtual SIM card (profile). The management operations are to download new profiles, activate and deactivate those profiles, and also delete those profiles from the eUICC. This LPA is the application that interacts with the user and communicates with the eUICC and the server in the network. Theoretically, the LPA can exist in the eUICC or in the device that interacts with the user.

[0009] Profiles are provided by the MNO and include profile components. These profile components are as follows: - MNO SD (Security Domain); - Supplementary Security Domains (SSD) and CASD (Controlling Authority Security Domain); - Applet; - Applications, such as NFC applications; - NAAs (Network Attachment Subsystem); - Other elements of the file system; - Profile Metadata including Profile Policy Rule.

[0010] The device is provided by the device manufacturer (OEM).

[0011] [[ID=!26]]The MNO reserves the profile for the end user, but the MNO does not know the actual device used by the end user.

[0012] MNO has to reserve a profile with the SM-DP+ in order to distribute to the end user the profile behind the subscription plan.

Summary of the Invention

Problems to be Solved by the Invention

[0013] Today, following the specifications provided by the GSMA, the MNO, prior to the download, is unaware of the device and there is a risk that the profile reserved with the SM-DP+ does not comply with the device.

[0014] The RSP Technical Specification, titled "Profile Eligibility Check (Informative)" V2.x in Annex F of GSMA Specification SGP.22, describes the following two types of checks: - Static Eligibility Check (SEC): If the MNO does not know the device (its IMEI) and the eUICC (its EID) and their capabilities, eligibility is not possible.

[0015] - Dynamic Eligibility Check (DEC): This check is based on the eUICC information (eUICC Info) signed by the eUICC and the device capabilities during the "Download & Installation procedure". Therefore, "compatible or not" profiles have already been reserved and used.

[0016] In this case, the end user will receive an error message and the MNO has to reserve an error profile with the SM-DP+, which potentially involves the same risk.

Brief Description of the Drawings

[0017]

Figure 1

Figure 2

Mode for Carrying Out the Invention

[0018] FIG. 1 represents the interaction between the MNO server 21, for example, an OTA server, the SM-DP+ 22, and the device 23 including the LPA and eUICC.

[0019] In this figure, a Technical Consultant (TC 20) is also represented.

[0020] In step 10, after discussing with the MNO 21 regarding its needs, the TC 20 constructs the profile prepared by the MNO on its own server 21.

[0021] In step 11, the MNO 21 server provisions these profiles to the SM-DP+ 22.

[0022] In the SEC scenario, in step 12, the MNO server 21 reserves the profile through the ES2+ interface in the SM-DP+ 22.

[0023] The ES2+ interface connects the SM-DP+ 22 to the MNO server 21. Since the SM-DP+ server 22 can be operated by various entities, standardization of this interface is necessary. For example, the MNO can purchase and operate its own SM-DP+ server, or the MNO can outsource the operation of the SM-DP+ and the creation of profiles to an external entity.

[0024] In the DE scenario, through the ES9+ interface, in step 13, the LPA establishes an encrypted connection to the SM-DP+22 when, for example, the user wants to download a new profile (virtual SIM). Then, after the installation of the profile in the eUICC, the following two solutions become possible: - If the installation is successful, the device 23 notifies the SM-DP+22 of this success in step 14a. The SM-DP+22 notifies the MNO server 21 of the success of the installation in step 15a; - If the installation is not successful, the device 23 notifies the SM-DP+22 of this failure in step 14b. The SM-DP+22 notifies the MNO server 21 of the failure of the installation in step 15b.

[0025] Step 13 actually consists of four consecutive requests from the eUICC to the SM-DP+ point 22.

[0026] The first request is a function called "InitiateAuthentication".

[0027] This function requests authentication from the SM-DP+22. This follows "GetEUICCChallenge" between the eUICC and the LPA, where the LPA obtains the material from the eUICC that will be provided to the SM-DP+22. Upon receiving this function call, the SM-DP+22 will do the following: - Verify that it supports the Specification Version Number indicated by the eUICC. - Check whether the received address matches its own SM-DP+22 address. Check whether it is possible to use one of the GSMA CI Public Keys against which the eUICC signature can be verified, and select that CI. Verify that it is possible to provide CERT.DPauth.ECDSA signed by one of the GSMA CI public keys supported by the eUICC, and preferably select CERT.DPauth.ECDSA according to the priority provided by the eUICC for the CI public key. If any of these verifications fail, SM-DP+22 will return a "Function Execution Status" indicating "Failure" along with the relevant status code. Otherwise, SM-DP+22 will do the following: 〇 Generate a TransactionID used to uniquely identify the ongoing RSP session. 〇 Generate a ServerChallenge for the eUICC authentication associated with the ongoing RSP session. 〇 Generate the serverSigned1 data object as expected by the eUICC. 〇 Generate a signature (serverSignature1).

[0028] The second request is a function called "AuthenticateClient".

[0029] This function is called by the LPA to request the authentication of the eUICC by SM-DP+22. This function is correlated with the previous normal execution of the "ES9+.InitiateAuthentication" function described above through the TransactionID generated and distributed by SM-DP+. The TransactionID is an identifier for the current transaction (related to a given device). This TransactionID is incremented in each transaction to avoid replay attacks. Upon receiving this function call, SM-DP+ will: - Verify the validity of CERT.EUM.ECDSA using the associated public key PK.CI.ECDSA. - Verify the validity of CERT.EUICC.ECDSA using the public key PK.EUM.ECDSA. - Verify the eUICC signature (euiccSignature1) using PK.EUICC.ECDSA. - Verify that the TransactionID is known and associated with an ongoing RSP session. - Verify that the ServerChallenge associated with the ongoing RSP session matches the ServerChallenge returned by the eUICC.

[0030] The third requirement is a function called "GetBoundProfilePackage".

[0031] This function must be called to request the delivery and binding of a profile package for the eUICC. This function is correlated with a previous normal execution of the "ES9+.AuthenticateClient" function through the TransactionID. When this function call is received, SM-DP+ should: - Verify that the received TransactionID is known and associated with an ongoing RSP session. - Verify the eUICC signature (euiccSignature2) using PK.EUICC.ECDSA associated with the ongoing RSP session. - Verify whether this command requires verification of a confirmation code, and if so, SM-DP+ should verify that the received hashed confirmation code matches the value known to SM-DP+.

[0032] The fourth and final function is called "HandleNotification".

[0033] This function is called by the LPA to notify the SM-DP+ that the Profile Management Operation has been successfully performed on the eUICC. This corresponds to steps 14a and 14b.

[0034] The problem with these known solutions, as already mentioned, is that according to the specifications provided by the GSMA, the MNO before the download does not know the device and there is a risk that the profile reserved on the SM-DP+ does not comply with the device.

[0035] The present invention proposes a solution to this problem.

[0036] More precisely, the present invention is a method for informing a Mobile Network Operator Server which profile should be downloaded from the SM-DP+ to a Secure Element that cooperates with the device, wherein the SM-DP+ stores profiles classified into three categories: - Preferred profile type, which is a profile type that has been successfully downloaded to a previous secure element; - Authorized profile type, which is a profile type that has been approved by the MNO providing the profile type to the SM-DP+ for download to the secure element; - Forbidden profile type, which is a profile type that has been prohibited by the MNO providing the profile to the SM-DP+ from being downloaded to the secure element and the method is: The method is: Generate an EligibilityId, share it between the mobile network operator server and the SM-DP+, and transmit the EligibilityId from the device to the SM-DP+ together with information about the secure element and the device. - Based on the EligibilityId and information about the secure element and the device, transmit information about the profile to be downloaded to the secure element from the SM-DP+ to the mobile network operator server. A method is proposed that includes the above.

[0037] Preferably, the information is included in a QR code scanned by the device.

[0038] Advantageously, the secure element is a Sim card, UICC, eUICC, or iUICC.

[0039] The present invention will be better understood by reading the following description of FIG. 2, which represents a solution to the above problems.

[0040] Regarding this solution, three states of profile types are required to define the available actions of the SM-DP+ 22. These profile types are as follows: - Preferred ProfileType: It is the profile type that has been successfully downloaded to the previous secure element by the SM-DP+ 22. This previous secure element has the same or similar capabilities as the current secure element. Also, the previous device that collaborated with this previous secure element has the same or similar capabilities as the device that collaborates with the current secure element; - Authorized ProfileType: An operator has approved that a certain profile type can be used by an end user. Profiles of the approved ProfileType are, therefore, profiles approved to be downloaded to the secure element by the SM-DP+22. - Forbidden ProfileType: A profile type that is not a suitable profile (profiles of this type are downloaded onto the secure element with failure).

[0041] This solution includes an "Eligibility Procedure" before the "Download Initiation Procedure" from the GSMA specification (Annex F mentioned above). This solution is represented in the flowchart of Figure 2.

[0042] In step 30, similar to step 10 in Figure 1, TC20 provides a profile that complies with the specifications of the device manufacturer (5G, OS,...).

[0043] In step 31, the MNO server 21 provisions several batch profiles (Profile Type) from the MNO to the SM-DP+22.

[0044] In step 32, the administrator of the SM-DP+22 configures the Profile Type (Preferred, Authorized, or Forbidden). This means that different profiles are classified into the above three categories. The profile type can, therefore, be Preferred, Authorized, or Forbidden. By default, the profileType is Authorized.

[0045] Then, start the eligibility procedure according to the present invention: In step 33, and through ES2+, the MNO requests the SM-DP+22 to generate an EligibilityId. The EligibilityId is, for example, a QR code and corresponds to a number. This number is different for each device 23 unless the secure element has been provisioned with a profile. The MNO21 can also generate the EligibilityId based on the type of profile (VIP, preferred list of PLMNs, ...) that will be downloaded to the secure element. The EligibilityId can also be generated by the MNO21 and sent to the SM-DP+22. The SM-DP+22 reserves the EligibilityId as an activation code for the end user (or it uses the SM-DS). The EligibilityId is used for any type of device (car, e-meter, smartphone, ...). There is no need to know the device model or to select a specific profile; the EligibilityId is simply an identifier that pairs the MNO server 21, the SM-DP+22, and the device 23.

[0046] The proposed solution is thus based on an "Eligibility Procedure" that is executed before the "Download Initiation Procedure" from the GSMA specifications.

[0047] In order to manage this new eligibility procedure, there must therefore be a new QR code for the end user. This QR code will help the MNO to obtain information from the device and the eUICC (euiccInfo and deviceInfo, hereinafter "information") and to select the "perfect" or "best" subscription for this device / eUICC. In this case, the solution guarantees the success of the subscription download in the device / eUICC in any case, at least after the first selection of the profile. The QR code can be printed on the box of the device 23 purchased by the user, or sent to the user by the MNO server 21 when the user wishes to subscribe to this MNO. This ensures that the eUICC of the device 23 is provisioned by a profile belonging to the MNO.

[0048] The QR code is scanned by the user before step 33a, and during step 33a, the SM-DP+ 22 requests the information euiccInfo and deviceInfo from the device 23.

[0049] The euiccInfo is, for example, the EID of the eUICC, and the device information (device info) includes, for example, the model of the device 23, the installed OS,....

[0050] In step 34, the SM-DP+ 22 sends the message "DownloadProfile (ES9+.InitiateAuthentication, ES9+.AuthenticateClient) with EligibilityId" to the device 23. Therefore, the two above-mentioned functions, InitiateAuthentication and AuthenticateClient, are sent to the device 23, i.e., to request its EligibilityId.

[0051] In step 34b, the device (LPA) performs a "download" action using ES9+ (InitiateAuthentication and AuthenticateClient functions). Here, device 23 uses the scanned QR code to send information such as deviceInfo (device information like IMEI or TAC) and eUICCInfo (information about the eUICC) signed by the eUICC.

[0052] In step 35, SM-DP+ 22 obtains which Profile Type is compatible with the device and the eUICC due to a previous successful download (with respect to the information euiccInfo and deviceInfo).

[0053] If the Preferred Profile Type is not available, SM-DP+ 22 selects one of the Authorized Profile Types (but never a prohibited profile).

[0054] In step 36, SM-DP+ 22 notifies the MNO server 21 of all the necessary information for selecting the best profile: not only the "Authorized", "Preferred" Profile Types for this device, but also eUICCInfo, EID, DeviceInfo, IMEI, and EligibilityId. Now, the MNO 21 server knows the device model and can select a specific profile that is compatible with the eUICC, and the MNO 21 server can activate this subscription in its backend. It is the MNO server 21 that determines which profile must be downloaded based on the data received from SM-DP+ in step 36.

[0055] Step 36 is the end of the Eligibility Procedure according to the present invention.

[0056] In step 37, using ES2+, the known GSMA procedure is started, and MNO21 reserves a profile from the "Download Initiation Procedure" GSMA specification. The EligibilityId can be used as the MatchingID (defined by the GSMA) to hold the same identifier for the Eligibility Procedure and Download. The MatchingID must be set (in accordance with the GSMA) between MNO21 and SM-DP+22 to identify the context of a particular administrative setup given to SM-DP+22. The MatchingID is generated during the download initiation procedure of SGP.22.

[0057] In the prior art, the MatchingID is included in a QR code printed on the box containing the device sold to the customer (or on a card given to the customer). The MatchingID includes an activation code and the URL address of the SM-DP+. Therefore, the MatchingID secures the profile to be downloaded to the eUICC of the device. When the user scans the QR code, the profile is downloaded to the eUICC, but there is no guarantee that this profile matches the eUICC or the device. If the profiles do not match, the download has failed, and the user must request another profile (i.e., another QR code) from the MNO.

[0058] However, here in step 37, the instruction includes the preferred profile type (MatchingID or EligibilityID) to download the profile corresponding to euiccInfo and deviceInfo. This profile is selected by MNO21.

[0059] In step 38, the device / LPA performs a "Download" action using ES9+(InitiateAuthentication,AuthenticateClient,GetBoundProfilePackage).

[0060] In step 39, upon receiving ES9+HandleNotification, the SM-DP+ server 22 does the following (in step 40): If the download fails, the SM-DP+ 22 will never propose this profile to this type of device again. The Profile Type becomes a Forbidden Profile for this device type.

[0061] If the download is successful, the Profile Type becomes the Preferred Profile Type for this device Type (if not already done).

[0062] In step 41, after a successful download, the SM-DP+ 22 sends a notification of successful installation to the MNO server 21.

[0063] Using this solution, the MNO server 21 knows the device model and profile type compatible with this device before starting the "Download Initiation procedure" from the GSMA specification SGP.22.

[0064] Using this solution, there is only one error per attempt: namely, the first error regarding a preferred profile type with a bad configuration. When the SM-DP+ 22 updates the profile type, all other subsequent downloads will succeed.

Claims

1. A method for informing a mobile network operator (21) server which profile should be downloaded from an SM-DP+ (22) to a secure element that collaborates with a device (23), wherein the SM-DP+ (22) stores profiles classified into three categories, namely: A Preferred profile type which is a profile type that has been successfully downloaded to a previous secure element, An Authorized profile type which is a profile type that has been approved by the MNO providing the profile type to the SM-DP+ (22) for download to the secure element, A Forbidden profile type which is a profile type that has been prohibited by the MNO providing the profile to the SM-DP+ (22) from being downloaded to the secure element and the method includes: generating an EligibilityId, sharing it between the mobile network operator server (21) and the SM-DP+ (22), and transmitting the EligibilityId from the device (23) to the SM-DP+ (22) together with information about the secure element and the device (23); transmitting, from the SM-DP+ (22) to the mobile network operator (21) server, information about the profile to be downloaded to the secure element based on the EligibilityId and the information about the secure element and the device (23). A method as claimed in claim 1 or 2, wherein the information is included in a QR code scanned by the device (23). A method as claimed in claim 1 or 2, wherein the secure element is a Sim card, UICC, eUICC, or iUICC.

2. The method according to claim 1, wherein the information is included in a QR code scanned by the device (23).

3. The method according to claim 1 or 2, wherein the secure element is a Sim card, UICC, eUICC, or iUICC.

Images