Offline scripts for remote file management

Abstract

The invention relates to a method, device and system for performing a remote file management, RFM, operation at a secure element, SE. A secure file update script is received at an Offline RFM Agent located within the SE from an off-card entity, OCE. The secure file update script has been generated offline by a SE issuer managing the OCE using a distributed remote file management, DRFM, platform and comprises a plurality of remote management commands for implementing file management operations on the SE. In a further step, a security level authentication between the OCE and the SE is performed based on the secure file update script. If the security level authentication is successful, in a subsequent step, a secure channel session between the OCE and the SE is established by the Offline RFM Agent. Finally, the plurality of remote management commands are processed to remotely manage a file system on the SE.

Description

TECHNICAL FIELD

[0001] The present application relates generally to mobile communications, and in particular to a method and device for offline creation of a remote file management script for subscription management of a mobile terminal comprising a secure element, such as a Subscriber Identity Module (SIM), Universal Integrated Circuit Card (UICC), etc. BACKGROUND

[0002] Communicating via a Public Land Mobile Network (PLMN, also referred to herein as a mobile or cellular communication network) operated by a Mobile Network Operator (MNO) by means of a mobile terminal, such as a mobile phone, typically requires the mobile terminal to be equipped with a secure element (SE) for securely storing data uniquely identifying a user (also referred to as a subscriber) of the mobile terminal. The secure element is essentially a microprocessor chip that can store sensitive data and run secure applications, such as payment, transportation or telecommunication applications.

[0003] In the context of a mobile terminal configured to communicate according to the Global System for Mobile Communications (GSM), the secure element is referred to as a Subscriber Identity Module (SIM) or Universal Integrated Circuit Card (UICC), and is typically provided in the form of a smart card. As specified in the GSM standard, the SIM contains subscriber credentials for authenticating and identifying a user of the mobile terminal, including in particular an International Mobile Subscriber Identity (IMSI) and authentication keys. These subscriber credentials (IMSI and related keys) are typically stored on the SIM by the SIM manufacturer / supplier or the MNO during a SIM personalization process, before the SIM is provided to the user of the mobile terminal. The subscription credentials are used to identify and authenticate the subscriber on the mobile terminal to attach to the MNO network.

[0004] Figure 1 An example of a SIM / UICC file system structure 100 conforming to the ETSI 102 221 V11.0.0 smart card standard specification is shown. The file system resides in the EEPROM of the smart card and comprises a master file (MF) 110 as the root of the file system, a plurality of dedicated files (DFs) or directories 122, and elementary files (EFs) 121. An application DF (ADF) 120 is a specific DF containing all DFs and EFs of an application.

[0005] Similar to the file system, the secure element can contain secure applications, which can be intended for multiple use cases, such as building access control, transportation ticketing or payment schemes.

[0006] One particular field of application of secure elements is M2M (Machine-to-Machine) communication, i.e. communication between machines through a cellular communication network without human intervention. In M2M communication, data is automatically transmitted between many different types of machines equipped with secure elements in the form of M2M modules, such as TV systems, set-top boxes, vending machines, vehicles, traffic lights, surveillance cameras, sensor devices, etc. M2M devices can be provided with an embedded Universal Integrated Circuit Card (eUICC). The eUICC performs similar functions to those performed by a Subscriber Identity Module (SIM) card in a personal wireless device. However, the eUICC is not easily removable as it is embedded in the device, for example soldered to the device's circuit board.

[0007] For some of these devices, it is not possible or at least very difficult to provision the secure element in advance with the necessary subscription credentials (including for example an IMSI), as the secure element will most likely be implemented in the form of a surface mount chip. Therefore, these devices and their non-personalized secure elements need to be provisioned with subscription credentials over the air once deployed in the field.

[0008] Over-The-Air (OTA) is a technology that allows a SE issuer (or owner of the SE) to update or change data in the SE without having to reissue a new sample. In particular, OTA technology provides functions for updating the directory and files of a SIM / UICC / eUICC card (Remote File Management, RFM) and for managing applications on the SE (Remote Application Management, RAM).

[0009] The GlobalPlatform Card Technology Specification establishes a global standard for card and / or secure element issuers to be implemented within a smart card. Among others, a Secure Channel Protocol (SCP) is defined as a communication mechanism between an off-card entity (OCE) that can be managed by the SE issuer and the card (or SE) that provides a certain level of assurance to one or both entities. A new Secure Channel Protocol has recently been introduced in the GlobalPlatform Technical Secure Channel Protocol '11' Card Specification, which is referred to as Secure Channel Protocol '11' (SCP11), which is based on Elliptic Curve Cryptography (ECC) for mutual authentication and secure channel initiation.

[0010] Different types of Secure Channel Protocol (SCP) are defined in the GlobalPlatform specification, namely authentication based on symmetric cryptography and authentication based on asymmetric cryptography. In the first case, the authenticated off-card entity is the one knowing the secret Secure Channel Key required to initiate a secure channel session. For example, DES-based SCP02 (considered as deprecated), AES-based SCP03 or DES or AES-based SCP80, which is one of the most common SCPs used for OTA operations. In the case of authentication based on asymmetric cryptography, any off-card entity possessing a pair of asymmetric keys and having its public key certified by a certificate issued by an authority recognized by the SE can be successfully authenticated. Protocols following this authentication include for example RSA-based SCP10, or ECC-based SCP11. SCP11 has three different variants for different purposes. SCP11a provides mutual authentication between the off-card entity (OCE) and the card. SCP11b provides only the card's authentication to the OCE. SCP11c (also known as Distributed Secure Element Management (DSEM)) provides mutual authentication between the OCE and the card, only using a static key to authenticate the card.

[0011] In general, SCP11 and its variants are intended to be used for card content management defined by GlobalPlatform, such as installing new applications on the SE, updating application content, etc. All of these are based on the Elliptic Curve Key Agreement Algorithm (ECKA) defined in BSI TR-03111 "BSI Technical Guideline TR-03111: Elliptic Curve Cryptography" version 2.0. Each variant uses a different scheme according to the specification NIST 800-56A "Recommendation for Pair- wise Key Establishment Schemes Using Discrete Log Cryptography" revision 2.

[0012] The existing RFM solutions defined in the current standards have some constraints, which means a considerable economic cost to build and set up an OTA-based solution. A complex key management system has to be provided to manage the various SE keys in a secure way. As a result of the Secure Channel Protocol (SCP) involved in the end-to-end secure communication between the OTA platform and the SE, a separate OTA script should be generated for each SE. This is not only because of the separate keys, but also because of other SCP parameters, such as the SCP80 OTA counter, which can differ depending on the SE state. Therefore, the script provided by the SE issuer to update the SE is a separate OTA script, as the same script can only be executed once by one single SE and cannot be reused by any other SE. Moreover, an online OTA platform with a specific guaranteed availability (e.g. 99.997%) has to be established and deployed to handle multiple requests.

[0013] It is therefore desirable to provide a solution that would enable SE issuers and / or off-card entities (OCEs) to remotely update SE file systems without the need for an online OTA platform system and allow SE issuers / OCEs to send the same script to several SEs. SUMMARY

[0014] The application solves the above-mentioned objects by the subject matter covered by the independent claims. Preferred embodiments of the application are defined in the dependent claims.

[0015] According to a first aspect of the application, a method for performing remote file management, RFM, operations at a secure element, SE, by a proxy OfflineRFM Agent, the OfflineRFM Agent being located within the SE, is provided. The method comprises the step of receiving a secure file update script from an off-card entity, OCE, the secure file update script comprising a plurality of remote management commands for implementing file management operations on a secure element. In a further step, a security level authentication of the OCE and the SE is performed based on a security level of the secure file update script. If the authentication is successful, a secure channel session between the OCE and the SE is established in a subsequent step. Finally, the plurality of remote management commands is processed to manage a file system on the SE.

[0016] The OfflineRFM Agent is an application installed in the SE and acts as a proxy between the OCE (and respectively the SE issuer managing the OCE) and the SE file system and allows to remotely perform file management operations in a secure manner. The OTA platform does not need to be maintained by the SE issuer, thereby reducing the complexity of the infrastructure for remote file management operations. As the same secure file script can be used to perform file management operations at several secure elements, SEs, the SE issuer is provided with a method for updating several SEs in a fast and efficient manner.

[0017] In some embodiments of the application, the method is implemented using a secure channel communication protocol, in particular a secure channel communication protocol providing mutual authentication based on a pair of temporary keys of the OCE.

[0018] Preferably, the secure channel communication protocol used is the SCP11c version defined in GlobalPlatform Card Technology Specification Revision F.

[0019] The use of the SCP11c variant of the secure channel protocol, SCP11, allows for offline scripting, i.e. the creation of a secure command sequence offline.

[0020] In some embodiments, the OfflineRFM Agent receives the secure file update script by a plurality of messages from the OCE, each message comprising one command from the plurality of remote management commands.

[0021] In some embodiments of the application, performing the security level authentication comprises checking whether the security file update script's security level is set to authenticated.

[0022] In some embodiments of the application, the method further comprises rejecting the security file update script if the security level is not authenticated.

[0023] This ensures that the authentication security level requested in the GlobalPlatform Card Technical Specification is guaranteed by the OfflineRFMAgent. In particular, any script to be processed by the OfflineRFMAgent should preferably be sent at least in the case where the security level is authenticated. Otherwise, it will be rejected by the OfflineRFMAgent.

[0024] In some embodiments of the application, the security file update script comprises at least a PERFORM SECURITY OPERATION command and a MUTUAL AUTHENTICATE command, wherein the PERFORM SECURITY OPERATION command comprises an OCE certificate and the MUTUAL AUTHENTICATE command comprises a temporary public key of the OCE.

[0025] A simplified remote file management solution is provided herein, since the OfflineRFMAgent does not need to implement the full SCP11 logic, but only supports the reception and processing of the main SCP11 c APDU commands (PERFORM SECURITY OPERATION and MUTUAL AUTHENTICATE). In particular, the PERFORM SECURITY OPERATION command is used to submit an OCE certificate, which contains the public key of the OCE and is used for key agreement, and to determine the security level required for all subsequent commands. This is required as a prerequisite to initiate an SCP11 C secure channel session. The MUTUAL AUTHENTICATE command is used to send a temporary public key of the OCE to the secure domain by the OfflineRFMAgent to trigger the key establishment and to provide the card authentication information to the OCE.

[0026] Preferably, establishing the secure channel session comprises requesting, by the OfflineRFMAgent, a secure domain (SD) located at the operating system OS of the secure element, to perform a security operation for verifying the OCE certificate, and preferably also comprises requesting the secure domain to extract the public key from the OCE certificate, and then during the mutual authentication operation, requesting the SD to perform the key agreement process.

[0027] The secure domain SD is an entity within the card that provides support for the control, security and communication requirements of the card external entities. Preferably, the OfflineRFMAgent according to the application is configured to request such support from the corresponding SD of the secure element SE.

[0028] In particular, the Offline RFM Agent will forward the execute secure operation and mutual authentication commands to the associated secure domain through the Java Card Global Platform API in order to process the commands.

[0029] In some embodiments of the application, the secure file update script further comprises a SELECT command instructing a remote management application for executing remote management commands on a file system of the secure element during the established secure channel session, and wherein the Offline RFM Agent processes the SELECT command without closing the established secure channel session.

[0030] This prevents what usually happens when using a SELECT command within an established session, i.e. closing the session and thus interrupting any further communication with the SE.

[0031] In some embodiments of the application, processing the plurality of remote management commands comprises creating and / or updating the content of the file system on the secure element by using a file access application programming interface.

[0032] According to a second aspect of the application, there is provided an Offline Remote File Management, RFM, Agent, Offline RFM Agent, located at a secure element, SE. The Offline RFM Agent comprises means for receiving a secure file update script from an Off Card Entity, OCE, the secure file update script comprising a plurality of remote management commands for implementing file management operations on the secure element; means for performing a security level authentication of the OCE with the SE based on a security level of the secure file update script; means for establishing a secure channel session between the OCE and the SE if the security level authentication is successful; and means for processing the plurality of remote management commands for managing a file system on the SE by invoking corresponding methods.

[0033] In some embodiments of the application, the Offline RFM Agent is configured to perform the method according to the first aspect or the method according to any one of the preferred embodiments of the first aspect.

[0034] In some embodiments of the application, the Offline RFM Agent comprises an access domain configuration defining at least one access domain parameter for controlling an application instance to the file system of the SE and / or an application provider identifier defining an ownership relationship between the Offline RFM Agent and the secure element, wherein the value of the application provider identifier corresponds to a subject identifier in the OCE certificate used during the authentication process.

[0035] This guarantees proper access to the file system on the SE to the OfflineRFMAgent for successful execution. This avoids the need to verify the PIN, as the PIN is usually diversified and thus impossible to embed in the DSEM script.

[0036] In some embodiments, the OfflineRFMAgent further comprises means for restricting the execution of a set of remote management commands, in particular the set comprising verifying a PIN / PUK, changing a PIN / PUK, disabling a PIN / PUK, enabling a PIN / PUK, and unblocking a PIN / PUK.

[0037] SCP 11 c allows the generation of offline built static scripts, and it is possible that these scripts can be executed several times. But SCP 11 c does not provide forward secrecy, as only the OCE ephemeral key is used. Any script including a command to update the PIN / PUK value will continuously fail at any time the command is executed, as the original PIN / PUK value has been updated. Therefore, some commands are restricted to be executed during the SCP 11 c session. Moreover, by configuring the OfflineRFMAgent with means for restricting the execution of a remote management command, it is possible to easily disable sensitive commands such as PUT KEY or SET STATUS, which are not allowed by the GlobalPlatform card specification of the SCP 11 c protocol.

[0038] In some embodiments of the application, the OfflineRFMAgent further comprises an application provider identifier defining the ownership relationship between the OfflineRFMAgent and the secure element, wherein the value of the application provider identifier corresponds to the subject identifier in the OCE certificate used during the authentication process.

[0039] This ensures the necessary level of security, in particular the level of security of the authentication, which is implemented by the OfflineRFMAgent.

[0040] According to a third aspect of the application, there is provided a decentralized remote file management, DRFM, platform for offline generation of secure file update scripts for a plurality of secure elements, SEs. The platform comprises a memory for storing credentials of an off-card entity, OCE, and a processor for generating secure file update scripts. The processor is configured to receive a file update script from an SE issuer; to protect the file update script using the credentials stored in the memory to obtain a secure file update script; and to send the secure file update script to the SE issuer.

[0041] Preferably, for each OCE, the credentials comprise a static OCE key pair and an ephemeral key pair.

[0042] Preferably, the secure file update script further comprises a card group ID identifying the plurality of SEs having the same OCE credential.

[0043] The DRFM platform provides the means for protecting the script content provided by the SE issuer with the SCP11c key of the targeted SE, however this means has a much simpler structure than the regular OTA platform, as only two key pairs of the OCE are used. Moreover, as the process of protecting the script content is only done once for all SEs identified by a card group ID, the same secure file update script can be deployed into any of these SEs. In other words, in case the content is the same for all SEs, the process of protecting the script content will only happen once. Otherwise, if the content is diversified and unique for each SE, this process should be repeated for each individual content. In the same way, for each card group ID defined during the SE personalization, the process of protecting the script content should be repeated.

[0044] The main function of the DRFM platform is to store and manage the DSEM (i.e. SCP11c) credentials and the offline script preparation. The two functions can be implemented by a single entity or split between different entities in charge of each function. As the DSEM credentials are shared by a plurality of SEs and in particular by all SEs having the same card group ID, the key management in this case is much simpler than the traditional key management performed by the Trusted Service Management (TSM). Moreover, with the card group ID, it is possible to define a target group of cards or SEs to which an application specific script is applied. This can be specific to MNOs with different profile configurations. In this case, the DRFM platform allows to build scripts that are only suitable for a single profile configuration defined by his card group ID (according to [GPAmdF]). At the same time, the availability of scripts broadcasted across all SEs sharing the same credential is supported. This gives a huge flexibility in terms of script handling.

[0045] The DRFM platform can be an offline platform that generates on-demand offline scripts based on input data and a target group of SEs. Once the script is generated by the DRFM platform, it can be delivered to the SEs by any means, for example through the Internet to a smartphone application that subsequently forwards it to the SEs.

[0046] In particular, according to the second aspect of the application, the secure file update script can be delivered to the target group of SEs via a respective OfflineRFM Agent. In particular, the OfflineRFM Agent is an application, such as a Java Card application, installed in the SEs that receives and processes the secure file update script command by command.

[0047] According to a fourth aspect of the application, a decentralized remote file management system is provided. The decentralized remote file management system comprises a secure element SE issuer, an off-card entity OCE, a decentralized remote file management DRFM platform according to the third aspect of the application, and at least one secure element SE. The SE comprises an OfflineRFM Agent according to the second aspect of the application. The SE issuer is configured to obtain a secure file update script comprising a plurality of remote file management commands from the DRFM platform and to deliver the secure file update script to the OCE. The OCE is configured to provide the secure file update script to the at least one SE through the OfflineRFM Agent corresponding to the SE. The OfflineRFM Agent is configured to establish a secure channel session between the OCE and the corresponding SE and to execute the method for remote file management RFM according to the first aspect of the application at the secure element.

[0048] It has to be noted that all devices, elements, units and means described in the present application can be implemented by software or hardware elements or any combination thereof. All steps which are performed by the various entities described in the present application as well as the described functionality are intended to mean that the respective entity is adapted to perform the respective steps and functionalities, or is configured to perform them.

[0049] Other aspects, features, and advantages of the present application will become apparent to those of ordinary skill in the art, upon reviewing the following detailed description of preferred embodiments and variations thereof, in conjunction with the accompanying figures. BRIEF DESCRIPTION OF DRAWINGS

[0050] Reference will now be made to the drawings wherein:

[0051] Figure 1 An example of a SIM / UICC file system structure is shown;

[0052] Figure 2 An example of an OTA management system is shown;

[0053] Figure 3 An example of a decentralized remote file management system according to an embodiment is shown;

[0054] Figure 4 An example of a decentralized remote file management system according to another embodiment is shown;

[0055] Figure 5 A method for performing a remote file management operation according to an embodiment is shown;

[0056] Figure 6 A sequence diagram of a method for performing a remote file management operation according to an embodiment is shown. DETAILED DESCRIPTION

[0057] A detailed explanation of the present application is given below with reference to the attached drawings showing specific examples of embodiments of the application. These embodiments are described in sufficient detail to enable one skilled in the art to practice the application. It is to be understood that various embodiments of the application, although different, are not necessarily mutually exclusive. For example, specific features, structures, or characteristics described herein in connection with one embodiment can be implemented within other embodiments without departing from the scope of the application. In addition, it is to be understood that the position or arrangement of individual elements within each disclosed embodiment can be modified without departing from the scope of the application. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present application is defined only by the appended claims, appropriately interpreted, and the full ambit of equivalents to which they are entitled. In the drawings, like numerals refer to the same or similar functionality throughout the several views.

[0058] The following abbreviations and symbols are used in view of the specifications:

[0059] Table 1 : Abbreviations and symbols

[0060]

[0061]

[0062] In view of the specifications, reference is made to the following standards for smart cards:

[0063] Table 2: Standards for smart cards

[0064]

[0065] Figure 2 An example of a conventional OTA management ecosystem 200 is shown. The SE issuer 210, which can be an MNO in a telecommunication environment, provides a "file update script" 212 to the OTA platform 214. The file update script 212 includes a set of APDU commands for updating specific files in the SE. The OTA platform 214 prepares a separate "secure file update script" 216 for a particular SE. This is done by using a separate OTA SE key securely stored in the HSM 218 to protect the script content as specified in the smart card standard specifications like ETSI 102 225 (Smart Cards; Security package structure for UICC-based applications) and ETSI 102 226 (Smart Cards; Remote APDU structure for UICC-based applications). Finally, the "secure file update script" is transmitted over the network 220 to the SE 224 of the mobile device 222. The SE is able to unscramble the script, read and process the APDU commands contained therein.

[0066] Figure 2The illustrated RFM processing can only be applied to a single SE. In case several different SEs are to be updated, within a so-called OTA campaign, the SE issuer indicates to the OTA platform which SEs are to be updated, e.g. by using individual SE identifiers or SE keys (e.g. ICCID for SIM / UICC, EID for eUICC, SEID for eSE). The OTA platform prepares a "secure file update script" for each SE and then transmits it to the corresponding SE. In other words, Figure 2 The processing depicted in the middle has to be repeated as many times as the number of SEs to be updated.

[0067] To implement the OTA operation as described above, the conventional solution employs a separate key management system, which means a huge database linking SE identifiers (e.g. ICCID for SIM / UICC, EID for eUICC, or SEID for eSE) with HSM key labels in order to securely wrap the OTA script content.

[0068] To solve the above-identified drawbacks of the conventional OTA-based solution, the present invention introduces a decentralized remote file management platform, a remote file management agent and a decentralized remote file management system, which allow to remotely perform file management operations in a secure way by means of a variant of the Secure Channel Protocol SCP11C.

[0069] SCP11C (also referred to as Decentralized Secure Element Management (DSEM)) provides mutual authentication between the OCE and the SE, authenticating the SE using only static keys, which makes the protocol suitable for offline script usage. In particular, SCP11C supports offline script creation for groups of SEs, as all computations can be pre-computed and deployed later.

[0070] SCP11C is based on the Elliptic Curve Key Agreement algorithm (ECKA). Specifically, it is based on the one-pass uniform model C (1e, 2s, ECC CDH) scheme as defined in section 6.2.1.2 of the [NIST 800-56A] specification. Following the NIST recommendation, the computed shared secret is not directly used as the key for encryption, but as input to a key derivation process. The scheme uses a single ephemeral key pair instead of two pairs. Only the OCE ephemeral key pair is used in the scheme, while the ephemeral key pair from the SE side is removed, and the SD ECKA key (i.e. the static key pair of the SD) is used twice. This allows offline pre-computation of the computed session keys without the need to know the current state of the SE. Once the session keys are computed, any script can be built that leverages these keys to protect and secure it.

[0071] Reference is made below to Figures 3 to 6 Example embodiments of a decentralized remote file management system are described.

[0072] Figure 3 The basic operation of a remote file management system according to embodiments of the application is illustrated.

[0073] In Figure 3 The SE issuer (e.g. SE issuer 210 of Figure 2 provides a "file update script" 212 to the DRFM platform 314. The DRFM platform 314 replaces the OTA platform 214 from a regular OTA-based solution as Figure 2 illustrated and is responsible for protecting the script content provided by the SE issuer 210 with the SCP 11c key of the targeted SE 224. As a major difference with regular OTA-based approaches, this process is done only once for all SEs, as the same "secure file update script" can be deployed into any SE.

[0074] The DRFM platform 314 performs major functions including storage and management of DSEM credentials and offline script preparation. The two functions can be implemented by a single entity of the DRFM platform or split into different entities responsible for each function.

[0075] The SCP 11 specification [GPAmdF] allows to define SE target groups to which an application specific file update script is applied. This can be the case of MNOs with different profile configurations. In this case, scripts will be built that are only suitable for a single profile configuration defined by its card group ID (according to [GPAmdF]). At the same time, it is possible to broadcast the availability of scripts across all SEs sharing the same credentials. As the DSEM credentials are shared by all SEs in a card group ID, the key management in this case is much simpler than the traditional key management performed by the TSM. This gives a huge flexibility in terms of script handling.

[0076] The DRFM platform 314 can be an offline platform that generates on-demand offline scripts based on input data (e.g. file update script 212) and target SE group 224. Once the secure file update script 316 is generated by the DRFM 314 platform, it can be delivered to the SE 224 by any means, e.g. delivered to the smartphone application 222 through the Internet 220, which will forward it afterwards to the SE 224.

[0077] Figure 4 A remote file management system 500 according to embodiments of the application is illustrated.

[0078] Reference is made to Figure 4, the remote file management system 500 comprises the SE issuer 210, the DRFM platform 314, the off-card entity OCE 211 which transmits the secure file update script 316 to the SE 224 of the device 222 through wired or wireless communication means 220. The DRFM platform 314 receives the file update script 212 from the SE issuer and generates the secure file update script 316 as described above with reference to Figure 3 The secure file update script can be generated by the DRFM platform offline, i.e. before the actual task of updating the file system at the SEs.

[0079] The secure file update script 316 comprises a plurality of remote management commands 410 for implementing file management operations on the secure element SE 224. These commands are received one by one at the OfflineRFM Agent 400 located within the SE 224.

[0080] The OfflineRFM Agent 400 is contained within the SE 224 and can act as a proxy between the SE issuer 210 and the file system 450 of the SE 224. Preferably, the OfflineRFM Agent 400 is a Java Card TM application.

[0081] The secure file update script 316 is sent to the SE with a preset authentication security level. The GlobalPlatform technical Secure Channel Protocol "11" card specification defines the authentication security level and assigns an authentication security level to the authentication implemented by the SD owner. Any script to be processed by the OfflineRFM Agent can be sent at least in the case where the security level is authenticated. Otherwise, it can be rejected by the OfflineRFM Agent.

[0082] The OfflineRFM Agent 400 can use the Secure Channel Java Card TM API as defined by GlobalPlatform to establish an SCP11 c session between the OCE device application (owned by the SE issuer) and the SE. The Secure Channel API defines basic services for managing entity authentication and protecting APDU commands and responses. It is typically exposed by the secure domain to its associated applications. The secure domain is an on-card entity that provides support for off-card entity control, security, and communication requirements.

[0083] The instances using this secure channel interface do not need to be aware of the underlying protocols, algorithms and secrets used to perform entity authentication and provide integrity and confidentiality of APDU commands and responses, which only the provider of the instances needs to know. Moreover, it allows reusing the current ecosystem and standards in the deployment of Offline RFM Agent.

[0084] Preferably, Offline RFM Agent 400 does not implement the full SCP 11c logic as it can be delegated to its associated secure domain, but can at least support the reception of main SCP 11c APDU commands (performing security operations and mutual authentication and appropriate access domain configuration). Upon their reception, Offline RFM Agent 400 can forward the incoming data back and forth.

[0085] In addition to this, Offline RFM Agent 400 can use the File View API defined by ETSI in [ETSI_102241] in order to be able to create and / or update the content of file system 450.

[0086] The method for performing remote file management operations on the file system 450 of a secure element SE performed by Offline RFM Agent 400 will be illustrated below with reference to the Figure 5 and the Figure 6 implementation details according to the preferred embodiment.

[0087] With reference to Figure 5 When receiving a secure file update script from OCE 211 in a first step S10, Offline RFM Agent 400 performs in a step S20 a security level authentication of OCE 211 with SE 224 based on the security level of the secure file update script for authenticating the ownership of the received script. As described above with reference to Figure 4 Any script to be processed by Offline RFM Agent is sent by an OCE with an authenticated security level. Any other script sent with a different security authentication level will be rejected by Offline RFM Agent 400.

[0088] Preferably, if SCP 11 related operations are directly managed by Offline RFM Agent, the application provider identifier should be configured within the applet. Otherwise, if the SD is in charge of managing SCP 11 operations, the application provider identifier should be configured in the secure domain where Offline RFM Agent is installed.

[0089] In step S30, if the security level authentication is successful, Offline RFM Agent 400 establishes a secure channel session between the off-card entity OCE 211 and the secure element SE 224.

[0090] After the secure channel session has been established, Offline RFM Agent 400 processes in step S40 a plurality of remote management commands included in the secure file update script and received one by one from OCE 211 to remotely manage the file system 450 on secure element 224.

[0091] A preferred implementation of steps S30 and S40 will be described with reference to Figure 6 Figure 6 A sequence diagram illustrating the decentralized remote file management by passing messages between various components of the Figure 3 and Figure 4 ecosystems is shown.

[0092] As shown in Figure 6 , Offline RFM Agent 400 receives from OCE 211 a plurality of APDU commands contained in the secure file update script 316. The secure file update script 316 can include several APDU commands including but not limited to selection, execution of security operations and mutual authentication. In the embodiment shown in Figure 6 , these commands are sent one by one by OCE 211 to Offline RFM Agent 400 and are processed one by one as they arrive at Offline RFM Agent.

[0093] The secure file update script includes a select command 421 for indicating the ID (Offline RFM Agent AID) of the application (or file) to be managed (e.g. updated, deleted) at the SE.

[0094] Upon performing the security level authentication according to step S20 in Figure 5 , Offline RFM Agent 400 acknowledges 431 the received messages by sending back to OCE 420 a so-called status word (SW) which is an acknowledgment indicating the status of the command processing as defined in ISO 7816-4.

[0095] As mentioned with reference to Figure 5 , in step S30, Offline RFM Agent 400 establishes a secure channel session between the off-card entity OCE 211 and the secure element SE 224. This step can be achieved by (1) performing security operations and then (2) performing mutual authentication.

[0096] ​The execution of the security operation is initiated at the Offline RFM Agent 400 by receiving 422 an execution security operation command from the OCE 211. This command can be used by the OCE to submit the OCE certificate, which includes the public key of the OCE.

[0097] Preferably, the Offline RFM Agent 400 requests 432 the secure domain of the operating system OS 450 of the secure element 224 to execute the above-mentioned security operation for verifying the OCE certificate and to extract the public key from the OCE certificate and to store the public key. In this case, the Offline RFM Agent 400 can receive a response 451 from the OS 450.

[0098] After receiving 422 the execution security operation command, the Offline RFM Agent 400 sends 433 a response to the OCE 211 together with an acknowledgement (status word). The response message can indicate whether the security operation was successful and, if applicable, one or more error conditions.

[0099] The mutual authentication command 423 is used to transfer the OCE 211 temporary key to the SE 224 and can also contain the flavor authentication information for the SD. The SE will complete the key agreement between the OCE key and the SD key and return a receipt of the key agreement result to the OCE.

[0100] The Offline RFM Agent 400 delegates 434 the operation of the mutual authentication to the OS 450 and forwards 435 the response together with a status word (SW) to the OCE upon receiving a response 452 from the OS. The status word (SW) is an acknowledgement indicating the status of the command processing as defined in ISO 7816-4. In particular, the status word will depend on the status of the authentication. If the authentication is successfully achieved, a SW = 9000 will be issued by the SE to the OCE. Otherwise, a different SW indicating a specific error will be sent back to the OCE. In addition, the SD public key and the receipt can be returned. The OCE can check the receipt value to confirm that the same value is computed on his side.

[0101] The Offline RFM Agent 400 can delegate both the security authentication and the mutual authentication to be executed to its associated secure domain 432, 434 by calling SecureChannel.processSecurity(APDU).

[0102] In Figure 5 The above-mentioned steps of executing the security operation and the mutual authentication command to complete the establishment of the secure channel session are performed in step S30.

[0103] Once the secure channel session is established, the Offline RFM Agent can proceed with step S40, as shown in Figure 5 , to process the plurality of remote management commands received from the OCE. In particular, with reference to Figure 6 , the Offline RFM Agent 400 invokes SecureChannel.unwrap(APDU) 436 in order to process and validate the secure messaging of the incoming APDU commands according to the security level of the current secure channel session. The security level of the current secure channel session is preferably set to the security level indicated in the mutual authentication command received at the Offline RFM Agent in step 423.

[0104] Once the security has been processed, the Offline RFM Agent 400 can process the file management APDU commands by itself and can invoke the relevant file view methods 437, 440 in order to create, delete, search or update the file system content. Preferably, the Offline RFM Agent sends a response message to the OCE 441 after processing the security (in step 456) and / or after performing the remote file management operation at the SE (in step 457).

[0105] Table 3 gives an overview of the APDU commands that the Offline RFM Agent can support to perform remote file management operations, as defined in [ETSI_102226]. Some restrictions can apply to certain commands, as will be described below in connection with Table 5.

[0106] Table 3: APDU commands

[0107]

[0108]

[0109] According to the [GPAmdF] specification, any attempt to use the Select APDU inside the SCP 11c session is allowed, but it causes the termination of the already open secure channel session. On a legacy OTA RFM session, the RFM application is implicitly selected by the Toolkit Application Reference (TAR) included as part of the OTA command, so there is no need to select any application.

[0110] In order to prevent the above-described situation of causing the secure channel session to close when a Select command is sent during an RFM script to select any file in the file system, the Offline RFM Agent 400 can be configured to process any Select command embedded in the SCP 11c script without closing the secure channel session.

[0111] Preferably, the Offline RFM Agent is configured with the Access Domain parameters as defined in [ETSI_102221] and [ETSI_102226] which indicate the mechanism used to control the access of the application instance to the file system, i.e. the access rights granted to the application.

[0112] This guarantees to the Offline RFM Agent the proper access to the file system in order to run successfully. This avoids the need to verify the PIN, since the PIN is usually diversified and thus impossible to embed in the DSEM script.

[0113] Preferably, the Offline RFM Agent 400 further comprises means for limiting the execution of a set of remote management commands. In particular, the Offline RFM Agent can be configured to limit the use of the commands from [ETSI_102226] listed in Table 5 below.

[0114] Table 5: Not allowed APDU commands

[0115] Not allowed command Verify PIN Change PIN Disable PIN Enable PIN Unblock PIN

[0116] This limitation supports the session replay requirements defined in conjunction with the SCP11c protocol. SCP11c allows the generation of offline built static scripts which can be executed several times is possible. Therefore, some commands are limited to be executed during an SCP11c session, like the PUT KEY and SET STATUS commands. The Offline RFM Agent can be configured to limit the use of certain commands from [ETSI_102226].

[0117] Preferably, the Offline RFM Agent is configured to meet further limitations defined in the SPC11c protocol specification [GPAmdF].

[0118] Thanks to the SCP11c variant being able to enter the remote file management ecosystem, the above embodiments of the invention provide several advantages. The proposed solution simplifies the existing SE file management by reusing existing APIs and the architecture of the GlobalPlatform standard. In particular:

[0119] - Offline scripts:

[0120] RFM scripts can be created and deployed without the need of an active online connection with the OTA platform. Since the session keys can be pre-computed, it is possible to build any script without the need of any response from the SE.

[0121] - Broadcast / multicast scripts:

[0122] It allows the possibility to deploy the same secure RFM script to all SEs of a batch or specific subset based on the card group ID.

[0123] - High security solution:

[0124] The RFM script will be protected using the latest standards and specifications. Each command is protected by SCP 11c credentials, guaranteeing E2E encrypted communication. Therefore, no one can access the script except the owner of the credentials and no one can modify or change the script in any way. Moreover, the credentials are securely stored in the SE's SD.

[0125] - Inline with current standards:

[0126] The solution provided by the present invention reuses current standards in order to minimize the impact on existing deployments of file system management.

[0127] - No specific infrastructure required:

[0128] In fact, the offline script for the remote file management solution tries to simplify integration and deployment requirements to improve time to market and related costs.

[0129] In addition to this, it is worth noting that the economic cost of the whole solution is significantly lower than existing solutions because the OTA platform complexity is significantly reduced.

[0130] In the foregoing specification, the application has been described with reference to specific embodiments thereof. It is evident, however, that various modifications and changes can be made thereto without departing from the broader spirit and scope of the application. For example, the order of process actions can be changed, where appropriate, while the scope of the application remains the same. Therefore, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense.

Claims

1. A method for performing remote file management RFM operations at a secure element SE (224) by an offline remote file management agent (400) located within the SE (224), the method comprising: - Receive (S10) a security file update script (316) from the external entity OCE (211), the security file update script including a plurality of remote management commands (410) for performing file management operations on the security element (224); -Based on the security level of the security file update script, perform (S20) the security level authentication of the OCE (211) and the SE (224); -If the security level authentication is successful, a secure channel session (S30) is established between the OCE (211) and the SE (224); as well as - Process (S40) the plurality of remote management commands to manage the file system (450) on the security element (224).

2. The method according to claim 1, wherein, The method is implemented using a secure channel communication protocol, which includes a secure channel communication protocol that provides mutual authentication based on a pair of temporary keys of the OCE.

3. The method according to claim 1 or 2, wherein, The OfflineRFMAgent (400) communicates via multiple messages (421; 422; 423; 424) from the OCE (211). 423; 424; 425) Receive the security file update script, each message including one command from the plurality of remote management commands (410).

4. The method according to claim 1, wherein, Performing security level authentication (S20) includes checking whether the security level of the security file update script (432) is set to authenticated.

5. The method according to claim 4, wherein, The method further includes: - If the security level is uncertified, then the security file update script is rejected.

6. The method according to claim 1, wherein, The security file update script includes a security operation command and a mutual authentication command, wherein the security operation command includes an OCE certificate, and the mutual authentication command includes the OCE's temporary public key.

7. The method according to claim 6, wherein, Establishing a secure channel session (S30) includes requesting (432) a security domain located at the operating system OS (450) of the secure element (224) to perform a security operation for verifying the OCE certificate, and also includes requesting (434) the security domain to extract the public key from the OCE certificate and perform a mutual authentication operation.

8. The method according to claim 1, in, The secure file update script (316) further includes a selection command that instructs a remote management application to execute the plurality of remote management commands on the file system of the secure element during the established secure channel session, wherein the OfflineRFMAgent (400) processes the selection command without closing the established secure channel session.

9. The method according to claim 1, wherein, Processing the multiple remote management commands (410) includes creating and / or updating the contents of the file system (450) on the secure element (224) by using a file access application programming interface.

10. An offline remote file management RFM agent (OfflineRFMAgent(400)) located at a secure element SE(22), said OfflineRFMAgent(400) comprising: - A component for receiving a security file update script (316) from an external entity OCE (211), the security file update script including a plurality of remote management commands (410) for performing file management operations on the security element (224); - A component for performing security level authentication of the OCE (211) and the SE (224) based on the security level of the security file update script (316); - A component for establishing a secure channel session between the OCE (211) and the SE (224) if the security level authentication is successful; - A component for processing the plurality of remote management commands by calling the corresponding methods to manage the file system (450) on the SE (224).

11. The OfflineRFMAgent (400) according to claim 10, wherein The OfflineRFMAgent (400) is configured to receive the security file update script via multiple messages (421; 422; 423; 424; 425) from the OCE (211), each message including one command from the multiple remote management commands, and The OfflineRFMAgent (400) is also configured to perform the method according to any one of claims 3 to 9.

12. The OfflineRFMAgent (400) of claim 10 or 11 further includes a component for restricting the execution of a set of remote management commands, the set of remote management commands including verifying a PIN, changing a PIN, disabling a PIN, enabling a PIN, and unblocking a PIN.

13. The OfflineRFMAgent (400) of claim 10 further includes an access domain configuration and / or an application provider identifier, the access domain configuration defining at least one access domain parameter for controlling application instances of the file system to the SE, the application provider identifier defining the ownership relationship between the OfflineRFMAgent (400) and the security element (224), wherein the value of the application provider identifier corresponds to the principal identifier in the OCE certificate used during the authentication process.

14. A distributed remote file management (DRFM) platform (314) for offline generation of security file update scripts for multiple security elements (SEs) (224), the platform comprising: - Memory, used to store credentials for the external entity OCE(211); - A processor for generating a security file update script (316), said processor being configured to: - Receive file update script (212) from SE issuer (210); -Use credentials stored in the memory to protect the file update script (212) to obtain a secure file update script (316); as well as - Send the security file update script (316) to the SE issuer (210).

15. The DRFM platform (314) according to claim 14, wherein, For each OCE (211), the credentials include a static OCE key pair and a temporary key pair, and / or the security file update script (316) also includes a card group ID that identifies multiple SEs with the same OCE credentials.

16. A distributed remote file management system (500), comprising: -Safety Components SE issuer (210); -External entity OCE(211); - The distributed remote file management (DRFM) platform (314) according to any one of claims 14 and 15; and - At least one security element SE (224), said at least one security element (224) comprising OfflineRFMAgent (400) according to any one of claims 10 to 13; The SE issuer (210) is configured to obtain a security file update script (316) including multiple remote file management commands from the DRFM platform (314) and deliver the security file update script (316) to the OCE (211); Wherein, the OCE (211) is configured to provide the security file update script (316) to the at least one SE via the OfflineRFMAgent (400) corresponding to the SE (224); and The OfflineRFMAgent (400) is configured to establish a secure channel session between the OCE (211) and the corresponding SE (224), and to execute the method for remote file management RFM according to any one of claims 1 to 9 at the secure element (224).

Images