PERSONALIZING A SECURITY APPLET ON A MOBILE DEVICE

DE502022004079D1Active Publication Date: 2025-06-18BUNDESDRUCKEREI GMBH
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
DE502022004079
Authority / Receiving Office
DE · DE
Patent Type
Patents
Current Assignee / Owner
Priority Date
2021-04-21
Filing Date
2022-04-01
Publication Date
2025-06-18
Estimated Expiration
2042-04-01

AI Technical Summary

Technical Problem

Existing methods for securing mobile devices struggle to uniformly implement high security standards across devices from different manufacturers, particularly in ensuring secure user authentication and preventing unauthorized access to user attributes.

Method used

A method for personalizing a security applet on a mobile device using a personalization server, where attributes from an ID token are read and securely stored on the security applet, ensuring that only the authorized user can access and use these attributes for authentication purposes.

Benefits of technology

This approach enhances the security of mobile devices by ensuring that user attributes are securely bound to the device, preventing unauthorized access and misuse, while also allowing for device manufacturer-independent security solutions.

✦ Generated by Eureka AI based on patent content.
Patent Text Reader
Need to check novelty before this filing date? Find Prior Art

Description

[0001] The invention relates to a method for personalizing a security applet installed on a security element of a mobile terminal, as well as to a mobile terminal and a system for carrying out the method.

[0002] 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 areas with high security requirements.

[0003] 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, securely assigning the mobile device to a user of the device is of great importance. From the perspective of program manufacturers and service providers, implementing a uniformly high security standard for devices from different manufacturers is particularly difficult.

[0004] DE 10 2016 208040 A1 describes a method for reading attributes from an ID token, which includes: sending a service request from a user computer system to a service computer system coupled to an ID provider module; sending a first attribute specification from the service computer system to the ID provider module; after successful mutual authentication of the ID provider module and the ID token, writing the first attribute specification into the ID token by the ID provider module; sending a trigger signal from the user computer system to an APV computer system, wherein the first trigger signal is free of the first attribute specification and parts thereof and contains an address of the ID token;In response to receiving the trigger signal, mutual authentication of the APV computer system and the ID token using the address, reading the first attribute specification from the protected memory area of ​​the ID token by the APV computer system and splitting the read first attribute specification into at least a second and a third attribute specification by the APV computer system; sending the second attribute specification and the address from the APV computer system to a first AP computer system and sending the third and each further attribute specification and the address of the ID token from the APV computer system to a further AP computer system; and writing the first attribute set to the ID token and sending a confirmation signal from the first attribute provider computer system to the attribute provider directory computer system to cause the service computer system to read the written attribute sets.

[0005] DE 10 2015 209073 A1 describes a method for reading attributes from an ID token, comprising the steps of: establishing a local secure transmission channel between the ID token and the user computer system for authenticating the user to the ID token; establishing a first secure transmission channel with end-to-end encryption between the ID token and the ID provider computer system via the network, wherein the local secure transmission channel remains intact; establishing a second secure transmission channel with end-to-end encryption between the first attribute provider computer system and the ID token, wherein the first secure transmission channel remains intact; and outputting the attributes read from the ID token by the ID provider computer system as a result of the read accesses to the service computer system.

[0006] US 2011 / 016323 A1 describes a method for providing cryptographic network keys to a client when direct physical transmission is not possible. A client token generates a temporary key encrypted with a first secret key known only in a master token database and passes it to an enterprise network token of a network for which a service is requested. The enterprise network token then further encrypts the encrypted temporary key with a second secret key and passes it to the master token database. Since the second secret key is also known to the master token database, the originally encrypted temporary key can only be securely decoded by a master token linked to the master token database.The decrypted temporary key can then be re-encrypted with a key known only to the corporate network token and the master token and returned to the corporate network token. This allows the corporate network token to gain secure access to the client token's temporary key, allowing the corporate network token to securely provide the remote client token with the appropriate corporate network keys.

[0007] The invention is based on the object of creating an improved method for personalizing a security applet.

[0008] The object underlying the invention is solved 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 personalizing a security applet installed on a first security element of a mobile terminal using a first ID token and a personalization server. An ID application program is installed on the mobile terminal, to which the security applet is assigned. First attributes of a user are stored in the first ID token.

[0010] Personalization includes: Establishing an encrypted communication channel between the mobile terminal and the personalization server via a network, wherein the ID application program is used to establish the encrypted communication channel; Establishing a first encrypted subchannel between the first ID token and the personalization server within the encrypted communication channel via the mobile terminal, wherein the ID application program is used to establish the first encrypted subchannel; Reading one or more of the first attributes from the first ID token by the personalization server via the first encrypted subchannel within the encrypted communication channel; Establishing a second encrypted subchannel between the security applet of the first security element and the personalization server within the encrypted communication channel;wherein the ID application program is used to establish the second encrypted subchannel, receiving the read-out first attributes by the security applet of the first security element from the personalization server via the second encrypted subchannel within the encrypted communication channel, storing the received first attributes by the security applet, wherein the ID application program is configured to use the first attributes to prove an identity of the user to another computer system.

[0011] Embodiments can have the advantage that a security element is provided on a mobile device, which enables a manufacturer of an application program to personalize the corresponding security element for the corresponding application. Such personalization includes, for example, incorporating cryptographic keys into the security element that are associated with the application program installed on the individual mobile device. Furthermore, during the personalization process, attributes of a user of the mobile device can be incorporated into the corresponding security element. Thus, the corresponding security element and the application program installed on the corresponding device are associated with a specific user.At the same time, the corresponding application program can be provided with individual key material for executing cryptographic protocols, which can be used, for example, to prove the corresponding application program to the user. For example, a security applet is installed on the security element for this purpose. The corresponding security applet is assigned to the corresponding application program and manages the corresponding cryptographic elements and protocols, such as cryptographic keys, for this program. The application program is, for example, an ID application program that is configured to prove the identity of the user of the mobile device. To do this, the ID application program can use user attributes that identify the corresponding user. These attributes represent the user's electronic identity.The corresponding attributes and thus the user's electronic identity are provided, for example, by an ID token, i.e., an electronic identity document. During the personalization of the security element or security applet assigned to the ID application program, attributes are read from the electronic identity document and stored on the security element for the ID application program. The resulting electronic identity of the user, which the mobile device provides, is therefore a derived identity derived from the electronic identity document. The corresponding electronic identity document can, in particular, be a sovereign identity document, such as an electronic identity card or an electronic passport.

[0012] Embodiments can have the advantage that, in the course of such derivation, it can be ensured that the derived identity in the form of the attributes stored on the security element is actually stored on a security element bound to the user. In other words, embodiments can have the advantage that a binding of the security element and thus the corresponding attributes to the actual owner of the corresponding attributes can be guaranteed. This can prevent an unauthorized user from gaining access to attributes of another user and using them to identify themselves with a fake electronic identity. In the case of proof of identity with the mobile device, it can therefore advantageously be ensured that attributes presented with the proof of identity are actually attributes of the identified user.To this end, the transmission path for reading the corresponding attributes, i.e., the electronic identity of an identity document, is secured with a transmission path for personalizing the derived identity, i.e., incorporating the read attributes into a security element of a mobile device using cryptographic means. This ensures that the mobile device used to read the attributes is the same mobile device whose security elements are personalized with the read attributes.

[0013] For example, when reading the ID token using the mobile device, the user must authenticate themselves to the ID token. This ensures that the user initiating or confirming the reading is actually the owner of the corresponding ID document. Furthermore, when personalizing the security element of the mobile device, i.e. when entering the read attributes, the user must authenticate themselves to the mobile device. This ensures that the user initiating or confirming the personalization is actually the owner of the mobile device or the user registered on this mobile device. By additionally providing the transmission paths for reading the attributes and for entering the attributes orIf the mobile devices are linked together for personalization using cryptographic means, it can be ensured that the same mobile device is used for reading and entering the attributes, and that the same mobile device is assigned to the same user. If the user has to authenticate themselves to both the mobile device and the ID token when reading the attributes, it can be ensured, for example, that the holder of the ID token is the same person who also owns the mobile device. At the very least, it can be ensured that the holder of the ID token gives their consent together with the owner of the mobile device during the reading process, and that at least the consent of the owner of the same mobile device is required for entering the corresponding attributes.This prevents the mobile device used from being swapped during the reading and insertion of attributes, and thus preventing the corresponding attributes from being accessed by another, particularly an unauthorized, user. This effectively prevents misuse. To cryptographically link the transmission path for reading the attributes to the transmission path for personalizing or inserting the attributes, an encrypted communication channel is established between the mobile device and a personalization server that performs the personalization. This communication channel is encrypted to ensure that communication via it is actually only possible between the two participants who initially established the corresponding communication channel, i.e. the mobile device and the personalization server.End-to-end encryption can be used for this purpose. For example, encryption on the mobile device side is performed using an additional security element of the mobile device, which is assigned, for example, to an operating system of the mobile device and is configured to establish encrypted communication channels independently of the first security element with the security applet to be personalized. Reading from the ID token, on the one hand, and incorporating the read attributes into the security element to be personalized during personalization, on the other hand, are each performed, for example, via a separate encrypted subchannel of the encrypted communication channel.The encrypted subchannels ensure that only participants who have established the corresponding subchannel and have the corresponding cryptographic keys can communicate with each other. In the case of the first encrypted subchannel between the ID token and the personalization server, these are the corresponding ID token and the personalization server. In the case of the second encrypted subchannel between the security applet to be personalized of the first security element and the personalization server, these are the corresponding security applet to be personalized and the personalization server.

[0014] The subchannels are encrypted subchannels within the encrypted communication channel. The transmitted data is encrypted twice in each case. First, the corresponding data is encrypted by the ID token during the reading process from the ID token using a channel-specific ephemeral symmetric cryptographic session key assigned to the corresponding encrypted subchannel. During the transmission of the corresponding encrypted data between the mobile device and the personalization server, the data is additionally encrypted a second time by the mobile device using a channel-specific ephemeral symmetric cryptographic session key of the encrypted communication channel.The receiving personalization server must therefore first decrypt the encryption of the communication channel and then the encryption of the corresponding sub-channel in order to gain access to the transmitted data.

[0015] During personalization, the personalization server consistently uses the same encrypted communication channel. This means that the attributes used for personalization are encrypted with the channel-specific ephemeral symmetric cryptographic session key of the encrypted communication channel. Since only the mobile device already used to read the attributes, for example, its additional security element, possesses the same channel-specific ephemeral symmetric cryptographic session key, only the same mobile device is capable of decrypting the attributes to be used for personalization. This ensures that the same mobile device is used for personalization that was previously used to read the corresponding attributes.To ensure secure transmission of the attributes to be used for personalization to the security element of the mobile device to be personalized, an additional encrypted subchannel within the encrypted communication channel is used to transmit the attributes. In other words, the corresponding attributes are first encrypted with an ephemeral symmetric cryptographic session key of the corresponding subchannel and then with the channel-specific ephemeral symmetric cryptographic session key of the encrypted communication channel. The attributes thus doubly encrypted are first decrypted by the mobile device forming the endpoint of the encrypted communication channel, for example, by another security element of the device managing the necessary ephemeral cryptographic session key.The data resulting from this first decryption is sent to the security element containing the security applet to be personalized in the corresponding ID application program. The corresponding security applet has the cryptographic session key, which is assigned to the corresponding subchannel, whose endpoint, for example, the security applet forms. This cryptographic session key can also be used to decrypt the second encryption of the transmitted data, which can then be used for personalization by the security element to be personalized.

[0016] For example, a secure connection in the form of an encrypted communication channel is first established from the mobile device to the personalization server. This connection is secured, for example, by mutual authentication, which allows the participants to verify who they are communicating with. Authentication on the part of the mobile device may require authentication of the user of the mobile device to the mobile device. This not only ensures that communication takes place in the communication channel with or via the mobile device, but also that the communication takes place with the consent of the user of the mobile device. For this purpose, the corresponding user provides, for example, an authentication factor, such as a biometric feature or a PIN, in particular a system PIN.The corresponding authentication factor is recorded, for example, by an authentication sensor on the mobile device in the form of authentication data. This can be a biometric sensor, such as a finger scanner or a camera for detecting the user. For example, the corresponding authentication sensor can also be an input device on the mobile device via which the user can enter their PIN, such as a keyboard or a touchscreen. A system PIN, for example, is a PIN assigned to the operating system of the corresponding mobile device. In order to read attributes from the ID token, i.e. the user's electronic identity document, authentication of the user with the ID token is also necessary during the setup of the subchannel.For this purpose, the user can, for example, provide a corresponding authentication factor via the authentication sensor of the mobile device. Alternatively, the corresponding authentication factor can also be provided directly to the ID token if the ID token has the authentication sensor for detecting the corresponding authentication factor. As before, the corresponding authentication factor can be, for example, biometric characteristics of the user or, in particular, a document PIN. A corresponding document PIN is a PIN that is assigned to the corresponding ID token or electronic identity document. To transmit the attributes read from the ID token to the personalization server, an encrypted subchannel of the encrypted communication channel is established. The corresponding establishment takes place, for example, via the encrypted communication channel.The attributes to be read are then transferred from the personalization server to the mobile device or the security applet of the ID application program to be personalized, secured with double encryption.

[0017] To personalize the security applets of the ID application program to be personalized on the first security element, a second subchannel is established within the encrypted communication channel. This requires, for example, user authentication with the security applet to be personalized. Authentication occurs, for example, using an additional security element, which is a security element assigned to the operating system of the mobile device. The user authenticates himself with the corresponding additional security element or is successfully authenticated by the corresponding additional security element. The additional security element communicates the user's successful authentication to the security applet to be personalized on the security element. The corresponding notification can be made, for example, using a challenge-response procedure.This also successfully authenticates the user to the security applet on the mobile device that is to be personalized. Upon successful authentication of the user to the security applet on the first security element using the additional security element, an encrypted subchannel is established between the security applet on the first security element that is to be personalized and the personalization server via the encrypted communication channel. The encrypted subchannel is, for example, an end-to-end encrypted subchannel. The previously read data, i.e., attributes, from the ID token are then transmitted via the second subchannel within the communication channel to the security applet on the security element that is to be personalized.Furthermore, additional cryptographic elements, such as cryptographic keys, can be transmitted to the security applet to be personalized via the corresponding subchannel. The corresponding cryptographic keys are, for example, the attribute-specific and thus identity-specific cryptographic keys that are assigned to the derived electronic identity of the mobile device user stored on the mobile device during personalization.

[0018] A method is proposed for the secure personalization of a mobile device or an ID application program installed on the mobile device with identity information of a user bound to the mobile device, wherein the security applet is, in particular, independent of the device manufacturer. A correspondingly personalized mobile device enables user authentication with a device manufacturer-independent security applet, for example, for the purpose of identification and / or authentication by an ID provider server to third-party service providers.

[0019] A security element is a secured element of a mobile device that provides cryptographic means. These cryptographic means are protected against tampering and, for example, are accessible only to authorized services and applications via cryptographic keys. In particular, the cryptographic means can only be incorporated into, supplemented, modified, and / or deleted from the security element by authorized services and applications. A security element therefore 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 connected, i.e., not non-destructively removable. A security element can be implemented, for example, in the form of a Secure Element (SE). 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." 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 security element can be implemented using a TEE. Security elements are implemented, for example, as hardware and / or firmware. According to embodiments, security elements orKey stores can also be implemented as software. For example, two security elements are independent of each other if there is no common instance that has access rights for both security elements.

[0020] 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.

[0021] 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."

[0022] 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.

[0023] A computer or a computer system can be, for example, a stationary computer, such as a personal computer (PC), service terminal, or server, or a mobile portable computer, such as a laptop, tablet, smartphone, or other smart device. The computer can include an interface for connecting to the network, which can be a private or public network, in particular the Internet. Depending on the embodiment, this connection can also be established via a mobile network.

[0024] A "service provider server" or service server is understood here to be a server or computer system on which a server program is executed and which provides the possibility of initiating, using and / or executing an offered service via a network.

[0025] A "personalization server" is a server or computer system on which a server program is executed and which is configured to read attributes from an ID token and insert them into a mobile device.

[0026] An "ID token" is understood here to be a portable electronic device, for example, a so-called USB stick, a chip card, or a document on which a user's attributes are stored. A "document" is understood in particular to be an identification, valuables, or security document, in particular a sovereign document, 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 card, or another ID document, a chip card, a 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, such as that standardized by the International Civil Aviation Organization (ICAO) and / or the Federal Office for Information Security (BSI).

[0027] A "provisioning server" is a server or computer system on which a server program is executed and which is configured to provision a mobile device, in particular with cryptographic keys.

[0028] A "personalization server" is a server or computer system on which a server program is executed and which is configured to read attributes from an ID token and insert them into a mobile device.

[0029] An "ID provider server" is understood to mean a server or a computer system on which a server program is executed and which is configured to provide attributes of an electronic identity provided by the mobile device to a service provider server and / or to confirm them to the service provider server.

[0030] A "program" or "program instructions" is understood here, without limitation, to mean any type of computer program that includes machine-readable instructions for controlling a functionality of the computer.

[0031] A "processor" is understood here and below to mean a logic circuit that serves to execute program instructions. The logic circuit can be implemented on one or more discrete components, in particular on a chip. In particular, a "processor" is understood to mean a microprocessor or a microprocessor system comprising multiple processor cores and / or multiple microprocessors.

[0032] The term "memory" refers here to both volatile and non-volatile electronic memories or digital storage media.

[0033] "Non-volatile memory" is defined here as an electronic memory for the permanent storage of data, in particular static cryptographic keys, attributes, or identifiers. 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.

[0034] An "interface" or "communication interface" is understood here to be an interface through which data can be received and sent. The communication interface can be configured as contact-based or contactless. A communication interface can, for example, enable communication over a network. Depending on the configuration, a communication interface can, for example, provide wireless communication according to a cellular standard, Bluetooth, RFID, Wi-Fi, and / or NFC standards. Depending on the configuration, a communication interface can, for example, provide cable-based communication. The communication interface can be an internal interface or an external interface.

[0035] Encrypted communication channels, for example, are encrypted end-to-end connections. An "encrypted end-to-end connection" or "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.End-to-end encryption, for example, is based on two symmetric cryptographic keys, with a first symmetric key used to encrypt messages and a second symmetric key used to authenticate the sender of the message, for example, using Message Authentication Code (MAC) algorithms. For example, during the setup of an encrypted communication channel, ephemeral encryption keys are negotiated, which become invalid when the communication channel is terminated. Using different ephemeral keys for different communication channels makes it possible to operate multiple communication channels in parallel.

[0036] An encrypted communication channel can be established, for example, using the Transport Layer Security (TLS) protocol, for example as part of the Hypertext Transfer Protocol Secure (HTTPS) protocol.

[0037] Asymmetric key pairs are used in a variety of cryptosystems and play an important role in the secure transmission of electronic data. An asymmetric key pair consists of a public cryptographic key, which is used to encrypt and / or decrypt data and may be shared with third parties, such as a sender or receiver of data, and a private cryptographic key, which is used for encryption and / or decryption but also for signing data and must generally be kept secret. The public key allows anyone to encrypt data for the owner of the private cryptographic key or to verify digital signatures created with the private cryptographic key.A private key allows its owner to decrypt data encrypted with the public cryptographic key or to create digital signatures of data.

[0038] A digital signature of data includes, for example, creating a check value for the data, such as a hash value, which is encrypted with a private cryptographic key of an asymmetric key pair used as the signature key. In the case of a signature, only the signatory knows the private cryptographic key (i.e., signature key) of the asymmetric key pair used to create the signature. The signature recipient only has the public cryptographic key (i.e., signature verification key) of the asymmetric key pair used for the signature. The signature recipient can therefore verify the signature but cannot calculate it themselves. To verify a signature, the signature recipient calculates, for example, the check value of the signed data and compares this with the result of decrypting the signature using the signature verification key.If the calculated hash value matches the decryption result, the signature is correct. If the authenticity of the signature verification key is also confirmed, for example, by a certificate, especially a PKI certificate, the signature is valid.

[0039] A "certificate" here refers to a digital certificate, also known as a public key certificate (PKI certificate). A certificate is structured data used to assign a public cryptographic key of an asymmetric cryptosystem to an identity, such as a person, institution, or device. For cryptographic security and to prove the authenticity of the certificate data, these are signed by a certificate issuer. PKI certificates, which are based on asymmetric key pairs and, with the exception of a root certificate, are each signed by a certificate issuer with a signature key, the corresponding signature verification key of which is assigned to the certificate issuer by a PKI certificate of the corresponding certificate issuer, create a so-called public key infrastructure (PKI).For example, the certificate can conform to the X.509 standard or another standard. For example, the certificate is a Card Verifiable Certificate (CVC). An authorization certificate contains structured data that additionally defines the rights of the identity.

[0040] The PKI provides a system for issuing, distributing, and verifying digital certificates. In an asymmetric cryptosystem, a digital certificate can confirm the authenticity of a public cryptographic 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 cryptographic 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 cryptographic key, which can be used to verify the previous certificate. Such a chain of certificates forms a so-called validation path or certification path.For example, PKI participants must be able to rely on the authenticity of the last certificate, the so-called root certificate, and the key certified by it, without requiring 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.

[0041] Digital certificates, for example, are validated by an independent, trustworthy authority (certification service provider / CSP or trust service provider / TSP), i.e., the certification authority that issued the certificate. Certificates can be made available to a wide range of people to enable them to verify electronic signatures for authenticity and validity. A certificate can be associated with an electronic signature and provide a signature verification key in the form of the public cryptographic key if the private key associated with the signature verification key was used as the signature key.By making a certificate in association with a public cryptographic key available to the public, a CDA / VDA enables users of asymmetric cryptosystems to assign the public cryptographic key to an identity, for example a person, an organization, or a computer system.

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

[0043] At least one security applet is assigned to the ID application program installed and executed on the mobile device. The security applet is installed and executed on the first security element of the mobile device. The mobile device with the electronic identities managed by the ID application program can be used, for example, for identification and authentication, for transmitting identity data, and for supporting declarations of intent in a mobile context.

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

[0045] A user's electronic identity is unambiguous, meaning it is unique and unmistakable. It is defined based on characteristics, so-called identity attributes. An electronic 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.

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

[0047] According to embodiments, an electronic 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 terminal without additional hardware besides the mobile terminal.

[0048] Identity attributes are requested, for example, by service providers or service providers for online services. 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 by this provider 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).For example, the service provider queries whether the requested identity attributes have one or more characteristics, which is checked by the ID provider server based on the read identity attributes and either confirmed or denied to the service provider.

[0049] The user's consent to the use of identity attributes and / or user authentication takes place, for example, by checking one or more authentication factors, such as password, PIN, fingerprint or facial recognition.

[0050] According to embodiments, the ID application program controls the establishment of the encrypted communication channel between the mobile terminal and the personalization server. For example, the ID application program comprises a personalization component that controls the personalization on the mobile terminal side. For example, the personalization component of the ID application program controls the establishment of the encrypted communication channel on the mobile terminal side, as well as the establishment of the first encrypted subchannel and the second encrypted subchannel, mediated by the mobile terminal.

[0051] For example, the received first attributes are stored by the security applet in the first security element. For example, the attributes are stored in a memory area of ​​the first security element assigned to the security applet or the ID application program.

[0052] For example, along with the first attributes, the personalization server sends a request to the first security element to save the first attributes. For example, the request is sent in the form of a CAPDU (Commando Application Protocol Data Unit) to the security applet of the first security element.

[0053] According to embodiments, the encrypted communication channel is encrypted with a first channel-specific ephemeral symmetric cryptographic session key. According to embodiments, the first encrypted subchannel is encrypted with a second channel-specific ephemeral symmetric cryptographic session key. According to embodiments, the second encrypted subchannel is encrypted with a third channel-specific ephemeral symmetric cryptographic session key.

[0054] Embodiments may have the advantage that the encryption in the communication channel and in the two encrypted subchannels are each assigned channel-specific ephemeral symmetric cryptographic session keys. Thus, the subchannels can each be combined with the communication channel or executed within it by using double encryption through the cryptographic session keys assigned to the corresponding channels.

[0055] According to embodiments, the first channel-specific ephemeral symmetric cryptographic session key, the second channel-specific ephemeral symmetric cryptographic session key, and the third channel-specific ephemeral symmetric cryptographic session key are each independent of one another.

[0056] For example, a channel-specific ephemeral symmetric cryptographic authentication key for authenticating data is further assigned to each of the first and second encrypted sub-channels, which data is transmitted via the corresponding first or second encrypted sub-channel. For example, a MAC is generated for the corresponding data using the respective channel-specific ephemeral symmetric cryptographic authentication key. The corresponding authentication keys are, for example, cryptographic keys for generating the corresponding MAC.

[0057] A MAC, for example, is calculated using a MAC algorithm that receives the data to be protected, e.g., identity attributes, and a cryptographic key, e.g., a symmetric cryptographic key, 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 MACs. An HMAC (Keyed-Hash Message Authentication Code), for example, can be used as a MAC. A cryptographic hash function, such as the Secure Hash Algorithm (SHA), and a secret cryptographic key, e.g., a symmetric cryptographic key, are used to construct the MAC.

[0058] To secure a data transmission, for example, the transmission of identity attributes, a cryptographic key, such as a symmetric cryptographic key, is agreed upon between the sender, for example the ID token, and the receiver, for example a personalization server. The sender uses this cryptographic key to calculate a MAC of the data to be transmitted and sends the calculated MAC along with the data to be transmitted to the receiver. The receiver, in turn, calculates a MAC for the received data using the cryptographic key and compares the result with the received MAC. If the calculated MAC matches the received MAC, the integrity check is successful, and the received data is considered authentic.

[0059] In the case of a MAC, both sender and receiver must know the cryptographic key used, unlike when using 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 (i.e., signature key) of an asymmetric key pair used to create the signature. The signature recipient only has the public cryptographic key (i.e., 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.

[0060] According to embodiments, the encryption of the encrypted communication channel is end-to-end encryption between the mobile device and the personalization server.

[0061] Embodiments can have the advantage of ensuring that the same mobile device always forms an endpoint of the encrypted communication channel. Thus, as long as communication is carried out via the same encrypted communication channel, the personalization server knows that it is communicating with the same mobile device. Thus, it can be ensured that the mobile device via which the ID token is read is the same mobile device that is personalized with the read data, i.e., attributes of the ID token.

[0062] According to embodiments, the encrypted communication channel is encrypted by the mobile device using a second security element of the mobile device, which is associated with an operating system of the mobile device. The second security element provides, for example, cryptographic keys and / or cryptographic protocols for the operating system.

[0063] According to embodiments, the encryption of the first encrypted subchannel is end-to-end encryption between the first ID token and the personalization server.

[0064] Embodiments can have the advantage that the data transmitted in encrypted form between the ID token and the personalization server can be transmitted at least between the mobile device and the personalization server within the encrypted communication channel. At the same time, the mobile device does not yet gain access to the data transmitted via the encrypted subchannel at this point. This ensures that access to the corresponding data occurs exclusively through the personalization server during personalization. This can thus prevent misuse or unauthorized reading of attributes. Rather, the corresponding reading and use of the attributes for personalization can occur exclusively via a trusted entity in the form of the personalization server.

[0065] According to embodiments, the encryption of the second encrypted subchannel is end-to-end encryption between the security applet and the personalization server.

[0066] Embodiments can have the advantage that the end-to-end encryption between the security applet of the security element to be personalized and the personalization server can ensure that the security applet of the first security element of the mobile device to be personalized is actually personalized and that the data used for personalization is made available exclusively to the corresponding security applet. This can prevent, for example, unauthorized access to the corresponding personalization data.

[0067] Depending on the embodiment, personalization further includes: Generating an asymmetric cryptographic key pair associated with the ID application program by the security applet, which comprises a private cryptographic key and a public cryptographic key of the ID application program, wherein the asymmetric key pair serves to authenticate the ID application program in the course of using the first attributes,

[0068] According to embodiments, the security applet sends the public cryptographic key of the ID application program to the personalization server via the second encrypted subchannel within the encrypted communication channel.

[0069] Embodiments may have the advantage that the security applet on the first security element can generate an individual asymmetric key pair for the individual ID application program and make it available for use by the ID application program. For example, the asymmetric key pair is assigned to the individual electronic identity, which is introduced into the mobile terminal during personalization. The public cryptographic key of the corresponding asymmetric key pair is transmitted via the encrypted subchannel between the security applet and the personalization server in the encrypted communication channel. Thus, the corresponding public cryptographic key, which is generated on the personalized security element during personalization, is made available to the personalization server.This can, for example, make the corresponding public cryptographic key available to other instances as a signature verification key. The corresponding signature verification key can be used to ensure that data signed with the associated private cryptographic key actually originates from the personalized security applet of the first security element. For example, the personalization server can issue a certificate for or with the corresponding public cryptographic key. Using the corresponding certificate, which can be, for example, a certificate from a certificate chain, in particular a PKI, the personalization server can confirm the authenticity of the corresponding public cryptographic key or its assignment to the personalized security element and thus to the corresponding personalized ID application program.

[0070] For example, to initiate the generation of the asymmetric cryptographic key pair associated with the ID application program, the personalization server sends a request to the security applet of the first security element, requesting the security applet to generate the asymmetric cryptographic key pair associated with the ID application program. For example, the request is sent to the security applet of the first security element in the form of a CAPDU.

[0071] Depending on the embodiment, personalization further includes: Receiving one or more root signature verification keys by the security applet from the personalization server via the second encrypted subchannel within the encrypted communication channel, wherein the received root signature verification keys are used to verify certificate signatures of one or more root instances which have certificates which are each used in the course of reading the first attributes for authenticating a reading computer system to the ID application program, storing the received root signature verification keys by the security applet in the first security element.

[0072] Embodiments can have the advantage that, during personalization, root signature verification keys can be stored on the corresponding security element in the security applet. The corresponding root signature verification keys enable the security applet to verify signatures from root instances, in particular certificate signatures from root instances. A certificate chain for authenticating a computer system is presented to the ID application program and thus to the security applet, for example, a computer system that wishes to access the attributes read out and stored in the personalized security element to prove the identity of the user of the mobile device. For example, the root signature verification key can be used to verify a first initial certificate of the corresponding certificate chain issued within the certificate chain.If the corresponding initial certificate proves to be authentic, the authenticity of the entire certificate chain can be successively checked and verified. For example, each certificate in the certificate chain is signed using a private cryptographic key of an issuing authority as the signature key. The corresponding signature can be verified, for example, using a corresponding public cryptographic key provided by the preceding certificate as the signature verification key. Only the initial certificate, which is not preceded by a certificate, is signed with a root signature key of a root authority. This root signature can be checked and verified using a corresponding root signature verification key stored in the personalized security element.

[0073] For example, the personalization server sends a request to the security applet of the first security element to store the root signature verification keys along with the one or more root signature verification keys. For example, the request is sent to the security applet of the first security element in the form of a CAPDU.

[0074] Depending on the embodiment, personalization further includes: Receiving a signature of the first attributes from the personalization server by the security applet of the first security element via the second encrypted subchannel within the encrypted communication channel, wherein the signature serves as proof of authenticity of the first attributes, storing the received signature of the first attributes by the security applet in the first security element.

[0075] Embodiments can have the advantage that the authenticity of the attributes can be verified using the corresponding signature. Thus, the mobile device, which includes a corresponding signature of the attributes used for personalization, can also be used offline to prove the identity of the user of the mobile device. To this end, the mobile device displays the corresponding attributes, including the signature, for example, on a display device, for example in the form of a one- or two-dimensional readable machine code, such as a QR code. The corresponding attributes with the signature can then be captured, for example, by a reader and verified using the signature. Furthermore, a contactless transmission of the corresponding attributes with the signature to another computer system, such as another mobile device, would be possible for example to prove the identity of the user of the mobile device.In this case, too, the authenticity of the corresponding attributes and thus the identity of the user of the mobile device could be proven using the signature.

[0076] For example, along with the signature of the first attributes, the personalization server sends a request to the security applet of the first security element to store the signature of the first attributes. For example, the request is sent to the security applet of the first security element in the form of a CAPDU.

[0077] According to embodiments, establishing the encrypted communication channel comprises negotiating the first channel-specific ephemeral symmetric cryptographic session key.

[0078] According to embodiments, negotiating the first channel-specific ephemeral symmetric cryptographic session key comprises: Generating a first random value by the mobile terminal, generating the first channel-specific ephemeral symmetric cryptographic session key using the first random value by the mobile terminal, receiving a first certificate of the personalization server with a first public cryptographic key of a first asymmetric cryptographic key pair of the personalization server by the mobile terminal from the personalization server, encrypting the first random value using the received first public cryptographic key of the personalization server by the mobile terminal, sending the encrypted first random value to the personalization server by the mobile terminal for generating the first channel-specific ephemeral symmetric cryptographic session key by the personalization server.

[0079] Embodiments may have the advantage that a secure method for providing the first channel-specific ephemeral symmetric cryptographic session key for encrypting the communication channel between the mobile terminal and the personalization server can be provided. For example, a first initial random value is first generated by the mobile terminal and sent to the personalization server. After receiving the corresponding first initial random value, the personalization server generates a second initial random value, which it sends to the mobile terminal. Thus, both participants, the mobile terminal and the personalization server, have both initial random values. Furthermore, the server sends, for example, its certificate to the mobile terminal and receives a certificate of the mobile terminal from the mobile terminal after successfully verifying the corresponding certificate.The mobile device's certificate can, for example, be a certificate assigned to the application program. The mobile device's certificate received by the personalization server is also verified. Both certificates each contain a public cryptographic key, i.e. the personalization server's certificate contains a public cryptographic key of an asymmetric key pair of the personalization server, and the mobile device's certificate contains a public cryptographic key of an asymmetric key pair of the mobile device. Thus, both participants now each have public cryptographic keys of the other party, the authenticity of which is each proven by a certificate. The mobile device then generates, for example, the first random value, which it sends to the personalization server.Thus, both participants in the communication now each have three random values ​​from which, for example, the channel-specific ephemeral symmetric cryptographic session key can be calculated. Furthermore, the mobile device sends, for example, a signature of one, several, or all previous messages exchanged during channel establishment to the personalization server. By verifying the corresponding signature using the public cryptographic key provided by the mobile device's certificate as the signature verification key, the personalization server can authenticate the mobile device. If the personalization server subsequently sends a message encrypted with the first channel-specific ephemeral symmetric cryptographic session key to the mobile device, this also authenticates the personalization server to the mobile device.The personalization server can only calculate the first channel-specific ephemeral symmetric cryptographic session key if it has a private cryptographic key with which it can decrypt the first random value received from the mobile device. Thus, only the personalization server in possession of the corresponding private cryptographic key, to which the personalization server's certificate is assigned, is capable of encrypted communication over the encrypted communication channel.

[0080] According to embodiments, establishing the encrypted communication channel further comprises mutually authenticating the ID application program and / or the mobile terminal and the personalization server.

[0081] Embodiments can have the advantage that mutual authentication can ensure which participants are communicating with each other and between which participants the encrypted communication channel is established. In particular, this can determine the identity of the mobile device and ensure which device the user's electronic identity is assigned to or which mobile device is personalized.

[0082] According to embodiments, the mobile terminal further comprises a second security element. For example, on the mobile terminal side, the second security element is used to authenticate the mobile terminal or the application program. The second security element comprises a first initial private cryptographic key of a first initial asymmetric cryptographic key pair of the ID application program. Furthermore, the mobile terminal further comprises an initial certificate of the ID application program, which comprises the initial public cryptographic key of the initial asymmetric cryptographic key pair of the ID application program.For authentication with the personalization server, the mobile device sends, for example, the initial certificate of the ID application program to the personalization server as well as a message signed by the second security element with the first initial private cryptographic key of the ID application program.

[0083] Embodiments may have the advantage that the mobile terminal can authenticate itself to the personalization server using the corresponding certificate of the ID application program.

[0084] According to embodiments, the mobile device further comprises one or more authentication sensors for detecting one or more authentication factors of the user. An operating system installed on the mobile device is configured to control the authentication sensors. The second security element is assigned to the operating system. A prerequisite for signing with the first initial private cryptographic key of the ID application program is successful authentication of the user with the second security element. The user is registered on the mobile device, and at least one reference value of the registered user is stored in the second security element for verifying at least one detected authentication factor.

[0085] Embodiments can have the advantage of enabling authentication of a user of the mobile device. This authentication of the registered user is then, for example, a necessary prerequisite for successful authentication of the mobile device to the personalization server. This ensures that a registered user consents to the use of the mobile device to establish the encrypted communication channel.

[0086] According to embodiments, establishing the first encrypted subchannel comprises authenticating the user to the ID token via the mobile device.

[0087] Embodiments may have the advantage that, when reading the ID token, it can be ensured that the corresponding reading is authorized by the owner of the ID token. For example, the user is authenticated to the ID token using the mobile device.

[0088] According to embodiments, authenticating the user to the ID token includes: Receiving a further user authentication factor detected by the one or more authentication sensors by the ID application program, generating a symmetric cryptographic key by the second security element using the received further authentication factor, receiving an encrypted second random value by the ID application program from the ID token, wherein the encrypted second random value is encrypted using the symmetric cryptographic key which the ID token generates using a further reference value of the registered user stored in the ID token for verifying the further authentication factor, decrypting the received encrypted second random value by the second security element using the generated symmetric cryptographic key,Generating a first ephemeral asymmetric cryptographic key pair of the ID application program by the second security element, which comprises a first ephemeral private cryptographic key and a first ephemeral public cryptographic key of the ID application program, sending the first ephemeral public cryptographic key of the ID application program to the ID token, receiving an ephemeral public cryptographic key of the ID token, generating a first secret shared with the ID token using the decrypted second random value, the first ephemeral private cryptographic key of the ID application program, and the ephemeral public cryptographic key of the ID token,Generating a first common authentication key for mutually authenticating the ID application program and the ID token by the second security element using the shared first secret, Generating a first authentication token using the first authentication key and the first ephemeral public cryptographic key of the ID token by the second security element, Sending the first authentication token to the ID token by the second security element, Receiving a second authentication token from the ID token by the second security element, Verifying the received second authentication token using the first authentication key and the first ephemeral public cryptographic key of the ID application program.

[0089] For example, an ephemeral symmetric cryptographic key is derived using a recorded user authentication factor. The authentication factor recorded by the mobile device, on the one hand, and a reference value stored on the ID token, on the other, each serve as a shared password for mutually deriving the ephemeral symmetric cryptographic key. The mobile device receives a random value from the ID token, which is encrypted with the same ephemeral symmetric cryptographic key. The ID token derives the corresponding ephemeral symmetric cryptographic key, for example, from a reference value for the authentication factor, or the correspondingly derived ephemeral symmetric cryptographic key is stored on the ID token.If the mobile device is able to correctly decrypt the received encrypted random value, this provides proof that the mobile device has the correct authentication factor. The mobile device generates an ephemeral asymmetric key pair, whose public cryptographic key the mobile device sends to the ID token. In return, the mobile device receives the public cryptographic key of the ID token. At this point in the process, static cryptographic keys are therefore not necessary; only randomly generated ephemeral asymmetric key pairs can be used. The mobile device generates a secret shared with the ID token using the decrypted random value, the ephemeral private cryptographic key of the ID application program, and the ephemeral public cryptographic key of the ID token.The ID token is also capable of calculating the corresponding secret using the random value it generates, the ephemeral private cryptographic key of the ID token, and the ephemeral public cryptographic key of the mobile device received from the mobile device.

[0090] The mobile device can then use the shared secret thus generated to calculate a common authentication key for mutually authenticating the ID application program and the ID token. For example, the mobile device can generate a first authentication token using the corresponding authentication key and the ephemeral public cryptographic key of the ID token. The corresponding authentication token can be sent from the mobile device to the ID token, which can verify the received authentication token using the shared authentication key and the ephemeral private cryptographic key of the ID token. Thus, the mobile device can authenticate itself to the ID token. Likewise, the ID token can send an authentication token to the mobile device.The mobile device receives the authentication token, which is generated, for example, using the shared secret and the mobile device's ephemeral public cryptographic key. The authentication token can be verified using the authentication key and the public cryptographic key of the ID application program.

[0091] According to embodiments, an application domain identifier of an application domain of the ID token is further used to generate the shared first secret, wherein the application domain identifier is received together with the encrypted second random value from the ID token by the ID application program.

[0092] According to embodiments, the first authentication key is a cryptographic key for generating a message authentication code, wherein the first authentication token is a first MAC of the first ephemeral public cryptographic key of the ID application program generated using the first authentication key.

[0093] According to embodiments, the second security element further generates a fifth ephemeral symmetric cryptographic key using the shared first secret for encrypting the communication between the mobile terminal and the ID token.

[0094] Embodiments may have the advantage that an ephemeral symmetric cryptographic key can be provided, with which the communication between the mobile terminal and the ID token can be encrypted. Thus, for example, the further communication between the IT token and the mobile terminal, the ID token communicating with the personalization server during the establishment of the second subchannel, can be encrypted. For example, the communication is encrypted with the corresponding ephemeral symmetric cryptographic key until the encrypted subchannel between the ID token and the personalization server is established, which enables end-to-end encryption between the ID token and the personalization server.

[0095] According to embodiments, establishing the first encrypted subchannel comprises authenticating the personalization server by the ID token via the mobile terminal.

[0096] Embodiments can have the advantage that the participants establishing the encrypted subchannel can be sure with whom they are communicating. In particular, the ID token can thus be sure with whom it is communicating. For example, a corresponding authentication method is used to authenticate the personalization server using the ID token.

[0097] According to embodiments, authenticating the personalization server by the ID token comprises: Receiving a second certificate from the personalization server, which comprises a second public cryptographic key of a second asymmetric cryptographic key pair of the personalization server, via the encrypted communication channel, verifying a signature of the received second certificate of the personalization server, generating a third random value using the ID token, sending the third random value as a challenge to the personalization server via the encrypted communication channel, receiving a first signature of the challenge as a response from the personalization server via the encrypted communication channel, wherein the challenge is signed using a second private cryptographic key of the personalization server,Verifying the received first signature using the second public cryptographic key of the personalization server and the sent third random value.

[0098] According to embodiments, a second ephemeral public cryptographic key of the personalization server, for example in compressed form, is further received by the ID token via the encrypted communication channel.

[0099] According to embodiments, to generate the response, a first data combination is signed, which includes the challenge. For example, the first data combination includes, in addition to the third random value sent as a challenge, the second ephemeral public cryptographic key of the personalization server, for example in compressed form.

[0100] Embodiments may have the advantage that the personalization server can be authenticated by the ID token in a cryptographically secure manner. For this purpose, the ID token receives, for example, a certificate from the personalization server, which provides a public cryptographic key of the personalization server for authentication. The ID token verifies the signature of the received certificate. For example, the corresponding certificate is received as part of a certificate chain, for the verification of which corresponding signature verification keys, in particular root signature verification keys, are stored on the ID token. Thus, the ID token can verify the authenticity of the provided certificate based on the certificate chain, for example, a PKI. Furthermore, the ID token receives, for example, an ephemeral public cryptographic key of the personalization server.For example, the ID token receives the personalization server's ephemeral public cryptographic key in compressed form. In return for receiving the personalization server's certificate, the ID token generates a random value, which it sends to the personalization server as a challenge via the encrypted communication channel. The personalization server creates a signature of the challenge as a response to the challenge using a private cryptographic key that forms an asymmetric key pair with the public cryptographic key of the previously provided certificate. For example, to generate the response, a data combination is signed that includes the random value as a challenge and the personalization server's ephemeral public cryptographic key, for example, in compressed form.The ID token receives the corresponding signature via the encrypted communication channel and verifies it using the previously received public cryptographic key of the personalization server as the signature verification key. For this purpose, the ID token also uses, for example, the random value previously sent as a challenge and the previously received ephemeral public cryptographic key of the personalization server.

[0101] According to embodiments, the first and second certificates of the personalization server are different certificates with different public cryptographic keys of the personalization server. Thus, in this case, the first and second public cryptographic keys of the personalization server are, for example, different public cryptographic keys of different asymmetric cryptographic key pairs.

[0102] According to embodiments, the first and second certificates of the personalization server are the same certificate with the same public cryptographic key of the personalization server. Thus, in this case, the first and second public cryptographic keys of the personalization server are, for example, the same public cryptographic key of the same asymmetric cryptographic key pair.

[0103] According to embodiments, the second certificate of the personalization server is a read certificate which proves a read authorization of the personalization server to read the first attributes to be read from the first ID token.

[0104] Embodiments may have the advantage that the personalization server can use the corresponding certificate to prove read authorization to read the attributes to be read from the ID token.

[0105] According to embodiments, the second certificate of the personalization server is received as part of a certificate chain, wherein verifying the signature of the received certificate comprises checking a signature chain of the certificates of the certificate chain. According to embodiments, the certificate chain begins with an initial certificate signed by a root authority whose signature is verifiable with a root signature verification key stored in the ID token. According to embodiments, the certificate chain ends with the certificate of the personalization server.

[0106] According to embodiments, the combination further comprises an identifier of the ID token, wherein the identifier of the ID token is further used to verify the received signature.

[0107] According to embodiments, the identifier of the ID token is generated, for example, using the ephemeral public cryptographic key of the ID token. For example, the identifier of the ID token is the compressed first ephemeral public cryptographic key of the ID token.

[0108] Embodiments may have the advantage that the ID token can be identified using the identifier. For example, an ephemeral public cryptographic key of the ID token can be used as the identifier of the ID token, which key was previously generated, for example, during the user's authentication to the ID token. The corresponding ephemeral public cryptographic key of the ID token can, for example, be forwarded from the mobile device to the personalization server. Thus, the personalization server, for example, receives access to the corresponding ephemeral public cryptographic key and can use this as an identifier to ensure that the ID token with which it is authenticating is the same ID token with which the user of the mobile device previously authenticated.

[0109] According to embodiments, establishing the first encrypted subchannel comprises authenticating the ID token to the personalization server via the mobile terminal.

[0110] Embodiments may have the advantage that mutual authentication between ID token and personalization server takes place during the establishment of the encrypted subchannel.

[0111] According to embodiments, authenticating the ID token to personalization servers includes: Sending the ID token's public cryptographic key from the ID token to the personalization server via the encrypted communication channel, receiving the second ephemeral public cryptographic key of the personalization server by the ID token from the personalization server via the encrypted communication channel, generating a second secret shared with the personalization server by the ID token using the ID token's private cryptographic key and the second ephemeral public cryptographic key of the personalization server, generating a fourth random value by the ID token, generating a second shared authentication key for authenticating data sent via the first encrypted subchannel by the ID token, wherein the second shared authentication key is generated using the shared second secret and the fourth random value,Generating a third authentication token by the ID token using the second authentication key and the second ephemeral public cryptographic key of the personalization server to authenticate the ID token to the personalization server, sending the fourth random value together with the third authentication token to authenticate the ID token by the ID token to the personalization server via the encrypted communication channel.

[0112] Embodiments may have the advantage that the ID token can authenticate itself to the personalization server in a cryptographically secure manner. To do so, the ID token sends a public cryptographic key to the personalization server. This occurs via the encrypted communication channel. In return, the ID token receives an ephemeral public cryptographic key from the personalization server via the encrypted communication channel. The ID token calculates a shared secret with the personalization server using the private cryptographic key of the ID token and the received ephemeral public cryptographic key of the personalization server. The personalization server can calculate the same shared secret using the public cryptographic key of the ID token and the ephemeral private cryptographic key of the personalization server.The ID token generates a random value, which it uses to calculate a shared authentication key. The authentication key is used to authenticate data sent over the encrypted subchannel. The ID token generates the corresponding shared authentication key using the random value and the shared secret. Furthermore, the ID token generates an authentication token using the corresponding authentication key and the ephemeral key of the personalization server. The ID token sends the authentication token thus generated, along with the random value, to the personalization server in the communication channel. Upon receipt of the random value, the personalization server is also able to calculate the authentication key using the shared secret.Using this shared authentication key and the personalization server's ephemeral public cryptographic key, the personalization server can verify the received authentication token. If the verification is successful, the ID token is also successfully authenticated to the personalization server, and successful mutual authentication of the ID token and the personalization server is achieved. Furthermore, the shared authentication key calculated in this way can be used to authenticate data exchanged between the ID token and the personalization server via the encrypted subchannel.

[0113] According to embodiments, the ephemeral public cryptographic key of the personalization server received during the authentication of the personalization server, for example in compressed form, is compared with the ephemeral public cryptographic key of the personalization server received during the authentication of the ID token, wherein a match between both ephemeral public cryptographic keys of the personalization server is a prerequisite for generating the shared second secret. For example, the ephemeral public cryptographic key of the personalization server received during the authentication of the ID token is compressed for the purpose of comparison.

[0114] Embodiments may have the advantage that a binding can be established between the personalization server and the authentication server with which communication takes place during the authentication of the ID token.

[0115] According to embodiments, an application domain identifier of an application domain of the ID token is further used to generate the shared second secret, wherein the application domain identifier is sent from the ID token to the personalization server together with the public cryptographic key of the ID token.

[0116] Embodiments may have the advantage that the ID token can be assigned to a specific application area.

[0117] According to embodiments, the second authentication key is a cryptographic key for generating a message authentication code, wherein the second authentication token is a second MAC of the second ephemeral public cryptographic key of the personalization server generated using the second authentication key.

[0118] According to embodiments, the ID token further generates the second channel-specific ephemeral symmetric cryptographic session key using the shared second secret and fourth random value.

[0119] Embodiments may have the advantage that a channel-specific, ephemeral, symmetric cryptographic session key can be provided for the subchannel in a cryptographically secured manner, which is known only to the ID token and the personalization server. Thus, end-to-end encryption can be enabled via the encrypted subchannel between the ID token and the personalization server.

[0120] According to embodiments, establishing the second encrypted subchannel comprises authenticating the user by the second security element. Establishing the second encrypted subchannel further comprises executing a challenge-response procedure between the second security element and the first security element. Successful execution of the challenge-response procedure confirms successful authentication of the user by the second security element.

[0121] Embodiments can have the advantage that after reading the attributes from the ID token, prior to personalizing the first security element, i.e., during the establishment of the second channel, the user is first authenticated by the mobile device. This authentication is performed on the first security element to be personalized by a further security element of the mobile device, which is assigned to the operating system of the mobile device and is configured for authenticating the registered user of the mobile device using the authentication sensor of the mobile device. The corresponding further security element authenticates the user and, upon successful authentication, confirms the successful authentication to the personalizing security element.This ensures not only that the personalization takes place on the same mobile device that was already used to read the attributes from the ID token, but also that the personalization takes place with the consent of the registered user of the mobile device.

[0122] According to embodiments, the challenge-response method comprises, in response to an authentication request from the ID application program, authenticating the user by the operating system of the mobile terminal using the authentication sensor and the second security element, generating a response by the second security element, sending the response by the second security element to the first security element, and validating the response by the first security element or the security applet, wherein generating the response comprises encrypting the challenge and wherein validating the response comprises decrypting the response.

[0123] 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 mobile device, for further authentication by an ID provider service.

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

[0125] Embodiments may have the advantage that application program manufacturers or the corresponding application programs can utilize 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 secure binding of the terminal to the corresponding application program is missing. Such a secure binding can be implemented by using the first security element with an applet of the application program.The second security element, which may be, for example, a hardware-based security element from 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 user of the mobile device available to an application program installed on the mobile device. Thus, the second security element ensures the cryptographic security of the operating system or provides the operating system with cryptographic security functionality. According to embodiments, the second security element may also be, for example, a software-based and / or firmware-based security element from the device manufacturer.The first security element, which communicates securely with the second security element using the challenge-response protocol and comprises the applet of the application program, can ensure a secure connection with the second security element. The first 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 manufacturer of the application program. Thus, the first 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 first security element comprises an eSIM or an eUICC.

[0126] Embodiments describe a method for the secure authentication of a user on a mobile terminal and the secure authentication of the user by means of a further security element on the corresponding mobile terminal with a device manufacturer-independent security application or security applet.

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

[0128] According to embodiments, a challenge-response method is used to authenticate the user to the application program. This method is executed between the operating system-associated and thus device-specific second security element and the device-independent first security element, which is not associated with the operating system. The first security element or the security applet of the application program is, for example, an application-specific security element or security applet.

[0129] To implement the cryptographically secured connection between the first and the second security element, cryptographic key material is, for example, introduced into the device manufacturer-dependent second security element and / or generated therein. This occurs, for example, during initialization of the mobile terminal. Furthermore, cryptographic key material is introduced into the device manufacturer-independent security applet of the first security element and / or generated therein. This occurs, for example, during initialization of the security applet or the first security element. The cryptographically initialized second security element can introduce a cryptographic key of the second security element into the security applet of the first security element ormake it available to the latter and / or the security applet of the first security element can introduce a cryptographic key of the security applet into the second security element or make it available to the latter. The cryptographic key of the second security element is, for example, a public cryptographic key of an asymmetric cryptographic key pair of the second security element assigned to the application program. The cryptographic key of the security applet is, for example, a public cryptographic key of an asymmetric cryptographic key pair assigned to the security applet. According to embodiments, a cryptographic secret, for example a cryptographic key, in particular a symmetric cryptographic key for executing the challenge-response method, is generated and transmitted.For example, the second security element generates the cryptographic secret and transmits it to the security applet in a cryptographically secured manner using the public cryptographic key provided by the security applet. For example, the security applet generates the cryptographic secret and transmits it to the second security element in a cryptographically secured manner using the public cryptographic key provided by the second security element.

[0130] Embodiments may have the advantage of providing a secure method for authenticating a user of the mobile terminal to the application program. 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, in addition to one security element, i.e., the second security element, which is associated with the operating system and, for example, under the control of the manufacturer of the mobile terminal, to additionally use one security element, i.e., the first security element, which is independent of the second security element and, for example, is not under the control of the device manufacturer.According to embodiments, the security applet of the first security element associated with 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 terminal.

[0131] Embodiments may have the advantage that a simultaneous binding of the user to two independent security elements with a mutually secure entanglement of the two security elements is implemented on a mobile device. The binding of the user is implemented, for example, by the second security element having access to reference values ​​for the one or more authentication factors of the user. For example, the corresponding reference values ​​are stored in a memory area of ​​the mobile device assigned to the second security element. For example, the security element comprises the corresponding memory area. For example, the reference values ​​are stored outside the second 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 second security element is capable of authenticating the user using the corresponding reference values ​​based on authentication factors or authentication data detected by the authentication sensor. This allows the user to be bound to the second security element. The result of the authentication can be forwarded to the first security element in a cryptographically secure manner using the challenge-response method, thereby enabling the user to be bound to the first security element. 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 thus be implemented on the mobile device.For example, the cryptographic means comprise a symmetric key which is stored in the first security element and in the second security element and provides a cryptographic entanglement of the two security elements.

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

[0133] 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 an authentication may include authorization.

[0134] 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 characteristics or behavioral characteristics. For example, the corresponding proof is captured by an authentication sensor of the mobile device in the form of authentication data of one or more authentication factors of the user and compared by a security element of 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 operating system of the mobile device.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, confirmation of successful user authentication involves executing a challenge-response procedure by the confirming security element. For example, upon successful user authentication, the confirming security element confirms this successful authentication to another security element of the mobile device, such as the security element with the application program's security applet, by issuing a correct response to a challenge from the corresponding other security element.

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

[0136] An authentication sensor is a sensor for capturing authentication data of one or more authentication factors of the user of the mobile device. The authentication data can, for example, include biometric data of the user. The authentication sensor can be configured to capture biometric data of the user. Biometric data can, for example, include: fingerprint data, body geometry data / anthropometric 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.

[0137] A challenge-response method represents a secure authentication method between a first instance and a second instance based on knowledge. For example, an authenticating security element of a mobile device, such as a security element of the mobile device's operating system, is authenticated by another authenticating security element of the mobile device using a challenge-response method. 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 authenticating security element.Thus, in the case of a successful challenge-response procedure, the authenticating security element not only knows that the user authentication has been confirmed, but also that it has been confirmed by the authenticating security element and is therefore valid.

[0138] In the course of a challenge-response procedure, a first instance presents a task ("challenge") to a second instance, for which the second instance must provide a correct answer ("response").

[0139] For example, the first instance generates a random number ("nonce") and sends it to the second instance. The second instance uses a shared secret to cryptographically transform the nonce and sends the result as a response to the first instance for the purpose of authenticating the second instance. For example, the nonce is combined with the shared secret and a cryptographic hash function or encryption is applied to this combination. Alternatively, the shared secret, such as a symmetric cryptographic key, can be used to encrypt the nonce. The first instance, which knows both the nonce and the shared secret, can, for example, perform the same computation as the second instance and / or perform an inverse computation, e.g., decrypt the encrypted nonce using the shared secret.If the result of the calculation by the first instance matches the result of the calculation by the second instance or the challenge, the challenge-response procedure is successful and the second instance is successfully authenticated.

[0140] Furthermore, a challenge-response procedure can also be based on an asymmetric cryptosystem and serve to prove to the first instance that the second instance possesses a private and thus secret cryptographic key. In this case, 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, for example, be 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 has knowledge of the private cryptographic key, without the first instance itself gaining knowledge of the private cryptographic key during the verification process.

[0141] According to embodiments, encryption and decryption are performed using a symmetric cryptographic key. According to embodiments, encryption is performed using a private cryptographic key of an asymmetric cryptographic key pair of the first security element, and decryption is performed using a public cryptographic key of the asymmetric cryptographic key pair of the first security element.

[0142] According to embodiments, establishing the second encrypted subchannel further comprises authenticating the personalization server by the security applet of the first security element.

[0143] Embodiments may have the advantage that a prerequisite for establishing the second encrypted subchannel is successful authentication of the personalization server by the security element. Thus, the security element can be certain not only that the personalization is performed by the same personalization server that read the attributes from the ID token, but also that the corresponding server is authorized to personalize the corresponding security element.

[0144] According to embodiments, authenticating the personalization server by the security applet of the first security element comprises: Receiving a third certificate from the personalization server, which comprises a third public cryptographic key of the personalization server, by the security applet of the first security element via the encrypted communication channel, verifying a signature of the received third certificate of the personalization server by the security applet of the first security element, generating a fifth random value by the security applet of the first security element, sending the fifth random value as a challenge by the security applet of the first security element via the encrypted communication channel to the personalization server, receiving a second signature of the challenge as a response from the personalization server, wherein the challenge is signed using a third ephemeral private cryptographic key of the personalization server,Verifying the received second signature using the third public cryptographic key of the personalization server and the fifth random value sent.

[0145] According to embodiments, a third ephemeral public cryptographic key of the personalization server, for example in compressed form, is further received by the security applet via the encrypted communication channel.

[0146] According to embodiments, a second data combination comprising the challenge is signed to generate the response. For example, the second data combination includes the fifth random value sent as a challenge and the third ephemeral public cryptographic key of the personalization server, for example in compressed form.

[0147] Embodiments may have the advantage that the first security element to be personalized first receives a certificate from the personalization server via the encrypted communication channel. The corresponding certificate can be verified by the security element. For example, the corresponding certificate is provided as part of a certificate chain, which the security element can verify using stored root signature verification keys. Thus, the ID token can verify the authenticity of the provided certificate using the certificate chain, for example, a PKI. Furthermore, the security element receives an ephemeral public cryptographic key from the personalization server. For example, the security element receives the ephemeral public cryptographic key of the personalization server in compressed form.In return for receiving the certificate from the personalization server, the security element generates a random value and sends the corresponding random value as a challenge to the personalization server. In response to sending the random value as a challenge, the security element receives a signature of the challenge as a response from the personalization server via the encrypted communication channel. To create the signature, the private cryptographic key of the personalization server is used, which forms an asymmetric key pair with the public cryptographic key of the previously provided certificate. For example, to generate the response, a data combination is signed. The corresponding data combination includes, for example, the random value previously sent as a challenge and the ephemeral public cryptographic key of the personalization server, e.g., in compressed form.The security element can verify the corresponding signature using the previously received public cryptographic key of the personalization server as the signature verification key. To do this, the security element can, for example, also use the ephemeral public cryptographic key of the personalization server and the random value previously sent as a challenge. If the signature verification is successful, the personalization server is considered successfully authenticated.

[0148] According to embodiments, the first, second, and / or third certificates of the personalization server are different certificates with different public cryptographic keys of the personalization server. Thus, in this case, the first, second, and / or third public cryptographic keys of the personalization server are, for example, different public cryptographic keys of different asymmetric cryptographic key pairs.

[0149] According to embodiments, the first, second, and / or third certificate of the personalization server is the same certificate with the same public cryptographic key of the personalization server. Thus, in this case, the first, second, and / or third public cryptographic key of the personalization server is, for example, the same public cryptographic key of the same asymmetric cryptographic key pair.

[0150] According to embodiments, the certificate is received as part of a certificate chain, wherein verifying the signature of the received certificate comprises checking a signature chain of the certificates in the certificate chain. According to embodiments, the certificate chain begins with an initial certificate signed by a root authority whose signature is verifiable with a root signature verification key to which the security applet of the first security element has access. According to embodiments, the certificate chain ends with the certificate of the personalization server.

[0151] According to embodiments, establishing the second encrypted subchannel further comprises authenticating the security applet of the first security element to the personalization server.

[0152] Embodiments may have the advantage of performing authentication of the security element with the personalization server. Thus, for example, mutual authentication can be implemented between the security applet to be personalized and the personalization server.

[0153] According to embodiments, authenticating the security applet of the first security element to the personalization server comprises: Receiving the third ephemeral public cryptographic key of the personalization server by the security applet of the first security element from the personalization server via the encrypted communication channel, generating a third secret shared with the personalization server by the security applet of the first security element using the private cryptographic key of the security applet of the first security element and the ephemeral public cryptographic key of the personalization server, generating a sixth random value by the security applet of the first security element, generating a third common authentication key for authenticating data sent via the second encrypted subchannel, wherein the third common authentication key is generated using the shared third secret and the sixth random value,Generating a fourth authentication token by the security applet of the first security element using the third authentication key and the third ephemeral public cryptographic key of the personalization server to authenticate the security applet of the first security element to the personalization server, Sending the sixth random value together with the fourth authentication token to authenticate the security applet of the first security element by the security applet of the first security element to the personalization server via the encrypted communication channel.

[0154] Embodiments can have the advantage that the not yet personalized security applet of the first security element can authenticate itself to the personalization server. To do so, the corresponding security applet to be personalized first uses a stored initial cryptographic key of the security applet. This initial cryptographic key is, for example, an initial private cryptographic key. The corresponding initial cryptographic key is, for example, stored on the first security element during provisioning of the security applet. For example, an initial asymmetric key pair is stored. To authenticate the security applet, the corresponding security applet first receives, for example, an ephemeral public cryptographic key generated for the purpose of authentication from the personalization server.The personalization server generates the corresponding ephemeral public cryptographic key, for example, for the authentication of the security applet to be personalized. The security applet receives the ephemeral public cryptographic key on the first security element, for example, via the encrypted communication channel. The security applet calculates a shared secret using the initial private cryptographic key of the security applet and the received ephemeral public cryptographic key of the personalization server. The security applet to be personalized generates a random value. The security applet to be personalized uses the corresponding random value to generate a shared authentication key. The shared secret is also used to generate the corresponding shared authentication key.The security applet also generates an authentication token. The security applet generates the corresponding authentication token using the previously received ephemeral public cryptographic key from the personalization server and the previously generated shared authentication key. The security applet to be personalized sends this authentication token, along with the random value, to the personalization server via the encrypted communication channel. The personalization server can also initially calculate the shared secret. To do this, the personalization server uses an initial public cryptographic key of the security applet, which is known to the personalization server. This key was stored on the personalization server, for example, during the registration of the ID application program during provisioning.For example, the corresponding initial public cryptographic key was generated during provisioning of the security applet to be personalized and made available to the personalization server. Furthermore, the personalization server uses the personalization server's ephemeral private cryptographic key to calculate the shared secret. With the corresponding shared secret, the personalization server is able to calculate the shared authentication key. To do this, the personalization server uses the received random value and the previously calculated shared secret. The personalization server can thus verify the received authentication token using the shared authentication key and the personalization server's ephemeral public cryptographic key.

[0155] This allows the security applet to be personalized to be authenticated. This can have the advantage, for example, that the participants in the encrypted subchannel between the security applet to be personalized of the first security element and the personalization server know who they are communicating with, or they can ensure that they are communicating with the correct participant. Furthermore, the shared authentication key can be used to authenticate data exchanged over the second encrypted subchannel between the security applet to be personalized and the personalization server.

[0156] According to embodiments, the ephemeral public cryptographic key of the personalization server received during the authentication of the personalization server is compared with the ephemeral public cryptographic key of the personalization server received during the authentication of the security applet of the first security element, wherein a match between both ephemeral public cryptographic keys of the personalization server is a prerequisite for generating the shared secret.

[0157] According to embodiments, the third authentication key is a cryptographic key for generating a message authentication code, wherein the third authentication token is a third MAC of the third ephemeral public cryptographic key of the personalization server generated using the third authentication key.

[0158] According to embodiments, the security applet of the first security element further generates the third channel-specific ephemeral symmetric cryptographic session key using the shared third secret and the sixth random value.

[0159] Embodiments may have the advantage that a channel-specific ephemeral symmetric cryptographic session key can be provided for the security element to be personalized and the personalization server, by means of which the second subchannel can be encrypted. In particular, end-to-end encryption can thus be realized between the endpoints of the corresponding subchannel, i.e., the security element to be personalized and the personalization server.

[0160] According to embodiments, the third channel-specific ephemeral symmetric cryptographic session key for encrypting the second encrypted subchannel between the security applet of the first security element and the personalization server is stored as an initial key for use by the security applet in the first security element and in the personalization server.

[0161] For example, the security applet for personalization is provided by the personalization server in a subsecurity domain of the first security element, which is otherwise empty and, for example, does not contain any key material for mutual authentication with the personalization server. In this case, for example, no corresponding mutual authentication with the personalization server takes place during the establishment of the second encrypted subchannel. Rather, only the initial key for use by the security applet is stored in the first security element.

[0162] According to embodiments, a channel-specific ephemeral symmetric cryptographic authentication key for authenticating data transmitted via the corresponding second encrypted subchannel is further stored in the first security element for use by the security applet and in the personalization server.

[0163] According to embodiments, a plurality of ID tokens are used for personalization.

[0164] According to embodiments, a second ID token is further used for personalization. The personalization further includes: Establishing a third encrypted subchannel between the second ID token and the personalization server within the encrypted communication channel via the mobile terminal, wherein the ID application program is used to establish the third encrypted subchannel, Reading one or more of the second attributes from the second ID token by the personalization server via the third encrypted subchannel within the encrypted communication channel, Establishing a fourth encrypted subchannel between the security applet of the first security element and the personalization server within the encrypted communication channel, wherein the ID application program is used to establish the fourth encrypted subchannel,Receiving the read second attributes by the security applet of the first security element from the personalization server via the fourth encrypted subchannel within the encrypted communication channel, storing the received second attributes by the security applet, wherein the ID application program is configured to use the second attributes to prove an identity of the user to another computer system.

[0165] Embodiments can have the advantage that attributes can be read from different ID tokens and, during personalization, stored in the security element of the mobile device to be personalized. Thus, the mobile device can store not only digital identities that reflect identities provided by an ID token, i.e., an electronic identity document, but also identities that represent combinations of attributes of corresponding ID tokens. For example, the attributes from different ID tokens are read via the same encrypted communication channel.

[0166] For example, attributes from different ID tokens are read via different encrypted communication channels. According to embodiments, a third encrypted communication channel is established between the mobile device and the personalization server via the network, within which a third and fourth encrypted subchannel are established.

[0167] For example, the ID application program is configured to use the second attributes in combination with the first attributes to prove the user's identity to another computer system.

[0168] According to embodiments, the ID application program is configured to send one or more of the first and / or second attributes of the user to another terminal.

[0169] According to embodiments, the ID application program is configured to send one or more of the first and / or second attributes of the user using a communication interface of the mobile terminal via the network to an ID provider server for provision to a service provider server and / or for confirmation to the service provider server.

[0170] Embodiments further include a mobile terminal comprising a processor and a memory. An ID application program is stored in the memory. The mobile terminal further includes a security element with a security applet associated with the ID application program. The processor is configured to execute a method for personalizing the security applet using an ID token and a personalization server. The mobile terminal further includes a communication interface for contactless communication with the ID token and for communication via a network with the personalization server.

[0171] Personalization includes: Establishing an encrypted communication channel between the mobile terminal and the personalization server via a network, wherein the ID application program is used to establish the encrypted communication channel; Establishing a first encrypted subchannel between the first ID token and the personalization server within the encrypted communication channel via the mobile terminal, wherein the ID application program is used to establish the first encrypted subchannel; Reading one or more of the first attributes from the ID token by the personalization server via the first encrypted subchannel within the encrypted communication channel; Establishing a second encrypted subchannel between the security applet of the security element and the personalization server within the encrypted communication channel;wherein the ID application program is used to establish the second encrypted subchannel, receiving the read attributes by the security applet of the security element from the personalization server via the second encrypted subchannel within the encrypted communication channel, storing the received attributes by the security applet, wherein the ID application program is configured to use the attributes to prove the identity of the user to another computer system.

[0172] According to embodiments, the mobile terminal is configured to execute each of the above-described embodiments of the method for personalizing a security applet.

[0173] Embodiments further include a system. The system includes a mobile device and a personalization server. The personalization server is configured to read attributes from an ID token via the mobile device and to personalize the security applet of the mobile device.

[0174] According to embodiments, the system is configured to perform any of the above-described embodiments of the method for personalizing a security applet.

[0175] According to embodiments, the system further comprises the ID token in which the attributes to be read are stored.

[0176] 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 schematic diagram of an exemplary system, Figure 4 is a flowchart of an exemplary method for personalizing a security applet, Figure 5 is a schematic diagram of exemplary encrypted channels, and Figures 6A,B is a flowchart of an exemplary method for personalizing the security applet.

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

[0178] Figure 1shows an exemplary mobile terminal 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 terminal 100 and an ID application program 108. The ID application program 108 is configured to manage attributes or identity attributes of a user in a personalized state and, for example, to provide them to another computer system for verifying the user's identity. Furthermore, the ID application program 108 comprises, for example, a personalization component that controls a personalization of a security applet 114 assigned to the ID application program 108. In particular, the personalization component controls, for example, the establishment of encrypted channels for communication in the course of a corresponding personalization.The corresponding attributes are part of or form an electronic identity of the user managed by the ID application program 108, which the user can use via the mobile terminal 100. Furthermore, the mobile terminal 100 comprises, for example, two security elements 110, 112, which can each be implemented as an eSIM and / or eUICC, for example. One of the two security elements 110 is assigned to the operating system 106 and provides cryptographic means for it, such as cryptographic keys, cryptographic functions, and / or cryptographic protocols. For example, the security element 110 provides a key store for storing cryptographic keys, such as symmetric, public, and / or private cryptographic keys, and certificates, such as read certificates, public key certificates, and / or attribute certificates.The cryptographic means provided by the security element 110 enable the operating system 106 to execute or participate in a challenge-response procedure. For example, the security applet 114 associated with the ID application program 108 is installed on the other security element 112. This security applet 114 provides cryptographic means for the ID application program 108, such as cryptographic keys, cryptographic functions, and / or cryptographic protocols. The security applet 114 or a memory area of ​​the security element 112 associated with 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 read certificates, public-key certificates, and / or attribute certificates.The cryptographic means provided by the security element 112 enable the ID application program 108 to execute or participate in a challenge-response procedure. For example, such a challenge-response procedure serves to confirm successful user authentication by the security element 110 to the ID application program 108 or the security applet 114 of the security element 112, which is assigned to the application program 108. Furthermore, the mobile terminal 100 comprises a user interface 116, which comprises, for example, a display, in particular a touchscreen. Using the user interface 116, the user can interact with the mobile terminal 100. For example, the user can be prompted to provide authentication factors or authentication features.To capture authentication data of the user's authentication factors, the mobile terminal 100 includes an authentication sensor 118, which can be integrated into the user interface 116 or implemented as a standalone component, for example. Finally, the mobile terminal 100 includes a communication interface or antenna 120, which is configured for wireless communication, for example, via a network.

[0179] Using the communication interface 120, the mobile terminal 100 can communicate, for example, with a personalization server for the purpose of personalizing the security applet 114 in the security element 112 and thus the ID application program 108. Furthermore, the communication interface 120 is configured, for example, for wireless communication with an ID token that provides the user's attributes. For different communication methods, the communication interface 120 comprises, for example, different communication components. The mobile terminal 100 with the communication interface 120 can thus act as a transceiver, enabling communication between the ID token and the personalization server for the personalization server to read the attributes from the ID token.The mobile terminal 100 establishes an encrypted communication channel between the personalization server and the ID token via a network using the security element 110. The corresponding communication channel is encrypted, for example, using end-to-end encryption. Within the encrypted communication channel, a first encrypted subchannel is established between the ID token and the personalization server through the mediation of the mobile terminal 100 or a personalization component of the ID application program 108. The corresponding first subchannel is also encrypted, for example, using end-to-end encryption. This first encrypted subchannel is used, for example, for communication between the ID token and the personalization server, for example, for the personalization server to read out the attributes provided by the ID token.Furthermore, within the encrypted communication channel, a second encrypted subchannel can be established between the security applet 114 of the security element 112 to be personalized and the personalization server. This establishment is again carried out, for example, via the personalization component of the ID application program 108. The corresponding second subchannel is also encrypted, for example, using end-to-end encryption. This second encrypted subchannel serves, for example, for communication between the security applet 114 of the security element 112 and the personalization server, for example, for personalizing the security applet 114 with the attributes read from the ID token by the personalization server.

[0180] Figure 2shows an exemplary mobile terminal 100 on which an operating system 106 is installed, which manages the resources of the mobile terminal 100 and makes them available to the ID application program 108. The managed resources include, for example, the two security elements 110, 112, the authentication sensor 118, the user interface 116, and the communication interface 120. Although the security element 112 is provided or managed, for example, by the operating system 106, the security applet 114 included in the corresponding security element 112 is assigned to the ID application program 108, i.e., the security applet 114 only provides cryptographic means to the ID application program 108. The operating system 106 cannot use these cryptographic means.For cryptographic tasks, for example when using the authentication sensor 118 or the communication interface 120, the other security element 110 with its cryptographic means is available to the operating system 106.

[0181] Figure 3 shows an exemplary system 170 comprising a mobile terminal 100 connected to a personalization server 220 via a network 150, for example, the Internet. Furthermore, the mobile terminal 100 can communicate via the network 150, for example, with an ID provider server 240 and / or a service provider server 260. Furthermore, the mobile terminal 100 can be connected to an ID token 200, for example, via a wireless direct communication link 152. The mobile terminal 100 is configured, for example, as shown in Figure 1described and has the corresponding functionalities. To personalize the security applet of the security element 112, for example, attributes 206 provided by an ID token 200 are used. The ID token 200 comprises a processor 202 and a memory 204. The attributes 206, which are identity attributes of the holder of the ID token 200, are stored in a protected memory area 205 of the memory 204. Furthermore, program instructions 208 are stored in the memory 204, the execution of which by the processor 202 causes the processor to enable the attributes 206 to be read out by an authorized entity, such as the personalization server 220. For this purpose, the ID token 200, for example using its communication interface 210, establishes a wireless direct connection 152 with the mobile terminal 100, via which the personalization server 220 can read the attributes 206.

[0182] The personalization server 220 comprises a processor 222, a memory 224, and a communications interface 230. Memory 224 stores program instructions 228, the execution of which causes the processor 222 to control the personalization server 220 to establish encrypted channels with the mobile terminal 100, the ID token 200 via the mobile terminal 100, and the security applet in the security element 112 of the mobile terminal 100. The personalization server 220 uses these channels to read attributes 206 from the ID token 200 and to incorporate the read attributes 206 into the security element 112 during the personalization process. To prove a read authorization for the attributes 206 from the ID token 200 and a write authorization for writing the read attributes 206 into the security element 112 of the mobile terminal 100, the personalization server 220 uses, for example, corresponding certificates 226.

[0183] The system further comprises, for example, a service provider server 260. The service provider server 260 comprises a processor 262, a memory 264, and a communication 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 150. 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.

[0184] 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 to read 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 this, the user must successfully authenticate themselves to the ID application program 108. For example, a display device of the user interface 116 shows the user which identity attributes are to be sent to the ID provider server 240, and the user is able to edit this selection. For example, the user can select which of the requested identity attributes are actually sent.Upon successful verification of read authorization and successful user authentication, the released identity attributes are sent to the ID provider server 240. The ID provider server 240 signs the received identity attributes and sends them to the service provider server 260.

[0185] Figure 4shows an exemplary method for personalizing a security applet. The security applet to be personalized is installed on a security element of a mobile device and assigned to an ID application program installed on the mobile device. Personalization is performed using an ID token, on which a user's attributes are stored, and a personalization server, which has both authorization to read the attributes from the ID token and authorization to incorporate the read attributes into the security applet for personalization purposes. The personalization server verifies the corresponding authorizations using certificates and / or the possession and use of specific cryptographic keys.

[0186] In block 300, personalization comprises establishing an encrypted communication channel between the mobile device and the personalization server via a network. For example, the ID application program or a personalization component of the ID application program is used to control the establishment. During the establishment, mutual authentication of the mobile device and the personalization server takes place, for example, using challenge-response methods. Furthermore, a first channel-specific ephemeral symmetric cryptographic session key is negotiated for encrypting the communication channel between the mobile device and the personalization server.

[0187] In block 302, a first encrypted subchannel is established between the ID token and the personalization server within the encrypted communication channel via the mobile device. For example, the ID application program or a personalization component of the ID application program is used to control the establishment. During the establishment, mutual authentication of the ID token and the personalization server takes place, for example, using challenge-response methods. Furthermore, a second channel-specific ephemeral symmetric cryptographic session key for encrypting the first subchannel is negotiated between the ID token and the personalization server. In block 304, one or more of the attributes from the ID token are read by the personalization server via the first encrypted subchannel within the encrypted communication channel.

[0188] Furthermore, in block 306, a second encrypted subchannel is established between the security applet of the security element and the personalization server within the encrypted communication channel. For example, the ID application program or a personalization component of the ID application program is used to control the establishment. During the establishment, mutual authentication of the ID application program or the associated security applet and the personalization server takes place, for example, using challenge-response methods. Furthermore, a third channel-specific ephemeral symmetric cryptographic session key for encrypting the second subchannel is negotiated between the security applet and the personalization server.In block 308, the security applet receives the read attributes from the personalization server via the second encrypted subchannel within the encrypted communication channel. In block 310, the security applet stores the received attributes, thus assigning or personalizing it to the corresponding user. The ID application program is configured to use the stored attributes to verify the electronic identity of the corresponding user to another computer system. During the personalization process, the security applet also initiates, for example, the generation of an asymmetric cryptographic key pair assigned to the ID application program on the personalization server.The asymmetric cryptographic key pair comprises a private cryptographic key and a public cryptographic key of the ID application program, which serve, for example, to authenticate the ID application program when using the attributes. The public cryptographic key of the ID application program is sent, for example, from the security applet to the personalization server via the second encrypted subchannel within the encrypted communication channel. Furthermore, the security applet receives, for example, one or more root signature verification keys from the personalization server via the second encrypted subchannel within the encrypted communication channel.These received root signature verification keys are stored and serve to verify certificate signatures of one or more root authorities, which have certificates that are each used to authenticate a reading computer system to the ID application program during the reading of the first attributes. In addition, the security applet receives and stores, for example, a signature of the received attributes from the personalization server via the second encrypted subchannel within the encrypted communication channel. The signature serves as proof of authenticity of the attributes, particularly when the attributes are used for the purpose of identity verification in offline mode.

[0189] Figure 5shows exemplary encrypted channels 160, 162, 164, which are established during the personalization of the security applet on the security element 112. An encrypted communication channel 160 is established between the mobile terminal 100 and the personalization server 220. This serves to secure the communication between the mobile terminal 100 and the personalization server 220. At the same time, this channel binds the mobile terminal 100 to the personalization server 220 during the communication. The personalization server 220 can thus ensure that all communication via the encrypted communication channel 160 takes place via the same mobile terminal 100. For example, the same mobile terminal 100 is used to read attributes from the ID token, which is subsequently personalized with the read attributes.

[0190] During further personalization, communication between the mobile terminal 100 and the personalization server 220 takes place via an encrypted communication channel 160. This also includes communication between the personalization server 220 and the ID token 200, which takes place via the mobile terminal 100. The encrypted communication channel 160 is encrypted, for example, using end-to-end encryption. The encryption and decryption of the communication takes place on the mobile terminal 100 side, for example, using the further security element of the operating system of the mobile terminal 100. Within the encrypted communication channel 160, a first encrypted subchannel 162 is also established between the ID token 200 and the personalization server 220, mediated by the mobile terminal 100 or a personalization component of the ID application program.This first encrypted subchannel 162 is used, for example, for communication between the ID token 200 and the personalization server 220, for example, for the personalization server 220 to read the attributes provided by the ID token 200. The corresponding first subchannel 162 is also encrypted, for example, using end-to-end encryption. The data transmission between the mobile device 100 and the personalization server 220 takes place, for example, via a network, while the data transmission between the mobile device 100 and the ID token 200 takes place, for example, via a direct radio connection.

[0191] In this context, subchannel means that data to be transmitted via the corresponding subchannel is first encrypted using a cryptographic session key of the corresponding subchannel. For example, an additional MAC of the data is generated using a cryptographic authentication key of the corresponding subchannel and transmitted together with the encrypted data. In addition, the data to be transmitted is encrypted using another cryptographic session key of the communication channel that is higher than the subchannel. For example, an additional MAC of the data is generated using another cryptographic authentication key of the corresponding communication channel and transmitted together with the encrypted data. When the transmitted data reaches the end of the communication channel, the encryption of the communication channel is first decrypted.When the transmitted data reaches the end of the subchannel, the subchannel's encryption is also decrypted. Transmission over an encrypted subchannel within an encrypted communication channel therefore involves double encryption with two independent session keys. The session keys are independent in the sense that access to one of the two session keys does not automatically result in access to the other session key.

[0192] Within the encrypted communication channel 160, a second encrypted subchannel 164 is also established between the security element 112 or a security applet 114 of the security element 112 to be personalized and the personalization server 220, mediated by the personalization component of the ID application program. The corresponding second subchannel 164 is also encrypted, for example, using end-to-end encryption. This second encrypted subchannel 164 serves, for example, for communication between the security element 112 and the personalization server 220, for example, for personalizing the security applet 114 of the security element 112 with the attributes read from the ID token 200 by the personalization server 220.

[0193] Figure 6 , which the Figures 6A and 6Bshows an exemplary method for personalizing a security applet 114 in a security element 112. First, in step 400, a user of the mobile terminal authenticates himself with a security element 110 of the mobile terminal 100 configured for this purpose. For example, reference values ​​for one or more authentication factors, such as biometric features or a PIN, of a user registered on the mobile terminal are stored in the security element 110. During user authentication, one or more authentication factors of the user are recorded and compared with the reference values. If there is a match, the user is considered to have been successfully authenticated, for example. In step 402, an encrypted communication channel is established between the mobile terminal, for example the security element 110, and the personalization server 220.This includes, for example, mutual authentication of the mobile terminal or security element 110 and the personalization server 220, for example by means of a challenge-response method, as well as negotiation of a cryptographic key, for example a channel-specific ephemeral symmetric cryptographic session key, for encrypting the communication channel.

[0194] For example, a first initial random value is first generated by the mobile terminal or the security element 110 and sent to the personalization server 220. After receiving the corresponding first initial random value, the personalization server 220 generates a second initial random value, which it sends to the mobile terminal 100. Thus, both participants, the mobile terminal and the personalization server 220, have both initial random values. Furthermore, the server sends, for example, its certificate to the mobile terminal and, after successfully verifying the corresponding certificate, receives a certificate of the mobile terminal from the mobile terminal. The certificate of the mobile terminal can, for example, be a certificate assigned to the application program. The certificate of the mobile terminal received by the personalization server 220 is also verified.The two certificates each comprise a public cryptographic key, i.e., the certificate of the personalization server 220 comprises a public cryptographic key of an asymmetric key pair of the personalization server 220, and the certificate of the mobile terminal comprises a public cryptographic key of an asymmetric key pair of the mobile terminal. Thus, both participants now each have public cryptographic keys of the other party, the authenticity of which is verified by a certificate. The mobile terminal then generates, for example, the first random value, which it sends to the personalization server 220. Thus, both participants in the communication now each have three random values, from which, for example, the channel-specific ephemeral symmetric cryptographic session key can be calculated.Furthermore, the mobile terminal sends, for example, a signature of one, several, or all previous messages exchanged during channel establishment to the personalization server 220. By verifying the corresponding signature using the public cryptographic key provided by the mobile terminal's certificate as the signature verification key, the personalization server 220 can authenticate the mobile terminal. If the personalization server 220 subsequently sends a message encrypted with the first channel-specific ephemeral symmetric cryptographic session key to the mobile terminal, the personalization server 220 is thereby also authenticated to the mobile terminal.The personalization server 220 can only calculate the first channel-specific ephemeral symmetric cryptographic session key if it has a private cryptographic key with which it can decrypt the first random value received from the mobile terminal. Thus, only the personalization server 220 in possession of the corresponding private cryptographic key, to which the certificate of the personalization server 220 is assigned, is capable of encrypted communication over the encrypted communication channel.

[0195] To enable establishment of a first encrypted subchannel, in step 404, the user of the mobile terminal is authenticated by the ID token 200 using the mobile terminal or the security element 110. For example, the user is authenticated to the ID token 200 using the mobile terminal. For example, an ephemeral symmetric cryptographic key is derived using the user's recorded authentication factor. The mobile terminal receives a random value from the ID token 200, which is encrypted with the same ephemeral symmetric cryptographic key. The ID token 200 derives the corresponding ephemeral symmetric cryptographic key, for example, from a reference value for the authentication factor, or the correspondingly derived ephemeral symmetric cryptographic key is stored on the ID token 200.If the mobile device is able to correctly decrypt the received encrypted random value, this constitutes proof that the mobile device has the correct authentication factor. The mobile device generates an ephemeral asymmetric key pair, the public cryptographic key of which the mobile device sends to the ID token 200. In return, the mobile device receives the public cryptographic key of the ID token 200. At this point in the method, therefore, no static cryptographic keys are necessary; instead, only randomly generated ephemeral asymmetric key pairs can be used. Using the decrypted random value, the ephemeral private cryptographic key of the ID application program, and the ephemeral public cryptographic key of the ID token 200, the mobile device generates a secret shared with the ID token 200.The ID token 200 is also capable of calculating the corresponding secret using the random value generated by it, the ephemeral private cryptographic key of the ID token 200, and the ephemeral public cryptographic key of the mobile terminal received from the mobile terminal.

[0196] The mobile terminal can now use the shared secret thus generated to calculate a common authentication key for mutually authenticating the ID application program and the ID token 200. For example, the mobile terminal can generate a first authentication token using the corresponding authentication key and the ephemeral public cryptographic key of the ID token 200. The corresponding authentication token can be sent from the mobile terminal to the ID token 200, which can verify the received authentication token using the shared authentication key and the ephemeral private cryptographic key of the ID token 200. Thus, the mobile terminal can authenticate itself to the ID token 200. Likewise, the ID token 200 can send an authentication token to the mobile terminal.The mobile device receives the authentication token, which is generated, for example, using the shared secret and the mobile device's ephemeral public cryptographic key. The authentication token can be verified using the authentication key and the public cryptographic key of the ID application program.

[0197] In step 406, a first encrypted subchannel is established following successful user authentication in step 404. Establishing the first encrypted subchannel includes, for example, mutual authentication of ID token 200 and personalization server 220, as well as negotiating a cryptographic key for encrypting the corresponding subchannel.

[0198] For example, the personalization server 220 is first authenticated by the ID token 200 in a cryptographically secure manner. For this purpose, the ID token 200 receives, for example, a certificate from the personalization server 220, which provides a public cryptographic key of the personalization server 220 for authentication. The ID token 200 verifies the signature of the received certificate. For example, the corresponding certificate is received as part of a certificate chain, for the verification of which corresponding signature verification keys, in particular root signature verification keys, are stored on the ID token 200. Thus, the ID token 200 can verify the authenticity of the provided certificate based on the certificate chain, for example, a PKI. Furthermore, the ID token 200 receives, for example, an ephemeral public cryptographic key from the personalization server 220.For example, the ID token 200 receives the ephemeral public cryptographic key of the personalization server 220 in compressed form. In return for receiving the certificate from the personalization server 220, the ID token 200 generates a random value, which it sends to the personalization server 220 as a challenge via the encrypted communication channel. The personalization server 220 creates a signature of the challenge as a response to the challenge using a private cryptographic key, which forms an asymmetric key pair with the public cryptographic key of the previously provided certificate. For example, to generate the response, a data combination is signed that includes the random value as a challenge and the ephemeral public cryptographic key of the personalization server 220, for example in compressed form.The ID token 200 receives the corresponding signature via the encrypted communication channel and verifies it using the previously received public cryptographic key of the personalization server 220 as the signature verification key. For this purpose, the ID token 200 further uses, for example, the previously sent random value as well as the ephemeral public cryptographic key of the personalization server 220 previously received as a challenge.

[0199] The ID token 200 then authenticates itself to the personalization server 220 in a cryptographically secure manner. To do so, the ID token 200 sends a public cryptographic key to the personalization server 220. This occurs via the encrypted communication channel. In return, the ID token 200 receives an ephemeral public cryptographic key from the personalization server 220 via the encrypted communication channel. The ID token 200 calculates a secret shared with the personalization server 220 using the private cryptographic key of the ID token 200 and the received ephemeral public cryptographic key of the personalization server 220. The personalization server 220 may calculate the same shared secret using the public cryptographic key of the ID token 200 and the ephemeral private cryptographic key of the personalization server 220.The ID token 200 generates a random value, which it uses to calculate a shared authentication key. The authentication key is used to authenticate data sent over the encrypted subchannel. The ID token 200 generates the corresponding shared authentication key using the random value and the shared secret. Furthermore, the ID token 200 generates an authentication token using the corresponding authentication key and the ephemeral key of the personalization server 220. The ID token 200 sends the authentication token thus generated, along with the random value, to the personalization server 220 in the communication channel. Upon receipt of the random value, the personalization server 220 is enabled to also calculate the authentication key using the shared secret.Using this shared authentication key and the ephemeral public cryptographic key of the personalization server 220, the personalization server 220 can verify the received authentication token. If the verification is successful, the ID token 200 is also successfully authenticated to the personalization server 220, and successful mutual authentication of the ID token 200 and the personalization server 220 is achieved. Furthermore, the shared authentication key calculated in this way can be used to authenticate data exchanged between the ID token 200 and the personalization server 220 via the encrypted subchannel.

[0200] Furthermore, the ID token 200 and the personalization server 220 may each generate the channel-specific ephemeral symmetric cryptographic session key for encrypting the first subchannel using the shared secret and the random value.

[0201] The personalization server 220 uses the first encrypted subchannel thus established between the personalization server 220 and the ID token 200 within the encrypted communication channel between the personalization server 220 and the mobile terminal or the security element 110 in step 408 to read the attributes from the ID token 200 via the mobile terminal.

[0202] To incorporate the read attributes, a second encrypted subchannel is established between the security applet 114 of the security element and the personalization server 220. In step 410, for example, the user is authenticated by the security element 110, which confirms the successful authentication to the security applet of the security element 112, for example, using a challenge-response procedure.

[0203] In step 412, a second encrypted subchannel is established upon successful user authentication in step 410. Establishing the second encrypted subchannel includes, for example, mutual authentication of security applets and personalization server 220 and negotiation of a cryptographic key for encrypting the corresponding subchannel.

[0204] First, for example, the personalization server 220 is authenticated in a cryptographically secure manner by the first security element 112 or the security applet 114. For this purpose, the security element 112 to be personalized first receives a certificate from the personalization server 220 via the encrypted communication channel. The corresponding certificate can be verified by the security element 112. For example, the corresponding certificate is provided as part of a certificate chain, which the security element 112 can verify using stored root signature verification keys. Thus, the security element 112 can verify the authenticity of the provided certificate based on the certificate chain, for example, a PKI. Furthermore, the security element 112 receives an ephemeral public cryptographic key from the personalization server 220.For example, the security element 112 receives the ephemeral public cryptographic key of the personalization server 220 in compressed form. In return for receiving the certificate from the personalization server, the security element 112 generates a random value and sends the corresponding random value as a challenge to the personalization server 220. In response to sending the random value as a challenge, the security element 112 receives a signature of the challenge as a response from the personalization server 220 via the encrypted communication channel. To create the signature, the private cryptographic key of the personalization server 220 is used, which forms an asymmetric key pair with the public cryptographic key of the previously provided certificate. For example, to generate the response, a data combination is signed.The corresponding data combination includes, for example, the random value previously sent as a challenge and the ephemeral public cryptographic key of the personalization server 220, for example in compressed form. The security element 112 can verify the corresponding signature using the previously received public cryptographic key of the personalization server 220 as a signature verification key. To do so, the security element 112 further uses, for example, the ephemeral public cryptographic key of the personalization server 220 and the random value previously sent as a challenge. If the signature verification is successful, the personalization server 220 is considered successfully authenticated.

[0205] The security element 112 or the security applet 114 then authenticates itself in a cryptographically secure manner to the personalization server 220. To do so, the corresponding security element 112 or the security applet 114 to be personalized first uses a stored initial private cryptographic key of the security applet 114. The corresponding initial private cryptographic key is stored on the security element 112, for example, during provisioning of the security applet 114. For example, an asymmetric cryptographic key pair of the security applet 114 comprising the initial private cryptographic key is stored. To authenticate the security applet 114, the corresponding security applet 114 first receives, for example, an ephemeral public cryptographic key generated for the purpose of authentication from the personalization server 220.The personalization server 220 generates the corresponding ephemeral public cryptographic key, for example, for the authentication of the security applet 114 to be personalized. The security applet 114 receives the ephemeral public cryptographic key, for example, via the encrypted communication channel. The security applet 114 calculates a shared secret using the initial private cryptographic key of the security applet 114 and the received ephemeral public cryptographic key of the personalization server 220. The security applet 114 to be personalized generates a random value. The security applet 114 to be personalized uses the corresponding random value to generate a shared authentication key. The shared secret is also used to generate the corresponding shared authentication key.In addition, the security applet 114 generates an authentication token. The security applet 114 generates the corresponding authentication token using the previously received ephemeral public cryptographic key from the personalization server 220 and the previously generated shared authentication key. The security applet 114 to be personalized sends this authentication token, along with the random value, to the personalization server 220 via the encrypted communication channel. The personalization server 220 can also initially calculate the shared secret. To do this, the personalization server 220 uses an initial public cryptographic key of the security applet 114, which is known to the personalization server 220.For example, the corresponding initial public cryptographic key was generated during provisioning of the security applet 114 to be personalized and made available to the personalization server 220. Furthermore, the personalization server 220 uses the ephemeral private cryptographic key of the personalization server 220 to calculate the shared secret. With the corresponding shared secret, the personalization server 220 is able to calculate the shared authentication key. To do this, the personalization server 220 uses the received random value and the previously calculated shared secret. Thus, the personalization server 220 can verify the received authentication token using the shared authentication key and the ephemeral public cryptographic key of the personalization server 220.

[0206] Furthermore, the security applet 114 of the security element 112 and the personalization server 220 can each independently generate the channel-specific ephemeral symmetric cryptographic session key for encrypting the second subchannel using the shared secret and the random value. The personalization server 220 uses the second encrypted subchannel thus established between the personalization server 220 and the security applet 114 of the security element 112 within the encrypted communication channel in step 414 to incorporate the attributes from the ID token 200 into the security applet 114 of the first security element 112 to be personalized. List of reference symbols

[0207] 100 mobile device 102 processor 104 memory 106 operating system 108 ID application program 110 security element 112 security element 114 security applet 116 user interface 118 authentication sensor 120 communication interface 150 network 160 encrypted communication channel 162 encrypted subchannel 164 encrypted subchannel 170 system 200 ID token 202 processor 204 memory 205 protected memory area 206 attributes 208 program instructions 210 communication interface 220 personalization server 222 processor 224 memory 226 certificate 228 program instructions 230 communication interface 240 ID provider server 242 processor 244 memory 246 certificate 248 program instructions 250 communication interface 260Service provider server 262Processor 264Memory 266Program instructions 270Communication interface

Claims

1. A method for personalising a security applet (114) installed on a first security element (112) of a mobile terminal (100), using a first ID token (200) and a personalisation server (220), wherein an ID application program (108) is installed on the mobile terminal (100), to which the security applet (114) is assigned, wherein first attributes (206) of a user are stored in the first ID token (200), wherein the personalisation comprises: • establishing an encrypted communication channel (160) between the mobile terminal (100) and the personalisation server (220) via a network (150), wherein the ID application program (108) is used to establish the encrypted communication channel (160), • establishing a first encrypted subchannel (162) between the first ID token (200) and the personalisation server (220) within the encrypted communication channel (160) via the mobile terminal (100), wherein the ID application program (108) is used to establish the first encrypted subchannel (162), • reading out one or more of the first attributes (206) from the first ID token (200) by the personalisation server (220) via the first encrypted subchannel (162) within the encrypted communication channel (160), • establishing a second encrypted subchannel (164) between the security applet (114) of the first security element (112) and the personalisation server (220) within the encrypted communication channel (160), wherein the ID application program (108) is used to establish the second encrypted subchannel (164), • receiving, by the security applet (114) of the first security element (112), the read-out first attributes (206) from the personalisation server (220) via the second encrypted subchannel (164) within the encrypted communication channel (160), • storing the received first attributes (206) by the security applet (114), wherein the ID application program (108) is configured to use the first attributes (206) to prove an identity of the user to another computer system.

2. The method according to claim 1, wherein the encrypted communication channel (160) is encrypted with a first channel-specific ephemeral symmetric cryptographic session key, wherein the first encrypted subchannel (162) is encrypted with a second channel-specific ephemeral symmetric cryptographic session key, wherein the second encrypted subchannel (162) is encrypted with a third channel-specific ephemeral symmetric cryptographic session key.

3. The method according to any one of the preceding claims, wherein the encryption of the encrypted communication channel (160) is an end-to-end encryption between the mobile terminal (100) and the personalisation server (220), and / or wherein the encryption of the first encrypted subchannel (162) is an end-to-end encryption between the first ID token (200) and the personalisation server (220), and / or wherein the encryption of the second encrypted subchannel (164) is an end-to-end encryption between the security applet (114) and the personalisation server (220).

4. The method according to any one of the preceding claims, wherein the personalisation further comprises: • generating an asymmetric cryptographic key pair associated with the ID application program (108) by the security applet (114) of the first security element (112) comprising a private cryptographic key and a public cryptographic key of the ID application program (108), wherein the asymmetric key pair is used to authenticate the ID application program (108) in the course of using the first attributes (206), and / or wherein the personalisation further comprises: • receiving one or more root signature verification keys by the security applet (114) of the first security element (112) from the personalisation server (220) via the second encrypted subchannel (164) within the encrypted communication channel (160), wherein the received root signature verification keys are for verifying certificate signatures of one or more root instances having certificates each used in the course of a readout of the first attributes (206) for authenticating a reading computer system to the ID application program (108), • storing the received root signature verification keys by the security applet (114) in the first security element (112), and / or wherein the personalisation further comprises: • receiving a signature of the first attributes (206) from the personalisation server (220) by the security applet (114) of the first security element (112) via the second encrypted subchannel (164) within the encrypted communication channel (160), wherein the signature serves as proof of authenticity of the first attributes (206), • storing the received signature of the first attributes (206) by the security applet (114) in the first security element (112).

5. The method according to any one of claims 2 to 4, wherein establishing the encrypted communication channel (160) comprises negotiating the first channel-specific ephemeral symmetric cryptographic session key.

6. The method according to claim 5, wherein negotiating the first channel-specific ephemeral symmetric cryptographic session key comprises: • generating a first random value by the mobile terminal (100), • generating the first channel-specific ephemeral symmetric cryptographic session key using the first random value by the mobile terminal (100), • receiving a first certificate (226) of the personalisation server (220) with a first public cryptographic key of a first asymmetric cryptographic key pair of the personalisation server (220) by the mobile terminal (100) from the personalisation server (220), • encrypting the first random value using the received first public cryptographic key of the personalisation server (220) by the mobile terminal (100), • sending the encrypted first random value to the personalisation server (220) by the mobile terminal (100) for generating the first channel-specific ephemeral symmetric cryptographic session key by the personalisation server (220).

7. The method according to claim 6, wherein establishing the encrypted communication channel (160) further comprises mutually authenticating the ID application program (108) of the mobile terminal (100) and the personalisation server (220).

8. The method according to claim 7, wherein the mobile terminal (100) further comprises a second security element (110), wherein the second security element (110) comprises a first initial private cryptographic key of a first initial asymmetric cryptographic key pair of the ID application program (108), wherein the mobile terminal (100) further comprises an initial certificate of the ID application program (108) comprising the initial public cryptographic key of the initial asymmetric cryptographic key pair of the ID application program (108), wherein the mobile terminal (100) sends the initial certificate of the ID application program (108) to the personalisation server (220) for authentication to the personalisation server (220) as well as a message signed by the second security element (110) with the first initial private cryptographic key of the ID application program (108).

9. The method according to claim 8, wherein the mobile terminal (100) further comprises one or more authentication sensors (118) for detecting one or more authentication factors of the user, wherein an operating system (106) installed on the mobile terminal (100) is configured to control the authentication sensors (118), wherein the second security element (110) is associated with the operating system (106), wherein a prerequisite for signing with the first initial private cryptographic key of the ID application program (108) is successful authentication of the user with respect to the second security element (110), wherein the user is registered on the mobile terminal (100) and at least one reference value of the registered user is stored in the second security element (110) for verifying at least one detected authentication factor.

10. The method according to any one of the preceding claims, wherein establishing the first encrypted subchannel (162) comprises authenticating the user to the ID token (200) via the mobile terminal (100), wherein authenticating the user to the ID token (200) in particular comprises: • receiving, by the ID application program (108), a further authentication factor of the user detected by the one or more authentication sensors (118), • generating a symmetric cryptographic key by the second security element (110) using the received further authentication factor, • receiving an encrypted second random value by the ID application program (108) from the ID token (200), wherein the encrypted second random value is encrypted using the symmetric cryptographic key generated by the ID token (200) using a further reference value of the registered user stored in the ID token (200) for verifying the further authentication factor, • decrypting the received encrypted second random value by the second security element (110) using the generated symmetric cryptographic key, • generating a first ephemeral asymmetric cryptographic key pair of the ID application program (108) by the second security element (110), which comprises a first ephemeral private cryptographic key and a first ephemeral public cryptographic key of the ID application program (108), • sending the first ephemeral public cryptographic key of the ID application program (108) to the ID token (200), • receiving an ephemeral public cryptographic key of the ID token (200), • generating a first secret shared with the ID token (200) using the decrypted second random value, the first ephemeral private cryptographic key of the ID application program (108) and the ephemeral public cryptographic key of the ID token (200), • generating a first shared authentication key for mutual authentication of the ID application program (108) and the ID token (200) by the second security element (110) using the shared first secret, • generating a first authentication token using the first authentication key and the ephemeral public cryptographic key of the ID token (200) by the second security element (110), • sending the first authentication token to the ID token (200) by the second security element (110), • receiving a second authentication token from the ID token (200) by the second security element (110), • verifying the received second authentication token using the first authentication key and the first ephemeral public cryptographic key of the ID application program (108), and / or wherein establishing the first encrypted subchannel (162) comprises authenticating the personalisation server (220) by the ID token (200) via the mobile terminal (100), wherein authenticating the personalisation server (220) by the ID token (200) in particular comprises: • receiving a second certificate (226) of the personalisation server (220), comprising a second public cryptographic key of a second asymmetric cryptographic key pair of the personalisation server (220), via the encrypted communication channel (160), • verifying a signature of the received second certificate (226) of the personalisation server (220), • generating a third random value by the ID token (200), • sending the third random value as a challenge to the personalisation server (220) via the encrypted communication channel (160), • receiving a first signature of the challenge as a response from the personalisation server (220) via the encrypted communication channel (160), wherein the challenge is signed using a second private cryptographic key of the personalisation server (220), • verifying the received first signature using the second public cryptographic key of the personalisation server (220) and the transmitted third random value, and / or wherein establishing the first encrypted subchannel (162) comprises authenticating the ID token (200) to the personalisation server (220) via the mobile terminal (100), wherein authenticating the ID token (200) to personalisation servers (220) in particular comprises: • sending the public cryptographic key of the ID token (200) from the ID token (200) via the encrypted communication channel (160) to the personalisation server (220), • receiving the second ephemeral public cryptographic key of the personalisation server (220) by the ID token (200) from the personalisation server (220) via the encrypted communication channel (160), • generating a second secret shared with the personalisation server (220) by the ID token (200) using the private cryptographic key of the ID token (200) and the second ephemeral public cryptographic key of the personalisation server (220), • generating a fourth random value by the ID token (200), • generating a second shared authentication key for authenticating data sent over the first encrypted subchannel (162) by the ID token (200), wherein the second shared authentication key is generated using the shared second secret and the fourth random value, • generating a third authentication token by the ID token (200) using the second authentication key and the second ephemeral public cryptographic key of the personalisation server (220) to authenticate the ID token (200) to the personalisation server (220), • sending the fourth random value together with the third authentication token for authenticating the ID token (200) by the ID token (200) via the encrypted communication channel (160) to the personalisation server (220), and / or wherein establishing the second encrypted subchannel (164) comprises authenticating the user by the second security element (110), wherein establishing the second encrypted subchannel (164) further comprises executing a challenge-response procedure between the second security element (110) and the first security element (112), wherein a successful execution of the challenge-response procedure confirms a successful authentication of the user by the second security element (110), and / or wherein establishing the second encrypted subchannel (164) further comprises authenticating the personalisation server (220) by the security applet (114) of the first security element (112), wherein authenticating the personalisation server (220) by the security applet (114) of the first security element (112) in particular comprises: • receiving a third certificate (226) of the personalisation server (220), comprising a third public cryptographic key of the personalisation server (220), by the security applet (114) of the first security element (112) via the encrypted communication channel (160), • verifying a signature of the received third certificate (226) of the personalisation server (220) by the security applet (114) of the first security element (112), • receiving a third ephemeral public cryptographic key of the personalisation server (220) by the security applet (114) of the first security element (112), • generating a fifth random value as a challenge by the security applet (114) of the first security element (112), • sending the fifth random value by the security applet (114) of the first security element (112) via the encrypted communication channel (160) to the personalisation server (220), • receiving a second signature of the challenge as a response from the personalisation server (220), wherein the challenge is signed using a third ephemeral private cryptographic key of the personalisation server (220), • verifying the received second signature using the third public cryptographic key of the personalisation server (220) and the sent fifth random value.

11. The method according to any one of the preceding claims, wherein establishing the second encrypted subchannel (164) further comprises authenticating the security applet (114) of the first security element (112) to the personalisation server (220), wherein authenticating the security applet (114) of the first security element (112) to the personalisation server (220) in particular comprises: • receiving the third ephemeral public cryptographic key of the personalisation server (220) by the security applet (114) of the first security element (112) from the personalisation server (220) via the encrypted communication channel (160), • generating a third secret shared with the personalisation server (220) by the security applet (114) of the first security element (112) using the private cryptographic key of the security applet (114) of the first security element (112) and the ephemeral public cryptographic key of the personalisation server (220), • generating a sixth random value by the security applet (114) of the first security element (112), • generating a third common authentication key for authenticating data sent over the second encrypted subchannel (164), wherein the third common authentication key is generated using the shared third secret and the sixth random value, • generating a fourth authentication token by the security applet (114) of the first security element (112) using the third authentication key and the third ephemeral public cryptographic key of the personalisation server (220) to authenticate the security applet (114) of the first security element (112) to the personalisation server (220), • sending the sixth random value together with the fourth authentication token for authenticating the security applet (114) of the first security element (112) by the security applet (114) of the first security element (112) via the encrypted communication channel (160) to the personalisation server (220), or wherein the third channel-specific ephemeral symmetric cryptographic session key for encrypting the second encrypted subchannel (164) between the security applet (114) of the first security element (112) and the personalisation server (220) is stored in the first security element (112) and in the personalisation server (220) as an initial key for use by the security applet (114), wherein in the first security element (112) for use by the security applet (114) and in the personalisation server (220) in particular there is further stored a channel-specific ephemeral symmetric cryptographic authentication key for authenticating data transmitted via the corresponding second encrypted subchannel (164).

12. The method according to any one of the preceding claims, wherein a second ID token is further used for the personalisation, wherein the personalisation further comprises: • establishing a third encrypted subchannel between the second ID token and the personalisation server (220) within the encrypted communication channel (160) via the mobile terminal (100), wherein the ID application program (108) is used to establish the third encrypted subchannel, • reading out one or more of the second attributes from the second ID token by the personalisation server (220) via the third encrypted subchannel within the encrypted communication channel (160), • establishing a fourth encrypted subchannel between the security applet (114) of the first security element (112) and the personalisation server (220) within the encrypted communication channel (160), wherein the ID application program (108) is used to establish the fourth encrypted subchannel, • receiving the read-out second attributes by the security applet (114) of the first security element (112) from the personalisation server (220) via the fourth encrypted subchannel within the encrypted communication channel (160), • storing the received second attributes by the security applet (114), wherein the ID application program (108) is configured to use the second attributes to prove an identity of the user to another computer system.

13. A mobile terminal (100), wherein the mobile terminal (100) comprises a processor (102) and a memory (104), wherein the memory (104) stores an ID application program (108), wherein the mobile terminal (100) further comprises a security element (112) having a security applet (114) associated with the ID application program (108), wherein the processor (102) is configured to carry out a method for personalising the security applet (114) using an ID token (200) and a personalisation server (220), wherein the mobile terminal (100) further comprises a communication interface (120) for contactless communication with the ID token (200) and for communication via a network (150) with the personalisation server (220), wherein the personalisation comprises: • establishing an encrypted communication channel (160) between the mobile terminal (100) and the personalisation server (220) via a network (150), wherein the ID application program (108) is used to establish the encrypted communication channel (160), • establishing a first encrypted subchannel (162) between the first ID token (200) and the personalisation server (220) within the encrypted communication channel (160) via the mobile terminal (100), wherein the ID application program (108) is used to establish the first encrypted subchannel (162), • reading out one or more of the first attributes (206) from the ID token (200) by the personalisation server (220) via the first encrypted subchannel (162) within the encrypted communication channel (160), • establishing a second encrypted subchannel (164) between the security applet (114) of the security element (112) and the personalisation server (220) within the encrypted communication channel (160), wherein the ID application program (108) is used to establish the second encrypted subchannel (164), • receiving the read-out attributes (206) by the security applet (114) of the security element (112) from the personalisation server (220) via the second encrypted subchannel (164) within the encrypted communication channel (160), • storing the received attributes (206) by the security applet (114), wherein the ID application program (108) is configured to use the attributes (206) to prove an identity of the user to another computer system.

14. A system (170), wherein the system (170) comprises a mobile terminal (100) according to claim 13 and a personalisation server (220), wherein the personalisation server (220) is configured to read out attributes (206) from an ID token (200) via the mobile terminal (100) and to personalise the security applet (114) of the mobile terminal (100).

15. The system (170) according to claim 14, wherein the system (170) further comprises the ID token (200) in which the attributes (206) to be read out are stored.