EP4327223A1

EP4327223A1 - Data management system implemented in a mobile device

Info

Publication number: EP4327223A1
Application number: EP22723411.9A
Authority: EP
Inventors: Björn KINSCHER; Sandra KOSTIC; Kinga WROBLEWSKA-AUGUSTIN
Original assignee: Freie Universitaet Berlin
Current assignee: Freie Universitaet Berlin
Priority date: 2021-04-20
Filing date: 2022-04-19
Publication date: 2024-02-28
Also published as: WO2022223520A1

Abstract

Aspects of the disclosure regard a data management system (100) and method for storing confidential data implemented in a mobile device (1), the system comprising: a trusted environment (2) comprising a master key (K_MK) created in and bound to the trusted environment (2); at least one service provider software application (4); and a first software application (3) configured to communicate with the at least one service provider software application (4) to receive confidential data from the service provider software application (4) that is to be stored; wherein the first software application (3) is further configured to communicate with the trusted environment (2) for encryption of the received confidential data in the trusted environment (2); wherein the trusted environment (2) is configured to encrypt by means of the master key (K_MK) the confidential data received by the first software application, wherein the data management system (100) is configured that the encrypted confidential data (E_MK(data)) is stored either in the trusted environment or through the first software application (3) in a database (38) or other data storage. Further aspects of the disclosure regard a data management system (100) and method for verification of a digital message.

Description

Data management system implemented in a mobile device

Description

The invention regards a data management system implemented in a mobile device. Further aspects of the invention regard a method for storing confidential data in a mobile device and a method for verification of a digital message.

There is a need in smartphone technology to provide for confidentiality and integrity of code and data in an isolated environment separate from normal application data. One known technique used in this respect is called Trusted Execution Environment (TEE). In TEE, data are processed separately from application data in a main processor.

More recently, special computer chips called Secure Elements (SEs) have become available for smartphones on which special proprietary secure programs, so-called applets, are running. SE computer chips offer secure storage, a secure execution environment and support for cryptographic operations. SE computer chips are protected against various attacks that aim at manipulation or retrievement of stored data and/or effects on processed operations. However, SE applet programming requires special knowledge and applets can only be provisioned with the help of the device manufacturer.

A problem associated with present solutions for security technologies (both TEE and SE) lies in the accessibility to the technology as the use of such security technologies requires specialized knowledge and typically also special contracts with and possible payments to the device manufacturers.

The problem underlying the present invention is to provide for a secure technology that provides for confidentiality and integrity of code and data which may be implemented in a simple and cost-effective manner.

The invention provides for a data management system with the features of claim 1 , a data management system with the features of claim 17, a method with the features of claim 19, a method with the features of claim 20, a software application with the features of claim 21 and a software application with the features of claim 22. Embodiments of the invention are identified in the dependent claims.

Aspects of the invention thus provide for a data management system for storing confidential data implemented in a mobile device. The system comprises: a trusted environment comprising a master key KMK created in and bound to the trusted environment, at least one service provider software application, and a first software application configured to communicate with the at least one service provider software application to receive confidential data from the service provider software application that is to be stored, wherein the first software application is further configured to communicate with the trusted environment for encryption of the received confidential data in the trusted environment, wherein the trusted environment is configured to encrypt by means of the master key KMK the confidential data received by the first software application, wherein the data management system is configured that the encrypted confidential data E _K(data) is stored either in the trusted environment or through the first software application in a database or other data storage.

Aspects of the invention are thus based on the idea to provide for a “central”, first software application which is authorized to interact with the trusted environment, wherein service provider software applications have to communicate through the first software application in order to store and retrieve data in and from the trusted environment. In such a system, the first software application may receive confidential data from different service provider software applications separately and independently such that one service provider is not able to retrieve confidential data of another service provider stored in the trusted environment. The stored data of different service providers software applications can neither influence each other nor do they have access to each other. Also, the stored data can only be released through the first software application.

The confidential data are provided from the first software application to the trusted environment for encryption. The confidential data are encrypted using the master key KMK of the trusted environment, wherein the master key is a key that has been created in the trusted environment and never leaves the trusted environment. The master key may be a symmetric key. The encrypted confidential data may be stored either in the trusted environment or, through the first software application, in a database or other data storage, in particular a database of the first software application. Other data storage” may include any digital storage medium as well as data files.

As storage space is limited in the trusted environment, it is preferable that the encrypted confidential data is provided to the first software application and stored in the database or other storage medium by the first software application. However, in principle, the encrypted confidential data may stay inside the trusted environment, thus not leaving the trusted environment.

The system, by encrypting the confidential data by means of a master key in the trusted environment, ensures that the encrypted data can only be decrypted if it is later processed in the trusted environment again, thereby binding the encryption and the decryption to the trusted environment.

The trusted environment contains its own processor, its own memory and its own operating system, thereby providing for high security of any operations implemented in the trusted environment. It may interact with the other components of the mobile device through defined interfaces only.

In an embodiment, the trusted environment is provided by Secure Elements (SE) which offer a high level of hardware-based security available on a mobile device. Secure Elements provide secure storage, secure execution environment and support for cryptographic operations. The Secure Element may be a separate part of the smartphone comprising, as discussed above, its own processor, memory and operating system, or may be part of a UICC (UICC = “Universal Integrated Circuit Card”) such as a SIM card or of an embedded UICC (so called eUICC). Only programs previously authorized such as the first software application are allowed to access the trusted environment provided by the Secure Element.

In an embodiment, the system provides a first applet installed in the trusted environment and configured to interact with the first software application, wherein the first applet comprises the master key KMK. The first applet is a proprietary software which is part of the trusted environment and runs in the trusted environment, such as a Secure Elements trusted environment, and allows to store and retrieve data in the trusted environment. An Access Control List in the trusted environment is configured such that the trusted environment may only communicate with the first software application. The first software application, on the other side, may also be configured to only communicate with the trusted environment. However, in embodiments, the first software application may be configured to communicate with several trusted environments.

In an embodiment, the first applet further comprises an attestation certificate and a private key associated with the attestation certificate. It is pointed out that the attestation certificate and the private key associated with the attestation certificate may be provided into the trusted environment from the outside. To the contrary, as discussed before, the master key is created in the trusted environment and does not leave the trusted environment.

The applet may be divided into program code and memory. The master key, the attestation certificate and the private key associated with the certificate are stored in the memory of the applet.

In an embodiment, the system further comprises a second software application which is configured to allow loading of the first applet in the trusted environment. The second software application is a separate application that allows it to load the first applet onto the mobile device and into the trusted environment. It is part of or interacts with a trusted service manager. After the installation of the first applet, such trusted service manager may trigger the generation of a master key in the trusted environment and provisioning of an attestation certificate which proves the authenticity of the applet. The second software application may comprise functionality to indicate all installed applets in the trusted environment.

Alternatively, the functionality to allow loading of the first applet in the trusted environment may be integrated into the first software application. Accordingly, a user only has to install the first software application on the mobile device to implement the invention, or the first software application may be preinstalled by the mobile device manufacturer.

The mobile device may be, in embodiments, a smartphone, a tablet computer, a handheld computer, a laptop, and the like. The operating system of the mobile device may be, in embodiments, Android, iOS, Chrome OS or Harmony OS.

In another embodiment, the system further comprises for each service provider software application an archive library communicating directly with the first software application and integrated into the service provider software application, wherein confidential data to be stored and provided by the service provider software application is provided to the archive library and communicated to the first software application through the archive library.

The archive library represents an intermediary between the first software application and the service provider software application, wherein the first software application directly speaks to the archive library. The communication channel between the first software application and the archive library may be used to add data managed by the first software application, to forward messages from the first software application to the service provider software application, and to query a user consent for access to data stored by the first software application.

The archive library may be further used to communicate with a communication device which is configured to send and receive data to and from a user device through, e.g., a near field data communication technology such as NFC (NFC = “Near Field Communication”), wherein the user device communicates with the service provider software application through the communication device. For example, the communication device receives a challenge from an automobile (which in such case is the user device) through NFC technology.

In an embodiment, the trusted environment is further configured to provide the encrypted confidential data E _K(data) to the first software application, wherein the encrypted confidential data E _K(data) are stored in a database or other data storage of the first software application. Accordingly, it is not required to consume memory of the trusted environment for storing of the encrypted confidential data.

It may be provided that the first software application is further configured to encrypt the encrypted confidential data E _K(data) a second time by means of a key K«s of a hardware- backed keystore to have double encrypted confidential data E_Ks(E _K(data)) that are stored, wherein the key K«s of the hardware-backed keystore is associated with a user in that access to the key requires the user to authenticate its identity towards the keystore. Such second encryption with the key from the hardware-backed keystore serves to ensure that the user must authenticate himself to the device, thereby binding the second encryption and subsequent decryption to the user. The user is the user of the mobile device. The key from the keystore is only released after successful authentication. The user may authenticate itself, e.g., by a code or by biometric data.

With encryption by both keys (the master key KMK and the key K«s of a hardware-backed keystore) neither the service provider nor applets in the trusted environment (such as applets in a Secure Element SE) have access to the data as one would have to have access to both the trusted environment and the key in the hardware-backed keystore, which is not possible without the user's involvement.

Only the master key KMK is stored in the trusted environment. The key KKS is stored in the hardware-backed keystore.

In a further embodiment, the data management system is configured to initially register the service provider software application, wherein initial registration includes generation of a private key SK_s and of a public key PK_S in the trusted environment, wherein the private key SKs is encrypted by the master key KMK to provide an encrypted private key E K(SK_s), wherein the encrypted private key E K(SK_s) is stored in the first software application, and wherein the public key PK_S is provided to the service provider software application through the first software application. This allows the service provider software application to encrypt data to be sent to the first software application with the public key PK_S. For decryption of such encrypted data, the encrypted private key is used, wherein the encrypted private key is first decrypted in the trusted environment using the master key.

In an embodiment, the system is configured such that for decryption of the stored encrypted confidential data E _K(data), the encrypted confidential data E _K(data) is provided through the first software application to the trusted environment and decrypted in the trusted environment by means of the master key KMK. Decryption of the stored encrypted confidential data is thus bound to the trusted environment such that a high level of security is provided for. In order that the decrypted confidential data is then provided in a secure manner to the service provider software application, it may be provided that the decrypted confidential data are then encrypted in the trusted environment by a public key PK_B created during registration, and that such encrypted data E_B(data) are provided to the service provider software application through the first software application. At the service provider software application, or a device communicating with the service provider software application, the data may then be decrypted by using the private key SK_B which has been generated together with PK_B by the service provider during registration. The key pair PK_B, SK_B is created at/by the service provider.

In an embodiment, the system is further configured such that the confidential data are double encrypted as discussed before and that for decryption of the double encrypted confidential data E_Ks(E _K(data)) the data is first decrypted by the first software application by means of the key KKS of the hardware-backed keystore, and is subsequently decrypted in the trusted environment by means of the master key KMK. Decryption, accordingly, is bound both to the user by means of the key of the hardware-backed keystore and to the trusted environment by means of the master key.

In a further embodiment, the system is configured such that during registration the private key SKs is encrypted by the master key KMK to provide an encrypted private key E K(SK_s) and the encrypted private key E K(SK_s) is encrypted a second time by means of the key KKS of a hardware-backed keystore to have a double encrypted private key EKS(E K(SK_s)), and that in the process of encryption of the data E_s(data) encrypted by the public key PK_S at the service provider software application, the double encrypted private key EKS(EMK(SK_s)) is decrypted with the key KKS of the hardware-backed keystore to retrieve the private key SK_s only encrypted by the master key KMK and this encrypted private key EMK(SKA) is provided to the trusted environment for decrypting the encrypted private key EMK(SKS) by the master key KMK. This way, the private key SK_s is regained and this private key SKs is then used to decrypt the encrypted data E_s(data) received form the service provider software application. The confidential data are then encrpyted with the master key (KMK) for storage in the database or other data storage. This provides for an even higher level of security when confidential data to be stored are initially provided from the service provider software application to the first software application.

In a further embodiment, the first software application includes a graphical user interface. The first software application, when executed in the mobile device, is operative to indicate all service provider software applications with which the first software application is communicating, and to allow a user of the service provider software application to delete confidential data. Accordingly, in this embodiment, a user may interact directly with the first software application to delete confidential data. In a further embodiment, the trusted environment comprises a specialized computer chip, wherein the specialized computer chip is in accordance with the Secure Element industry standard. As discussed before, the trusted environment may be implemented in accordance with Secure Element standard.

The confidential data may be at least one of a vehicle key, a hotel room key and credit card details. The provision of such confidential data is provided by service provider software applications. The different confidential data can be stored in the trusted environment independently, without influencing each other and without having access to each other.

In a further embodiment, the first software application is configured to also communicate with another service provider software application to receive other confidential data from the other service provider software application that is to be stored, to communicate with the trusted environment for encryption of the other received confidential data in the trusted environment, wherein the trusted environment is configured to encrypt by means of the master key KMK the other confidential data, wherein the data management system is configured that the other encrypted confidential data E _K(data) is stored either in the trusted environment or through the first software application in a database or other data storage, wherein storing of the encrypted confidential data E _K(data) and the other encrypted confidential data E _K(data) in the trusted environment or in the database or other data storage is implemented separately and independently.

This embodiment emphasizes that by means of a single first software application the data of a plurality of service provider software applications can be stored separately and independently in a secure manner.

In a further embodiment of the invention, there is additionally provided encryption between the first software application and the trusted environment. To this end, public keys are exchanged and authenticated when the first software application and the trusted environment first communicate. These keys are then be used for encryption in the communication between the first software application and the trusted environment. However, such further encryption may be refrained from under the assumption of a correct operation of an Access Control Enforcer (ACE) of the (Android or other) operating system. In a further aspect of the invention, the invention provides a data management system for verification of a digital message implemented in a mobile device, the system comprising: a trusted environment comprising a master key KMK created in and bound to the trusted environment, at least one service provider software application, and a first software application configured to communicate with the at least one service provider software application and the trusted environment, wherein the data management system is configured to initially register the service provider software application, wherein initial registration includes generation of a private key SK_A and of a public key PK_A in the trusted environment, wherein the private key SK_A is encrypted by the master key K_MK to provide an encrypted private key E _K(SK_a), the encrypted private key E _K(SK_a) is stored, and wherein the public key PK_A is provided to the service provider software application through the first software application, wherein the first software application is configured to communicate with the at least one service provider software application to receive a digital message, wherein the first software application is further configured to communicate with the trusted environment for signing the digital message with the private key SK_A in the trusted environment, wherein signing the digital message with the private key SK_A comprises decrypting the encrypted private key E _K(SK_a) in the trusted environment by the master key KMK to retrieve the non-encrypted private key SK_A and signing the digital message with the non-encrypted private key SK_A, wherein the first software application is further configured to receive the signed digital message from the trusted environment and return the signed digital message to the service provider software application, wherein the signed digital message can be verified with the public key PK_A.

Accordingly, in this aspect of the invention, a private key and a public key are created in the trusted environment during registration, wherein the private key is encrypted by the master key and stored. To verify a digital message, the private key is decrypted in the trusted environment and the digital message is then signed with the private key in the trusted environment and returned to the service provider software application, where the signed digital message can then be verified using the public key that had been provided to the service provider software application during registration. In this aspect of the invention, the only data that is to be stored is the encrypted private key. As the encrypted private key has to be decrypted in the trusted environment, verification of the digital message is bound to the trusted environment. The digital message to be verified may be used, in embodiments, as a key such as a hotel room key or a vehicle key, or a signature, or credit card information, or a biometric parameter. The digital message may be provided from the service provider software application to the first software application in form of a challenge. The signed digital message allows to authenticate, in embodiments, a user, a device, a signature or key.

The master key KMK may be a symmetric key that has been generated in the trusted environment and never leaves the trusted environment.

The first software application may be configured to verify digital messages of different service provider software applications separately and independently, wherein communication with the trusted environment for verification is through the first software application only.

In an embodiment, the first software application is further configured to encrypt during initial registration the private key SK_A encrypted by the master key KMK a second time by means of a key K_Ks of a hardware-backed keystore to have a double encrypted private key EKS(E K(SK_a)), and to decrypt in the process of signing the digital message the double encrypted private key EKS(E K(SK_a) with the key KKS of the hardware-backed keystore to retrieve the private key SK_A only encrypted by the master key KMK and to provide this encrypted private key EMK(SK_a) to the trusted environment for decrypting the encrypted private key E K(SK_a) by the master key KMK and signing the digital message with the non-encrypted private key SK_A.

Accordingly, in this embodiment, a double encryption of the private key created during registration is provided. This provides for an additional level of security in that decryption is bound to both the user (through the key of the hardware-backed keystore) and the trusted environment (through the master key).

Further embodiments of the data management system of claim 17 are similar to those claimed in claims 2 to 16. Further, it is pointed out that the data management system of the invention may be implemented to combine the features of the data management system of claim 1 and of the data management system of claim 17. In a still further aspect of the invention, a method for storing confidential data in a mobile device is provided, the method comprising: providing a first software application that is configured to communicate with at least one service provider software application and a trusted environment that comprises a master key KMK created in and bound to the trusted environment, communication between the service provider software application and the first software application to receive confidential data from the service provider software application at the first software application that is to be stored, communication between the first software application and the trusted environment of the mobile device for encryption of the received confidential data in the trusted environment, encrypting by means of the master key KMK the confidential data received by the first software application in the trusted environment, storing the encrypted confidential data E _K(data) either in the trusted environment or through the first software application in a database or other data storage.

This method corresponds to the data management system of claim 1. Aspects of the method correspond to the functionalities of claims 2 to 16. For example, the method further comprises encrypting the encrypted confidential data E _K(data) a second time by means of a key K_Ks of a hardware-backed keystore to have double encrypted confidential data E_Ks(E _K(data)) that are stored, wherein the key KKS of the hardware-backed keystore is associated with a user in that access to the key requires the user to authenticate its identity towards the keystore.

Further, it may be provided that the service provider software application is initially registered with the first software application, wherein initial registration includes generation of a private key SK_s and of a public key PK_S in the trusted environment, wherein the private key SKs is encrypted by the master key KMK to provide an encrypted private key E K(SK_s), the encrypted private key E K(SK_s) is stored, and wherein the public key PK_S is provided to the service provider software application through the first software application.

Further, it may be provided that for decryption of the stored encrypted confidential data E _K(data) the stored encrypted confidential data E _K(data) is provided through the first software application to the trusted environment and decrypted in the trusted environment by means of the master key KMK, wherein the decrypted confidential data are encrypted by a public key PK_B and such encrypted data E_B(data) are provided to the service provider software application through the first software application and decrypted by the private key SK_B. The key pair PK_B, SK_B has been created at/by the service provider during registration and the public key PK_B has been provided from the service provider to the first software application and the trusted environment.

In a still further aspect of the invention, a method for verification of a digital message is provided, the method comprising: providing a first software application that is configured to communicate with at least one service provider software application and a trusted environment that comprises a master key KMK created in and bound to the trusted environment, registering the service provider software application with the first software application, wherein registering comprises generation of a private key SK_A and of a public key PK_A in the trusted environment, wherein the private key SK_A is encrypted by the master key K_MK to provide an encrypted private key E _K(SK_a), the encrypted private key E _K(SK_a) is stored, and wherein the public key PK_A is provided to the service provider software application through the first software application, communicate between a service provider software application and a first software application to receive a digital message that is to be verified, communication of the first software application with the trusted environment for signing the digital message with the private key SK_A in the trusted environment, wherein signing the digital message with the private key SK_A comprises decrypting the encrypted private key E _K(SK_a) in the trusted environment by the master key KMK to retrieve the non-encrypted private key SK_A and signing the digital message with the non-encrypted private key SK_A, receiving the signed digital message from the trusted environment and returning the signed data to the service provider software application, verifying the signed digital message with the public key PK_A.

It may be provided that the service provider software application relays the received signed digital message to a relying party which verifies the signed digital message with the public key.

This method corresponds to the data management system of claim 17. Aspects of the method correspond to the functionalities of claims 2 to 16 and 18. For example, the method further comprises encrypting during initial registration the private key SK_A encrypted by the master key KMK a second time by means of a key K_Ks of a hardware-backed keystore to have a double encrypted private key E_KS(E K(SK_a)), and decrypting in the process of signing the digital message the double encrypted private key E_KS(E K(SK_a) with the key K_KS of the hardware-backed keystore to retrieve the private key SK_A only encrypted by the master key K_MK and to provide this encrypted private key E _K(SK_a) to the trusted environment for decrypting the encrypted private key E _K(SK_a) by the master key K_MK, and signing the digital message with the non-encrypted private key SK_A.

In a still further aspect of the invention, a software application storable and operable in a mobile device is provided, the software application when executed on a processor in the mobile device being operative to: communicate with a service provider software application to receive confidential data from the service provider software application, communicate with a trusted environment of the mobile device for encryption of the received confidential data, prompt the trusted environment to encrypt the confidential data by means of a master key KMK of the trusted environment, receive the encrypted confidential data E _K(data) from the trusted environment, store the encrypted confidential data E _K(data) in a database or other data storage.

This software application corresponds to the first software application of claims 1 and 19 and represents the invention of claims 1 and 19 from the perspective of the first software application. Embodiments of the software application correspond to the functionalities of claims 2 to 16.

In a still further aspect of the invention, a software application storable and operable in a mobile device is provided, the software application when executed on a processor in the mobile device being operative to: register a service provider software application, wherein registering comprises prompting a trusted environment to generate a private key SK_A and a public key PK_A and to encrypt the private key SK_A with a master key K_MK, receiving the encrypted private key E_MK(SK_a), storing the encrypted private key E _K(SK_a), and providing the public key PK_A to the service provider software application, communicate with the service provider software application to receive a digital message from the service provider software application that is to be verified, communicate with the trusted environment for signing the digital message with the private key SK_A in the trusted environment, to this end prompt the trusted environment to decrypt the encrypted private key E _K(SK_a) by the master key KMK to retrieve the non-encrypted private key SK_A and sign the digital message with the non-encrypted private key SK_A, receive the signed digital message from the trusted environment; and send the signed digital message to the service provider software application.

This software application corresponds to the first software application of claims 17 and 20 and represents the invention of claims 17 and 20 from the perspective of the first software application. Embodiments of the software application correspond to the functionalities of claims 2 to 16 and 19.

The invention will be explained in more detail on the basis of exemplary embodiments with reference to the accompanying drawings in which:

Fig. 1 is a schematic depiction of components of a data management system implemented in a mobile device, the system comprising a trusted environment, a first software application and at least one service provider software application;

Fig. 2 shows elements of the system of Fig. 1 with additional details;

Fig. 3 is a flowchart of a method for storing confidential data in a mobile device;

Fig. 4 is a flowchart of a method for verification of a digital message;

Fig. 5 shows an embodiment of the process of adding data to a trusted environment;

Fig. 6 shows an embodiment of the process of using data stored in a trusted environment;

Fig. 7 shows an embodiment of the process of deleting data stored in a trusted environment;

Fig. 8 is an example protocol for registration of a service provider software application for storage space in a trusted environment;

Fig. 9 is an example protocol indicating the process flow for storing data in the trusted environment; Fig. 10 is an example protocol indicating the process flow for retrieving data stored in the trusted environment;

Fig. 11 is an example protocol indicating the process flow for preparation of a first software application to act as an authenticator together with the service provider application; and

Fig. 12 is an example protocol indicating the process flow for authentication subsequent to the preparation protocol of Fig. 11.

Fig. 1 depicts an embodiment of a confidential data management system 100. The system is implemented in a mobile device 1 , which in the embodiment of Fig. 1 is a smartphone.

The system comprises components which may be a regular part of the mobile device 1 , namely, a trusted environment 2 and a near field communication NFC device 6, wherein the latter represents an example of a near field data communication technology device which may be implemented in a different manner as well. The trusted environment 2 is provided by a Secure Element SE that comprises an industry-standard, certified chip running, e.g., a Java Card platform, and hosting specially designed applications, called applets in this disclosure. The applets are special proprietary secure programs. One of the applets is identified as ASSET applet 31 in Fig. 1 and will be discussed in more detail below. The Secure Element 2 allows high levels of security.

The system further comprises a first software application 3, which is referred to in the following as ASSET app for ease of reference. The first software application 3 is configured to communicate with the ASSET applet 31 of the trusted environment 2 for encryption of confidential data or for verification of a digital message, as will be discussed in detail below. The ASSET applet 31 can only communicate with trusted applications such as the ASSET app 3. The ASSET applet 31 is a proprietary software.

The ASSET app 3 is further configured to communicate with at least one service provider software application 4, referred to as service provider app 4 in the following for ease of reference, wherein confidential data of the service provider app 4 is provided to the ASSET app 3, or wherein a digital message that is to be verified is provided to the ASSET app 3.

The ASSET app 3 may communicate with a plurality of service provider apps 4, wherein only one service provider app is shown in Fig. 1. Confidential data of different service provider apps 4 that are encrypted in the trusted environment 2 and stored by the first software application 3 do neither influence each other nor have access to each other. They are stored separately and independently, meaning, that storing and retrieving of confidential data of a service provider app 4 is done separately and independent of storing and retrieving of confidential data of other service provider apps 4.

The service provider app 4 includes code 41 of the service provider, meaning the computer program code that defines the software application.

As further component the system 100 includes an archive library 32, in the following referred to as ASSET library 32. The ASSET library 32 is optional and serves to ease communication between the service provider app 4 and the ASSET app 3. The ASSET library 32 may also participate in providing the near field communication functionality of device 6. The ASSET library 32 may be integrated into the service provider app 4 as a module. Confidential data to be stored and provided to the ASSET app 3 are first provided to the ASSET library 32 and communicated from the ASSET library 32 to the ASSET app 3.

The system 100 further includes a second software application 5, in the following referred to as Trusted Service Manager (TSM) app for ease of reference. The TSM app 5 is a proprietary app which is required to load the ASSET applet 31 into the trusted environment 2. TSM app 5 is communicating in this respect with a Trusted Service Manager System TSM 51 implemented outside the mobile device 1 and represents a trusted authority. During a setup phase, the ASSET applet 31 is installed by the TSM 51 and TSM app 5. After the installation, the TSM 51 triggers the generation of a Master Key (KMK) in the ASSET applet 31 and provisions an attestation certificate which can later prove the authenticity of the applet 31 and a private key associated with the attestation certificate. It is pointed out that the master key is automatically created in the ASSET applet 31 during the installation of the applet using a cryptographically secure (pseudo-)random number generator of the trusted environment and never leaves the ASSET applet 31. The attestation certificate and the associated private key, on the other hand, may be created outside the ASSET applet 31 and be loaded into the ASSET applet 31 , e.g., by TSM app 51.

The ASSET app 3 can be used by a plurality of service provider apps 4 for storing respective confidential data, wherein such confidential data are communicated from ASSET app 3 to ASSET applet 31 . Multiple service providers can share one ASSET applet 31 for storing sensitive data, like financial data or health data, based on the fact that all communication is through ASSET app 3, wherein the respective confidential information is stored separately and independently.

The TSM app 5 is only required for installation of the ASSET app 3. In other embodiments, the ASSET app 3 and/or the ASSET applet 31 may be preinstalled in the mobile device 1 before delivery to a user. In another embodiment, the ASSET app 3 is integrated into the operating system of the mobile device 1. In still another embodiment, the ASSET app 3 comprises the trusted functionality that allows loading of the ASSET applet 31 in the trusted environment, such that the ASSET app 3 incorporates the functionality of the TSM app 5.

Fig. 2 shows the system 100 in more detail, wherein the TSM app 5 is not shown or not present in the mobile device 1 , i.e., because the ASSET app 3 and in particular the applet 31 has been preinstalled.

Regarding the ASSET applet 31 , Fig. 2 indicates that the ASSET applet 31 comprises, in a memory of the ASSET applet 31 , the master key KMK, the attestation certificate and the private key SK_Ac associated with the attestation certificate.

More details are also shown with respect to the ASSET app 3. The ASSET app 3 comprises a graphical user interface (GUI) 33, an ASSET logic 34, and applet management 35, an application programming interface (API) 36, a user consent module 37 and a database 38.

The GUI 33 allows the management of data stored using the trusted environment 2. For example, a user may communicate directly through GUI 33 with ASSET app 3 to have indicated all service provider apps 4 for which the ASSET app 3 stores confidential data. It thus serves to provide an overview to a user. In another example, the GUI 33 allows a user of a service provider app 4 to stop communication between the service provider app 4 and the ASSET app 3 and to terminate storage of confidential data by the ASSET app 3. The GUI 33 thus allows direct deletion of data in such embodiment.

The ASSET Logic 34 is a component that connects all other components together and is usually invoked on API calls. It handles general API requests. The ASSET logic 34 comprises an authentication module or subcomponent 341 and a storage module or subcomponent 342. The authentication module 341 handles API requests for the authentication functionality. The storage module 342 handles API requests for the data storage functionality. The API interface 36 is the central interface to integrate ASSET into other apps. It offers other apps the necessary access to the functionality.

The user consent module 37 deals with obtaining user consent for operations on secured data and keys. It uses features available through the operating system (e.g., Android or iOS), such as a system-wide PIN, but also provides alternatives if there are none.

The Database 38 takes care of the storage of all accumulated data. This includes data about which app has access to which data, but also encrypted data and encrypted key material. The content of the database 38 will be discussed in more detail below.

The applet management 35 takes care of all applet related operations. It includes an applet lifecycle module/subcomponent 351 and an applet communication module/subcomponent 352. The applet lifecycle module 351 abstracts the installation, personalization and updating of the ASSET applet 31. The applet 31 can be pre-installed at the factory, downloaded directly from the manufacturer or installed via an independent TSMS. The applet communication module 352 takes care of the communication with the applet 31 . It may be based on Android specific interfaces. But it may also address manufacturer specific interfaces.

The ASSET Library 32 integrated into the service provider app 4 is used to easily integrate the ASSET app 3 into existing or new apps. It serves to free the service provider from having to implement too many details by itself and from having too much specialized knowledge.

The SP Code 41 of the service provider app 4 is the code of the service provider, i.e., the software program code, as mentioned before. The service provider app 4 may be, e.g., an app for car sharing. The app 4 uses the ASSET library 32 to access the API 36 of the ASSET app 3. The library 32 serves to simplify the process. The service provider app 4 can alternatively access the API 36 without the library 32.

The service provider app 4 also includes a memory 43 in which particular keys and data are stored. This will be discussed further below.

Fig. 2 further indicates a keystore 8. The keystore 8 is a hardware-backed keystore that is provided by the operating system of the mobile device 1 . It includes a plurality of keys (typically symmetrical keys, but possibly also asymmetric keys) which can be used by identification of the user of the mobile device by means of a PIN, a fingerprint or the like. The ASSET app 3 can rely on the keys of keystore 8 to encrypt or decrypt data.

Fig. 2 further indicates a device 7 communicating with NFC device 6. The device 7 may be a relying party. It could be, e.g., an automobile, a hotel room lock, a bank or ATM.

The following, an overview is given about the keys and data that are implemented and stored in the data management system 100.

Generally, it is to be noted that SK is a private key (Secret Key): It is used to decrypt or sign a date. PK is a public key: It is used to encrypt a date or to verify a signature. A valid signature confirms that a date has been signed unaltered by an owner of the used private key.

The keys SK_A, PK_A and the encrypted form EKS(E K(SK_a)) are only in use in the authentication use case that will be discussed with respect to Figs. 4 and 11-12 (e.g., car key, eTicketing and hotel room key use case).

The keys SK_B, PK_B and the encrypted data E_Ks(E _K(data1)), E_Ks(E _K(data2)), ... are only used in the secure data storage application that will be discussed with respect to Figs. 3, 8 10

The following keys and data are associated with the ASSET applet 31 , the database 38 of ASSET app 3, the keystore 8 and memory 43 of service provider (SP) app 4.

After having discussed the structure of the system 100 with respect to Figs. 1 , 2, and the relevant keys and data that are stored in the system 100, two methods that may be implemented by such system 100 are next discussed with respect to Figs. 3 and 4. The method of Fig. 3 serves to store confidential data in a trusted manner. The method of Fig. 4 serves to verify a digital message.

According to step 301 of Fig. 3, initially the ASSET app is provided. The ASSET app is configured to communicate with the service provider app and the ASSET applet, wherein the ASSET applet comprises a master key (KMK) created in and bound to the ASSET applet, as discussed before.

According to step 302, the ASSET app and the service provider app communicate to receive confidential data from the service provider app at the ASSET app that is to be stored. In step 303, the ASSET app communicates with the ASSET applet for encryption of the received confidential data in the ASSET applet. The encryption takes place in the ASSET applet. According to step 304, encryption is implemented by means of the master key (KMK), wherein the confidential data received by the ASSET app are encrypted in the ASSET applet. Subsequently, according to step 305, the encrypted confidential data (E _K(data)) are provided from the ASSET applet to the ASSET app and stored through the ASSET app in a database such as database 38 of ASSET app 3 (See Fig. 2). Alternatively, the encrypted confidential data could be stored in the ASSET applet itself. Flowever, as the Secure Element SE typically comprises only limited memory, the encrypted confidential data are stored in a database such as database 38 or other data storage.

The same procedure can be repeated with respect to other service provider apps. The method of Fig. 3 allows different service provider apps to store confidential data in a trusted manner.

Next the method of Fig. 4 is discussed which serves to verify a digital message. The digital message that is verified may be provided in the form of a challenge submitted from the service provider app to the ASSET app. The digital message may refer, in embodiments, to a car key, a hotel key, or bank details that are to be verified in order to implement an action such as opening of the car door, opening of the hotel door, or implementing a bank transaction.

According to step 401 of Fig. 4, initially the ASSET app is provided. The ASSET app is configured to communicate with the service provider app and the ASSET applet, wherein the ASSET applet comprises a master key (KMK) created in and bound to the ASSET applet, as discussed before. For verification of the digital message, an initial registration of the service provider app with the ASSET app is required, step 402. The registration process comprises the steps of a) generation of a private key (SK_A) and of a public key (PK_A) in the ASSET applet, wherein the private key (SK_A) is encrypted by the master key (KMK) to provide an encrypted private key (EMK(SK_a)); b) storing the encrypted private key (E K(SK_a)) in a database; c) providing the public key (PK_A) to the service provider app.

The encrypted private key (E K(SK_a)) is stored, e.g., in database 38 of ASSET app 3. Generally, storing of the encrypted private key is implemented through the ASSET app 3. Encrypting the private key (SK_A) by the master key (KMK) binds encryption and decryption to the trusted environment. In addition, as will be discussed with respect to Figures 11 and 12 below, the encrypted private key may be additionally encrypted by a key of the hardware-backed keystore 8 of Fig. 2, such that a double encrypted private key is stored.

According to step 403, the service provider app and the ASSET app communicate to receive a digital message from the service provider app at the ASSET app that is to be verified. For verification, the digital message needs to be signed with the private key (SK_A) in the ASSET applet, step 404. To implement such signature, the private key (SK_A) needs to be loaded from the database where it is stored and decrypted. Accordingly, signing the digital message with the private key (SK_A) comprises decrypting the encrypted private key (EMK(SK_a)) in the trusted environment by the master key (KMK) to retrieve the non-encrypted private key (SK_A) and signing the digital message with the non-encrypted private key (SK_A).

After signing the digital message with the private key (SK_A), in step 405, the signed digital message (Sign(FI(c))) from the ASSET applet is received at the ASSET app and returned from the ASSET app to the service provider app. At the service provider app or at the service provider the received signed digital message (Sign(FI(c))) is then verified with the public key (PK_A), step 406, wherein the public key received during registration is used to verify the signed digital message.

The same procedure can be repeated with respect to other service provider apps.

Figs. 5 to 7 provide additional detail of processes used to allow communication between the components of system 100 of Figs. 1 , 2, in particular regarding the communication between a service provider app 4 and the ASSET app 3. When referring in the following to ASSET managed data, it is referred to any data of a user or service provider app, in particular data of a user related to the service provided by the service provider app, wherein such data is managed by the ASSET app 3. For example, in the exemplary case of “Carsharing”, ASSET managed data are vehicle key material. The service provider app 4 initiates this process and communicates with the ASSET app 3 so that, for example, the vehicle key is being stored and then managed by the ASSET app 3.

Fig. 5 shows in detail an embodiment of how ASSET managed data is added into the trusted environment of the mobile device when a new service provider app is set up or use of a service provider app is started by a user.

The process starts with a user opening a service provider app 4, step 501 .

In step 502, the user subscribes to a service of the service provider app 4. The data required for this service is to be stored in database 38 of the mobile phone. To do so, the service provider app triggers in step 503 that a new data record is created by the ASSET app 3. The data is encrypted, and the encrypted data is stored in the background in the database 38 as discussed with respect to Figs. 1 to 3. The user only sees the service provider app 4 and only interacts with the service provider app 4. In step 504, the user receives a confirmation from the service provider app 4 that the new service can be used (if relevant for the user/service provider). The data required for the new service is now stored in the database 38 and managed by the ASSET app. Afterwards, the user can go to the ASSET app and find out that there is a new entry in the list of stored ASSET managed data.

Fig. 6 shows in detail how ASSET managed data that is already stored in the trusted environment and managed by the ASSET app 3 may be used.

The process of using a subscribed service requiring ASSET managed data is as follows: The user opens the service provider app 4 in step 601 . The user wants to use a subscribed service requiring ASSET managed data in step 602. The ASSET app 3 is accessed in the background while the user remains in the service provider app 4. In step 603, an overlay window of the ASSET app 3 is placed over the service provider app. The user consent is requested. The user submits its consent, e.g., via PIN input or a fingerprint, step 604. The overlay window of the ASSET app 3 now disappears and the service provider app 4 gives the feedback that the user can now use the desired service, namely, that the ASSET managed data related to the service can now be accessed, step 605. Fig. 7 shows in detail how ASSET managed data may be deleted. The process starts with the user opening the ASSET app 3, step 701 . As discussed (see Fig. 2), the ASSET app 3 has a GUI 33 for direct user communication. Upon opening the ASSET app 3, the user is shown through GUI 33 a list of all subscribed services requiring data which is currently stored and managed by the ASSET app 3, step 702. If the user finds that a service is no longer needed, the user may delete the ASSET managed data required to perform this service, step 703. In this respect, it is pointed out that, as the ASSET app 3 does not have any insight into the data managed by it, the deletion options for the user are limited to deleting ASSET managed data per service provider app. In step 704, the user confirms the deletion request through GUI 33. This triggers the immediate deletion of the corresponding ASSET managed data from database 38 (see Figs. 1 , 2). In case of a new access, the service provider app 4 receives the response from the ASSET app 3 that the requested ASSET managed data do not exist.

In case the entire ASSET app 3 is deleted, all the data stored and managed by the ASSET app are deleted as well. Upon deletion of the ASSET app 3, however, the ASSET applet 31 remains installed in the trusted environment to, unless it was previously deleted at the request of TSM app 5, see Fig. 1 .

Figs. 5 to 7 discussed above describe the system 100 and the associated procedures with a focus on steps performed by a user. In Figs. 8 to 12, protocols for performing various processes implemented by system 100, in particular the processes of Figures 3 and 4, are discussed, the protocols considering the service provider app 4, the ASSET app 3 and the ASSET applet 31 .

The description of Figs. 8 to 12 uses abbreviations as follows (wherein some of the abbreviations have already been discussed in the table above):

Figures 8 to 10 regard embodiments in which sensitive/confidential data are stored in a secure fashion using the trusted environment, in accordance with the method of Fig. 3.

Initially, a setup phase is started after the first use of the ASSET app 3 through a service provider app 4. The service provider App 4 detects the presence of the ASSET app 3 or asks the user to install it.

During the setup phase, the ASSET applet 31 is installed by the TSM 51 , see Fig. 1 . After the installation, the TSM 51 triggers the generation of a Master Key (MK) in the ASSET applet 31 and provisions an attestation certificate which later can prove the authenticity of the applet 31 . The service provider app 4 registers itself to the ASSET app 3. The ASSET app provider can add the requirement to supply authentication data to gain access to the ASSET apps functionality. The authentication data could be used to submit a signed proof of entitlement to support billing of ASSET app usage. The returned key handle is necessary in all following calls to the ASSET app and must be stored securely (e. g. in a hardware- backed KeyStore like Android Keymaster).

Next secure storage is discussed. With the protocol specified in Fig. 8 the Secure Element in a mobile device can be used to encrypt data that subsequently is stored in database 38. The diagram of Fig. 8 shows the flow for registration of storage space.

The message ASSET RegisterStorage is used to register device storage:

The registration request message has four parts and is sent to the ASSET app:

A key handle Fi_Auth [e.g., 36 bytes]. The handle retrieved during app registration.

A challenge [variable length, 32 bytes or more recommended]. A random challenge.

A public key PK_A [e.g., 65 bytes]. The public key with which data is encrypted when retrieved.

A signature Sig_Auth [e.g., 64 bytes]. A cryptographic signature (such as an ECDSA signature) over the following field represented as byte string: the cryptographic hash of the function name, and a hash of every previous parameter. In the ASSET applet, during registration, a private key SK_s and a public key PK_S are created, wherein the private key SK_s is encrypted with the master key KMK to receive an encrypted private key E K(SK_s).

The response returns a public key:

It has the following parts:

A public key [e.g., 65 bytes]. A point on the elliptic curve.

An attestation certificate [variable length] A X.509 certificate signed by the ASSET app vendor.

A signature [e.g., 64 bytes]. A cryptographic signature over the following field represented as byte string: the cryptographic hash of the challenge parameter from the registration, the cryptographic hash of the application identifier from the registration, the above public keys.

Further, the public key PK_s is provided to the service provider app 4.

The signature is to be verified using the public key certified in the attestation certificate.

The encrypted private key E K(SK_s) may be further encrypted with a key K«s of the keystore 8 and the double encrypted key EK_S(E K(SK_s) is then stored in database 38.

Next storage of data is discussed. Figure 9 shows the flow for storing data. For storing data, the message ASSET StorageStore is used:

The store data request message has four parts and is sent to the ASSET app:

The key handle H_Auth [e.g., 36 bytes]. The handle retrieved during app registration.

The data identifier [variable length] A UTF-8 encoded string identifying the data.

The encrypted data [variable length]. Arbitrary user data encrypted with the previously obtained public key.

A signature Sig_Auth [e.g., 64 bytes] A cryptographic signature over the following field represented as byte string: the cryptographic hash of the function name, a hash of every previous parameter.

The encrypted data E_s(data) sent to the ASSET app 3 have been encrypted with the public key PKs provided during registration. The double encrypted key EK_S(E K(SK_s)) is retrieved from database 38 and is decrypted using the keystore key after consent. The then single encrypted key E K(SK_s) is provided together with the encrypted data E_s(data) to the ASSET app 31. There, the encrypted data are first decrypted, wherein the single encrypted key EMK(SKS) is decrypted to receive the private key SK_s and the private key SK_s is used to decrypt the encrypted data. After decryption, the data are then encrypted using the master key to receive data encrypted by the master key E _K(data). The encrypted data are then provided to the ASSET app where they are encrypted a second time using a key KKS of the keystore 8. The double encrypted data E_Ks(E _K(data)) are stored in database 38.

Next retrieval of data is discussed. Figure 10 shows the flow for retrieving data. For retrieving data, the message ASSET StorageRetrieve is used:

The retrieve data request message has three parts and is sent to the ASSET app:

The key handle Fl_Auth [e.g., 36 bytes]. The handle retrieved during app registration. The data identifier [variable length] A UTF-8 encoded string identifying the data.

A signature Sig_Auth [e.g., 64 bytes]. A cryptographic signature over the following field represented as byte string: the cryptographic hash of the function name, a hash of every previous parameter.

For decryption, the double encrypted data E_Ks(E _K(data)) is first decrypted by the ASSET app by means of the key KKS after consent by the user. The then single encrypted data E _K(data) is then decrypted with the master key KMK in the ASSET applet 31 . The decrypted data are then encrypted with the public key PK_B to have encrypted data E_B(data) which are sent through the ASSET app 3 to the service provider app 4, where they can be decrypted using private key SK_B.

Next deletion of stored data is discussed. For deleting data, the message ASSET StorageDelete is used:

Hftuth data identifier SigAuth

The delete data request message has three parts and is sent to the ASSET app:

The key handle FI_Auth [e.g., 36 bytes]. The handle retrieved during app registration. The data identifier [variable length] A UTF-8 encoded string identifying the data.

The response is a status value with no special fields. Figures 11 and 12 discuss an embodiment in which there is no storage of data in database 38. However, the trusted environment 2 is used to authenticate a user to third parties after an initial registration, in accordance with the method of Fig. 4.

With the protocol specified in Fig. 12 a mobile device provides cryptographic assertions that can be verified by relying parties. In the authentication embodiment the trusted environment serves to use the mobile device for authentication towards third parties. The diagram of Fig. 11 shows the flow for preparing the device 1 as authenticator:

The message ASSET RegisterAuth is used to register the device as authentication token:

H_Auth challenge SigAuth

The registration request message has three parts and is sent to the ASSET app 3:

The key handle H_Auth [e.g., 36 bytes]. The handle retrieved during app registration. The challenge [variable length, 32 bytes or more recommended]. A random challenge. A signature Sig_Auth [e.g., 64 bytes]. A cryptographic signature over the following field represented as byte string: the cryptographic hash of the function name, a hash of every previous parameter.

The message received by the ASSET app 3 is processed and forwarded to the ASSET applet 31. A key pair PK_A, SK_A is generated and the private key SK_A is encrypted by the master key KMK inside the applet 31. The public key PK_A and the encrypted private Key EMK(SK_a) is returned to the ASSET app 3 and the encrypted private Key is encrypted again with the key K«s from the keystore so there is EKS(E K(SK_a)). The double encrypted key EKS(EMK(SK_a)) is stored in the database 38.

The response thus returns the public key PK_A:

It has the following parts:

A public key [e.g., 65 bytes]. A point on the elliptic curve.

A signature [e.g., 64 bytes]. A cryptographic signature over the following field represented as byte string: the cryptographic hash the challenge parameter from the registration, the cryptographic hash of application identifier from the registration, the above user public key.

Next the process to authenticate is shown in Fig. 12. An authentication request “Auth” is sent from a relying party 7 to the service provider app 4. The relying party 7 may be, e.g., a car control. The field “challenge” in the request “Auth” represents an ID of the process. It may be a random number created by the relying party. The field “context” identifies a key usage context that identifies the intended use of the key, e.g., opening the car door of a particular car. Further, the field “context” may be used to prevent relay attacks. For example, in the case of car sharing, the license plate number can be entered there. It is displayed while the user gives her/his consent, so the authentication response message is only valid for the vehicle with the associated license plate. The service provider app 4 can additionally check if the context submitted by a relying party 7 has a valid syntax and does not confuse the user or the service provider app 4 can set the context itself.

The message ASSET Auth is sent from the service provider app 4 to the ASSET app and is used for the actual authentication:

The authentication request message has four parts and is sent to the ASSET app:

The key handle FI_Auth [e.g., 36 bytes]. The handle retrieved during app registration.

The challenge [variable length, 32 bytes or more recommended]. A random challenge.

The context [variable length, 32 bytes or more recommended]. A UTF-8 encoded string identifying the key usage context.

After receipt of the message at the ASSET app 3, the double encrypted private key EKS(EMK(SK_a)) is retrieved from the database 38 and decrypted one time by the key KKS- The key is still encrypted by the master key and sent to the ASSET applet 31 as encrypted key EMK(SKA). At the ASSET applet 31 , the encrypted key E K(SK_a) is decrypted by use of the master key KMK to retrieve the private key SK_A. The digital message is then signed with the retrieved private key SK_A and the signed digital message Sign(FI(c)) is sent, through the ASSET app 3, to the service provider app 4 and the relying party 7. Using the public key PK_A, the relying party 7 can authenticate the message. It is to be noted that not the original message (the challenge c) but a hash value of this message H(c) is signed by the retrieved private key SK_A (together with H(aid), H(ctx) and counter, as shown in Fig. 12). In the present context, the hash value of the message is considered a representation of the message.

Accordingly, the response returns a signed assertion:

It has the following parts:

A counter [e.g., 4 bytes]. A counter value that is increased each time the key is used. A signature [e.g., 64 bytes]. A cryptographic signature over the following field represented as byte string: the cryptographic hash the challenge from the registration, the cryptographic hash of application identifier from the registration, the cryptographic hash of application context from the request, the counter.

The signature is to be verified by the relying party 7 using the public key PK_A obtained during registration.

Next deletion of authenticator data is discussed. For deleting the authenticator data, the message ASSET DeleteAuth is used:

The registration request message has only two parts and is sent to the ASSET app 3:

A signature Sig_Auth [e.g., 64 bytes]. A cryptographic signature over the following field represented as byte string: the cryptographic hash of the function name.

The response is a status value with no special fields.

In the following, an example for the verification of a digital message is discussed for further illustration of the inventive data management system and method. The example refers to opening a car by verifying a key in the sense that a message is verified which replaces a key. The procedure is as follows.

The car detects the mobile device in the reader field and sends a random number to the mobile device. The SP app 4 receives the random number and passes it to the ASSET app 3. The ASSET app 3 selects the appropriate double encrypted key pair created during registration for an authentication. It was encrypted once during registration with the master key KMK in the ASSET applet 31 and then with a key K«s from the hardware-backed keystore by the ASSET app 3. This double encrypted key is now decrypted once with the key K_Ks from the keystore which checks that the user is present and agrees to the action (that means the authentication is bound to the user). Now the ASSET app 3 gives the key, which is only encrypted once, with the random number to the ASSET applet 31 in the SE. The applet 31 in the SE now decrypts the key SK_A with the master key KMK and signs this random number, among other things, with the decrypted private key SK_A of the key pair created during registration and returns it to the ASSET app, which passes the signed random number back to the SP app 4 (that means the process is bound to the device). The SP app 4 responds to the car with the signed random number (and possibly other signed data, such as a booking record). Now the car can compare the signature with the public key received during registration and, if necessary, use the other signed data to check whether there is an opening authorization.

The above procedures address, among others, two problems:

First, the problem of bounding data to the device. Data and keys are stored in encrypted form. If the trusted environment works properly, the master key generated in the setup phase cannot be extracted. That means that the keys can only be used with the trusted environment / SE element present and the encrypted data can only be read through the trusted environment / SE element.

Second, the problem of bounding data to the user. Even if a third party manages to steal the device or secretly gains access to it, such third party cannot do any harm since the data is still encrypted using a hardware-backed keystore, e.g., Android Keymaster, which most likely secures the keys in a trusted execution environment. So only if the owner is present and gives its consent, keys can be used, or data can be decrypted.

With the ASSET app concept of the present invention, it is possible for any service provider to benefit from the advantages of the trusted environment without much effort and expense. Service providers are given the opportunity to securely store data on the mobile device, wherein access to the stored data is only granted with the consent of the authorized user. The service providers may at the same time access NFC communication or the like by integrating the ASSET library 32. This extends the functionality of the ASSET app concept, because not only can data be stored securely, but also the user has easy access to open, e.g., doors like car doors, hotel doors or the door of their own house if they have the correct digital key, and this can be done alone with their own mobile device.

Due to the high effort required to protect a Secure Element SE as well as the relatively small memory size, the use of the Secure Element is very costly (in terms of resources), especially with regard to memory. The present invention makes it possible to keep the costs very low and offers every provider the possibility to store arbitrarily large amounts of data in the "normal storage" outside the SE. In addition, the protocol guarantees the same level of protection of the data as if the data were stored in the SE itself.

It should be understood that the above description is intended for illustrative purposes only and is not intended to limit the scope of the present disclosure in any way. Also, those skilled in the art will appreciate that other aspects of the disclosure can be obtained from a study of the drawings, the disclosure and the appended claims. All methods described herein can be performed in any suitable order unless otherwise indicated herein or otherwise clearly contradicted by context. Various features of the various embodiments disclosed herein can be combined in different combinations to create new embodiments within the scope of the present disclosure. In particular, the disclosure extends to and includes all combinations and sub-combinations of one or more features described herein. Any ranges given herein include any and all specific values within the range and any and all sub-ranges within the given range.

Claims

1. A data management system (100) for storing confidential data implemented in a mobile device (1), the system comprising: a trusted environment (2) comprising a master key (KMK) created in and bound to the trusted environment (2), at least one service provider software application (4), and a first software application (3) configured to communicate with the at least one service provider software application (4) to receive confidential data from the service provider software application (4) that is to be stored, wherein the first software application (3) is further configured to communicate with the trusted environment (2) for encryption of the received confidential data in the trusted environment (2), wherein the trusted environment (2) is configured to encrypt by means of the master key (KMK) the confidential data received by the first software application, wherein the data management system (100) is configured that the encrypted confidential data (E _K(data)) is stored either in the trusted environment or through the first software application (3) in a database (38) or other data storage.

2. The system of claim 1 , characterized by a first applet (31) installed in the trusted environment (2) and configured to interact only with the first software application (3), wherein the first applet comprises the master key (KMK).

3. The system of claim 2, characterized in that the first applet (31 ) further comprises an attestation certificate and a private key (SK_Ac) associated with the attestation certificate.

4. The system of claim 2 or 3, characterized in that the system further comprises a second software application (5) which is configured to allow loading of the first applet (31) in the trusted environment (2).

5. The system of claim 2 or 3, characterized in that functionality to allow loading of the first applet (31) in the trusted environment (2) is integrated into the first software application (3).

6. The system of any of the preceding claims, characterized in that the trusted environment (2) is further configured to provide the encrypted confidential data (E_Mi<(data)) to the first software application (3), wherein the encrypted confidential data (E_Mi<(data)) are stored in a database (38) of the first software application (3) or other data storage.

7. The system of any of the preceding claims, characterized in that the first software application (3) is further configured to encrypt the encrypted confidential data (E_Mi<(data)) a second time by means of a key (K_Ks) of a hardware-backed keystore to have double encrypted confidential data (E_Ks(E _K(data))) that are stored, wherein the key (KKS) of the hardware-backed keystore is associated with a user in that access to the key requires the user to authenticate its identity towards the keystore.

8. The system of any of the preceding claims, characterized in that the data management system (100) is configured to initially register the service provider software application (4), wherein initial registration includes generation of a private key (SKs) and of a public key (PK_S) in the trusted environment (2), wherein the private key (SKs) is encrypted by the master key (KMK) to provide an encrypted private key (EMK(SKS)), the encrypted private key (E K(SK_s)) is stored, and wherein the public key (PKs) is provided to the service provider software application (4) through the first software application (3).

9. The system of claim 8, characterized in that the system is configured such that for decryption of the stored encrypted confidential data (E _i<(data)) the stored encrypted confidential data (E _i<(data)) is provided through the first software application (3) to the trusted environment (2) and decrypted in the trusted environment (2) by means of the master key (KMK), and wherein the decrypted confidential data are encrypted by a public key (PK_B) generated at the service provider and such encrypted data (E_B(data)) are provided to the service provider software application (4) through the first software application (3) and decrypted by the private key (SK_B).

10. The system of claim 9, as far as referring to claim 7, characterized in that the system is configured such that for decryption of the double encrypted confidential data (E_Ks(E _K(data))) the data is first decrypted by the first software application by means of the key (KKS) of a hardware-backed keystore, and is subsequently decrypted in the trusted environment (2) by means of the master key (KMK).

11. The system of claim 10, characterized in that the system is configured such that during registration the private key (SK_s) is encrypted by the master key (KMK) to provide an encrypted private key (E K(SK_s)) and the encrypted private key (E K(SK_s)) is encrypted a second time by means of the key (KKS) of a hardware-backed keystore to have a double encrypted private key (EKS(E K(SK_s))), and that, in the process of encryption of the data (E_s(data)) encrypted by the public key (PK_S) at the service provider software application (4), the double encrypted private key (EKS(E K(SK_s))) is decrypted with the key (KKS) of the hardware-backed keystore to retrieve the private key (SKs) only encrypted by the master key (KMK) and this encrypted private key (EMK(SKA)) is provided to the trusted environment for decrypting the encrypted private key (EMK(SKS)) by the master key (KMK), wherein the private key (SKS) is used to decrypt the encrypted data (E_s(data)) and the confidential data are then encrpyted with the master key (KMK) for storage in the database or other data storage.

12. System of any of the preceding claims, characterized in that the system further comprises for each service provider software application (4) an archive library (32) communicating directly with the first software application (3) and integrated into the service provider software application (4), wherein confidential data to be stored and provided by the service provider software application (4) is provided to the archive library (32) and communicated to the first software application (3) through the archive library (32).

13. The system of any of the preceding claims, characterized in that the service provider software application (4) is further configured to communicate with a communication device (6) which is configured to send and receive data to and from a user device through a near field data communication technology, the user device communicating with the service provider software application (4) through the communication device (6).

14. The system of any of the preceding claims, characterized in that the first software application (3) includes a graphical user interface (33), the first software application (3) when executed in the mobile device being operative to:

- indicate all service provider software applications (4) with which the first software application (3) is communicating,

- allow a user of the service provider software application (4) to delete confidential data.

15. The system of any of the preceding claims, characterized in that the trusted environment (2) comprises a specialized computer chip, wherein the specialized computer chip is in accordance with the Secure Element industry standard.

16. The system of any of the preceding claims, characterized in that the first software application (3) is configured: to also communicate with another service provider software application to receive other confidential data from the other service provider software application (4) that is to be stored, to communicate (304) with the trusted environment (2) for encryption of the other received confidential data in the trusted environment (2), wherein the trusted environment (2) is configured to encrypt by means of the master key (KMK) the other confidential data, wherein the data management system (100) is configured that the other encrypted confidential data (E _i<(data)) is stored either in the trusted environment or through the first software application (3) in the database or other data storage, wherein storing (305) of the encrypted confidential data (E _i<(data)) and the other encrypted confidential data (E _i<(data)) in the trusted environment (2) or in the database or other data storage is implemented separately and independently.

17. A data management system (100) for verification of a digital message implemented in a mobile device (1), the system comprising: a trusted environment (2) comprising a master key (KMK) created in and bound to the trusted environment (2), at least one service provider software application (4), and a first software application (3) configured to communicate with the at least one service provider software application (4) and the trusted environment (2), wherein the data management system (100) is configured to initially register the service provider software application (4), wherein initial registration includes generation of a private key (SK_A) and of a public key (PK_A) in the trusted environment (2), wherein the private key (SK_A) is encrypted by the master key (K_MK) to provide an encrypted private key (E_MK(SK_a)), the encrypted private key (E_MK(SK_a)) is stored, and wherein the public key (PK_A) is provided to the service provider software application (4) through the first software application (3), wherein the first software application (3) is configured to communicate with the at least one service provider software application (4) to receive a digital message (c), wherein the first software application (3) is further configured to communicate with the trusted environment (2) for signing the digital message with the private key (SK_A) in the trusted environment (2), wherein signing the digital message (c) with the private key (SK_A) comprises decrypting the encrypted private key (E _K(SK_a)) in the trusted environment by the master key (KMK) to retrieve the non-encrypted private key (SK_A) and signing the digital message (c) with the non-encrypted private key (SK_A), wherein the first software application (3) is further configured to receive the signed digital message (Sign(H(c))) from the trusted environment and return the signed digital message (Sign(H(c))) to the service provider software application (4), wherein the signed digital message (Sign(H(c))) can be verified with the public key (PK_A).

18. The system of claim 17, characterized in that the first software application (3) is further configured

- to encrypt during initial registration the private key (SK_A) encrypted by the master key (KMK) a second time by means of a key (K_Ks) of a hardware-backed keystore to have a double encrypted private key (EKS(E K(SK_a))), and

- to decrypt in the process of signing the digital message (c) the double encrypted private key (EKS(E K(SK_a))) with the key (K_Ks) of the hardware-backed keystore to retrieve the private key (SK_A) only encrypted by the master key (KMK) and to provide this encrypted private key (E K(SK_a)) to the trusted environment for decrypting the encrypted private key (E K(SK_a)) by the master key (KMK) and signing the digital message with the non-encrypted private key (SK_A).

19. A method for storing confidential data in a mobile device, the method comprising: providing a first software application (3) that is configured to communicate with at least one service provider software application (4) and a trusted environment (2) that comprises a master key (KMK) created in and bound to the trusted environment (2), communication (301) between the service provider software application (4) and the first software application (3) to receive confidential data from the service provider software application (4) at the first software application (3) that is to be stored, communication (302) between the first software application (3) and the trusted environment (2) of the mobile device for encryption of the received confidential data in the trusted environment (2), encrypting by means of the master key (KMK) the confidential data received by the first software application in the trusted environment (2), storing the encrypted confidential data (E _K(data)) either in the trusted environment or through the first software application (3) in a database or other data storage.

20. A method for verification of a digital message, the method comprising: providing a first software application (3) that is configured to communicate with at least one service provider software application (4) and a trusted environment (2) that comprises a master key (KMK) created in and bound to the trusted environment (2), registering the service provider software application (4) with the first software application (3), wherein registering comprises generation of a private key (SK_A) and of a public key (PK_A) in the trusted environment (2), wherein the private key (SK_A) is encrypted by the master key (K_MK) to provide an encrypted private key (E_MK(SK_a)), the encrypted private key (E _K(SK_a)) is stored, and wherein the public key (PK_A) is provided to the service provider software application (4) through the first software application (3), communication between a service provider software application (4) and a first software application (3) to receive a digital message (c) that is to be verified, communication of the first software application (3) with the trusted environment (2) for signing the digital message with the private key (SK_A) in the trusted environment (2), wherein signing the digital message (c) with the private key (SK_A) comprises decrypting the encrypted private key (E _K(SK_a)) in the trusted environment by the master key (KMK) to retrieve the non-encrypted private key (SK_A) and signing the digital message with the non-encrypted private key (SK_A), receiving the signed digital message (Sign(H(c))) from the trusted environment and returning the signed data (Sign(H(c))) to the service provider software application (4), verifying the signed digital message (Sign(H(c))) with the public key (PK_A).

21. Software application storable and operable in a mobile device, the software application when executed on a processor in the mobile device being operative to: communicate with a service provider software application (4) to receive confidential data from the service provider software application (4), communicate with a trusted environment (2) of the mobile device for encryption of the received confidential data, prompt the trusted environment (2) to encrypt the confidential data by means of a master key (KMK) of the trusted environment (2), receive the encrypted confidential data (E _K(data)) from the trusted environment

(2), store the encrypted confidential data (E _K(data)) in a database or other data storage.

22. Software application storable and operable in a mobile device, the software application when executed on a processor in the mobile device being operative to:

- register a service provider software application (4), wherein registering comprises prompting a trusted environment (2) to generate a private key (SK_A) and a public key (PK_A) and to encrypt the private key (SK_A) with a master key (KMK), receiving the encrypted private key (E_MK(SK_a)), storing the encrypted private key (E_MK(SK_a)), and providing the public key (PK_A) to the service provider software application (4),

- communicate with the service provider software application (4) to receive a digital message (c) from the service provider software application (4) that is to be verified,

- communicate with the trusted environment (2) for signing the digital message (c) with the private key (SK_A) in the trusted environment (2), to this end

- prompt the trusted environment (2) to decrypt the encrypted private key (EMK(SK_a)) by the master key (KMK) to retrieve the non-encrypted private key (SK_A) and sign the digital message with the non-encrypted private key (SK_A),

- receive the signed digital message (Sign(H(c))) from the trusted environment (2); and

- send the signed digital message (Sign(H(c))) to the service provider software application (4).