PARTICIPANT IDENTITY MODULE WITH OR SET UP FOR APPLICATION

Description

Field of invention

[0001] The invention relates to a subscriber identity module for authenticating a mobile device to a mobile network, comprising at least one profile container configured to allow a profile to be loaded, installed and managed from a profile server, and further configured to allow applications to be loaded into the subscriber identity module and installed and managed there, or comprising applications, wherein the applications are configured to offer a service that is different from authentication to the mobile network.

[0002] The world is connected via mobile networks, and this connectivity continues to advance. Mobile-enabled devices communicate via mobile networks. Classic consumer-grade mobile-enabled devices include smartphones and mobile phones. IoT-enabled devices also include control devices (controllers, measuring devices, or combined control / measuring devices) for industrial facilities in commercial or private environments. Industrial facilities include, for example, production plants that have one or more control devices (end devices) capable of communicating with a background system and / or with each other via a mobile network. Other industrial facilities include smart home devices such as heating systems or electrical appliances with end devices in the form of control devices.

[0003] To use a mobile-enabled device, such as a smartphone or mobile phone, in a network operator's mobile network, the device contains a subscriber identity module with a subscription profile, or simply profile. The profile configures the device and its connection to the mobile network. The profile consists of a data set that enables the establishment, operation, and termination of a connection between the device and the mobile network, and includes, for example, a cryptographic authentication key (Ki) and an International Mobile Subscriber Identity (IMSI).

[0004] The terminal device itself has one or more terminal chips for operating its functions. Current smartphones, for example, typically have at least three terminal chips: a transceiver IC that handles the physical radio communication, a baseband processor (or equivalent modem) that performs data transmission over radio communication at the protocol level, and an application processor (AP) on which the operating system and application software run. Additional terminal chips may include transceiver ICs for other radio channels, particularly for short-range radio channels such as NFC (near field communication) or Bluetooth.

[0005] Subscriber identity modules can be designed in various form factors, including plug-in, embedded, integrated, and software. Plug-in and embedded subscriber identity modules are located on a dedicated, dedicated chip or SoC (System-on-Chip). Examples of plug-ins include SIM cards (SIM = Subscriber Identity Module), USIM cards (Universal SIM), or UICC (Universal Integrated Circuit Card), which communicate with the terminal device via a card reader. Alternatively, the dedicated chip can be integrated into a package that can be soldered or permanently integrated into the terminal device. A solderable / integrated subscriber identity module is designated with the suffix "embedded" and referred to as an eUICC, where "e" stands for embedded and the further designation is taken from the correspondingly equipped plug-in.Other possible form factors for a subscriber identity module include integrated subscriber identity modules, which are integrated onto a terminal chip or SoC (System-on-Chip) of the terminal device, meaning they do not have their own separate chip. Integrated subscriber identity modules are designated with the suffix "integrated" and are, for example, referred to as integrated UICC or iUICC. Another possible form factor for a subscriber identity module is a pure software module with the functionality of a subscriber identity module, which is integrated into a terminal chip.

[0006] The eUICC is becoming increasingly important in smartphones and IoT applications. Furthermore, the increasing digitalization across all sectors is driving the need for robust IT security solutions.

[0007] It can be assumed that in the future, in addition to authenticating network access to the mobile network, the eUICC will also widely offer security solutions for further services at the application level. Such services could include identification services (MobileID), signature services for signing various transaction data (electronic signatures), ticketing services, VPN access services (VPN = Virtual Private Network), and many more.

[0008] The strong standardization of the eUICC is helpful in ensuring a significant (though not complete) degree of compatibility between the eUICCs of different manufacturers.

[0009] The invention relates to an architecture for a subscriber identity module that makes it possible to implement and manage applications, in particular applets, for service functions in the subscriber identity module. State of the art

[0010] The GSMA specifications SGP.22, SGP.02 and SGP.21 describe the architecture and management capabilities of a subscriber identity module eUICC.

[0011] Specifically, see GSMA SGP.01 RSP Architecture, Version 2.2, 01 September 2017, Chapter 4.1.1 "eUICC Architecture Overview". Figure 2The architecture and communication channels for managing a subscriber identity module (eUICC) were shown. According to this, an eUICC has multiple profile containers, the so-called ISD-Ps (also SGP.21, Chapter 4.1.1.3). Each ISD-P profile container contains a subscription profile, or simply profile, which enables authentication of the mobile device to a mobile network. Each profile container and its contents are under the control of a specific network operator (MNO; sometimes also simply called "operator"). The profiles are loaded into the eUICC from a server—SM-DP+ in the case of SGP.22—via the Remote SIM Provisioning (RSP) mechanism and installed within the eUICC (SGP.21, Figure 2Channel ES6 "to Operator" = channel to the MNO (= operator); Channel ES8+ "to SM-DP+" = channel to the subscription server SM-DP+). The RSP of a profile container and its contents is under the control of the specific network operator MNO.

[0012] Additionally, as also stated in SGP.21, Figure 2 As can be seen, profile containers can contain ISD-P applets. Applets for additional services that go beyond authentication on the mobile network and are logically independent of it appear particularly interesting for future eUICCs. Examples of suitable services include Mobile ID (mobile identification of individuals similar to a physical ID document), signing of transaction data, ticketing, and VPN access (VPN = Virtual Private Network).

[0013] Applets within an ISD-P profile container can be loaded, installed, and modified within the ISD-P via the RSP mechanism. However, like all ISD-P content, these applets are under the control of the network operator (MNO) that manages the ISD-P. This resulting dependency on a specific MNO is not always desirable.

[0014] In some GSMA standardization working groups, an alternative eUICC architecture has been proposed, in which applets are installed outside of profile containers within eUICC. This would allow for the independent loading, installation, management, and modification of applets by network operators (MNOs). A disadvantage of this solution is that the proven GSMA RSP mechanisms can no longer be used for loading, installing, managing, and modifying applets. Instead, other OTA (over-the-air) servers can be used.

[0015] Figure 1 This shows an eUICC architecture according to SGP.21 with the possibility of including applets in eUICC. The eUICC from Figure 1 For example, there are two profile containers: ISDP and ISD-P 2. Profile container ISD-P contains three applets: Applet X, Applet X, and MNO Applet. Furthermore, eUICC has a separate MNO security domain for each profile container, ISD-P and ISD-P 2, on which the profile container is based. eUICC also has an eUICC operating system – eUICC OS – on which the individual profile containers run.

[0016] Set up profile containers ISD-Ps. The applet, the applet belonging to the MNO, and the MNO-independent applet X can be managed via the RSP architecture, for example, via the channels from ISD-P to SM-DP+, or via the channel from LPAd to ISD-R.

[0017] Figure 2This diagram shows an eUICC architecture based on the alternative proposal for housing applets in eUICC, as discussed in the GSMA. eUICC also has an eUICC operating system – eUICC OS. A Common Security Domain (CSD) is built on top of eUICC OS. Two profile containers, ISD-P and ISD-P 2, are built on top of the Common Security Domain (CSD). Independent of the ISD-P and ISD-P 2 profile containers, an MNO-independent applet, Applet X, is installed in eUICC. The ISD-P and ISD-P 2 profile containers can be managed via the RSP architecture, for example, via the channels from ISD-P to SM-DP+, or via the channel from LPAd to ISD-R. Both the ISD-P and MNO-specific applets can be managed via the RSP architecture. The MNO-independent Applet X cannot be managed via the RSP architecture, but requires its own OTA server (OTA = over the air).

[0018] The prior art document EP 3 484 198 A1 discloses an eUICC with profile SDs (profile security domains) and a so-called transversal security domain (TSD) arranged alongside the profile SDs. Access to the transversal security domain (TSD) by a subscription server SM-DP+ is achieved by sending a TSD identifier to the currently active profile SD.

[0019] The prior art document US 2018 / 0234405A1 discloses a subscriber identity module for authenticating a mobile device to a mobile network, comprising at least one profile container configured to allow a profile to be loaded, installed, and managed from a profile server. The profile container also includes an application security domain created within the profile container, configured to allow applications to be loaded, installed, and managed from an MNO TSM server.

[0020] The prior art document DE102015008179A1 discloses a participant identity module for authenticating a mobile device to a mobile network, comprising at least one profile container in which an MNO security domain is created under which an applet is created (for example, Fig. 1 ).

[0021] Document WO 2015 / 175164A1 describes a technique for managing one or more electronic subscriber identification modules (eSIMs) on an embedded UICC (eUICC). This technique involves using the GlobalPlatform™ specification and / or other telecommunications standards to support the eSIMs on the eUICC. Each eUICC can contain an Issuer Security Domain (ISD) owned by a device manufacturer, as well as an eSIM manager that manages the multitude of eSIMs on the eUICC. Specifically, binaries from one or more applications shared by different eSIMs can be standardized and stored in such a way that each eSIM is able to use the one or more applications (via the eSIM) or multiple applications (via the eSIM manager) without having to store the binaries individually. Summary of the invention

[0022] The invention is based on the objective of creating a subscriber identity module in which third-party applets can be efficiently installed and managed independently of a specific network operator (MNO).

[0023] The task is solved by a participant identity module according to claim 1 and a profile server SM-DP+ according to claim 8.

[0024] Advantageous embodiments of the invention are specified in the dependent claims.

[0025] The subscriber identity module according to claim 1 is configured for authenticating a mobile device to a mobile network. The subscriber identity module comprises at least one profile container configured to allow a profile to be loaded, installed, and managed within it from a profile server. The subscriber identity module is characterized by at least one application security domain created within the profile container, configured to allow applications to be loaded, installed, and managed within it from the same profile server. An application is installed in the application security domain. The application is configured to offer a service that differs from authentication to the mobile network.

[0026] The application security domain, as the name suggests, is a secure domain that allows secure communication. This security is ensured, for example, by encrypting the communication content and / or by authentication between the application security domain and the communication partner at the beginning of the communication. Communication can occur, in particular, between the application security domain and a third-party applet provider. Securing communication implies, in particular, the ability to exclude unwanted potential communication partners, including the profile container and thus the specific network operator (MNO) under whose management the profile container is administered. Communication content can consist of third-party applets and installation commands to download and install these applets.This creates a participant identity module in which third-party applets can be loaded, installed and managed independently of a specific network operator (MNO).

[0027] In contrast to the solution from EP 3 484 198 A1, where the eUICC provides for a transversal security domain (TSD) that is independent of the profile SDs (profile security domains) from the outset, the application security domain according to the invention is created within a profile container. This allows communication between a third-party provider and the application security domain to take place via the infrastructure for provisioning the profile container with profiles and applets, in particular from the same profile server that supplies the profile container with profiles and profile management instructions. Therefore, the architecture according to the invention is particularly efficient. To ensure the confidentiality of the communication between the application security domain and the communication partner (e.g., a third-party applet provider), the communication is secured, for example, by authentication and / or encryption.

[0028] Therefore, according to claim 1, a subscriber identity module is created in which third-party applets can be efficiently installed and managed independently of a specific network operator (MNO).

[0029] The application security domain according to the invention can itself contain one or more subordinate sub-application security domains, which are configured so that applications can be installed and managed therein from the same profile server. Sub-application security domains can in turn contain sub-sub-application security domains, etc., so that a hierarchical structure of application security domains can be provided.

[0030] Managing an application can optionally include: updating the application, changing the application's status, such as activating or deactivating the application, or personalizing the application.

[0031] Preferably, the application security domain is configured so that applications can be loaded, installed, and managed within it from the profile server, independently of the profile container administrator. In other words, a profile administrator can load, install, and manage a profile within the profile container from the profile server. Similarly, applications can be loaded, installed, and managed within the application security domain from the profile server, but by an application administrator who is different from the profile administrator.

[0032] Alternatively, the independence of the application manager from the profile manager is achieved by securing the communication between the application security domain and the profile server, in particular through authentication and / or encryption.

[0033] Optionally, the participant identity module is further configured to use keys when loading, installing, and managing profiles and applications, whereby different keys are used when loading, installing, and managing profiles in profile containers than when loading, installing, and managing applications in the application security domains and, if applicable, sub-application security domains contained in the profile containers.

[0034] Optionally, keys compliant with GSMA SGP.22 Common Mutual Authentication are provided as keys for loading, installing, and managing profiles and applications, so that the authentication and key derivation procedure provided for in GSMA SGP.22 Common Mutual Authentication can be carried out when loading, installing, and managing profiles and applications.

[0035] Generally, symmetric or asymmetric keys can be used.

[0036] Optionally, a profile is installed in the profile container within the participant identity module. An application is installed in the application security domain, or optionally, multiple applications are installed there.

[0037] The application is configured to offer a service that differs from authentication via the mobile network. Optionally, this service can be a payment transaction service for processing electronic money transfers, or a ticketing service for managing electronic tickets or electronic admission tickets, or similar applications. Optionally, installable or installed applications, designed as applets, are implemented within the application security domain of the participant identity module, specifically as Java applets conforming to the Java Card standard.

[0038] A profile server SM-DP+ according to the invention is set up for this purpose. To load profiles into profile containers of participant identity modules in order to install and manage them there, and to load applications into application security domains contained in the profile containers, and optionally into sub-application security domains contained in the application security domains, in order to install and manage them there.

[0039] The profile server is optionally configured to use keys when loading profiles and applications, whereby different keys are used for loading, installing, and managing profiles in profile containers than for loading, installing, and managing applications in the application security domains and, if applicable, sub-application security domains contained in the profile containers. Brief description of the drawings

[0040] The invention will now be explained in more detail using exemplary embodiments and with reference to the drawing, which shows: Fig. 1 an eUICC architecture according to SGP.21 with the possibility of providing applets in eUICC, with applets directly in the profile container; Fig. 2 an eUICC architecture based on the alternative proposal discussed in the GSMA for housing applets in the eUICC, with an applet security domain alongside profile containers; Fig. 3 an eUICC architecture according to an embodiment of the invention, with an applet security domain in the profile container. Detailed description of implementation examples

[0041] Fig. 1 shows an eUICC architecture according to SGP.21 with the possibility of providing applets in eUICC, with applets directly in the profile container, where the profile manager is also the applet manager.

[0042] Fig. 2This shows an eUICC architecture based on the alternative proposal discussed in the GSMA for housing applets in the eUICC, with an applet security domain alongside profile containers, where a different server is required to manage the applet security domain than to manage the profile containers.

[0043] Fig. 3 Figure 1 shows an eUICC architecture according to an embodiment of the invention, with an applet security domain, as the application security domain ACSD according to the invention, in the profile container. More precisely, Figure 2 shows... Fig. 3 an eUICC with an operating system (OS), a profile package interpreter, a first profile container (ISD-P) and a second profile container (ISD-P 2), as well as a root container (ISD-R) and an optional common application security domain (CSD) similar to the one in Fig. 2The CSD shown is as follows. The first profile container, ISD-P, contains an applet security domain, ACSD, and an MNO security domain, MNO SD. Applet X is installed in the ACSD security domain and is managed by an applet administrator (for clarity, applet X is shown under the ACSD security domain). An applet and an MNO applet are installed in the MNO security domain, managed by a mobile network operator, MNO. The second profile container, ISD-P 2, has an inactive ACSD security domain in which no applets are currently installed. Furthermore, the second profile container, ISD-P 2, has an MNO security domain, MNO SD, containing an applet and an MNO applet, similar to the first security domain, ISD-P.The applet security domains ACSD in the first and second profile containers ISD-P, ISD-P 2, and the applet X installed in the applet security domain ACSD in the first profile container ISD-P, can be addressed (loaded, installed, managed, etc.) by the respective applet administrator from the profile server SM-DP+. Through authentication and encryption, the applet administrator's communication with their applet security domain ACSD is kept confidential from the mobile network operator (MNO) that operates the profile server.

Claims

1. Subscriber Identity Module (eUICC) for authentication of a mobile terminal device against a mobile network, - comprising at least one profile container (ISD-P) which is configured to allow a profile to be loaded, installed and managed therein by a profile server SM-DP+; - a mobile network operator security domain (MNO-SD), created in the profile container (ISD-P), in which a mobile network operator application is installed, - at least one application security domain (ACSD), created in the profile container (ISD-P), which is configured to allow applications to be loaded, installed and managed by the same profile server SM-DP+, - wherein an application is installed in the application security domain (ACSD), and - wherein the application is configured to offer a service that is different from authentication to the mobile network.

2. The subscriber identity module (eUICC) according to claim 1, wherein, in the application security domain (ACSD), at least one sub-application security domain is created, which is configured to allow applications to be loaded, installed and managed therein by the same profile server SM-DP+.

3. The subscriber identity module (eUICC) according to claim 1 or 2, configured to use keys with the loading, installing and managing profiles and applications, wherein different keys are used with the loading, installing and managing profiles in profile containers (ISD-P) than for loading, installing and managing applications in the application security domains (ACSDs), contained in the profile containers (ISD-P), and possibly sub-application security domains.

4. The subscriber identity module (eUICC) according to claim 3, wherein as keys, keys in accordance with GSMA SGP.22, Common Mutual Authentication are provided.

5. The subscriber identity module (eUICC) according to any one of claims 1 to 4, wherein a profile is installed in the profile container.

6. The subscriber identity module (eUICC) according to any one of claims 1 to 5, wherein the service is a payment transaction service for carrying out electronic money payments or a ticketing service for managing electronic traffic tickets or electronic admission tickets.

7. The subscriber identity module (eUICC) according to any one of claims 1 to 6, wherein the application security domain is configured such that the applications can be loaded, installed and managed therein by the profile server SM-DP+ independently of the manager of the profile container.

8. Profile server SM-DP+, configured - to load profiles into profile containers (ISD-P) of subscriber identity modules (eUICCs) in order to install and manage them therein, wherein a mobile network operator security domain (MNO-SD) is created in the profile container (ISD-P) in which a mobile network operator application is installed, and - to load applications into application security domains (ACSDs) contained in the profile containers (ISD-P), and optionally into sub-application security domains contained in the application security domains (ACSDs), to install them there, and to manage; - wherein the application is installed in the application security domain (ACSD), and - wherein the application is configured to offer a service that is different from an authentication to the mobile network.

9. The profile server SM-DP+ according to claim 8, configured to use keys when loading profiles and applications, wherein, when loading, installing and managing profiles in profile containers (ISD-P), different keys are used than for loading, installing and managing applications in the application security domains (ACSDs) contained in the profile containers (ISD-Ps) and possibly sub-application security domains.

10. The profile server SM-DP+ according to claim 8 or 9, wherein as keys, keys in accordance with GSMA SGP.22, Common Mutual Authentication are provided.

11. System, comprising a subscriber identity module (eUICC) according to any one of claims 1 to 7 and a profile server SM-DP+ according to any one of claims 8 to 10.