EP4327223A1 - Système de gestion de données mis en oeuvre dans un dispositif mobile - Google Patents

Système de gestion de données mis en oeuvre dans un dispositif mobile

Info

Publication number
EP4327223A1
EP4327223A1 EP22723411.9A EP22723411A EP4327223A1 EP 4327223 A1 EP4327223 A1 EP 4327223A1 EP 22723411 A EP22723411 A EP 22723411A EP 4327223 A1 EP4327223 A1 EP 4327223A1
Authority
EP
European Patent Office
Prior art keywords
software application
data
trusted environment
encrypted
key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP22723411.9A
Other languages
German (de)
English (en)
Inventor
Björn KINSCHER
Sandra KOSTIC
Kinga WROBLEWSKA-AUGUSTIN
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Freie Universitaet Berlin
Original Assignee
Freie Universitaet Berlin
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Freie Universitaet Berlin filed Critical Freie Universitaet Berlin
Publication of EP4327223A1 publication Critical patent/EP4327223A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/30—Security of mobile devices; Security of mobile applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/40—Security arrangements using identity modules
    • H04W12/48—Security arrangements using identity modules using secure binding, e.g. securely binding identity modules to devices, services or applications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/71—Hardware identity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/69—Identity-dependent
    • H04W12/72—Subscriber identity

Definitions

  • 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.
  • TEE Trusted Execution Environment
  • SEs Secure Elements
  • applets special computer chips
  • 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.
  • SE applet programming requires special knowledge and applets can only be provisioned with the help of the device manufacturer.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • a communication device receives a challenge from an automobile (which in such case is the user device) through NFC technology.
  • 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.
  • 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 K s(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.
  • the key KKS is stored in the hardware-backed keystore.
  • 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 .
  • the encrypted private key is used, wherein the encrypted private key is first decrypted in the trusted environment using the master key.
  • 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.
  • 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.
  • 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.
  • 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 K s(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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • encryption between the first software application and the trusted environment.
  • 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.
  • 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.
  • ACE Access Control Enforcer
  • 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 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.
  • 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.
  • the only data that is to be stored is the encrypted private key.
  • 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.
  • 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 K s 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 .
  • 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).
  • a method for storing confidential data in a mobile device 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.
  • the method corresponds to the data management system of claim 1. Aspects of the method correspond to the functionalities of claims 2 to 16.
  • the method further comprises encrypting the encrypted confidential data E K (data) a second time by means of a key K K s of a hardware-backed keystore to have double encrypted confidential data E K s(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.
  • 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.
  • 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.
  • a method for verification of a digital message 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
  • 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.
  • 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 K s 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 .
  • a software application storable and operable in a mobile device 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.
  • a software application storable and operable in a mobile device 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
  • 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.
  • 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;
  • 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.
  • 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.
  • the system 100 includes an archive library 32, in the following referred to as ASSET library 32.
  • 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.
  • 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.
  • TSM 51 implemented outside the mobile device 1 and represents a trusted authority.
  • the ASSET applet 31 is installed by the TSM 51 and TSM app 5.
  • 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.
  • KMK Master Key
  • 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 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.
  • the ASSET app 3 and/or the ASSET applet 31 may be preinstalled in the mobile device 1 before delivery to a user.
  • the ASSET app 3 is integrated into the operating system of the mobile device 1.
  • 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.
  • 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 A c associated with the attestation certificate.
  • 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.
  • GUI graphical user interface
  • API application programming interface
  • 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.
  • 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.
  • 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 K s(E K (data1)), E K s(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.
  • Figs. 3 and 4 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.
  • 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.
  • KMK master key
  • 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.
  • 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.
  • 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.
  • the encrypted confidential data E K (data)
  • the encrypted confidential 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).
  • the encrypted confidential data could be stored in the ASSET applet itself.
  • 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.
  • 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.
  • 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.
  • KMK master key
  • 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.
  • 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.
  • the digital message needs to be signed with the private key (SK A ) in the ASSET applet, step 404.
  • the private key (SK A ) needs to be loaded from the database where it is stored and decrypted.
  • 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 ).
  • step 405 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.
  • PK A public key
  • 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.
  • 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.
  • 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 .
  • 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.
  • 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.
  • 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.
  • step 7 shows in detail how ASSET managed data may be deleted.
  • the process starts with the user opening the ASSET app 3, step 701 .
  • the ASSET app 3 has a GUI 33 for direct user communication.
  • the user 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.
  • the deletion options for the user are limited to deleting ASSET managed data per service provider app.
  • 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).
  • the service provider app 4 receives the response from the ASSET app 3 that the requested ASSET managed data do not exist.
  • Figs. 5 to 7 discussed above describe the system 100 and the associated procedures with a focus on steps performed by a user.
  • 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 .
  • 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.
  • 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.
  • the ASSET applet 31 is installed by the TSM 51 , see Fig. 1 .
  • 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 .
  • MK Master Key
  • 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).
  • FIG. 8 shows the flow for registration of storage space.
  • 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.
  • 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:
  • a public key [e.g., 65 bytes].
  • a point on the elliptic curve 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].
  • 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.
  • Figure 9 shows the flow for storing data.
  • ASSET StorageStore 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]
  • 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.
  • 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.
  • 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 K s(E K (data)) are stored in database 38.
  • Figure 10 shows the flow for retrieving data.
  • 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].
  • the double encrypted data E K s(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 .
  • 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.
  • a signature Sig Auth [e.g., 64 bytes].
  • 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.
  • 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.
  • a mobile device provides cryptographic assertions that can be verified by relying parties.
  • 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:
  • the registration request message has three parts and is sent to the ASSET app 3:
  • the key handle H Au th [e.g., 36 bytes].
  • the handle retrieved during app registration.
  • the challenge [variable length, 32 bytes or more recommended].
  • a signature Sig Auth [e.g., 64 bytes].
  • 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 )).
  • EKS(EMK(SK a )) is stored in the database 38.
  • a public key [e.g., 65 bytes].
  • a point on the elliptic curve 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].
  • the signature is to be verified using the public key certified in the attestation certificate.
  • 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.
  • 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 signature Sig Auth [e.g., 64 bytes].
  • 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).
  • 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.
  • the public key PK A the relying party 7 can authenticate the 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).
  • the hash value of the message is considered a representation of the message.
  • 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.
  • the registration request message has only two parts and is sent to the ASSET app 3:
  • the key handle H Auth [e.g., 36 bytes].
  • the handle retrieved during app registration.
  • a signature Sig Auth [e.g., 64 bytes].
  • the response is a status value with no special fields.
  • 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 K s 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.
  • 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.
  • 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.
  • the protocol guarantees the same level of protection of the data as if the data were stored in the SE itself.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Storage Device Security (AREA)

Abstract

Certains aspects de l'invention concernent un système (100) et un procédé de gestion de données, servant à stocker des données confidentielles, mis en œuvre dans un dispositif mobile (1), le système comportant: un environnement (2) de confiance comportant une clé principale (KMK) créée dans l'environnement (2) de confiance et liée à celui-ci; au moins une application logicielle (4) de fournisseur de services; et une première application logicielle (3) configuré pour communiquer avec l'application ou les applications logicielles (4) de fournisseur de services pour recevoir des données confidentielles en provenance de l'application logicielle (4) de fournisseur de services qui doivent être stockées; la première application logicielle (3) étant en outre configurée pour communiquer avec l'environnement (2) de confiance pour le chiffrement des données confidentielles reçues dans l'environnement (2) de confiance; l'environnement (2) de confiance étant configuré pour chiffrer au moyen de la clé principale (KMK) les données confidentielles reçues par la première application logicielle, le système (100) de gestion de données étant configuré de telle façon que les données confidentielles chiffrées (EMK(data)) soient stockées soit dans l'environnement de confiance, soit par l'intermédiaire de la première application logicielle (3) dans une base de données (38) ou un autre stockage de données. D'autres aspects de l'invention concernent un système (100) de gestion de données et un procédé de vérification d'un message numérique.
EP22723411.9A 2021-04-20 2022-04-19 Système de gestion de données mis en oeuvre dans un dispositif mobile Pending EP4327223A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021109949 2021-04-20
PCT/EP2022/060247 WO2022223520A1 (fr) 2021-04-20 2022-04-19 Système de gestion de données mis en œuvre dans un dispositif mobile

Publications (1)

Publication Number Publication Date
EP4327223A1 true EP4327223A1 (fr) 2024-02-28

Family

ID=81653486

Family Applications (1)

Application Number Title Priority Date Filing Date
EP22723411.9A Pending EP4327223A1 (fr) 2021-04-20 2022-04-19 Système de gestion de données mis en oeuvre dans un dispositif mobile

Country Status (2)

Country Link
EP (1) EP4327223A1 (fr)
WO (1) WO2022223520A1 (fr)

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2953290A1 (fr) * 2014-06-06 2015-12-09 Gemalto SA Gestion d'un grand nombre de clés uniques par un élément sécurisé
US10187363B2 (en) * 2014-12-31 2019-01-22 Visa International Service Association Hybrid integration of software development kit with secure execution environment
US11223485B2 (en) * 2018-07-17 2022-01-11 Huawei Technologies Co., Ltd. Verifiable encryption based on trusted execution environment
FR3090254B1 (fr) * 2018-12-12 2022-12-16 Idemia France Accès sécurise à des données chiffrées d’un terminal utilisateur

Also Published As

Publication number Publication date
WO2022223520A1 (fr) 2022-10-27

Similar Documents

Publication Publication Date Title
US10595201B2 (en) Secure short message service (SMS) communications
US20180082050A1 (en) Method and a system for secure login to a computer, computer network, and computer website using biometrics and a mobile computing wireless electronic communication device
KR101544722B1 (ko) 부인 방지 방법, 이를 위한 결제 관리 서버 및 사용자 단말기
US8724819B2 (en) Credential provisioning
US20130145455A1 (en) Method for accessing a secure storage, secure storage and system comprising the secure storage
US20140365781A1 (en) Receiving a Delegated Token, Issuing a Delegated Token, Authenticating a Delegated User, and Issuing a User-Specific Token for a Resource
US20200401718A1 (en) Secure storage of and access to files through a web application
US20180091502A1 (en) Method for using and maintaining user data stored on a smart card
WO2018014760A1 (fr) Procédé et dispositif servant à fournir et à obtenir des informations de code graphique, et terminal
JP2008538668A (ja) 移動体端末装置に収容されたｓｉｍカードに接続する方法および接続装置
US8225386B1 (en) Personalizing an anonymous multi-application smart card by an end-user
WO2019051839A1 (fr) Procédé et dispositif de traitement de données
CN111401901B (zh) 生物支付设备的认证方法、装置、计算机设备和存储介质
KR101656458B1 (ko) 본인 확인 및 본인 인증을 위한 인증 방법 및 시스템
CN108768941B (zh) 一种远程解锁安全设备的方法及装置
US20220247555A1 (en) Method for securing an execution of a local application and corresponding first and second user device and system
CN112528268A (zh) 跨渠道的小程序登录管理方法、装置及相关设备
Ahmad et al. Enhancing the security of mobile applications by using TEE and (U) SIM
US8152074B1 (en) Method for preparing by a smart card issuer an anonymous smart card and resulting structure
CN110287725B (zh) 一种设备及其权限控制方法、计算机可读存储介质
KR101639794B1 (ko) 본인 확인 및 본인 인증을 위한 인증 방법 및 시스템
US20240129139A1 (en) User authentication using two independent security elements
EP4327223A1 (fr) Système de gestion de données mis en oeuvre dans un dispositif mobile
Kasper et al. Rights management with NFC smartphones and electronic ID cards: A proof of concept for modern car sharing
Hyppönen An open mobile identity tool: An architecture for mobile identity management

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20231023

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR