Search

US-12619771-B2 - Secure element for a device

US12619771B2US 12619771 B2US12619771 B2US 12619771B2US-12619771-B2

Abstract

A secure element for a device includes an operative system the secure element including a first security applet configure to communicate with the device operative system, wherein the first security applet is configure to accept any first external application, after performing a key registration, as a local administrator application for some first data provided by the first external application, so that no other external application may access the first data without a permission of the first external application. The disclosure also provides a telecommunications device and a method of management of secure information in such a secure element.

Inventors

  • Qi Rong Lai
  • Harmony Stephanie Yu ANG
  • Junjie Daniel Ngui
  • Fabien COURTIADE
  • Gerald Maunier
  • Januar LIANTO
  • Tung Shen ANG

Assignees

  • THALES DIS FRANCE SAS

Dates

Publication Date
20260505
Application Date
20220630
Priority Date
20210727

Claims (14)

  1. 1 . A secure element for a device comprising an operative system, the secure element comprising a first security applet configured to communicate with the device operative system, the device operating system comprising a first external application, the first security applet and the first external application being configured for: performing a key exchange procedure between the first security applet and the first external application, and if the first security applet recognizes the first external application, authorizing the first external application by the first security applet to become a local administrator application for data, called first data, provided by the first external application, in order to forbid access to the first data to any other external application without a permission of the first external application, and without requiring access control managed by rules stored at the secure element.
  2. 2 . The secure element of claim 1 , wherein the first security applet is configured to accept that the first external application may delegate either the access to the first data or specific access permissions to some external applications, such as, for example, a local administrator role similar to the role of the first external application, so that more than one external application may manage the access to the first data.
  3. 3 . The secure element of claim 1 , wherein the first security applet is configured to require a token authorization for any external application to become local administrator for their corresponding data.
  4. 4 . The secure element of claim 1 , wherein the first security applet is configured to accept a main external application as main administrator application for the first security applet, and further configured to confer the main external application the ability to access any data stored in the first security applet and/or the ability to confer further external applications the permission to access any data stored in the first security applet.
  5. 5 . The secure element of claim 1 , wherein the first security applet is configured to establish a relation with the first external application so that any communication between them begins with a secure messaging session established by an authentication.
  6. 6 . The secure element of claim 1 , wherein the first external application is configured to be installed by a user.
  7. 7 . The secure element of claim 1 , wherein the secure element comprises more than one security applet.
  8. 8 . The secure element of claim 1 , wherein the first security applet is configured to recognize more than one external application as local administrator application for their corresponding data, so that no other external application may access the corresponding data without a permission of the corresponding external application.
  9. 9 . A telecommunications device comprising a secure element according to claim 1 .
  10. 10 . A method of management of secure information in a secure element according to claim 1 , the method comprising the steps of: a first external application which has not had any previous contact with the first security applet requests a local administrator permission for some first data provided by the first external application; and the first security applet, after performing a key registration, accepts the first external application as local administrator for the first data, so that no other external application may access the first data without a permission of the first external application and without requiring access control managed by rules stored at the secure element.
  11. 11 . The method of claim 10 , further comprising the steps of: a further external application requests the first external application a permission to access the first data in the first security applet; the first external application initiates a secure session to store the first data in the security applet; the first external application, after a key registration, confers the further external application the permission to access the first data in the first security applet; and the further external application establishes a secure session with the first security applet to access the first data.
  12. 12 . The method of claim 10 , further comprising the steps of; a second external application which has not had any previous contact with the first security applet request a local administrator permission for some second data provided by the second external application; and the first security applet, after performing a key registration, accepts the second external application as local administrator for the second data, so that no other external application may access the second data without a permission of the second external application.
  13. 13 . The method of claim 10 , further comprising the steps of: a fourth external application, which may be different or not from the first external application, requests the first security applet to become a main administrator; the first security applet, after a key registration, accepts the fourth external application as the main administrator; a fifth external application requests the fourth external application a local administrator permission for accessing some fourth data comprised in the first security applet; and the fourth external application, after performing a key registration, confers the fifth external application permission for accessing the fourth data.
  14. 14 . The method of claim 10 , wherein the first external application comprises a token and the key registration includes the authorization of the token as a requirement for accepting the first external application as local administrator for the first data.

Description

TECHNICAL FIELD This invention belongs to the field of managing the secure elements comprised in user devices, such as mobile phones. BACKGROUND As known, some user devices, such as mobile phones, store the user's private information in a dedicated secure element (SE), such as integrated or dedicated security chips, that are located in the same user device, but as a separated hardware, also comprising their own software. Any external application (understood as an application designed to work in the operative system of the user device) may have access to the information contained in the SE. However, this access must be ensured to happen in a secure environment, avoiding that the external application may have access to unnecessary information stored in the SE. Some solutions to these problems have been disclosed. For example, GlobalPlatform Secure Element Access is a solution to regulate the access of the external applications to the SE. However, when an external application has a granted access to the SE, this external application is free to send commands to the SE, and any data may be accessed by third parties. Another existing solution, such as Secure Channel Protocols (SCP), rely on keys stored in the Security Domain (SD). This implies that any external Mobile Application which is able to authenticate to the SD will be allowed access to any SE Applet which relies on an authentication to the SD. The SE Applet cannot differentiate between two different Mobile Applications which has successfully performed an authentication. This problem is usually dealt with by combining the isolation of the SE Applications into different SDs to avoid illegal access from different external Mobile Applications, with access condition management from High Level Operating System (HLOS). This makes deployment on card even more complicated. One other challenge with using the SCP to cipher the communication is that the mobile application will either need to have permanent access to a Trusted Services Manager (TSM) or store the SD's symmetric keys locally themselves which required them to first have access to TSM servers. The need to have access to the TSM servers creates challenges when deploying on the field, especially when the mobile application is only performing a local access to the secure element. Another problem with using SCP is that the SD keys are not always loaded by the service provider themselves, rather they will need the help of the Secure Element Issuer (SEI) TSM to do so. Some service providers may not trust that the keys at some point have passed through a third party entity. The present invention provides an alternative solution to the problem of managing the security in the access of external applications to the security element of a user's device. SUMMARY The invention provides an alternative solution for this problem by means of a secure element according to claim 1. Preferred embodiments of the invention are defined in dependent claims. Unless otherwise defined, all terms (including technical and scientific terms) used herein are to be interpreted as is customary in the art. It will be further understood that terms in common usage should also be interpreted as is customary in the relevant art and not in an idealised or overly formal sense unless expressly so defined herein. In this text, the term “comprises” and its derivations (such as “comprising”, etc.) should not be understood in an excluding sense, that is, these terms should not be interpreted as excluding the possibility that what is described and defined may include further elements, steps, etc. In a first inventive aspect, the invention provides a secure element for a device comprising an operative system, the secure element comprising a first security applet configured to communicate with the device operative system, wherein the first security applet is configured to accept any first external application, after performing a key registration, as a local administrator application for some first data provided by the first external application, so that no other external application may access the first data without a permission of the first external application. This invention introduces the direct communication between an external application and a first applet of the security element. The first external application only needs a key exchange with the first applet of the security element to obtain an “administrator role” over their own first data. A “device”, in the sense of this invention, should be understood as any device with an operative system which is configured to transmit or receive electronic communications with an external operator. Although telecommunications devices, such as computers, mobile phones or tablets are the best example thereof, the invention is not limited to these devices. Any other case, involving internet of things (e.g., car sharing app or parking app or virtual car key app with a car using its own operative system) are als