A method for informing the mobile network operator server which Profile Type profile should be downloaded from 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 cooperates with a device.

Background Art

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

[0003] The device can be, for example, a mobile phone, smartphone, PDA, M2M, or IoT device. Thanks to SM-DP+ defined by the GSMA specification, it is known that a profile (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+ (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 a user signs a contract or purchases a prepaid subscription, the profile associated with this contract is downloaded from a server on the network. This server is SM-DP+. SM-DP+ is contacted by the LPA application (Local Profile Assistant) to initiate the profile download. Subsequently, in the process, SM-DP+ is directly contacted by eUICC (through an encrypted data channel) with the help of LPA to download a new profile.

[0007] SM-DP+ also communicates with a network operator's provisioning system in the following scenario, for example: A user purchases a prepaid subscription (online or in-store). The network operator then links the subscription to a profile that the network operator knows already exists on SM-DP+. The network operator then assigns a MatchingID to the profile, informing SM-DP+ that a specific MatchingID has been assigned to a particular 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 to SM-DP+ by LPA when the user wants to download a profile, and thus SM-DP+ is able to find the profile that the network operator's provisioning system has assigned to the user.

[0008] Since profile downloads require user interaction, the LPA (Landing Page Application) is an application on the device that allows the user to manage their virtual SIM card (profile). Management operations include downloading new profiles, activating and deactivating those profiles, and also deleting those profiles from the eUICC (e-UICC). The LPA is the application that interacts with the user and communicates with the eUICC and servers over the network. Theoretically, the LPA can exist in the eUICC or on the device that interacts with the user.

[0009] The profile is provided by the MNO and includes 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 Rules.

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

[0011] While the mobile network operator (MNO) reserves a profile for the end user, the MNO does not know the actual device used by the end user.

[0012] MNOs must reserve profiles in SM-DP+ in order to deliver the profiles behind subscription plans to end users. [Overview of the Initiative] [Problems that the invention aims to solve]

[0013] Today, with the specifications provided by the GSMA, MNOs prior to the download risk being unaware of the device and having the reserved profile for SM-DP+ not conform to the device.

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

[0015] - Dynamic Eligibility Check (DEC): This check is based on eUICC information (eUICC Info) and device capabilities signed by eUICC during the "Download & Installation Procedure". Therefore, the "compatible or incompatible" profiles are already reserved and in use.

[0016] In this case, the end user will receive an error message, and the MNO must reserve an error profile in SM-DP+, which carries the same potential risks. [Brief explanation of the drawing]

[0017] [Figure 1] It represents the interaction between the MNO server 21, such as an OTA server, the SM-DP+ 22, and the device 23 including the LPA and eUICC. [Figure 2] It represents the flowchart of the solution to solve the problem.

Embodiment for Implementing the Invention

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

[0019] In this figure, the 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 the profile to an external entity.

[0024] In the DE scenario, through the ES9+ interface, at 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 at step 14a. The SM-DP+22 notifies the MNO server 21 of the success of the installation at step 15a; - If the installation is not successful, the device 23 notifies the SM-DP+22 of this failure at step 14b. The SM-DP+22 notifies the MNO server 21 of the failure of the installation at step 15b.

[0025] Step 13 actually consists of four consecutive requests from the eUICC to the SM-DP+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 to 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 if you can use one of the GSMA CI Public Keys (GSMA CI Public Keys) that can be used to verify the eUICC signature by comparison, and select that CI. - Verify that you can provide a CERT.DPauth.ECDSA signed by one of the GSMA CI public keys supported by eUICC, and preferably select the CERT.DPauth.ECDSA according to the priority given to CI public keys by eUICC. If any of these verifications fail, SM-DP+22 will return a "function execution status" indicating "failure" along with the associated status code. Otherwise, SM-DP+22 will do the following: ○ Generate a TransactionID, which will be used to uniquely identify the ongoing RSP session. ○ Generate a ServerChallenge for eUICC authentication associated with the ongoing RSP session. ○ Generate the serverSigned1 data object as expected by eUICC. ○ Generate a signature (serverSignature1).

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

[0029] This function is called by the LPA to request eUICC authentication by SM-DP+22. This function is correlated to a previous normal execution of the aforementioned "ES9+.InitiateAuthentication" function via a TransactionID generated and delivered by SM-DP+. The TransactionID is an identifier for the current transaction (associated with a given device). This TransactionID is incremented in each transaction to prevent replay attacks. Upon receiving this function call, SM-DP+: - 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 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 related to eUICC. This function is correlated to a previous normal execution of the "ES9+.AuthenticateClient" function via TransactionID. Upon receiving this function call, SM-DP+22: - 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. - This instruction verifies whether it requires verification of a Confirmation Code. If yes, SM-DP+22 verifies that the received hashed confirmation code matches a value known to SM-DP+22.

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

[0033] This function is called by the LPA to notify the SM-DP+22 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, due to the specifications provided by the GSMA, MNOs are unaware of the device before the download, and there is a risk that the profile reserved for SM-DP+ may not be compatible with the device.

[0035] This 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 SM-DP+ to a secure element that works with a device, wherein SM-DP+ has three categories: - Preferred profile type, which is a profile type that was successfully downloaded to the previous secure element; - Authorized profile types are profile types that are authorized to be downloaded to the secure element by the MNO providing the profile type to SM-DP+; - Forbidden profile types are profile types that are prohibited from being downloaded to the secure element by the MNO providing the profile to SM-DP+. It stores profiles categorized as follows: Method: - Generate an EligibilityId, share it between the mobile network operator server and SM-DP+, and transmit the EligibilityId from the device to SM-DP+ along with information about the secure element and the device. - Based on the EligibilityId and information about the secure element and device, transmit information about the profile to be downloaded to the secure element from SM-DP+ to the mobile network operator server. We propose a method that includes this.

[0037] Preferably, the information is contained within a QR code that is 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 Figure 2, which represents a solution to the above-mentioned problems.

[0040] This solution requires three state profile types to define the available actions for SM-DP+22. These profile types are as follows: - Preferred ProfileType: The profile type successfully downloaded to the previous secure element by SM-DP+22, and this previous secure element has the same or similar capabilities as the current secure element. Furthermore, previous devices working with this previous secure element have the same or similar capabilities as devices working with the current secure element; - Authorized ProfileType: A profile type has been authorized by the operator for use by end users. Profiles of an authorized ProfileType are therefore authorized to be downloaded to the secure element by SM-DP+22. - Forbidden ProfileType: Inappropriate profile type (This type of profile was downloaded to the secure element with a 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 in Figure 2.

[0042] In step 30, similar to step 10 in Figure 1, TC20 provides a profile that conforms to the device manufacturer's specifications (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 SM-DP+22 administrator configures the Profile Type (Preferred, Authorized, or Forbidden). This means that the various profiles are categorized into the three categories mentioned above. The profile type can therefore be Preferred, Authorized, or Forbidden. By default, the profileType is Authorized.

[0045] Next, the eligibility procedure according to the present invention is initiated: In step 33, and through ES2+, the MNO requests 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 a profile. The MNO 21 can also generate an EligibilityId based on the type of profile to be downloaded to the secure element (VIP, preferred list of PLMN, ...). The EligibilityId can also be generated by the MNO 21 and sent to SM-DP+22. The SM-DP+22 reserves the EligibilityId as an activation code for the end user (or uses SM-DS). The EligibilityId is used for any type of device (car, e-meter, smartphone, ...). There is no need to know the device model, no need to select a specific profile, the EligibilityId is simply an identifier that pairs the MNO server 21, SM-DP+22, and device 23.

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

[0047] To manage this new eligibility procedure, therefore, a new QR code for end users is necessary. This QR code will help the MNO retrieve information from the device and eUICC (euiccInfo and deviceInfo, hereafter referred to as "Info") to select the "perfect" or "best" subscription for this device / eUICC. In this case, the solution guarantees in all cases the successful download of the subscription on the device / eUICC, at least after the initial 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 from this MNO. This ensures that the eUICC of 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] euiccInfo is, for example, the EID of the eUICC, and device info includes, for example, the model of device 23, the installed OS, etc.

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

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

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

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

[0054] In step 36, the SM-DP+22 notifies the MNO server 21 of all the necessary information for selecting the best profile: not only the "Authorized" and "Preferred" Profile Types for this device, but also the eUICCInfo, EID, DeviceInfo, IMEI, and EligibilityId. The MNO server 21 can now determine which profile should be downloaded based on the data received from the SM-DP+22 in step 36.

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

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

[0057] In current technology, the MatchingID is contained 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 the activation code and the SM-DP+ URL address. Therefore, the MatchingID ensures that the profile will be downloaded to the device's eUICC. When the user scans the QR code, the profile is downloaded to the eUICC, but there is no guarantee that this profile will match the eUICC or the device. If the profile does not match, the download fails, and the user must request a different profile (i.e., a different QR code) from the MNO.

[0058] However, in step 37, the instruction includes a preferred profile type (MatchingID or EligibilityID) to download the profiles 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 an ES9+HandleNotification, the SM-DP+ server 22 performs the following (in step 40): If the download fails, the SM-DP+22 will never again suggest this profile to this type of device. The Profile Type will be "Forbidden" for this device type.

[0061] If the download is successful, the Profile Type will be the Preferred Profile Type for this device type (if it hasn't already been 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 will know the compatible device model and profile type for this device before initiating the "Download Initiation procedure" from GSMA specification SGP.22.

[0064] With this solution, there is only one error per attempt: the initial error related to the preferred profile type with a poor configuration. Once 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 SM-DP+ (22) to a secure element that works with a device (23), wherein the SM-DP+ (22) has three categories, namely, The Preferred profile type is a profile type that was previously downloaded to the secure element. Authorized profile type, which is a profile type authorized to be downloaded to the secure element by the MNO that provides the profile type to the SM-DP+(22), Forbidden profile type is a profile type that is prohibited from being downloaded to the secure element by the MNO that provides the profile to the SM-DP+(22). It stores profiles categorized as follows: The method described above is The mobile network operator server (21) or the SM-DP+ (22) generates an EligabilityId, shares it between the mobile network operator server (21) and the SM-DP+ (22), the device (23) receives the EligabilityId, and transmits the EligabilityId from the device (23) to the SM-DP+ (22) along with information about the secure element and the device (23). Based on the EligibilityId and the information regarding the secure element and the device (23), the SM-DP+ (22) transmits information about the profile to be downloaded to the secure element to the mobile network operator (21) server, and the mobile network operator server (21) selects a specific profile. Includes, A method wherein, if the profile is of a Preferred profile type, the device (23) has the same or similar capabilities as the device currently working with the secure element; if the profile is of an Authorized profile type, the device (23) downloads the profile; and if the profile is of a Forbidden profile type, the device (23) does not download the profile.

2. The method according to claim 1, wherein the information relating to the secure element and the device (23) 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, a UICC, an eUICC, or an iUICC.

Images