USER AUTHORIZATION USING TWO INDEPENDENT SECURITY ELEMENTS

Description

[0001] The invention is defined in the independent claims. Particular embodiments are specified in the dependent claims.

[0002] The invention relates to a method for authenticating a user to an application program installed on a mobile terminal, as well as to a mobile terminal and a system for carrying out the method.

[0003] Mobile devices, such as smartphones, are ubiquitous. They are used in many areas of life and situations to perform a wide variety of digital tasks or with the aid of digital tools. The same mobile devices are used in both areas with low security requirements and in areas with high security requirements.

[0004] Accordingly, corresponding mobile devices must also be capable of meeting such high security requirements. The security of mobile devices, such as smartphones, has therefore become a relevant requirement for device manufacturers, the manufacturers of the programs installed on the devices, and providers of services that can be used with the devices. To ensure secure use, secure authentication of the actual user of the device is of key importance. From the perspective of program manufacturers and service providers, implementing a uniformly high security standard for devices from different manufacturers is a particular challenge.

[0005] The technical guidelines of the Federal Office for Information Security "Technical Guideline TR-03159 Mobile Identities Part 1: Security Requirements for elDAS LoA "substantial"", Version 1.0 Draft 2 dated August 26, 2019, and "Technical Guideline TR-03159-2 Mobile Identities Amendment A - Provisioning and Personalization", Version 1.0.0 Draft dated November 4, 2020, define implementation-independent requirements for mobile identification scenarios and describe a procedure that enables identity to be read from an ID card, stored on commercially available SIM cards or secure elements in mobile phones, and then used as an electronic means of identification.

[0006] US 10 778 450 B1 describes a method for gesture-based multi-factor authentication, which comprises receiving a gesture password from a user. The gesture password is mapped to a first substitution string. A cryptographic key is generated using the substitution string as input to a password-authenticated key exchange protocol ("PAKE"). A challenge-response is encrypted with the cryptographic key to generate an encrypted challenge-response. A user ID and the encrypted challenge question are transmitted to a relying party.The encrypted challenge-response can be verified by the relying party by retrieving the first substitution string based on the user identifier, generating the cryptographic key using the first substitution string as an input to the PAKE protocol, decrypting the encrypted challenge response using the cryptographic key, and verifying the challenge-response to authenticate the user.

[0007] The invention is based on the object of creating a method for authenticating a user to an application program installed on a mobile terminal.

[0008] The object underlying the invention is achieved by the features of the independent patent claims. Embodiments of the invention are specified in the dependent patent claims.

[0009] Embodiments include a method for authenticating a user to an application program installed on a mobile terminal. An operating system is installed on the terminal. The operating system is configured to control at least one authentication sensor of the terminal for detecting at least one authentication factor of the user. The terminal comprises a first security element associated with the operating system. The first security element comprises cryptographic means for executing a challenge-response method. A private cryptographic key of an asymmetric key pair of the first security element is stored in a protected memory area of ​​the first security element.

[0010] Furthermore, a second security element is provided that is independent of the first security element and associated with the application program. The second security element comprises cryptographic means for executing a challenge-response method.

[0011] The procedure includes: in response to an authentication request from the application program, authenticating the user by the operating system using the authentication sensor and the first security element, executing a challenge-response procedure between the first security element and the second security element, wherein the challenge-response procedure comprises generating a response by the first security element and validating the response by the second security element,wherein generating the response comprises encrypting a challenge of the second security element by the first security element using the private cryptographic key of the first security element, and wherein validating the response comprises decrypting the response of the first security element by the second security element using a public cryptographic key of the asymmetric key pair of the first security element, wherein successful execution of the challenge-response method confirms successful authentication of the user by the operating system, upon successful execution of the challenge-response method, confirming the successful authentication of the user to the application program by the second security element.

[0012] The mobile device can serve, for example, as an authentication token, authorization token, and / or as proof of identity, i.e., ID token, for example in electronic business processes. For this purpose, the user can be securely authenticated by the mobile device. According to embodiments, the local authentication of the user by the device can serve as the basis for further authentication of the user using identity attributes, for example, stored on the device. Such further authentication is, for example, authentication by an ID provider service.

[0013] The mobile device is configured for secure user authentication using the authentication sensor and the operating system or the first security element. Authentication can be based, for example, on capturing and evaluating the user's biometric characteristics.

[0014] Embodiments can have the advantage that manufacturers of application programs or the corresponding application programs can access the authentication functionality of the mobile terminal for user authentication. The authentication functionality of the terminal using the authentication sensor and the first security element implements a secure binding of the user to the terminal. However, a comparably secure binding of the terminal or the user to the corresponding application program is lacking. Without further security mechanisms, it cannot be reliably concluded from the use of the application program that the terminal is being used, nor that a specific user is using the terminal. Such a secure binding can be implemented by using the second security element.The second security element is assigned to the application program, for example, by installing an applet of the application program in the second security element. The first security element, which may be, for example, a hardware-based security element of the device manufacturer, provides cryptographic means, such as cryptographic key material and protocols, which can be used to securely make the authentication results of the terminal device available to an application program installed on the terminal device. Thus, the first security element ensures the cryptographic security of the operating system or provides the operating system with cryptographic security functionality. According to embodiments, the first security element may also be, for example, a software-based and / or firmware-based security element of the device manufacturer.

[0015] The second security element, which communicates securely with the first security element using the challenge-response protocol, can ensure a secure connection with the first security element. For example, the end device comprises the second security element in addition to the first security element. The secure connection implements a secure connection between the second security element and the first security element, and thus to the end device and / or its user. This secure connection also allows the second security element to be provided as an external component, for example, on an external server.

[0016] The second security element comprises, for example, an applet of the application program. The second security element provides cryptographic means, such as cryptographic key material and protocols, which are assigned to the application program and are under its control and / or the control of the application program manufacturer. Thus, the second security element ensures the cryptographic security of the application program or provides the application program with cryptographic security functionality. The second security element is, for example, a hardware-, software-, and / or firmware-based security element. For example, the second security element comprises an eSIM or an eUICC.

[0017] The invention describes a method for securely authenticating a user on a mobile device, as well as for securely authenticating the user using an additional security element. The additional security element can be provided, for example, on the corresponding mobile device, for example, with a device-manufacturer-independent security application or security applet. For example, the additional security element is provided as an external component, for example, on an external server for use by the application program installed on the mobile device.

[0018] In particular, a secure use of user authentication features, such as biometric features, is enabled for authentication against a device manufacturer-independent application program and / or security applet of the application program.

[0019] According to embodiments, a challenge-response method is used to authenticate the user to the application program. This method is executed between the device-specific first security element and the device-independent second security element. The second security element is, for example, an application-specific security element or a security element assigned to the application program. For example, a security applet of the application program is installed on the second security element, which is, for example, an application-specific security applet.

[0020] To implement the cryptographically secured connection between the first and second security elements, cryptographic key material is, for example, introduced into and / or generated in the device manufacturer-dependent first security element. For example, an asymmetric key pair of the first security element is generated thereon. For example, key material is introduced that includes the private cryptographic key of the asymmetric key pair of the first security element. Furthermore, the introduced key material includes, for example, the public cryptographic key of the asymmetric key pair of the first security element. This occurs, for example, during initialization of the mobile device. If the asymmetric key pair is introduced, for example by an initialization server, the corresponding key pair is created by the initialization server.Alternatively, the asymmetric key pair is generated by another server and provided to the initialization server for incorporation into the first security element. For example, the public cryptographic key of the first security element is provided as part of a certificate and / or a certificate is provided that includes the corresponding public cryptographic key. For example, the certificate is signed by the initialization server and / or the other server that generates the asymmetric key pair of the first security element. For example, the certificate is part of a PKI that includes the initialization server and / or the other server that generates the asymmetric key pair of the first security element.The certificate of the public cryptographic key of the first security element is signed with a signature key of the initialization server and / or the further server generating the asymmetric key pair of the first security element.

[0021] The private cryptographic key of the first security element is stored in a protected memory area of ​​the first security element. The protected memory area of ​​the first security element can be, for example, a memory area of ​​the first security element's memory in the case of a hardware security element. In the case of a firmware or software security element, the protected memory area of ​​the first security element can be, for example, a memory area of ​​the mobile device's memory assigned to or managed by the first security element. A "protected memory area" is understood here to be an area of ​​an electronic memory to which access, i.e., read or write access, is restricted. An access restriction can, for example, be a condition that must be met.The corresponding condition can, for example, be a cryptographic condition, in particular successful authentication and / or successful authorization verification. Such verification can, for example, be based on an electronic signature with a signature key. Access can, for example, be restricted to being possible only via a processor of the security element or only via a processor of the mobile device. For example, external access to the protected memory area via a bus is not possible.

[0022] Furthermore, cryptographic key material is introduced into and / or generated in the device-manufacturer-independent second security element. For example, cryptographic key material is introduced into and / or generated in a device-manufacturer-independent security applet of the second security element. This occurs, for example, during the initialization and / or provisioning of the second security element. For example, this occurs during the initialization and / or provisioning of the security applet of the second security element that is assigned to the application program. For example, the introduced cryptographic key material comprises the public cryptographic key of the first security element.For example, the cryptographically initialized first security element can incorporate the public cryptographic key of the first security element into the second security element and / or the security applet of the second security element or make it available to the second security element. Likewise, the second security element and / or the security applet of the second security element can incorporate a cryptographic key of the second security element and / or the security applet of the second security element into the first security element or make it available to the second security element. For example, a provisioning server can incorporate the public cryptographic key of the first security element into the second security element and / or the security applet of the second security element.

[0023] Embodiments thus provide a method for authenticating a user by using an authentication method of a mobile terminal for authentication on an additional security element, e.g., implemented with an applet or as a remote security element that is independent of and not under the control of the device manufacturer. Authentication of the user of the mobile terminal is enabled by the additional security element. Incorporation of cryptographic key material, in particular a public cryptographic key of the first security element of the device manufacturer, into the security applet or the remote security element, which is independent of the device manufacturer, occurs, for example, during provisioning.

[0024] Furthermore, a challenge-response procedure is executed between the device-specific first security element and the device-independent second security element to authenticate the user based on a signature procedure. The device-manufacturer-independent second security element sends a nonce to the device manufacturer's first security element, for example, upon request. The user authenticates, for example, by entering a PIN or a biometric feature. Upon successful user authentication, a signature of the nonce is executed. The device-manufacturer-independent second security element receives the resulting signature as a response and verifies it with the public key introduced, for example, during provisioning.

[0025] According to embodiments, a challenge for executing the challenge-response method is generated by the second security element and / or the security applet of the second security element and transmitted to the first security element. The challenge is, for example, a random value, in particular a nonce.

[0026] A nonce is any number or character string intended for single-use in cryptographic communication. A nonce can be, for example, a random or pseudo-random number. A nonce can be used in a challenge-response process to ensure that old responses cannot be reused in replay attacks. A nonce can, for example, be configured to be time-variant, for example by including a timestamp or by using a timestamp to generate the nonce. Furthermore, a nonce can be configured or generated to include a sufficient number of random bits so that the probability of repeating a previously generated nonce value is negligible.

[0027] For example, the second security element and / or the security applet of the second security element generates the challenge, such as a nonce, and transmits it to the first security element. The first security element initiates user authentication. Upon successful user authentication, the first security element signs the challenge using the private cryptographic key of the first security element. The signed challenge is sent as a response to the second security element. The second security element and / or the security applet of the second security element checks the response using the public cryptographic key of the first security element. The signed challenge is, for example, a hash value of the challenge encrypted using the private cryptographic key of the first security element.Verifying the response includes, for example, decrypting the encrypted hash value using the public cryptographic key of the first security element. The resulting encrypted hash value is compared with the hash value of the sent challenge. If both match, the verification and thus the challenge-response process is successful. Upon a successful challenge-response process, the second security element and / or the security applet of the second security element knows that the authorized, i.e., successfully authenticated, user is actually using the mobile device. The exchange of challenge and / or response can also be cryptographically secured, for example, using an encrypted communication channel, for example, using end-to-end encryption.

[0028] Embodiments can have the advantage of providing a secure method for authenticating a user of the mobile terminal to the second security element and / or the security applet of the second security element, and thus to the application program. Thus, the user can securely authenticate to the application program through the intermediation of the two security elements. The method enables authentication of the user of the mobile terminal to the application program or the security applet associated with the application program using two security elements.The use of two independent security elements allows the use of a second security element, which is independent of the first security element and, for example, not under the control of the device manufacturer, in addition to the first security element, which is assigned to the operating system and, for example, under the control of the manufacturer of the mobile device. According to embodiments, a security applet of the second security element assigned to the application program is, for example, under the control of a manufacturer of the corresponding application program. Thus, the method also enables user authentication to the application program using the mobile device or the authentication means of the mobile device.These authentication means comprise, for example, an input device and / or a sensor, such as a biometric sensor of the mobile terminal, as well as the first security element.

[0029] Embodiments can have the advantage of implementing a simultaneous binding of the user to two independent security elements with a mutually secure interleaving of the two security elements on a mobile device. The user's binding is implemented, for example, by the first security element having access to reference values ​​for the user's one or more authentication factors. For example, the corresponding reference values ​​are stored in a memory area of ​​the mobile device assigned to the first security element. For example, the security element comprises the corresponding memory area. For example, the reference values ​​are stored outside the security element. For example, the reference values ​​are stored in the protected memory area of ​​the first security element.According to embodiments, the reference values ​​are stored in a cryptographically secured form, for example, in encrypted or hashed form. According to embodiments, the first security element, using the corresponding reference values, is capable of authenticating the user based on authentication factors or authentication data detected by the authentication sensor. This allows the user to be bound to the first security element. The result of the authentication can be forwarded to the second security element in a cryptographically secured manner using the challenge-response method, thereby enabling the user to be bound to the second security element and thus to the application program. As a result, the user can be bound to both security elements simultaneously.Using the challenge-response method and the underlying cryptographic means of the security elements, a mutually secure entanglement of the two security elements can be implemented on the terminal device. For example, the cryptographic means comprise an asymmetric key pair of the first security element, which is stored in the first security element, and the public cryptographic key of the corresponding key pair, which is stored in the second security element.

[0030] Authentication refers to the verification of a claimed property of an entity, such as a user of a mobile device. During authentication, for example, the corresponding proof provided by the user is verified. The entity performs authentication through its contribution to the authentication process, i.e., by providing appropriate proof such as authentication data or authentication factors for verification.

[0031] Authentication of the user regarding the claimed property of authenticity, for example, the authenticity of their person or identity, allows the authenticated user to perform further actions. For example, the user is granted access rights. A successfully authenticated user is considered authentic. Final confirmation of authentication may include authorization.

[0032] The user can authenticate themselves in various ways. For example, they can provide proof of knowledge, such as a PIN or password, proof of possession, such as a cryptographic key, a certificate, or an electronic device, and / or proof of their own personal characteristics, such as biometric or behavioral characteristics. For example, the corresponding proof is captured by an authentication sensor on the mobile device in the form of the user's authentication data and compared by a security element on the mobile device with one or more stored reference values. The security element that evaluates the captured authentication data is, for example, a security element of the mobile device's operating system.If there is a sufficient match between the captured authentication data and the stored reference values, the security element confirms successful user authentication. For example, confirming successful user authentication involves executing a challenge-response procedure by the confirming security element.

[0033] A mobile device is a mobile, portable communication device, such as a smartphone, a tablet or a smartwatch.

[0034] An authentication sensor is understood to be a sensor for capturing authentication data of the user of the mobile device. The authentication data can, for example, comprise the user's biometric data. The authentication sensor can be configured to capture biometric data of the user, i.e., a biometric sensor. Biometric data can, for example, comprise: fingerprint data, body geometry data / anthropometry data, such as facial, hand, or ear geometry data, hand line structure data, vein structure data, such as palm vein structure data, iris data, retina data, voice recognition data, and nail bed patterns. The authentication sensor can, for example, comprise a camera of the mobile device. The authentication data can, for example, comprise user knowledge, such as a PIN or password.The authentication sensor may include an input device for entering authentication data, such as a PIN or password. The input device may, for example, include a keyboard and / or a touchscreen.

[0035] A challenge-response procedure represents a secure authentication procedure between a first instance and a second instance based on knowledge. For example, the first security element is authenticated by the second security element and / or the security applet of the second security element using a challenge-response procedure. At the same time, the response represents confirmation of successful user authentication if the response is only generated under the condition of successful user authentication by the first security element. Thus, in the case of a successful challenge-response procedure, the second security element or the security applet not only knows that the user authentication has been confirmed, but also that it has been confirmed by the first security element and is therefore valid.

[0036] In a challenge-response process, a first instance presents a task ("challenge") to a second instance, for which the second instance must provide a correct answer ("response"). By providing the correct answer, the second instance proves that it knows a specific piece of information. The advantage of this is that the specific piece of information is not transmitted and thus cannot be compromised through the data exchange during the challenge-response process. Rather, the specific piece of information can be kept by the second instance as a secret known to it, or perhaps only to it.

[0037] A challenge-response procedure can be based on an asymmetric cryptosystem and serve to prove to the first instance that a second instance possesses a private and thus secret cryptographic key. Only the second instance knows the corresponding private cryptographic key, which it uses for a cryptographic transformation of the challenge, e.g., a nonce. The corresponding cryptographic transformation can be, for example, a digital signature. The first instance can use a public cryptographic key associated with the private cryptographic key to check the response to determine whether the second instance actually possesses knowledge of the private cryptographic key, without the first instance itself gaining knowledge of the private cryptographic key during the verification process.

[0038] For example, the first instance generates a random value, such as a nonce, and sends it to the second instance. The second instance uses the secret known to it for a cryptographic transformation of the nonce and sends the result as a response to the first instance for the purpose of authenticating the second instance. If the secret is a private cryptographic key of the second instance, the nonce can be signed using it. During the signing process, for example, a hash value of the nonce is calculated and encrypted with the private cryptographic key of the second instance. The first instance, which knows both the nonce and a public cryptographic key of the second instance belonging to the private cryptographic key of the second instance, can perform an inverse calculation, i.e.Decrypt the signed nonce using the public cryptographic key of the second instance. The result of the decryption is, for example, a hash value of the nonce. This decrypted hash value can be compared with the hash value of the sent nonce. For this purpose, a hash function is applied to the corresponding nonce stored in the first instance. If the decrypted hash value matches the hash value of the sent nonce, the challenge-response procedure is successful and the second instance is successfully authenticated.

[0039] In the present case, the second instance is the second security element assigned to the application program, and the second instance is the first security element assigned to the operating system of the mobile device.

[0040] A security element, also called a "Secure Element" or "SE," is a secured element of a mobile device that provides cryptographic means. These cryptographic means are protected against manipulation and are accessible only to authorized services and applications, for example, via cryptographic keys. In particular, the cryptographic means can only be inserted, added to, modified, and / or deleted in the security element by authorized services and applications.A security element thus provides a tamper-proof platform, for example, implemented in the form of a secure single-chip microcontroller, on which applets and / or confidential and / or cryptographic data can be stored according to predefined rules and security requirements by reliably identified trusted entities and thus made available to authorized application programs and / or operating systems. A security element can be embedded or integrated, for example, non-destructively removable or permanently attached, i.e., not non-destructively removable. The security element can, for example, comprise a SIM, UICC, SmartMicroSD, smart card, eSE, eSIM, or eUICC. For example, cryptographic keys are stored on a security element, i.e., the security element comprises a data safe for cryptographic keys or a "key store."The cryptographic keys can, in particular, be cryptographic keys of asymmetric key pairs. Such a key store or security element can also be implemented as part of the main processor, for example, in a TEE (Trusted Execution Environment). For example, the first security element can be implemented using a TEE. Security elements are implemented, for example, as hardware and / or firmware. According to embodiments, security elements or key stores can also be implemented as software. Two security elements are independent of each other, for example, if there is no common instance that has access rights for both security elements.

[0041] An application program, also called an application or app for short, is a computer program that provides, supports and / or enables the processing of non-system-technical functionality.

[0042] An applet is a computer program that is not run as a standalone application. The term "applet" is derived from the words "application" and "snippet."

[0043] An operating system is a computer program or a collection of computer programs that provides, supports, and / or enables the processing of system-specific functionalities. An operating system provides system resources. System resources refer to system elements or hardware components of a computer that are required by processes to function correctly.

[0044] A "communication interface" is understood here, for example, to be an interface via which data can be received and sent, whereby the communication interface can be configured as contact-based or contactless.

[0045] Communication can, for example, take place via a network. A "network" is understood here to mean any transmission medium with a connection for communication, in particular a local connection or a local network, in particular a local area network (LAN), a private network, in particular an intranet, and a digital private network (Virtual Private Network - VPN). For example, a computer system can have a standard wireless interface for connecting to a WLAN. Furthermore, it can be a public network, such as the Internet. Depending on the implementation, this connection can also be established via a mobile network.

[0046] Contactless communication is possible, for example, using Near Field Communication (NFC). This is a communication technology based on RFID technology for the contactless exchange of data via electromagnetic induction using loosely coupled coils over short distances. NFC can be implemented, for example, according to one of the standards ISO 14443, 18092, 21481, ECMA 340, 352, 356, 362, or ETSI TS 102 190.

[0047] A "processor" is understood here and below to mean a logic circuit used to execute program instructions. The logic circuit can be implemented on one or more discrete components, in particular on a chip. A processor comprises, for example, an arithmetic unit, a control unit, registers, and data lines for communication with other components. In particular, a "processor" is understood to mean a microprocessor or a microprocessor system comprising multiple processor cores and / or multiple microprocessors.

[0048] "Memory" here refers specifically to non-volatile memory. "Non-volatile memory" is understood here, for example, to be an electronic memory for the permanent storage of data. Non-volatile memory can be configured as non-modifiable memory, also known as read-only memory (ROM), or as modifiable memory, also known as non-volatile memory (NVM). In particular, this can be an EEPROM, for example, a flash EEPROM, also known as flash. Non-volatile memory is characterized by the fact that the data stored on it is retained even after the power supply is switched off.

[0049] A public key infrastructure (PKI) is a system for issuing, distributing, and verifying digital certificates. In an asymmetric cryptosystem, a digital certificate serves to confirm the authenticity of a public key and its permissible scope of use and validity. The digital certificate itself is protected by a digital signature, the authenticity of which can be verified using the public key of the certificate issuer. A digital certificate is used to verify the authenticity of the issuer key. In this way, a chain of digital certificates can be established, each of which confirms the authenticity of the public key with which the previous certificate can be verified. Such a chain of certificates forms a so-called validation path or certification path.PKI participants must be able to rely on the authenticity of the last certificate, the so-called root certificate, and the key certified by this certificate without the need for any additional certificates. The root certificate is managed by a so-called root certification authority, whose assumed authenticity underlies the authenticity of all PKI certificates.

[0050] A "certificate" here refers to a digital certificate, also known as a public-key certificate. Such certificates, based on asymmetric key pairs, create a so-called public-key infrastructure (PKI). Such a certificate is structured data used to assign a public key of an asymmetric cryptosystem to an identity, such as a person or device. A certificate can, for example, contain a public key and be signed. For example, the certificate can conform to the X.509 standard or another standard. For example, the certificate can be a Card Verifiable Certificate (CVC), which is a public-key certificate stored in a compact format.

[0051] Digital certificates are a proven means of proving authorization when securing electronic communication using asymmetric cryptographic methods. Certificates are structured data that document the authenticity and / or other properties / authorizations of the owner of a public key (signature verification key) and are confirmed by an independent, trustworthy authority (certification service provider / CSP), generally the certification authority that issued the certificate. Certificates are typically made available to a wide audience to enable them to verify electronic signatures for authenticity and validity.

[0052] A certificate can be associated with an electronic signature if the private key associated with the public key was used to generate the electronic signature to be verified. By making a certificate associated with a public key available to the public, a CDA enables users of asymmetric cryptosystems to associate the public key with an identity, such as a person, an organization, an energy system, or a computer system.

[0053] Asymmetric key pairs are used in a variety of cryptosystems and also play an important role in signing electronic documents. An asymmetric key pair consists of a public key, which is used to encrypt and / or decrypt data and may be shared with third parties, and a private key, which is used to encrypt and / or decrypt data and must generally be kept secret. The public key allows anyone to encrypt data for the owner of the private key and to verify digital signatures created with the private key. A private key allows its owner to decrypt data encrypted with the public key or to create digital signatures. A signature created with a private key can be verified with the corresponding public key.

[0054] The creation of a digital signature, hereinafter referred to simply as a "signature," is a cryptographic process in which an additional data value, referred to as a "signature," is calculated for any given piece of data. A signature can, for example, be a hash value of the source data encrypted with a private cryptographic key.

[0055] An "encrypted end-to-end connection" or an "encrypted end-to-end transmission channel" is understood here as a connection between a sender and a receiver with end-to-end encryption, in which the data to be transmitted is encrypted by the sender and only decrypted by the receiver. The encryption of transmitted data thus occurs across all transmission stations, so that intermediate stations cannot gain knowledge of the content of the transmitted data due to the encryption. The connection is cryptographically secured by encryption to prevent spying and / or manipulation of the transmission. A so-called secure messaging procedure can be used for this purpose.For example, end-to-end encryption is based on two symmetric cryptographic keys, with a first symmetric key being used to encrypt messages and a second symmetric key being used to authenticate the sender of the message.

[0056] Embodiments may have the advantage of enabling secure management of digital identities using a mobile device. For this purpose, the application program may be configured as an ID application program for managing digital identities or identity attributes associated with or defining digital identities. For example, a secure application program or application for managing digital identities is provided, which is referred to below as an ID application program.

[0057] The second security element is assigned to the ID application program, which is installed and executed on the mobile device. For example, a security applet is assigned to the ID application program, which is installed and executed on the second security element of the mobile device. The mobile device with the digital identities managed by the ID application program can be used for identification and authentication, for transmitting identity data, and for supporting declarations of intent in a mobile context.

[0058] According to embodiments, the digital identity may comprise an officially recognized identity, such as a digital identity created on the basis of an official identification document, such as an identity card or passport.

[0059] A user's digital identity is unambiguous, meaning unique and unmistakable. It is defined based on characteristics, so-called identity attributes. A digital identity includes, for example, personal data. Personal data refers to data that enables the identification of a person or can be assigned to a person to whom the personal data relates.

[0060] A user can have multiple different, application-specific digital identities. These digital identities can meet different security requirements.

[0061] According to embodiments, a digital identity stored on the mobile terminal and provided or managed by the ID application program can be used to identify and authenticate the user of the mobile portable device without additional hardware besides the mobile terminal.

[0062] Identity attributes are requested, for example, by service providers or online service providers. According to some embodiments, the identity attributes required by a service provider for its online service are transmitted in an encrypted and authentic manner. For example, authorization certificates are used to regulate who is authorized to access which identity attributes or who has read authorization for them. For example, the required identity attributes are read by an ID provider authorized to do so by means of an authorization certificate and made available to the requesting service provider. According to some embodiments, the ID provider only provides the requesting service provider with confirmation of the requested identity attribute(s).

[0063] The user's consent to the use of identity attributes and / or user authentication occurs, for example, through authentication, i.e. by checking one or more authentication factors, such as a password, PIN, or a biometric feature, for example a fingerprint or facial recognition.

[0064] According to embodiments, the challenge-response method comprises generating a response and validating the response. Generating the response comprises signing the challenge, and validating the response comprises verifying the signature.

[0065] Embodiments can have the advantage that knowledge of the first security element can be verified through signing, for example in the form of the signature key used for signing, i.e., a private cryptographic key, without the corresponding knowledge itself having to be transmitted for verification. For example, since only the first security element has access to the private cryptographic key used for signing, only this element can create the signature, which can be successfully verified for validity using the associated public cryptographic key. If the signature verification with the corresponding public cryptographic key is successful, the origin of the signature is verified.Thus, the first security element can be authenticated by the second security element and / or the security applet of the second security element in an efficient, effective, and secure manner through the challenge-response procedure. Since the prerequisite for sending the response is successful authentication of the user by the first security element, the successful challenge-response procedure also confirms and proves successful user authentication. Thus, the challenge-response procedure performs user authentication with the second security element and / or the security applet of the second security element using the first security element.

[0066] If a cryptographic key of sufficient length is used for the signature, this can have the advantage of increasing the entropy and thus the security of the authentication process.

[0067] According to one embodiment, the public cryptographic key of the first security element is provided to the second security element as part of a certificate. According to one embodiment, the second security element comprises a certificate that includes the public cryptographic key of the asymmetric key pair of the first security element.

[0068] Depending on the embodiment, the certificate is a certificate from a Public Key Infrastructure (PKI).

[0069] According to embodiments, the terminal device comprises the second security element.

[0070] According to embodiments, the second security element is provided by an external server.

[0071] Embodiments may have the advantage of providing the possibility of using a remote second security element, i.e., a remote security element, on an external server to provide cryptographic functions for an application program installed on a mobile terminal. A corresponding security element comprises, for example, cryptographic keys for executing cryptographic protocols, such as encryption, decryption, and / or signatures. A corresponding security element therefore does not have to be implemented on the mobile terminal itself, but can be provided for the mobile terminal by a server that communicates with the mobile terminal via a network.

[0072] For example, the remote security element can be used for encrypted communication between the application program installed on the mobile device and the reading computer system. For example, one or more electronic identities are stored on the mobile device. The electronic identities each comprise one or more identity attributes. The corresponding identity attributes are stored, for example, in encrypted form on the mobile devices. For example, the mobile device does not have one or more cryptographic keys for decrypting the encrypted identity attributes. For example, the identity attributes of different electronic identities are encrypted with different cryptographic keys. The cryptographic key(s) for decrypting the identity attributes are stored, for example, in the remote security element.Thus, the mobile device, and thus the user of the mobile device, has control over the identity attributes, while their cryptographic security is performed by the remote security element. Thus, on the one hand, the cryptographic security of the identity attributes can be outsourced to a remote server, while the user still retains control over the identity attributes. This means that the user can decide which identity attributes are made available to which computer system for reading. Without involving the mobile device, and thus the user of the mobile device, no identity attributes can be made available.

[0073] If identity attributes are to be read, the server receives the corresponding identity attributes to be read from the application program installed on the mobile device, which manages the associated electronic identity. The server's remote second security element decrypts the identity attributes to be read using a cryptographic key assigned to the electronic identity. The cryptographic key is, for example, a symmetric cryptographic key stored in the remote security element. For example, the security module is implemented in the form of a hardware security module (HSM) of the server. The corresponding security element can, for example, comprise a security applet assigned to the corresponding application program.For example, the corresponding cryptographic key for decrypting the identity attributes is stored in a sub-security domain of the security element assigned to the electronic identity. The decrypted identity attributes to be read are encrypted by the second security element using an ephemeral symmetric key. The corresponding ephemeral symmetric cryptographic key was generated, for example, during the establishment of a cryptographically secured communication channel between the remote second security element and the reading computer system. The corresponding ephemeral symmetric cryptographic key is stored, for example, in the remote second security element to secure communication with the reading computer system. Communication between the remote second security element and the reading computer systemThe connection between the server on the one hand and the reading computer system on the other hand takes place, for example, via the application program or the mobile device. The server sends encrypted identity attributes to the reading computer system using the ephemeral symmetric key.

[0074] Embodiments can have the advantage that hardware-based security of electronic identities can be provided on hardware independent of the mobile device, i.e., using the remote second security element ("remote secure element"), independent of the hardware and software configuration of the mobile device itself. For example, integrity, authenticity, and accountability of the electronic identities can be provided, for example, through authentication using the remote security element. Furthermore, decentralized storage of identity data on the mobile device can be enabled, whereby the user of the mobile device retains control over the identity attributes of their electronic identities. Furthermore, secure verification of the electronic identities on the mobile device can be ensured using suitable cryptographic methods.Finally, a variable and interchangeable use of authentication methods can be enabled.

[0075] According to embodiments, the second security element comprises a security applet associated with the application program. The security applet includes cryptographic means for executing a challenge-response procedure. Confirmation of the user's successful authentication to the application program is performed by the security applet.

[0076] According to embodiments, the method further comprises providing the asymmetric key pair. The asymmetric key pair can be generated, for example, by the first security element.

[0077] According to embodiments, providing the asymmetric key pair of the first security element comprises: Generating the asymmetric key pair by the first security element, transmitting the public cryptographic key of the asymmetric key pair of the first security element to the second security element.

[0078] Embodiments may have the advantage that the private cryptographic key of the symmetric key pair generated by the first security element does not leave the first security element and can be securely shared with the security applet. This ensures that only the first security element is able to use the private cryptographic key.

[0079] According to embodiments, the first security element sends the public cryptographic key of the asymmetric key pair of the first security element directly to the second security element.

[0080] According to embodiments, the mobile terminal comprises a communication interface for communication over a network. Transmitting the public cryptographic key of the asymmetric key pair of the first security element comprises: Sending the public cryptographic key of the asymmetric key pair of the first security element to the application program, forwarding the public cryptographic key of the asymmetric key pair of the first security element from the application program using the communication interface over the network to an external provisioning server that has write permission to write to a memory area of ​​the second security element, validating the write permission of the provisioning server to write to the memory area of ​​the second security element, upon successful validation of the write permission of the provisioning server, granting the external provisioning server write access to the memory area of ​​the second security element via the communication interface,Writing the public cryptographic key of the asymmetric key pair of the first security element into the memory area of ​​the second security element.

[0081] Embodiments may have the advantage that the security of the second security element or the security applet of the second security element can be increased. External cryptographic data, such as the public cryptographic key of the first security element, can, for example, only be introduced into the second security element by an external entity that can prove authorization to do so, for example, using an authorization certificate. In one embodiment, the external entity is, for example, the provisioning server. For example, the external entity is under the control of the developer / manufacturer of the application program and / or the security applet.For example, the external entity was a trusted third party independent of the developer / manufacturer of the application program, which was authorized by the developer / manufacturer of the application program to incorporate external key material and / or external keys into the second security element and / or the security applet, for example, on behalf of the developer / manufacturer of the application program and / or with the consent of the developer / manufacturer of the application program. In order to incorporate external key material and / or external keys into the security applet, possession of and / or access to the mobile device, for example, is not sufficient. Rather, additional control over an external entity independent of the mobile device is required.

[0082] According to embodiments, the provision of the asymmetric key pair of the first security element takes place in the course of initializing the first security element by an external initialization server, wherein the initialization server comprises a write authorization for initializing the first security element, wherein the initialization comprises: Generating the asymmetric key pair of the first security element by the first security element, validating the write authorization of the initialization server to initialize the second security element, upon successful validation of the write authorization of the initialization server, granting the external initialization server write access to the second security element via the communication interface, initializing the first security element, writing the asymmetric key pair of the first security element into the initialized memory area.

[0083] Embodiments can have the advantage that the security of the first security element can be increased, since, for example, there are only two ways to introduce cryptographic key material into the first security element: Either the corresponding cryptographic keys are generated by the first security element itself or they are introduced by an external entity that can prove authorization to do so, for example, using an authorization certificate. The corresponding external entity is, for example, an initialization server, which introduces the corresponding key material, such as an asymmetric key pair, into the first security element during its initialization. For example, the external entity is under the control of the device manufacturer of the mobile device.For example, the external entity was a trusted third party independent of the device manufacturer of the mobile device, which was authorized by the developer / manufacturer of the application program to incorporate external key material and / or external keys into the first security element, for example, on behalf of the device manufacturer and / or with the consent of the device manufacturer. In order to incorporate external key material and / or external keys into the first security element, possession of the mobile device and / or access to the mobile device is not sufficient, for example. Rather, additional control over an external entity independent of the mobile device is required.

[0084] For example, during the creation of the asymmetric key pair, a certificate, such as a PKI certificate, is also generated with or for the public cryptographic key of the first security element. For example, the public cryptographic key of the first security element is made available by the initialization server or first security element to a provisioning server for incorporation into the second security element.

[0085] According to embodiments, the method further comprises: Sending the public cryptographic key of the asymmetric key pair of the first security element from the external initialization server to the external provisioning server, which has write authorization to write to a storage area of ​​the second security element, validating the write authorization of the provisioning server to write to the storage area of ​​the second security element, upon successful validation of the write authorization of the provisioning server, granting the external provisioning server write access to the storage area of ​​the second security element via the communication interface, writing the public cryptographic key of the asymmetric key pair of the first security element to the storage area of ​​the second security element.

[0086] According to embodiments, the method further comprises initializing the security applet in the second security element by an external initialization server. The initialization server includes write permission to initialize the security applet in the second security element. The initialization comprises: Validating the write authorization of the initialization server to initialize the security applet in the second security element, upon successful validation of the write authorization of the initialization server, granting write access of the external initialization server to the second security element via the communication interface, initializing the memory area of ​​the second security element assigned to the security applet, writing an asymmetric key pair of the security applet into the initialized memory area.

[0087] Embodiments may have the advantage that the security of the second security element or the security applet of the second security element can be increased, since, for example, there are only two ways to introduce cryptographic keys into the security applet: Either the corresponding cryptographic keys are generated by the security applet itself or they are introduced by an external entity that can prove authorization to do so, for example, using an authorization certificate. For example, the external entity is under the control of the developer / manufacturer of the application program and the security applet.For example, the external instance could be a trusted third party independent of the developer / manufacturer of the application program, which was authorized by the developer / manufacturer of the application program to introduce external key material and / or external keys into the security applet, for example on behalf of the developer / manufacturer of the application program and / or with the consent of the developer / manufacturer of the application program. In order to introduce external key material and / or external keys into the security applet, possession of the mobile device and / or access to the mobile device is not sufficient, for example. Rather, additional control over an external instance independent of the mobile device is required. In one embodiment, the external instance is, for example, the initialization server.The initialization server can be dependent on, identical to, and / or independent of the provisioning server. For example, the initialization server of the second security element and / or the security applet of the second security element is a different initialization server from the initialization server of the first security element. For example, the initialization server of the second security element and / or the security applet of the second security element is an initialization server of the developer / manufacturer of the application program or an entity authorized by the developer / manufacturer of the application program, while the initialization server of the first security element is an initialization server of the device manufacturer.

[0088] Embodiments may have the advantage that the public cryptographic key of the asymmetric key pair of the first security element generated by or for the first security element can be securely shared with the second security element.

[0089] According to embodiments, communication in the course of the challenge-response procedure between the first security element and the second security element, for example the security applet, takes place via the application program.

[0090] Embodiments may have the advantage that the application program can use the challenge-response method itself. According to embodiments, the application program can thereby authenticate itself to the second security element and / or security applet. For example, the second security element and / or security applet sends the challenge to the application program, which responds in the course of the challenge-response method with a response provided by the first security element. This response serves as proof of ownership. For example, the response includes the challenge encrypted with the private cryptographic key of the first security element and thus proves ownership of the corresponding private cryptographic key.From the perspective of the second security element and / or security applet, the application program can authenticate itself to the second security element and / or security applet using the response, or is authenticated by the second security element and / or security applet. The private cryptographic key of the first security element therefore represents an authentication key for authenticating the application program. The public cryptographic key of the first security element therefore represents an authentication key for authenticating the application program. For example, the private cryptographic key is stored in a protected memory area of ​​the first security element.Access to the private cryptographic key in the protected memory area of ​​the first security element requires, for example, successful user authentication to the first security element using the authentication sensor. Access is therefore protected by user authentication. After successful user authentication by the first security element and successful authentication of the application program using the response provided by the first security element, the second security element can be used and / or the security applet of the second security element can be called by the application program and / or via the application program. For example, the second security element and / or the security applet of the second security element can be called by an external server via a client module of the application program.The second security element can be provided, for example, on the mobile device or another external server. According to embodiments, a prerequisite for the external server to call the second security element and / or the security applet of the second security element is successful authentication of the server for the call to the application program and / or to the second security element or the security applet of the second security element. Such authentication can, for example, comprise the use of an authorization certificate by the external server, which verifies the external server's authorization to access the second security element and / or the security applet of the second security element.

[0091] According to embodiments, access to the second security element and / or the security applet of the second security element, which is assigned to the application program, is only possible via the application program. Embodiments can have the advantage of increasing the security of the second security element and / or the security applet of the second security element and protecting it from unauthorized access.

[0092] Depending on the embodiment, the challenge-response procedure includes: Sending the challenge of the second security element, for example the security applet, to the application program, forwarding the challenge from the application program to the first security element upon successful authentication of the user by the operating system, generating the response by the first security element, sending the response from the first security element to the application program, forwarding the response from the application program to the second security element, for example the security applet, validating the decrypted response by the security applet.

[0093] Embodiments may have the advantage that the application program itself can use the challenge-response method, for example, for authentication against the second security element and / or the security applet of the second security element. If access to the second security element and / or the security applet of the second security element is only possible via the application program, the security of the second security element and / or the security applet of the second security element can be increased and protected from unauthorized access.

[0094] According to some embodiments, the authentication request includes the challenge, and the response is generated upon successful user authentication. Some embodiments may have the advantage that the challenge-response process can be implemented in an efficient and effective manner. At the same time, the response verifies and confirms the user's successful authentication.

[0095] Depending on the embodiment, authenticating the user includes: Detecting at least one authentication factor of the user using the authentication sensor, validating the detected authentication factor using the first security element.

[0096] Embodiments may have the advantage of providing an effective and secure method for authenticating the user.

[0097] According to embodiments, confirming the successful authentication of the user comprises sending an authentication confirmation of the second security element, for example the security applet, to the application program upon successful validation of the response.

[0098] Embodiments may have the advantage that the authentication is confirmed to the application program. Furthermore, the application program can use the authentication confirmation as proof of successful authentication. According to embodiments, the presence of an authentication confirmation is a prerequisite for executing one or more functions of the application program.

[0099] According to embodiments, the application program is an ID application program that is configured to manage one or more identity attributes associated with the user.

[0100] Embodiments may have the advantage that the one ID application program can provide one or more digital identities of the user based on the identity attributes. By authenticating the user to the ID application program, a cryptographically secured link between the real world, i.e., the user's identity, and the digital world, i.e., the digital identity attributes assigned to the user, can be implemented using the first security element and the second security element and / or the security applet of the second security element.

[0101] According to embodiments, the use of identity attributes requires successful authentication of the user of the mobile device.

[0102] The identity attributes define, for example, a digital identity. This digital identity may be based on a primary identity provided by an ID token and / or derived from this primary identity. According to embodiments, the digital identity may be a copy of the primary identity.

[0103] According to embodiments, the digital identity provided by the mobile device can be used to authenticate and / or identify the user without additional user-side hardware.

[0104] According to embodiments, the identity attributes are read from an ID token, which provides a primary identity comprising the identity attributes. Reading can be performed, for example, contactless, such as using NFC communication. In this case, the mobile device comprises, for example, a communication interface for contactless communication, such as NFC communication. An ID token is understood here to be a device, in particular an electronic device such as an electronic identification document, which provides a primary identity comprising identity attributes for identification purposes. The device can be, for example, a so-called USB stick, a chip card, or a document.In particular, an ID token is understood to be a portable electronic device comprising a processor for executing program instructions and a memory for storing program instructions. The identity attributes are stored in the memory and can be provided, using the processor, upon request for verification purposes via a communication interface of the ID token. The communication interface is, for example, a contactless communication interface.

[0105] A document is understood to mean, in particular, an identification, valuables, or security document, in particular a sovereign document with electronic means, such as a processor, memory, and communication interface, in particular a paper-based and / or plastic-based document, such as an electronic identification document, in particular a passport, identity card, visa, driver's license, vehicle registration document, vehicle registration document, health card, or a company ID, or another ID document, a chip card, means of payment, in particular a banknote, bank card, or credit card, a waybill, or other proof of authorization. In particular, the ID token can be a Machine-Readable Travel Document, as standardized, for example, by the International Civil Aviation Organization (ICAO) and / or the BSI.

[0106] According to embodiments, the ID token does not have its own power supply. Rather, the energy source can be a device for harvesting energy, which is transmitted from the mobile device to the ID token, for example, using communication interfaces configured as RFID antennas.

[0107] According to embodiments, the ID application program is configured to send one or more of the user's identity attributes to another terminal. Embodiments may have the advantage that sending the user's identity attributes requires successful authentication of the user of the mobile terminal. Thus, secure use of the identity attributes can be ensured solely by the user and / or with their consent.

[0108] The identity attributes can be sent, for example, using a wireless communication connection, such as an NFC connection, a Bluetooth connection, or a WiFi connection.

[0109] According to embodiments, the ID application program is configured to send one or more of the user's identity attributes using the communication interface over a network to an ID provider server for provision to a service provider server and / or for confirmation to the service provider server.

[0110] Embodiments may have the advantage that a secure provision of the user's identity attributes can be ensured, wherein the provision requires user authentication and wherein the provision is only carried out by an authorized external entity, ie the ID provider.

[0111] Sending identity attributes to the ID provider server requires, for example, authentication of the ID provider server, proof of authorization by the ID provider server to access the identity attributes, establishment of an encrypted channel for the secure transmission of the identity attributes, and / or assurance of the authenticity of the transmitted identity attributes. For this purpose, the second security element and / or the security applet of the second security element provides cryptographic means. The cryptographic means include, for example, an asymmetric key pair of the second security element or the security applet, in particular a private cryptographic key of the second security element or the security applet, as well as cryptographic protocols for calculating ephemeral session keys, in particular symmetric ephemeral session keys.

[0112] The authenticity of the transmitted identity attributes can be ensured, for example, by using a Message Authentication Code (MAC). The cryptographic protocols provided by the second security element and / or by the security applet of the second security element are configured, for example, to calculate a MAC, i.e., comprise a MAC algorithm. A MAC is calculated, for example, using a MAC algorithm to which data to be protected, i.e., the identity attributes, and a cryptographic key, for example, a symmetric cryptographic key, are provided as input data. Using this input data, the MAC algorithm calculates a checksum, which serves as the MAC. Block ciphers or hash functions, for example, can be used to calculate a MAC.For example, an HMAC (Keyed-Hash Message Authentication Code) can be used as a MAC, which is constructed using a cryptographic hash function, such as the Secure Hash Algorithm (SHA), and a cryptographic key, such as a symmetric cryptographic key.

[0113] To secure a data transmission, for example a transmission of identity attributes, a cryptographic key, for example a symmetric cryptographic key, is agreed between the sender, for example the second security element and / or the security applet of the second security element, and the receiver, for example the ID provider server. The sender uses this cryptographic key to calculate a MAC of the data to be transmitted and sends the calculated MAC together with the data to be transmitted to the receiver. The transmitted data is then encrypted, for example, with the same cryptographic key. The receiver decrypts the received data using the cryptographic key and, in turn, calculates a MAC for the received data using the cryptographic key. The receiver compares the result with the received MAC.If there is a match between the calculated MAC and the received MAC, the integrity check is successful and the received data is considered authentic.

[0114] In the case of a MAC, both sender and receiver must know the cryptographic key used, in contrast to the use of pure hash functions or signatures. In the case of pure hash functions, for example, no cryptographic keys are used. If the hash functions are public, anyone can calculate the hash value, especially for manipulated messages. In the case of a signature, only the signer knows the private cryptographic key used to create the signature (i.e., the signature key) of an asymmetric key pair used for the signature. The signature recipient only has the public key (i.e., the signature verification key) of the asymmetric key pair used for the signature. The signature recipient can therefore verify the signature using the signature verification key, but cannot calculate it themselves.

[0115] For example, a digital identity provided by the mobile device can be used to access a web service provided by a service provider server. For example, the ID application program can be used to register with the web service. To do so, the user accesses a website of the service provider using a mobile browser on the mobile device or contacts the service provider using a service provider application program installed on the mobile device. For example, the user clicks a login button. For example, the user selects registration using the ID application program. The ID application program is then launched, and the user is prompted by the ID application program to authenticate themselves to the ID application program using the mobile device.For this purpose, the user uses the mobile device with the first security element and provides it with authentication factors or authentication data for authentication using the authentication sensor. Upon successful authentication of the user to the ID application program, a secure connection is established between the second security element and / or the security applet of the second security element on the one hand and the service provider server on the other. For example, the secure connection is an encrypted connection, in particular one encrypted using end-to-end encryption. For example, the establishment of the secure connection includes mutual authentication of the reading service provider server and the second security element or security applet of the second security element, i.e.Authentication of the reading server by the second security element and / or by the security applet of the second security element, and authentication of the second security element and / or the security applet of the second security element by the reading server. This connection, secured, for example, by encryption, can be used to transmit identity attributes required for registration, such as the user's personal data such as first name, last name, date of birth, address, etc., to the service provider server. Depending on the embodiment, the user can see which type of personal data should be forwarded to the service provider server and can consent to its transmission through user authentication.In case of successful user verification, the required identity attributes are sent to the service provider server and the user is redirected to an authenticated web session with the service provider.

[0116] According to embodiments, the ID application program comprises an ID management module that manages a plurality of ID profiles, wherein each of the ID profiles is assigned an independent security applet in the second security element.

[0117] Embodiments can have the advantage that a plurality of different ID profiles and thus digital identities of the user can be managed by the ID application program. Each of these digital identities of the user is assigned its own security applet that is independent of the other security applets. Thus, each digital identity is secured by its own security applet. For example, one or more of the digital identities are digital identities of the user that the ID application program manages for other instances, such as other application programs and / or service providers. For example, different security levels can be assigned to the different ID profiles or digital identities, which must be fulfilled by the respectively assigned security applet. Furthermore, different ID profiles orFor each digital identities, different authentication factors must be defined in the first security element and assigned to the respective profile or the security applet associated with the respective profile. Therefore, in this case, the user must provide different authentication factors for different digital identities for successful authentication. The individual authentication factors and / or their combinations can meet different security levels, for example, due to different entropies.

[0118] According to embodiments, each of the ID profiles is assigned a set of one or more identity attributes. The sets of identity attributes originate, for example, from an ID token.

[0119] Embodiments further include a system. The system includes a mobile terminal for authenticating a user against an application program installed on a mobile terminal. The mobile terminal includes a processor. An operating system is installed on the terminal, which is configured to control at least one authentication sensor of the terminal for detecting at least one authentication factor of the user. The terminal further includes a first security element associated with the operating system, which includes cryptographic means for executing a challenge-response method. A private cryptographic key of an asymmetric key pair of the first security element is stored in a protected memory area of ​​the first security element.

[0120] The system further comprises a second security element independent of the first security element, which comprises cryptographic means for executing a challenge-response method.

[0121] The processor is configured to perform a method for authenticating a user to an application program installed on a mobile device, which method comprises: in response to an authentication request from the application program, authenticating the user by the operating system using the authentication sensor and the first security element, executing a challenge-response method between the first security element and the second security element, wherein the challenge-response method comprises generating a response by the first security element for validation by the second security element, wherein generating the response comprises encrypting a challenge of the second security element by the first security element using the private cryptographic key of the first security element for validation by decrypting the response of the first security element by the second security element using a public cryptographic key of the asymmetric key pair of the first security element,wherein a successful execution of the challenge-response procedure confirms a successful authentication of the user by the operating system, upon a successful execution of the challenge-response procedure, confirmation of the successful authentication of the user to the application program by the second security element. ,

[0122] According to embodiments, the mobile terminal and / or the system is configured to execute each of the previously described embodiments of the method for authenticating the user to the application program installed on the mobile terminal.

[0123] According to embodiments, the terminal device comprises the second security element.

[0124] According to embodiments, the terminal device comprises a communication interface for communication via a network, wherein the system further comprises a server which provides the second security element.

[0125] According to embodiments, the system further comprises an initialization server. The initialization server is configured to initialize the first security element and includes write permission to initialize the first security element.

[0126] Initialization includes: Generating the asymmetric key pair of the first security element by the first security element, validating the write authorization of the initialization server to initialize the second security element, upon successful validation of the write authorization of the initialization server, granting the external initialization server write access to the second security element via the communication interface, initializing the first security element, writing the asymmetric key pair of the first security element into the initialized memory area.

[0127] According to embodiments, the system is configured to perform any of the previously described embodiments of initializing the first security element.

[0128] According to embodiments, the system comprises a further initialization server for initializing the second security element and / or a security applet in the second security element, which comprises a write authorization for initializing the second security element and / or the security applet in the second security element.

[0129] Initialization includes: Validating the write authorization of the further initialization server for initializing the security applet in the second security element, upon successful validation of the write authorization of the further initialization server, granting write access of the further external initialization server to the second security element via the communication interface, initializing the memory area of ​​the second security element assigned to the security applet, writing the first asymmetric key pair into the initialized memory area.

[0130] According to embodiments, the system is configured to execute each of the previously described embodiments of the method for initializing the second security element and / or the security element of the second security element.

[0131] According to embodiments, the system further comprises a provisioning server. The provisioning server is configured to provision the second security element and includes a write permission for writing to a memory area of ​​the second security element.

[0132] Provisioning includes: Receiving a public cryptographic key of the asymmetric key pair of the first security element, validating the write authorization of the provisioning server to write to the storage area of ​​the second security element, upon successful validation of the write authorization of the provisioning server, granting the external provisioning server write access to the storage area of ​​the second security element via the communication interface, writing the public cryptographic key of the asymmetric key pair of the first security element to the storage area of ​​the second security element.

[0133] According to embodiments, the system is configured to perform each of the previously described embodiments of the method for provisioning the second security element.

[0134] According to embodiments, the system further comprises an ID provider server. The application program is an ID application program configured to manage one or more identity attributes stored in the mobile device and assigned to the user. The ID provider server is configured to provide and / or confirm one or more of the user's identity attributes to a service provider server and includes read authorization to read one or more of the user's identity attributes. Providing and / or confirming one or more of the user's identity attributes to a service provider server comprises: Validating the ID provider server's read authorization to read one or more of the user's identity attributes, upon successful validation of the read authorization, sending one or more of the user's identity attributes to the ID provider server, signing the sent one or more of the user's identity attributes by the ID provider server, sending the signed one or more of the user's identity attributes to the service provider server.

[0135] According to embodiments, the system is configured to perform each of the previously described embodiments of the method for providing user attributes.

[0136] Embodiments of the invention will be explained in more detail below with reference to the drawings. They show: Figure 1 is a schematic diagram of an exemplary mobile terminal, Figure 2 is a schematic diagram of an exemplary mobile terminal, Figure 3 is a flowchart of an exemplary method for authenticating a user, Figure 4 is a flowchart of an exemplary method for authenticating a user, Figure 5 is a schematic diagram of an exemplary mobile terminal, Figure 6 is a flowchart of an exemplary method for provisioning a public cryptographic key, Figure 7 is a flowchart of an exemplary method for initializing a memory area of ​​a security element, and Figure 8 is a flowchart of an exemplary method for initializing a memory area of ​​a security applet, Figure 9 is a schematic diagram of an exemplary system, and Figure 10 is a schematic diagram of an exemplary server providing a remote security element.

[0137] Elements of the following embodiments that correspond to one another are identified by the same reference numerals.

[0138] Figure 1shows an exemplary mobile device 100, for example a smartphone, which comprises a memory 104 with program instructions that are executed by a processor 102. The program instructions can, for example, comprise an operating system 106 installed on the mobile device 100 and an application program 108. Furthermore, the mobile device comprises a first security element 110. For example, the mobile device 100 further comprises a second security element 112. The security elements 110, 112 can each be implemented, for example, as an eSim and / or eUICC. The first security element 110 is assigned to the operating system and provides cryptographic means for it, such as cryptographic keys, cryptographic functions and / or cryptographic protocols. The first security element 110 represents, for example, a key store orKey storage is provided for storing cryptographic keys, such as symmetric, public, and / or private cryptographic keys, and certificates, such as authorization certificates, public key certificates, and / or attribute certificates. The cryptographic means provided by the first security element 110 enable the operating system 106 to execute or participate in a challenge-response procedure. For this purpose, the cryptographic means comprise, for example, a private cryptographic key of an asymmetric key pair of the first security element, which is stored in a protected memory area of ​​the first security element. The corresponding private cryptographic key serves, for example, as a signature key for signing a challenge in the course of generating a response to the challenge.

[0139] For example, a security applet 114 assigned to the application program 108 is installed on the second security element 112. This security applet 114 provides cryptographic means for the application program 108, such as cryptographic keys, cryptographic functions, and / or cryptographic protocols. The security applet 114 or a memory area of ​​the second security element 112 assigned to the security applet 114 provides, for example, a key store for storing cryptographic keys, such as symmetric, public, and / or private cryptographic keys, and certificates, such as authorization certificates, public key certificates, and / or attribute certificates. The cryptographic means provided by the second security element 112 enable the application program 108 to execute a challenge-response procedure.to participate in it. For this purpose, the second security element 112 and / or the security applet 114 of the security element has, for example, a public cryptographic key of the asymmetric key pair of the first security element. The corresponding public cryptographic key serves, for example, as a signature verification key for verifying a signature of a signed challenge, which is received as a response to the corresponding challenge in the course of a challenge-response procedure.

[0140] Furthermore, the mobile device 100 comprises a user interface 116, which, for example, comprises a display, in particular a touchscreen. Using the user interface 116, the user can interact with the mobile device 100. For example, the user can be prompted to provide authentication data or authentication features. To capture the user's authentication data, the mobile device 100 comprises a sensor or authentication sensor 118, which can, for example, be integrated into the user interface 116 or implemented as a standalone component. The authentication data can, for example, include the user's biometric data, such as: fingerprint data, body geometry data / anthropometry data, such as facial, hand, or ear geometry data, hand line structure data, vein structure data, such as hand vein structure data, iris data, retina data, voice recognition data, and nail bed patterns.The authentication data can, for example, include user knowledge, such as a PIN or password. Furthermore, the authentication data can, for example, include behavioral characteristics or behavioral data of the user, such as movement data of the mobile device 100, which are caused by gross and / or fine motor movements of the user when the user carries and / or uses the mobile device 100. Appropriate authentication of the user can, for example, be a prerequisite for releasing identity attributes of the electronic identity for reading by a reading computer system. Appropriate user authentication can, on the one hand, ensure that the mobile device 100 is being used by an authorized user.Secondly, the provision of authentication data by the user can represent the user's consent to the reading of the identity attributes of the electronic identity by the reading computer system. Finally, the mobile terminal 100 comprises a communication interface or antenna 120, which is configured for wireless communication, for example, via a network. For example, communication with the reading computer system can take place via a network, such as an intranet or the Internet.

[0141] Figure 2shows an exemplary mobile device 100 on which an operating system 106 is installed, which manages the resources of the mobile device 100 and makes them available to the application program 108. The managed resources include, for example, a first security element 110. Furthermore, the resources can include, for example, a second security element 112. In addition, the resources include the authentication sensor 118, the user interface 116, and the communication interface 120. Although the second security element 112 is provided or managed, for example, by the operating system 106, the security applet 114 included in the second security element 112 is assigned to the application program 108, i.e., the security applet 114 only makes cryptographic means available to the application program 108. The operating system 106 cannot use these cryptographic means.For cryptographic tasks, for example in the course of using the authentication sensor 118 or the communication interface 120, the first security element 110 with its cryptographic means is available to the operating system 106.

[0142] Figure 3shows an exemplary method for authenticating a user to an application program installed on a mobile device. In step 300, the application program (app) submits an authentication request to the operating system of the mobile device to authenticate the user of the mobile device. The operating system causes an authentication sensor of the mobile device to detect one or more authentication features of the user. In step 302, the user is authenticated using the first security element based on the detected authentication features. According to embodiments, the detected authentication features are compared with stored reference features. If there is a sufficient match between the detected authentication features and the stored reference features, the authentication is successful.In step 304, the first security element receives a challenge of a challenge-response method for confirming successful user authentication. The challenge includes, for example, a nonce. According to embodiments, the challenge can be received before or after authentication. In particular, the authentication request can include the challenge. The challenge is generated, for example, by the second security element and / or a security applet of the second security element and made available to the application program for executing the challenge-response method. In step 306, the first security element generates a response. For this purpose, the challenge is signed, for example, with a private cryptographic key of the first security element as a signature key.The corresponding private cryptographic key of the first security element is stored, for example, in a protected memory area of ​​the first security element. The response is sent from the first security element, for example via the application program, to the second security element and / or the security applet of the second security element. In step 308, the second security element and / or the security applet of the second security element receives the response and validates it in step 310. The second security element and / or the security applet of the second security element has a public cryptographic key of the first security element as a signature verification key for validating the response.To validate the response, the second security element and / or the security applet of the second security element decrypts the response. The result is, for example, a hash value of the challenge, which is compared with a hash value of the sent challenge. If the decryption result and the hash value of the sent challenge are identical, the challenge-response process is successful. In step 312, the second security element and / or the security applet of the second security element confirms the successful authentication of the user, for example, to the application program.

[0143] Figure 4shows an exemplary method for authenticating a user to an application program installed on a mobile device. In step 400, the second security element 112 and / or the security applet 114 on the second security element 112 sends a challenge, for example, a nonce, to the application 108. In step 402, the application program 108 sends the challenge to the first security element 110 in response to its receipt. The security element then initiates user authentication. In step 404, an authentication request is sent to the authentication sensor 118. For example, an authentication request for the user is also displayed on a display device of the mobile device, e.g., a display.In step 406, the authentication sensor 118 captures the user's authentication sensor data and provides it to the first security element in step 408 as a response to the authentication request. In step 410, the authentication sensor data is validated using the first security element 110. If the validation and thus the authentication is successful, the first security element 110 generates a response to the challenge in step 412. For this purpose, for example, the nonce of the challenge is signed with a private cryptographic key of the first security element, which is known only to the first security element 110. In step 414, the response is sent to the application program 108, which forwards the response in step 416 to the second security element 112 and / or the security applet 114 on the second security element 112 as a response to the challenge from step 400.

[0144] In step 418, the second security element 112 and / or the security applet 114 on the second security element 112 validates the received response. For example, the second security element 112 and / or the security applet 114 on the second security element 112 decrypts the response using a public cryptographic key of the first security element and compares the result with a hash value of the challenge sent in step 400. If both match, the validation is successful and valid user authentication is successfully verified. In step 418, to confirm successful authentication, for example, an authentication confirmation is sent from the security applet 114 to the application program.

[0145] Figure 5shows an exemplary mobile terminal 100 on which an application program 108 is stored, which is an ID application program. The ID application program manages identity attributes assigned to the user. For this purpose, it comprises an ID management module 111 with one or more ID profiles 113. Each of the ID profiles 113 is assigned an independent security applet 114 in the second security element 112. Each of the ID profiles 113 is assigned a set of one or more identity attributes. These identity attributes are, for example, each stored in a memory area of ​​the second security element 112, which is assigned to the corresponding security applet 114, and / or stored encrypted in a memory of the mobile terminal, wherein the cryptographic keys for decryption are stored in the corresponding security applets 114.The ID application program 108 further comprises an ID client module 109, via which the ID application program 108 can receive, for example, requests for identity attributes of one of the ID profiles 113. In response to the request, for example, from an ID provider service via a network, the ID application program 108 can provide the requested identity attributes, subject to user consent. For this purpose, user authentication to the ID application program 108 may be necessary, or proof of successful user authentication by the ID application program 108 using a challenge-response method may be necessary. For this purpose, a first security element 110 assigned to the operating system 106 is used, which confirms successful user authentication with an authentication sensor 118 of the mobile terminal 100.

[0146] Figure 6shows a method for providing the asymmetric key in the first security element 110 and the security applet 114 for the challenge-response method. In step 500, the first security element 110 generates an asymmetric key pair comprising a private cryptographic key PrK and a public cryptographic key PuK, for example, for use in the challenge-response method. In step 500, the first security element 110 stores the asymmetric key pair, with the private cryptographic key PrK being stored in a protected memory area of ​​a memory of the first security element 110.The first security element 110 sends the resulting public cryptographic key PuK to the application program 108 in step 504, which forwards the public cryptographic key PuK to a provisioning server 220 with write authorization for writing to a memory area of ​​the second security element assigned to the second security element and / or the security applet of the second security element in step 506. In step 508, the provisioning server 220 demonstrates its write authorization, for example, using an authorization certificate and / or a cryptographic key provided for this purpose. In step 510, the write authorization is validated.Upon successful validation of the write authorization, the provisioning server 220 is granted write access to the memory area of ​​the second security element, into which the provisioning server 220 writes the public cryptographic key PuK in step 512.

[0147] Figure 7shows a method for initializing the first security element 110 using an initialization server 200. In step 600, the initialization server 200 provides a write authorization for initializing the security applet in the second security element, which is validated in step 602. The write authorization can be verified, for example, by a corresponding authorization certificate and / or by using a cryptographic key provided for this purpose. The write authorization is provided, for example, via a cryptographically secured communication connection between the first security element 110 and the initialization server 200 or during the establishment of the corresponding cryptographically secured communication connection or a cryptographically secured communication channel.The cryptographically secured communication connection can, for example, be an end-to-end encrypted communication connection. Upon successful validation, the initialization server 200 is granted write access to the first security element 110 via the communication interface. In step 604, the initialization server 200 initializes a memory area of ​​the first security element 110 and, in step 606, writes an asymmetric key pair into the initialized memory area. Initializing the memory area includes, for example, writing a file system to the corresponding memory area. In step 608, for example, the first security element 110 makes the public cryptographic key of the asymmetric key pair of the first security element 110 available to the second security element and / or a security applet 112 on the second security element.For example, the provisioning of the public cryptographic key can also be carried out using a provisioning server 220, wherein the in . Figure 6 The 504 to 512 steps shown are executed.

[0148] Figure 8shows a method for initializing a security applet in a (second) security element 112 using an initialization server 201. In step 700, the initialization server 201 provides a write authorization for initializing the security applet in the second security element, which is validated in step 702. The write authorization can be verified, for example, by a corresponding authorization certificate and / or by using a cryptographic key provided for this purpose. The write authorization is provided, for example, via a cryptographically secured communication connection between the second security element 112 and the initialization server 201 or during the establishment of the corresponding cryptographically secured communication connection or a cryptographically secured communication channel.The cryptographically secured communication connection can, for example, be an end-to-end encrypted communication connection. Upon successful validation, the initialization server 201 is granted write access to the second security element via the communication interface. In step 704, the initialization server 201 initializes the memory area of ​​the second security element 112 assigned to the security applet and, in step 706, writes an asymmetric key pair into the initialized memory area. Initializing the memory area includes, for example, writing a file system to the corresponding memory area. In step 708, for example, the security applet 112 makes the public cryptographic key of the asymmetric key pair available to the first security element 110, for example via the application program.

[0149] Figure 9shows a system 170 comprising a mobile terminal 100 connected via a network 150, for example the Internet, to an initialization server 200, a provisioning server 220, an ID provider server 240 and / or a service provider server 260. The mobile terminal 100 is the mobile terminal 100 of Figure 1 .

[0150] The initialization server 200 comprises a processor 202, a memory 204 and a communication interface 210. Program instructions 208 are stored in the memory 204, upon execution of which the processor 202 controls the initialization server 200 to initialize the first security element 110 of the mobile terminal 100, for example according to the method in Figure 7. To prove a write authorization for initializing the security applet, the initialization server 200 uses, for example, the authorization certificate 206. Furthermore, for example, a further initialization server 201 configured analogously to the initialization server 200 can be used to initialize the second security element 112 and / or a security applet in the second security element 112 of the mobile terminal 100, for example according to the method in Figure 8 .

[0151] The provisioning server 220 comprises a processor 222, a memory 224 and a communication interface 230. Program instructions 228 are stored in the memory 204, upon execution of which the processor 222 controls the provisioning server 220 to provide a public cryptographic key of the first security element 110 for the challenge-response method in the second security element and / or in a security applet of the second security element 112, for example according to the method in Figure 6 To prove a write authorization to write the public cryptographic key of the first security element 110 into the second security element and / or into the security applet of the second security element 112, the provisioning server 220 uses, for example, the authorization certificate 226.

[0152] The service provider server 260 comprises a processor 262, a memory 264, and a communications interface 270. Program instructions 268 are stored in the memory 264. When executed, the processor 262 controls the service provider server 260 to provide services that can be requested and / or used, for example, by the mobile terminal 100 via the network 170. Using services from the service provider server 260 requires, for example, the provision and / or verification of one or more identity attributes of the user. Upon a request for a service from the service provider server 260 by the mobile terminal 100, the service provider server 260 sends an identity attribute request for identity attributes of the user of the mobile terminal 100 to an ID provider server 240.The identity attribute request can be sent from the service provider server 260 to the ID provider server 240, for example, directly or via the mobile terminal 100.

[0153] The ID provider server 240 comprises a processor 242, a memory 244, and a communication interface 250. Memory 244 stores program instructions 248, which, when executed, cause the processor 242 to instruct the service provider server 240 to read the identity attributes specified in the identity attribute request from a memory of the mobile terminal 100. To this end, the ID provider server 240 establishes a cryptographically secured communication channel with the mobile terminal 100. The cryptographically secured communication channel can, for example, be an end-to-end encrypted communication channel. For example, this requires mutual authentication of the ID provider server 240 and the mobile terminal 100. For read access to the identity attributes, the ID provider server 240 uses an ID application program 108 on the mobile terminal 100, which manages the identity attributes.The ID provider server 240 verifies read authorization for reading the identity attributes specified in the identity attribute request, for example, using the authorization certificate 248. Furthermore, read access by the ID provider server 240 to the identity attributes specified in the identity attribute request requires consent from the user of the mobile terminal 100. To do so, the user must successfully authenticate themselves to the ID application program 108, for example, using the method of [ ]. Figure 3 and 4For example, a display device of user interface 116 indicates to the user which identity attributes are to be sent to ID provider server 240, and allows the user to edit this selection. For example, the user can select which of the requested identity attributes are actually sent. Upon successful proof of read authorization and successful user authentication, the released identity attributes are sent to ID provider server 240. ID provider server 240 signs the received identity attributes and sends them to service provider server 260.

[0154] Figure 10shows an exemplary external server 280, which provides a remote second security element 292 for use by a mobile device or for an electronic identity managed by an application of the mobile device via a network. The server 280 further comprises, for example, a processor 282, a memory 284, and a communication interface 296. Program instructions 288 are stored in the memory 284 for reading identity attributes stored on the mobile device, which the application manages. The identity attributes to be read are made available to a reading computer system. Upon execution of the program instructions 288, the processor 202 controls the security management service server 240, for example, to receive the identity attributes to be read from the application using the communication interface 296.The identity attributes are encrypted using a cryptographic key associated with the electronic identity. The security element 292 has a cryptographic key 285 for decrypting the identity attributes. In the case of symmetric encryption, the cryptographic key 285 is, for example, the corresponding symmetric key. In the case of asymmetric encryption, the identity attributes are encrypted, for example, with a public cryptographic key, the corresponding private cryptographic key of which is stored as the cryptographic key 285 in the remote security element 292. The remote security element 292 decrypts the identity attributes to be read using the cryptographic key 285.Furthermore, the remote security element 292 encrypts the decrypted identity attributes to be read using an ephemeral symmetric cryptographic key 286 stored in the remote security element 292. The remote security element 292 shares this ephemeral symmetric cryptographic key 286, for example, with the computer system being read for communication encryption. Finally, the server 280 sends the encrypted identity attributes to be read to the computer system being read using the communication interface 296. For example, the server 280 sends the encrypted identity attributes to be read to the mobile terminal for forwarding to the computer system being read.

[0155] The remote security element 292 comprises, for example, a key ring 294 assigned to the application and / or the electronic identity. The key ring 294 provides the application 108 with identity-specific cryptographic keys for the electronic identity it manages. Furthermore, the remote security element 292 comprises, for example, further cryptographic means, such as cryptographic functions and / or cryptographic protocols, which the remote security element makes available to the application or the electronic identity for use. The key ring 294 is stored, for example, using a key store orA key store is provided for storing cryptographic keys for the individual electronic identity, such as symmetric, public and / or private cryptographic keys, and certificates, such as public key certificates and / or attribute certificates. The cryptographic means provided by the remote security element 292 enable the application 108, using the key ring 294 with the identity-specific cryptographic keys, to, for example, encrypt and / or decrypt data for the electronic identity managed by the application 108, as well as to create and / or verify signatures. For example, the cryptographic means provided by the remote security element 292 enable the application 108 to execute a challenge-response procedure for the electronic identity it manages.to participate in it. In particular, the cryptographic means of the application 108 comprise, for example, a public cryptographic key of the first security element of the mobile terminal. The security element 292 can be implemented, for example, as a hardware security module. A hardware security module refers to an internal or external peripheral device that enables efficient and secure execution of cryptographic operations and / or applications. Cryptographic keys used by the security module are stored there, for example, in software and protected against physical attacks or side-channel attacks.

[0156] For example, the server 280 further comprises a security management program module 290 of a security management service managing the security element 292. For example, the server 280 is a server of the security management service or a standalone server. The security management service provides, for example, the applet 294 for installation in the security element 294. For example, the server 280 comprises a plurality of security elements 292, each of which is managed by an individual security management service. For each of the security elements 292, for example, a security management program module 290 is installed on the server 280. For example, the server 280 comprises exactly one security element 292 or exclusively security elements 292 that are managed by the same security management service.For example, a plurality of servers 280 are provided, which are assigned to different security management services and comprise exclusively security elements 292, which are managed by the same security management service to which the corresponding server 280 is assigned. List of reference symbols

[0157] 100 Mobile device 102 Processor 104 Memory 106 Operating system 108 Application program 109 ID client 110 First security element 111 ID management module 112 Second security element 113 ID profile 114 Security applet 116 User interface 118 Authentication sensor 120 Communication interface 150 Network 170 System 200 Initialization server 201 Initialization server 202 Processor 204 Memory 206 Authorization certificate 208 Program instructions 210 Communication interface 220 Provisioning server 222 Processor 224 Memory 226 Authorization certificate 228 Program instructions 230 Communication interface 240 ID provider server 242 Processor 244 Memory 246 Authorization certificate 248Program instructions 250Communication interface 260Service provider server 262Processor 264Memory 266Program instructions 270Communication interface 280Server 282Processor 284Memory 285Cryptographic key 286Symmetric key 288Program instructions290Security management program module 292Security element 294Keychain 296Communication interface

Claims

1. A method for authenticating a user with respect to an application program (108) installed on a mobile terminal device (100), wherein an operating system (106) is installed on the terminal device (100), wherein the operating system (106) is configured to control at least one authentication sensor (118) of the terminal device (100) for detecting at least one authentication factor of the user, wherein the terminal device (100) comprises a first security element (110) associated with the operating system (106), wherein the first security element (110) comprises cryptographic means for executing a challenge-response method, wherein a private cryptographic key of an asymmetric key pair of the first security element (110) is stored in a protected memory area of the first security element (110), wherein a security element (112) independent of the first security element (110) and associated with the application program (108) is further provided, wherein the second security element (112) comprises cryptographic means for executing a challenge-response method, wherein the method comprises: • in response to an authentication request from the application program (108), authenticating the user by the operating system (106) using the authentication sensor (118) and the first security element (110), • performing a challenge-response method between the first security element (110) and the second security element (112), wherein the challenge-response method comprises generating a response by the first security element (110) and validating the response by the second security element (112), wherein generating the response comprises encrypting a challenge of the second security element by the first security element (110) using the private cryptographic key of the first security element (110), and wherein validating the response comprises decrypting the response of the first security element (110) by the second security element (112) using a public cryptographic key of the asymmetric key pair of the first security element (110), wherein a successful execution of the challenge-response method confirms a successful authentication of the user by the operating system (106), • upon successful execution of the challenge-response method, confirming successful authentication of the user to the application program (108) by the second security element (112), characterised in that the method further comprises providing the asymmetric key pair of the first security element (110), wherein providing the asymmetric key pair of the first security element (110) comprises: • generating the asymmetric key pair by the first security element (110), • transmitting the public cryptographic key of the asymmetric key pair of the first security element (110) to the second security element (112), wherein the mobile terminal device (100) comprises a communication interface (120) for communicating via a network (150), wherein transmitting the public cryptographic key of the asymmetric key pair of the first security element (110) comprises: • sending the public cryptographic key of the asymmetric key pair of the first security element (110) from the first security element (110) to the application program (108), • forwarding the public cryptographic key of the asymmetric key pair of the first security element (110) from the application program (108) using the communication interface (120) via the network (150) to an external provisioning server (220) which has write authorisation for writing to a memory area of the second security element (112), • validating the write authorisation of the provisioning server (220) for writing to the memory area of the second security element (112), • upon successful validation of the write authorisation of the provisioning server (220), granting write access of the external provisioning server (220) via the communication interface (120) to the memory area of the second security element (112), • writing the public cryptographic key of the asymmetric key pair of the first security element (110) into the memory area of the second security element (112).

2. The method according to claim 1, wherein the second security element (112) comprises a certificate comprising the public cryptographic key of the asymmetric key pair of the first security element (110).

3. The method according to claim 2, wherein the certificate is a certificate of a public key infrastructure.

4. The method according to any one of the preceding claims, wherein the terminal device (100) comprises the second security element (112), or wherein the second security element (112) is provided by an external server (280).

5. The method according to any one of the preceding claims, wherein the second security element (112) comprises a security applet (114) associated with the application program (108), wherein the security applet (114) comprises the cryptographic means for executing a challenge-response method, wherein the confirmation of the successful authentication of the user to the application program (108) is performed by the security applet (114).

6. The method according to any one of the preceding claims, wherein a communication in the course of the challenge-response method between the first security element (110) and the second security element (112) takes place via the application program (108).

7. The method according to claim 6, wherein the challenge-response method comprises: • sending the challenge of the second security element (112) to the application program (108), • forwarding the challenge from the application program (108) to the first security element (110), • upon successful authentication of the user by the operating system (106), generating the response by the first security element (110), • sending the response from the first security element (110) to the application program (108), • forwarding the response from the application program (108) to the second security element (112), • validating the decrypted response by the second security element (112).

8. The method according to any one of the preceding claims, wherein the authentication request comprises the challenge and the response is generated upon successful authentication of the user, and / or wherein the authentication of the user comprises: • detecting at least one authentication factor of the user using the authentication sensor (118), • validating the detected authentication factor using the first security element (110), and / or wherein confirming successful authentication of the user comprises sending an authentication confirmation of the second security element (112) to the application program (108) upon successful validation of the response.

9. The method according to any one of the preceding claims, wherein the application program (108) is an ID application program configured to manage one or more identity attributes associated with the user.

10. The method according to claim 9, wherein the ID application program is configured to send one or more of the identity attributes of the user to a further terminal device (100), or wherein the ID application program is configured to send one or more of the identity attributes of the user using the communication interface (120) via a network (150) to an ID provider server (240) for providing to a service provider server (260) and / or for confirmation to the service provider server (260) .

11. The method according to any one of claims 9 to 10, wherein the ID application program comprises an ID management module (111) that manages a plurality of ID profiles (113), wherein each of the ID profiles (113) is associated with an independent security applet (114) in the second security element (112).

12. The method according to claim 11, wherein each of the ID profiles (113) is associated with a set of one or more identity attributes.

13. A system (170), wherein the system (170) comprises a mobile terminal device (100) for authenticating a user to an application program (108) installed on a mobile terminal device (100), wherein the mobile terminal device (100) comprises a processor (102), wherein an operating system (106) is installed on the terminal device (100), wherein the operating system (106) is configured to control at least one authentication sensor (118) of the terminal device (100) for detecting at least one authentication factor of the user, wherein the terminal device (100) comprises a first security element (110) associated with the operating system (106), wherein the first security element (110) comprises cryptographic means for executing a challenge-response method, wherein a private cryptographic key of an asymmetric key pair of the first security element (110) is stored in a protected memory area of the first security element (110), wherein the system (170) further comprises a second security element (112) independent of the first security element (110), wherein the second security element (112) comprises cryptographic means for executing a challenge-response method, wherein the processor (102) is configured to execute a method for authenticating a user to an application program (108) installed on a mobile terminal device (100), which method comprises: • in response to an authentication request from the application program (108), authenticating the user by the operating system (106) using the authentication sensor (118) and the first security element (110), • performing a challenge-response method between the first security element (110) and the second security element (112), wherein the challenge-response method comprises generating a response by the first security element (110) for validation by the second security element (112), wherein the generation of the response comprises encrypting a challenge of the second security element by the first security element (110) using the private cryptographic key of the first security element (110) for validation by decrypting the response of the first security element (110) by the second security element (112) using a public cryptographic key of the asymmetric key pair of the first security element (110), wherein a successful execution of the challenge-response method confirms a successful authentication of the user by the operating system (106), • upon successful execution of the challenge-response method, confirming successful authentication of the user to the application program (108) by the second security element (112), characterised in that the method further comprises providing the asymmetric key pair of the first security element (110), wherein providing the asymmetric key pair of the first security element (110) comprises: • generating the asymmetric key pair by the first security element (110), • transmitting the public cryptographic key of the asymmetric key pair of the first security element (110) to the second security element (112), wherein the mobile terminal device (100) comprises a communication interface (120) for communicating via a network (150), wherein transmitting the public cryptographic key of the asymmetric key pair of the first security element (110) comprises: • sending the public cryptographic key of the asymmetric key pair of the first security element (110) from the first security element (110) to the application program (108), • forwarding the public cryptographic key of the asymmetric key pair of the first security element (110) from the application program (108) using the communication interface (120) via the network (150) to an external provisioning server (220) which has write authorisation for writing to a memory area of the second security element (112), • validating the write authorisation of the provisioning server (220) for writing to the memory area of the second security element (112), • upon successful validation of the write authorisation of the provisioning server (220), granting write access of the external provisioning server (220) via the communication interface (120) to the memory area of the second security element (112), • writing the public cryptographic key of the asymmetric key pair of the first security element (110) into the memory area of the second security element (112).

14. The system (170) according to claim 13, wherein the terminal device (100) comprises the second security element (112), or wherein the terminal device (100) comprises a communication interface (120) for communicating via a network (150), wherein the system (170) further comprises a server (280) that provides the second security element (112).

15. The system (170) according to any one of claims 13 to 14, wherein the system further comprises an initialisation server (200), wherein the initialisation server (200) is configured to initialise the first security element (110) and comprises a write permission to initialise the first security element (110), wherein the initialising comprises: • generating the asymmetric key pair of the first security element (110) by the first security element (110), • validating the write authorisation of the initialisation server (200) for initialising the second security element (112), • upon successful validation of the write authorisation of the initialisation server (200), granting write access of the external initialisation server (200) via the communication interface (120) to the second security element (112), • initialising the first security element (110), • writing the asymmetric key pair of the first security element (110) into the initialised memory area, and / or wherein the system further comprises a provisioning server (220), wherein the provisioning server (220) is configured to provision the second security element (112) and comprises a write authorisation for writing to a memory area of the second security element (112), wherein the provisioning comprises: • receiving a public cryptographic key of the asymmetric key pair of the first security element (110), • validating the write authorisation of the provisioning server (220) for writing to the memory area of the second security element (112), • upon successful validation of the write authorisation of the provisioning server (220), ensuring write access of the external provisioning server (220) via the communication interface (120) to the memory area of the second security element (112), • writing the public cryptographic key of the asymmetric key pair of the first security element (110) into the memory area of the second security element (112), and / or wherein the system further comprises an ID provider server (240), wherein the application program (108) is an ID application program configured to manage one or more identity attributes stored in the mobile terminal device (100) and associated with the user, wherein the ID provider server (240) is configured to provide and / or confirm one or more of the identity attributes of the user for a service provider server (260) and comprises a read authorisation to read one or more of the identity attributes of the user; the providing and / or confirming of one or more of the identity attributes of the user for a service provider server (260) comprises: • validating the read authorisation of the ID provider server (240) to read one or more of the identity attributes of the user, • upon successful validation of the read authorisation, sending one or more of the identity attributes of the user to the ID provider server (240), • signing the sent one or more of the identity attributes of the user by the ID provider server (240), • sending the signed one or more of the identity attributes of the user to the service provider server (260).