SECURE ELEMENT WITH ACCESS CONTROL APPLICATION ARA

Description

Field of the invention

[0001] The invention relates to a secure element, in particular a subscriber identity module (SIM) for operation in a mobile terminal, and an access control application, ARA application, by which the access of the mobile terminal to applications in the secure element is regulated.

[0002] Mobile (mobile radio-enabled) devices communicate via mobile networks. Classic mobile devices include smartphones and mobile phones. Mobile devices also include automotive telematics devices and control devices (control devices or 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) that can communicate 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 power consumers with end devices in the form of control devices.

[0003] For the use of a mobile device in a network operator's mobile network, the subscriber identity module operated in the mobile device contains one or more subscription profiles, or profiles for short. The profile manages the configuration of the device and its connection in the mobile network. The profile includes profile data that enables the establishment, operation, and termination of a connection of the device in the mobile network, for example, a cryptographic authentication key (Ki) and an International Mobile Subscriber Identity (IMSI). Furthermore, each profile can include applications.

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

[0005] The subscriber identity module can be designed in various form factors, including plug-in, embedded, integrated, and software. Subscriber identity modules in the plug-in and embedded form factors are located on a dedicated, separate chip or SoC (System-on-Chip). Examples of plug-ins are SIM cards (SIM = Subscriber Identity Module), USIM cards (Universal SIM), or UICC (Universal Integrated Circuit Card), and contact the terminal device via a card reader. Alternatively, the dedicated chip can be integrated into a housing that can be permanently soldered or soldered into the terminal device. A solderable or soldered subscriber identity module is designated "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 are integrated subscriber identity modules, which are integrated into a terminal device chip or SoC (System-on-Chip) of the terminal device, meaning they do not have their own chip. Integrated subscriber identity modules are designated with the suffix "integrated" and are referred to, for example, as integrated UICC, iUICC. Other possible form factors for a subscriber identity module are pure software modules with the functionality of a subscriber identity module, which are integrated into a terminal device chip.

[0006] Current operating systems for mobile devices, such as Android, allow access to the subscriber identity module (SIM access) at the application level via various APIs (API = Application Programming Interface), such as the OpenMobile API described in [3] [OM API] or the Device API described in [4] [Device API]. Several API classes are defined in [3], including the SE Service API. In addition, there is the Telephony API, which was defined by Google. State of the art

[0007] The document [1] [SEAC] GlobalPlatform Device Technology, Secure Element Access Control, Version 1.1, Public Release, September 2014, document reference GPD_SPE_013, describes access rules that govern a mobile device's access to applications in a secure element. In [1], a secure element is defined as a tamper-proof component used in a device to provide security, trustworthiness, and a multi-application environment. The form factor of the secure element can be, for example, that of a UICC (Universal Integrated Circuit Card) or eSE (embedded secure element).

[0008] The access rules from [1] are also applied in the context of subscriber identity modules.

[0009] Document [1] defines the Access Rule Application ARA implemented in the Secure Element.

[0010] Fig. 1Figure 2-1, taken from [1], shows a basic Secure Element with a single Issuer Security Domain (SD) and a single Access Rule Application Master (ARA-M). The Access Rule Application Master (ARA-M) controls the device's access to the Secure Element based on access rules, the Access Rules, using the Access Control Enforcer implemented in the device. Fig. 1 Figure 2-1 shows a typical UICC or SIM card with a fixed profile of a single network operator.

[0011] Fig. 2 shows the also taken from [1] Figure 2-2, which represents a Secure Element with an Issuer Security Domain (SD) and several Application Provider Security Domains. The Issuer Security Domain and each Application Provider Security Domain each contain an Access Rule Application ARA-M or ARA-C. The Access Rule Application (ARA application) Master ARA-M in the Issuer Security Domain (SGP.22: ISD-P) controls the device's access to the Secure Element, more precisely to the Issuer Security Domain, using the Access Control Enforcer implemented in the device, based on access rules of the issuer of the Secure Element. The respective Access Rule Application (ARA application) Client ARA-C controls the device's access to the respective Application Provider Security Domain (SGP.22: AP-SD under the ISD-P) based on access rules of the respective application provider.

[0012] Chapter 5 of document [1] provides that access rules can be managed via commands received by the secure element via Remote Application Management (RAM). In particular, new access rules can be saved to the secure element, deleted from the secure element, and modified and updated within the secure element using remote management. [1] proposes a secure communication channel, based on Global Platform specifications, for communication with the secure element. Remote Application Management (RAM) assumes that the commands for the access rules are sent from a remote server to the secure element.

[0013] Users of consumer devices such as smartphones with a subscriber identity module (eUICC) or mobile-enabled tablets often download applications, such as apps from app stores, to their devices. This can include downloading an application onto a device that is intended to access the subscriber identity module, but is denied access because the access rules (ARA Access Rules) of the ARA application in the subscriber identity module prohibit this.

[0014] Currently, the access rules for ISD-Ps and their profiles (i.e. in the model of [1] Application Provider Security Domains) are defined by the network operator (MNO) and can only be managed by the network operator through remote administration OTA (Over-The-Air), in particular newly stored in the subscriber identity module, deleted or modified.

[0015] Users sometimes change the number of apps from app stores on their devices very quickly and frequently. It would therefore be desirable for users to be able to adjust the access rules of the ARA application in the subscriber identity module themselves, depending on the applications currently installed on the device (especially apps from app stores).

[0016] For Secure Elements in other application areas, such as payment cards or digital payment solutions or identification documents in which an ARA application is used, there may also be a desire to enable the user to adapt ARA access rules.

[0017] The prior art document [5] EP2890171A1 discloses a method for enabling an access control enforcer provided in a mobile communication device to access access rules of an ARA master applet and ARA client applet provided in a secure element by means of specific commands.

[0018] Prior art document [6] EP2827274A1 discloses a method for enforcing access control of a device to a secure element hosted in the device, wherein the secure element, in response to an application-related request from the device to the secure element, grants the device access to those ARA access rules stored in a security domain to which the application belongs. Summary of the invention

[0019] The invention is based on the object of creating a secure element with an ARA application that enables flexible adaptation of the access options to SE applications in the secure element.

[0020] The object is achieved by a secure element according to claim 1. Advantageous embodiments of the invention are specified in the dependent claims.

[0021] The secure element according to claim 1 comprises an SE application implemented therein or is configured to implement an SE application therein, and further comprises: - an SE terminal interface to a terminal device in connection with which the secure element can be operated; - an ARA application and ARA access rules, by which access from applications implemented in the terminal device via the SE terminal interface to SE applications implemented or implementable in the secure element is regulated. The secure element is characterized by: an ARA user interface configured to: ** receive user commands entered by a user at a user interface provided on the terminal device or on the secure element; ** forward received user commands to the ARA application in the secure element; and ** cause the ARA application to apply forwarded user commands to the ARA application.

[0022] In contrast to previous management options for the ARA application, the user is not required to wait for a management action from a remote server and, if necessary, request this management action from the remote server. Instead, they can initiate a management action locally on their device via the ARA user interface. This allows the user to immediately react locally and adapt the ARA application accordingly if access requirements for the Secure Element's SE applications change on their device, for example, due to new applications being downloaded to the device.

[0023] Therefore, according to claim 1, a secure element is created which enables flexible adaptation of the access options to SE applications in the secure element.

[0024] In the context of the invention, the term terminal device is understood to include a device within the meaning of document [1] [SEAC].

[0025] The ARA user interface is specifically understood as a program code interface between program codes, which allows user commands to be sent to the ARA application. In contrast, the user interface is intended to receive user commands from the user. A typical user interface is the control element of a smartphone or tablet PC, such as a touch display, buttons, and / or voice input interfaces (microphone).

[0026] Optionally, the user commands are directed to managing ARA access rules, and applying the user command to the ARA application includes managing the ARA access rules according to the user commands.

[0027] One or more of the following administrative measures are optionally provided for as the administration: Creating a new ARA access rule; Saving a new ARA access rule in the Secure Element; Deleting an ARA access rule stored in the Secure Element; Changing, in particular updating to a newer version or otherwise changing, an ARA access rule stored in the Secure Element.

[0028] Optionally, management includes creating or adapting and saving an ARA access rule in the Secure Element for an application that has been newly loaded onto the device and for which no or no suitable ARA access rule exists in the Secure Element. The application can be downloaded to the device, in particular, from an app store.

[0029] The user interface can optionally be provided in the end device.

[0030] Optionally, the secure element is further configured to receive user commands from an ARA configuration application implemented in the terminal device that is coupled or can be coupled between the user interface and the ARA user interface.

[0031] In this embodiment, the ARA configuration application in the terminal device forwards the user commands to the ARA user interface of the secure element, and if necessary, converts them into instructions that can be interpreted (understood) by the ARA user interface. Specifically, the user command or instruction can instruct the ARA user interface to create a new ARA access rule and save it to the secure element, or to modify an existing ARA access rule.

[0032] Optionally, the user interface and the ARA configuration application are both implemented in the end device, and the ARA user interface in the secure element takes over the user commands from the ARA configuration application in the end device.

[0033] In particular, subscriber identity modules for mobile devices often do not have their own user interface, but instead accept user commands and other user inputs via the mobile device, either via SIM Toolkit commands or Card Toolkit commands. Alternatively, NFC SIM cards are also available as subscriber identity modules with their own contactless user interface, which a user can access without using the mobile device in which the subscriber identity module is operated. A corresponding embodiment is described below.

[0034] In particular, the ARA configuration application can be designed as an app for a mobile device, which can be downloaded from an app store, for example. Accordingly, the ARA configuration application can be operated by a user like any other app from an app store. The additional ARA configuration application enables the technical solution to be separated into a machine-oriented ARA user interface on the one hand and an intuitively operable ARA configuration application on the other. This separation has the advantage of increasing ease of use for the user. Further advantages that can be achieved with an ARA configuration application are described below.

[0035] The user interface can optionally be provided in the secure element and in such a way that a user can contact it directly, bypassing a terminal device with or in which the secure element is operated, for example as an NFC interface of the secure element.

[0036] Optionally, the Secure Element further includes an ARA configuration application that is coupled or can be coupled between the user interface and the ARA user interface and is configured to forward user commands to the ARA application. The ARA user interface and the ARA configuration application are optionally provided in the Secure Element. In particular, if the user interface is provided in the Secure Element, it can be a contactless interface such as an NFC interface. The ARA configuration application in the Secure Element can be either an application specifically loaded into the Secure Element or an application in the terminal device that uses the Telephony API or the SE Service API to perform a configuration in the ARA-M or ARA-C.

[0037] User commands that are transported across multiple applications can optionally be processed and / or modified by applications involved in the transport (e.g. by the ARA configuration application), and / or can be provided with additions such as hash values, signatures and the like.

[0038] Optionally, the secure element further comprises a timer configured to ensure that user commands received at the ARA user interface are only applied to the ARA application during a limited time interval and are no longer applied to the ARA application after the expiration of the time interval.

[0039] The timer is optionally generated and started by a Secure Element command, for example a SIM Toolkit command or Card Toolkit command, whereby the time interval is specified during which the timer runs until it expires. In this embodiment, commands received at the ARA user interface are applied to the ARA application from the time the timer is generated and within the time interval, and are not applied and / or forwarded outside the time interval, after the timer has expired. Within the time interval, for example, an ARA access rule can be generated for a newly loaded application on the terminal device and saved in the Secure Element. If a command to generate a new ARA access rule is received after the timer has expired, no ARA access rule will be generated. For this purpose, a new timer must be generated and started.

[0040] The ARA user interface can be designed as a standalone application. Alternatively, the ARA user interface, especially if provided in the end device, can be integrated into the ARA application, for example, as an additional functional program code module.

[0041] The ARA configuration application can be designed as a standalone application. Alternatively, the ARA configuration application, especially if provided in the end device, can be integrated into the ARA application, for example, as an additional functional program code module.

[0042] The Secure Element can optionally be designed as a subscriber identity module for operation in conjunction with (as a terminal device) a mobile device, whereby one or more of the following is or are provided as the SE application: a profile (subscription profile, in particular within the meaning of SGP.22); an application associated with a profile; an application implemented or implementable in the secure element independently of a profile.

[0043] Applications that are associated with a profile or independent of a profile can be applications in the mobile communications field or applications outside the mobile communications field, such as payment applications or identity applications.

[0044] The invention comprises a station according to claim 8. The station comprises a secure element and a terminal, in particular a mobile terminal.

[0045] The terminal device optionally includes the user interface, where the user commands are entered, and the ARA configuration application.

[0046] A method according to the invention according to claim 10 for managing a secure element is characterized by the steps: at an ARA user interface: ** receiving a user command entered by a user at a user interface of the terminal device or the secure element; ** forwarding the received user command to the ARA application; and ** causing the ARA application to apply the forwarded user command to the ARA application; ** by the ARA application, in response to the causing, applying the user command.

[0047] Optionally, the user command is directed to managing ARA access rules, whereby the application of the user command includes managing the ARA access rules, whereby the managing is intended to include one or more of the following administrative actions: Creating a new ARA access rule; Saving a new ARA access rule in the secure element; Deleting an ARA access rule stored in the secure element; Modifying an ARA access rule stored in the secure element.

[0048] A method according to the invention according to claim 12 for managing a station comprises Downloading a target application to the terminal device; managing a secure element according to the invention, including managing ARA access rules; wherein managing the ARA access rules comprises: ** generating a new ARA access rule for the target application, by which, in particular, the target application is allowed access to SE applications of the secure element according to the generated new ARA access rule; and ** storing the generated new ARA access rule in the secure element.

[0049] Alternatively, the ARA access rules can be managed using an ARA configuration application, as described above.

[0050] Optionally, the ARA configuration application provides the option to register target applications in the ARA configuration application. A registered target application can be granted either fixed or configurable permissions. For example, only target applications registered with the ARA configuration application are granted permission to receive an ARA access rule that grants the target application access to SE applications of the Secure Element.

[0051] Optionally, when registering a target application in the ARA configuration application, authentication of the target application with the ARA configuration application is required.

[0052] The registration of the target application can be done, for example, using a hash value of components of the target application, or using an applet identifier such as an AID of the target application.

[0053] A key advantage of the invention is that the user can actively influence the ARA access rules via the local ARA user interface, particularly locally on their device. An additional ARA configuration application can enable additional functionalities and increase user convenience. As an extension, the ARA user interface can provide the option of initiating ARA access rule management via remote OTA (Over-The-Air). If ARF access rule files according to [1] SEAC are used in the Secure Element file system, remote management can be implemented, particularly in the form of remote file management. Short description of the drawings

[0054] In the following, the invention is explained in more detail using exemplary embodiments and with reference to the drawing, in which: Fig. 1: a basic Secure Element with a single Issuer Security Domain (SD) and a single Access Rule Application Master (ARA-M), according to the prior art [1], Figure 2-1; Fig. 2: a Secure Element with an Issuer Security Domain (SD) with an Access Rule Application (ARA-M), and multiple Application Provider Security Domains, each with an Access Rule Application (ARA-C), according to the prior art [1], Figure 2-2; Fig. 3 shows possible applications of the invention to typical implementations of ARA applications according to [1] in an eUICC according to [2]; Fig. 4 shows a detailed view of a terminal device and a secure element with a security domain SD with an ARA application, according to several embodiments of the invention; Fig. 5 shows a flowchart illustrating a method for managing a secure element, comprising managing ARA access rules in response to a user command, according to embodiments of the invention; Fig. 6 shows a flowchart illustrating a method for managing a secure element, comprising managing ARA access rules in response to a user command using an ARA configuration application, according to embodiments of the invention. Detailed description of implementation examples

[0055] Fig. 1 and 2show two configurations of ARA applications from prior art document [1] that are suitable for applying the invention. The other configurations of ARA applications shown in [1] are also suitable for applying the invention.

[0056] Fig. 3 shows possible applications of the invention to typical implementations of ARA applications according to [1] in (as secure element) an eUICC according to [2]. Fig. 3 shows in more detail a single profile P of an eUICC, based on Figure 3from [2], SGP.22, supplemented by an ARA application Master ARA-M implemented in the network operator security domain MNO-SD, and ARA applications Client ARA-C arranged in the sub-security domains. According to embodiments of the invention, an ARA user interface ARA-UI is implemented in the network operator security domain MNO-SD. According to embodiments of the invention, an ARA user interface ARA-UI is implemented in the applet security domain Applet. According to embodiments of the invention, an ARA user interface ARA-UI is implemented in the SSD security domain SSD. According to embodiments of the invention, an ARA user interface ARA-UI is implemented in the CASD (Controlling Authority Security Domain).In the further subordinate or other security domains, such as FileSystem (file system), NAAs (Net Access Applications), ARA user interface ARA-UI can also be implemented according to embodiments of the invention.

[0057] Fig. 4shows a detailed view of a terminal device DEV / ME and a Secure Element SE / SIM with a Security Domain SD with an ARA application, according to several embodiments of the invention. The terminal device DEV / ME contains an Access Control Enforcer ACE according to [1] [SEAC]. The Secure Element SE / SIM contains an ARA application ARA-X, which, depending on the type of Issuer Security Domain ISD, can be an ARA-M, ARA-C, or ARA-D application according to [1] [SEAC]. According to the invention, the Secure Element contains an ARA user application ARA-UI. An interface DEV-SE-IF or ME-SIM-IF is provided between the terminal device DEV / ME and the Secure Element SE / SIM for communication between the terminal device DEV / ME and the Secure Element SE / SIM.

[0058] The DEV / ME terminal device has a user interface (UI) (in particular, D-UI or ME-UI) through which a user can enter inputs. The user interface (UI) can, for example, be a touch display, a keyboard, or one or more buttons, or a combination of a touch display, keyboard, and / or one or more buttons.

[0059] According to some embodiments, user inputs at the user interface UI are forwarded to the Secure Element SE / SIM via an STK application (STK = SIM Toolkit) or CTK application (CTK = Card Toolkit) of the terminal device DEV / ME, and in doing so are forwarded directly to the ARA user application ARA-UI.

[0060] According to some embodiments, the terminal device DEV / ME further contains an ARA configuration application (ARA-Config-App). In these embodiments, user inputs at the user interface (UI) are forwarded, for example, to the ARA configuration application (ARA-Config-App). The ARA configuration application (ARA-Config-App) makes the user inputs available to the ARA application (ARA-X) in the Secure Element SE / SIM and interacts with the Access Control Enforcer (ACE) of the terminal device DEV / ME.

[0061] According to some embodiments, Fig. 4 Any end device DEV with any Secure Element SE is represented. In the Issuer Security Domain ISD, an ARA application ARA-X corresponding to the type of ISD is provided.

[0062] According to some embodiments, Fig. 4a mobile terminal ME as defined in [2] [SGP.22], and a subscriber identity module or eUICC SIM as defined in [2] [SGP.22]. In these embodiments, an MNO-SD is provided in the secure element as the security domain SD, in which an ARA application Master ARA-M according to [1] is provided. According to some embodiments, a subdomain SSD (Supplementary Security Domain) of a profile P is provided in the secure element as the security domain SD, wherein an ARA application Client ARA-C according to [1] is provided in the SSD.

[0063] Fig. 5shows a flowchart illustrating a method for managing a Secure Element SE / SIM, comprising managing ARA access rules in response to a user command, according to embodiments of the invention. The method is exemplified using a terminal device that is a mobile terminal device ME in the form of a smartphone. A SIM toolkit application STK-App is implemented in the terminal device ME. The Secure Element SE / SIM is designed as a subscriber identity module SIM (eUICC). An ARA application ARA-X and ARA access rules for the ARA application ARA-X are implemented in the Secure Element SE / SIM. An ARA user interface ARA-UI is also implemented in the Secure Element SE / SIM.

[0064] According to Fig. 5The user visits an app store using the touch display and, if applicable, buttons on their smartphone, the user interface (UI) of the ME device, and sends a request to the app store to download a specific app to the ME device, hereinafter referred to as the target app. The target app is downloaded from the app store to the ME device. The target app would require access to applets (SE applications) of the Secure Element SE of the ME device, but does not have this access because the newly downloaded target app is not registered in the ARA access rules (Access Rule Application) of the ARA application (Access Rule Application).

[0065] According to some embodiments of the invention, the ARA application does not allow direct editing of ARA access rules by the user, but requires that the user first unlocks the ARA application for editing.

[0066] According to embodiments of the invention, the ARA application allows the user to activate the ARA application for processing using a SIM toolkit command, or in the case of a general Secure Element Card toolkit command. For example, the user sends a SIM toolkit command Timer (time specification) to the ARA user interface ARA-U1 via the user interface UI of the terminal device. The SIM toolkit command Timer (time specification) causes the ARA user interface ARA-UI to generate an ARA access rule ARA-ALLOW, which allows the processing of ARA access rules during a time interval specified by "time specification." "Time specification" can, for example, be a period of 1 to 10 minutes, for example, five minutes. The ARA user interface ARA-UI sends the ARA access rule ARA-ALLOW to the ARA application ARA-X. However, the procedure can also run without the timer (without the dashed arrows in the figure).

[0067] The user now launches the downloaded target app. The target app or the user sends a request to manage the ARA access rules to the ARA user interface. The request requests that the target app be granted access to SE applications (either all or only specific SE applications) of the Secure Element SE. The ARA user interface (ARA-UI) creates an ARA access rule that grants the target app the requested access to the Secure Element and sends the ARA access rule to the ARA application (ARA-X). The ARA application (ARA-X) enters the newly generated ARA access rule sent by the ARA user interface (ARA-UI) into the ARA access rules. The target app then has access to the Secure Element SE, as specified in the new ARA access rule.

[0068] The access to SE applications of the Secure Element SE requested with the user command and specified in the ARA access rule can optionally include all SE applications or only certain specified SE applications.

[0069] Fig. 6 shows a flowchart illustrating a method for managing a Secure Element SE, comprising managing ARA access rules in response to a user command using an ARA configuration application ARA-Config-App, according to embodiments of the invention.

[0070] Compared to the procedure from Fig. 5 is in the process of Fig. 6 In the ME terminal, an ARA configuration application, ARA-Config-App, is also provided. The processes up to the download of the target app are carried out, for example, as in the example from Fig. 5 .

[0071] The optional timer can be used as per the procedure according to Fig. 5using the SIM Toolkit application STK-App or Card Toolkit application CTK-App, as shown in Fig. 5 described, or alternatively set by the ARA configuration application ARA-Config-App, otherwise analogous to the Fig. 5 described timer. However, the procedure can also run without the timer (without the dashed arrows in the figure).

[0072] After downloading the target app, the ARA configuration application ARA-Config-App is started on the ME end device, for example, by the user by entering something at the UI user interface. Optionally, the ARA configuration application ARA-Config-App is displayed as a selectable app (e.g., as an icon or widget) on the ME end device's display, allowing the user to start it like any other app on the ME end device. Using the ARA configuration application ARA-Config-App on the ME end device, the user requests that an ARA access rule be created for the newly downloaded target app at the ARA user interface ARA-UI of the Secure Element SE. The target app does not necessarily have to be started yet, but it can be. The ARA user interface ARA-UI creates an ARA access rule that grants the target app the requested access to the Secure Element SE and sends the ARA access rule to the ARA application ARA-X.The ARA application ARA-X enters the newly generated ARA access rule sent by the ARA user interface ARA-UI into the ARA access rules. The target app then has access to the Secure Element SE as defined in the new ARA access rule.

[0073] At the latest, the target app is now started. According to another embodiment, after downloading the target app, the target app is started, and if necessary, the ARA configuration app ARA-Config-App is started by the target app, and then the method is carried out as described above with reference to Fig. 6 described to grant the target app access to the desired SE applications of the Secure Element SE. Cited documents

[0074] [1] SEAC] GlobalPlatform Device Technology, Secure Element Access Control, Version 1.1, Public Release, September 2014, Dokument-Referenz GPD_SPE_013; [2] [SGP.22] GSMA SGP.22 RSP Technical Specification, Version 2.2.2, 05 June 2020; [3] [OM API] GlobalPlatform Technology, Open Mobile API Specification, Version 3.3, Public Release July 2018, Document Reference: GPD_SPE_075; [4] [Device API] GlobalPlatform Device Technology, Device API Access Control, Version 1.0, Public Release November 2017, Document Reference: GPD_SPE_068; [5] EP 2 890 171 A1; [6] EP 2 827 274 A1.

Claims

1. Secure element (SE / SIM) comprising an SE application implemented therein or configured to implement an SE application therein, and further comprising: - an SE terminal interface to a terminal (DEV / ME), in conjunction with which the secure element (SE / SIM) can be operated; - an ARA application (ARA-X / M / C) and ARA access rules, by means of which access operations from applications implemented in the terminal (DEV / ME) to SE applications implemented or able to be implemented in the secure element (SE / SIM) via the SE terminal interface are controlled; characterized by: - an ARA user interface (ARA-UI), which is configured: ** to receive user commands that are entered by a user on a user interface (D / ME-UI; SE / SIM-UI) provided on the terminal (DEV / ME) or on the secure element (SE / SIM); ** to forward received user commands to the ARA application (ARA-X / M / C); and ** to prompt the ARA application (ARA-X / M / C) to apply forwarded user commands to the ARA application (ARA-X / M / C).

2. Secure element (SE / SIM) according to Claim 1, wherein the user commands are designed to manage ARA access rules, and the application of the user command to the ARA application (ARA-X / M / C) comprises the management of the ARA access rules, wherein one or more of the following management measures is or are provided as the management: - generating a new ARA access rule; - storing a new ARA access rule in the secure element (SE / SIM) ; - deleting an ARA access rule stored in the secure element (SE / SIM); - changing an ARA access rule stored in the secure element (SE / SIM).

3. Secure element (SE / SIM) according to Claim 1 or 2, further configured: - to receive the user commands from an ARA configuration application (ARA-Config-App) implemented in the terminal device (DEV / ME), which is or is able to be coupled between the user interface (D / ME-UI) and the ARA user interface (ARA-UI).

4. Secure element according to Claim 1 or 2, further comprising: - an ARA configuration application (ARA-Config-App) which is or is able to be coupled between the user interface (SE / SIM-UI) and the ARA user interface (ARA-UI) and is configured to direct user commands to the ARA application (ARA-X / M / C).

5. Secure element (SE / SIM) according to any one of Claims 1 to 4, further comprising - a timer, which is configured to cause user commands received at the ARA user interface (ARA-UI) to be applied to the ARA application (ARA-X / M / C) only during a limited time interval and no longer to be applied to the ARA application (ARA-X / M / C) after the time interval has expired.

6. Secure element (SE / SIM) according to Claim 5, wherein the timer is configured to be started by an elementary secure element command entered in the secure element (SE / SIM), in particular by a Card Toolkit command or SIM Toolkit command.

7. Secure element (SE / SIM) according to any one of Claims 1 to 6, designed as a subscriber identity module (SIM) for operation in conjunction with, as a terminal (DEV / ME), a mobile terminal (ME), wherein one or more of the following is or are provided as an SE application: - a profile; - an application associated with a profile; - an application that is or is able to be implemented in the secure element independently of a profile.

8. Station comprising a secure element (SE / SIM) according to any one of Claims 1 to 7, and a terminal (DEV / ME), in particular a mobile terminal (ME).

9. Station according to Claim 8, in conjunction with Claim 4, wherein the terminal (DEV / ME) comprises the user interface (D / ME-UI), on which the user commands are entered, and which comprises the ARA configuration application (ARA-Config-App).

10. Method for managing a secure element (SE / SIM) according to any one of Claims 1 to 8, - the secure element (SE / SIM) comprising an SE application implemented therein or configured to implement an SE application therein, and further comprising: - an SE terminal interface to a terminal (DEV / ME), in conjunction with which the secure element (SE / SIM) can be operated; - an ARA application (ARA-X / M / C) and ARA access rules, by means of which access operations from applications implemented in the terminal (DEV / ME) to SE applications implemented or able to be implemented in the secure element (SE / SIM) via the SE terminal interface are controlled; the method being characterized by the steps: - on an ARA user interface (ARA-UI): ** receiving a user command that is entered by a user on a user interface (D / ME-UI; SE / SIM-UI) of the terminal (DEV / ME) or the secure element (SE / SIM); ** forwarding the received user command to the ARA application (ARA-X / M / C); and ** prompting the ARA application (ARA-X / M / C) to apply the forwarded user command to the ARA application (ARA-X / M / C); ** applying the user command by means of the ARA application (ARA-X / M / C), in response to the prompting.

11. Method according to Claim 10, wherein the user command is designed to manage ARA access rules, and wherein the application of the user command comprises the management of the ARA access rules, wherein one or more of the following management measures is or are provided as the management: - generating a new ARA access rule; - storing a new ARA access rule in the secure element (SE / SIM); - deleting an ARA access rule stored in the secure element (SE / SIM); - changing an ARA access rule stored in the secure element (SE / SIM).

12. Method for managing a station according to Claim 8 or 9, comprising managing the secure element (SE / SIM) by means of a method according to Claim 10 or 11; - further comprising downloading a target application to the terminal (DEV / ME); - wherein managing the ARA access rules comprises: ** generating a new ARA access rule for the target application, by means of which the target application in particular is allowed access to SE applications of the secure element (SE / SIM) according to the generated new ARA access rule; and ** storing the generated new ARA access rule in the secure element (SE / SIM).

13. Method according to Claim 12, further comprising registering and / or authenticating the target application with respect to the ARA user interface (ARA-UI) or, if applicable, the ARA configuration application (ARA-Config-App), wherein the management comprises: - verifying the registration and / or authentication of the target application by means of the ARA user interface (ARA-UI) or, if applicable, the ARA configuration application (ARA-Config-App), - generating a new ARA access rule for the target application only if the registration and / or authentication is successfully verified.