Method for securely providing a personalized electronic identity on a terminal

Abstract

The invention relates to a method for securely providing a personalized electronic identity on a terminal (2) which can be used by a user (1) for identification purposes when claiming an online service. In the method, an identification application is ran on a terminal (2), which is assigned to a user (1), in a system comprising data processing devices (9; 10; 11; 12) and said terminal (2), and additionally a personalization application and an identity provider application are ran. The method has the following steps in particular; transmitting a request to transmit an identity attribute assigned to the user (1) front the personalization application to the identity provider application; transmitting the identity attribute from the identity provider application to the personalization application after an agreement to transmit the identity attribute by means of the identity provider application is received from the user (1); generating an asymmetric key pair with a public and a private key on the terminal (2) by means of the identification application; transmitting the public-key from tire identification application on the terminal (2) to the personalization application; and generating an electronic certificate for the public-key by means of tire personalization application and storing the electronic certificate in a data storage device in order to form a first public-key infrastructure of the personalization application, additionally having the steps of: generating a hash value for the identity attribute and recording the hash value onto the electronic certificate. The identity attribute is encoded and transmitted together with the electronic certificate from the personalization application to the identification application (14) on the terminal (2), where both are stored in a local storage device of the terminal (2).

Claims

1. Method for securely providing a personalized electronic identity on a terminal which can be used by a user for identification purposes when claiming an online service, wherein in the method in a system comprising data processing devices and a terminal which is assigned to a user, an identification application is executed on the terminal and furthermore a personalization application and an identity provider application are executed and wherein the method here comprises the following: transmitting a request to transmit an identity attribute assigned to the user from the personalization application to the identity provider application; transmitting the identity attribute from the identity provider application to the personalization application after an agreement to transmit the identity attribute by means of the identity provider application was received from the user; generating an asymmetric key pair with a public and a private key on the terminal by means of the identification application in response to the receipt of a request to generate the asymmetric key pair in the terminal from the personalization application; transmitting the public key from the identification application on the terminal to the personalization application; generating an electronic certificate for the public key by means of the personalization application and storing the electronic certificate to form a first public-key infrastructure of the personalization application in a data storage device, further comprising: generating a hash value for the identity attribute and recording the hash value onto the electronic certificate; encrypting the identity attribute with the public key by the personalization application, transmitting the encrypted identity attribute and the electronic certificate from the personalization application to the identification application on the terminal and decrypting the encrypted identity attribute with the private key and storing the decrypted identity attribute and the electronic certificate as personalized electronic identity of the user in a local storage device of the terminal.

2. Method according to claim 1, wherein the asymmetric key pair is generated in the terminal as a device-related asymmetric key pair.

3. Method according to claim 1, wherein the identification application is executed at least partially in a further terminal.

4. Method according to claim 1, wherein: encrypting the electronic certificate with the public key by the personalization application; transmitting the encrypted electronic certificate from the personalization application to the identification application on the terminal and decrypting the encrypted electronic certificate with the private key.

5. Method according to claim 1, wherein report information is generated and transmitted, wherein the following is provided: generating first report data by means of the identification application on the terminal which indicate on the storage of the electronic certificate, the provision of the personalized electronic identity in the terminal; and transmitting the first report data to the personalization application.

6. Method according to claim 1, where the electronic certificate is generated as an electronic certificate according to the X.509 standard.

7. Method according to claim 1, wherein the electronic certificate and the identity attribute is used as personalized electronic identity for an identification of the user with respect to an online service provider, wherein the following is provided here: provision of a service provider application on one of the data processing devices of the system; forming a data communication connection between the identification application on the terminal and the service provider application in response to the receipt of a request to use an online service provided via the service provider application by the service provider application; transmitting the electronic certificate with the included hash value for the identity attribute as well as the identity attribute from the identification application to the service provider application; verifying the electronic certificate for validity by the personalization application after receipt of the electronic certificate from the service provider application; calculating a comparison hash value for the identity attribute obtained from the identification application by the service provider application and comparing the comparison hash value with the hash value for the identity attribute from the electronic certificate and releasing the online service for the user when the electronic certificate is verified as valid and the comparison hash value corresponds to the hash value.

8. Method according to claim 7, characterized in that the data communication connection is configured as a mutually authenticated data communication connection.

9. Method according to claim 1, wherein for the provision and for the configuration of the identification application on the terminal the following is provided: installing the identification application on the terminal; starting the identification application (14) in response to a user start input; forming a secure data communication connection between the identification application on the terminal and the personalization application on a first data processing device; generating a further asymmetric key pair by the identification application in the terminal; transmitting the further public key and a device identifier from the identification application on the terminal to the personalization application and generating a preliminary electronic certificate for the further public key which contains the device identifier by the personalization application in the first data processing device.

Description

DESCRIPTION OF EXEMPLARY EMBODIMENTS

(1) Hereinafter further exemplary embodiments are explained in detail with reference to figures of a drawing. In the figures here:

(2) FIG. 1 shows a schematic diagram of terminals of a user and data processing devices for providing and using an electronic identity;

(3) FIG. 2 shows a schematic diagram for providing a software application for an electronic identity on a terminal;

(4) FIG. 3 shows a schematic diagram for a method for providing the electronic identity on the terminal;

(5) FIG. 4 shows a schematic diagram for identification and/or authentication by means of the electronic identity with respect to an online service;

(6) FIG. 5 shows a schematic diagram for a method for providing the electronic identity on the terminal using two public-key infrastructures;

(7) FIG. 6 shows a schematic diagram for identification and/or authentication by means of the electronic identity with respect to an online service using two public-key infrastructures;

(8) FIG. 7 shows a schematic diagram for a method for providing the electronic identity on the terminal using three public key infrastructures;

(9) FIG. 8 shows a schematic diagram for identification and/or authentication by means of the electronic identity with respect to an online service using three public-key infrastructures.

(10) FIG. 1 shows a schematic diagram of a system with terminals of a user 1 and data processing devices for providing and for using a (personalized) electronic identity which is stored on one of the terminals in a data storage device. The electronic identity is finally personalized, i.e. assigned to the user 1 so that said user can prove his identity herewith for the use of online services.

(11) A terminal 2 of the user 1 has an input device 3, an output device 4, a communication device 5 and a data storage device 6, a computing device 7 with at least one processor and a camera 8a. A further terminal 2a of the user 1 has an input device 3a, an output device 4a, a communication device 5a and a data storage device 6a, a computing device 7a with at least one processor. The terminal 2 can, for example, comprise a mobile terminal. The terminal 2a can, for example, comprise a personal computer.

(12) The terminals 2 or 2a can communicate electronically by means of the respective communication device 5 or 5a with an electronic data processing device 8 of a digital platform, an electronic data processing device 9 of a network-based personalization service and an electronic data processing device 10 of a registration website. The data processing device 9 can be configured as a distributed system. It can also be provided that the electronic data processing device 9 and the electronic data processing device 10 constitute the same electronic data processing device. Furthermore, the terminals 2, 2a can communicate electronically with an electronic data processing device 11 of an identity provider as well as with an electronic data processing device 12 of a further online service which can provide arbitrary online services. The electronic data processing devices 8 to 12 can also communicate electronically with one another.

(13) A plurality of software-implemented applications are implemented on the system comprising the terminal or terminals 2, 2a as well as the data processing devices, in particular a registration application (for example, providing the registration website), a personalization application (in particular providing the service of the personalization service) and an identity provider application (in particular providing the service of the identity provider). The applications are used in the processes and methods described hereinafter.

(14) FIG. 2 shows a schematic diagram for providing an identification application 14, which is subsequently also designated for simplicity as software application 14 for an electronic identity on the terminal 2 of the user 1.

(15) Firstly the software application 14 is to be installed in the data storage device 6 of the terminal 2 from a digital platform. The digital platform can, for example, comprise an App store for software applications which after retrieval and installation can be executed on terminals of the user. For this purpose in a first step 101 by means of the input device 3 of the terminal 2 the software application 14 is requested by the user 1 from a software application 13 of the digital platform, which is stored on the data processing device 8 of the digital platform. The software application 13 can be installed on the terminal 2. Then the installation process of the software application 14 is started on the terminal 2 of the user 1 from the software application 13 (step 102).

(16) After completion of the installation of the software application 14 on the terminal 2 of the user 1 (step 103) the software application 13 informs the user 1 of this (step 104). Subsequently the software application 14 starts for the first time (step 105).

(17) The software application 14 makes a secure connection to the data processing device 9 of the personalization service. In order to form the connection in the data processing device 9 a certificate Cert.sub.Persoservice of the personalization service is compared with a unique identifier (fingerprint) and hereby verified (certificate pinning, step 106). The fingerprint can, for example, comprise a hash function. The fingerprint is stored in the data storage device 6 of the terminal 2, optionally in encrypted form in such a manner that only the software application 14 can access the fingerprint. The secure connection can, for example, be produced by means of the TLS protocol (transport layer security). Alternatively other protocols such as, for example PACE (Password-Authenticated Connection Establishment) or EAC (Extended Access Control) can be used for the secure connection.

(18) The data processing device 9 of the personalization service then requests the software application 14 to generate a device-bound asymmetric first key pair (pk.sub.ID_prov, sk.sub.ID_prov) with a public key pk.sub.ID_prov and a private key sk.sub.ID_prov (step 107).

(19) In the following step 108 the first key pair (pk.sub.ID_prov, sk.sub.ID_prov) is generated by the software application 14. Then the public key pk.sub.ID_prov and a unique device identifier ID.sub.app are sent to the data processing device 9 (step 109). The device identifier ID.sub.app in the sense of the technology described here is unique insofar as it serves as unique (only allocated once) device identifier within the framework of the service provided by the personalization service.

(20) In step 110 the data processing device 9 generates a digital certificate Cert.sub.ID_app_prov based on a public key pk.sub.ID_prov and stores the certificate Cert.sub.ID_app_prov in an internal database. Here in particular this can comprise a certificate in accordance with the X.509-v3 standard. Such a certificate comprises a certificate version, a serial number, an algorithm ID, an issuer designation, validity data, certificate owner designations and key information, additional extensions and attributes as well as certificate signature algorithm and certificate signature. Furthermore, such a certificate can comprise unique identifiers of issuer and owner. The certificate Cert.sub.ID_app_prov in particular contains the device identifier ID.sub.app. Furthermore an encrypted certificate enc(Cert.sub.ID_app_prov, pk.sub.ID_prov) is generated by the data processing device 9 by means of the public key pk.sub.ID_prov. The data processing device 9 then sends the encrypted certificate enc(Cert.sub.ID_app_prov, pk) back to the software application 14 (step 111).

(21) In step 112 the software application 14 decrypts the encrypted certificate enc(Cert.sub.ID, pk.sub.ID_prov) with the private key sk.sub.ID_prov so that the certificate Cert.sub.ID_app_prov is generated and stores the certificate Cert.sub.ID_app_prov, which contains the device identifier ID.sub.app, in the data storage device 6 of the terminal 2. The software application 14 then indicates that the method has been successfully completed (step 113). For this purpose the software application 14 displays the device identifier ID.sub.app on the output device 4 of the terminal 2, for example, a screen. The device identifier ID.sub.app can be used, in particular for providing the electronic identity of the user 1, in particular by means of the method described hereinafter.

(22) FIG. 3 shows a schematic diagram for a method for providing the electronic identity on the terminal 2. By means of the method the electronic identity of the user 1 is registered in the software application 14 already installed on the terminal 2. For this purpose the software application 14 must be provided on the terminal 2.

(23) In a first step 201 a connection to the data processing device 10 is made by the user 1 by means of the input device 3a of the terminal 2a and a website located on the data processing device 10 is called up. The website can be called up, for example, by means of a web browser installed on the terminal 2a. The data processing device 10 then sends to the output device 4a of the terminal 2a a request to the user 1 to open the software application 14 on the terminal 2 (step 202) in order to be able to input the device identifier ID.sub.app on the website by means of the input device 3a of the terminal 2a. Furthermore, in step 202 additional information can be requested which can be added to the personalization of the electronic identity. The additional information can, for example, comprise driving license data, ID card data, student number, photos or signatures. In addition, the user 1 is requested in step 202 to search for an assisted identity provider.

(24) In the following step 203 the software application 14 is opened by the user 1 on the terminal 2 in order to obtain access to the device identifier ID.sub.app. The user 1 reads the device identifier ID.sub.app (step 204) and enters all the information requested by the data processing device 10 in step 202 by means of the input device 3a on the website (step 205). The data processing device 10 now sends the information input by the user and the device identifier ID.sub.app to the data processing device 9 of the personalization service (step 206). The data processing device 9 of the personalization service requests information attributes attr.sub.ID of the user 1 from the data processing device 11 of the identity provider (step 207). Alternatively the feature attr.sub.ID can comprise only a single identity attribute. The data processing device 11 of the identity provider then requests a permission of the user 1 to send the identity attributes attr.sub.ID to the data processing device 9 of the personalization service (step 208). Here the user 1 can for example use his ID card which can be read by means of a reader for the authorization (granting the permission).

(25) When the user 1 has authorized the data processing device 11 of the identity provider to send the identity attributes attr.sub.ID to the data processing device 9 of the personalization service (step 209), the data processing device 11 of the identity provider sends the identity attributes attr.sub.ID to the data processing device 9 of the personalization service (step 210). The data processing device 9 of the personalization service then processes the received identity attributes attr.sub.ID and adds optional further attributes (step 211), for example, from the information which was input by the user 1 in step 205 by means of the input device 3a in the terminal 2a on the website. Furthermore, in step 211 the data processing device 9 of the personalization service generates a 2D barcode which contains a nonce (a character string to be used once) nonce.sub.pers which is encrypted with the public key pk.sub.ID_prov (from the terminal 2, see step 109). The public key is obtained for this purpose from the certificate Cert.sub.ID_app_prov which contains the device identifier IDapp (cf. step 110). By using nonces to be used once, the security from crypto-analytical attacks is increased. The 2D barcode can, for example, comprise a QR code or an Aztec code. Instead of the 2D barcode, another opto-electronically readable code can also be used, for example, a one-dimensional barcode.

(26) The data processing device 9 of the personalization service then sends the 2D barcode to the data processing device 10 with the website (step 212). The website displays the 2D barcode on the output device 4a of the terminal and further requests the user 1 to scan the 2D barcode by means of the software application 14 on the terminal 2 (step 213). For this purpose the software application 14 accesses the camera 8a of the terminal 2. As soon as the user 1 has scanned the 2D barcode (step 214), the software application 14 decrypts the nonce nonce.sub.pers which is contained in the 2D barcode. The decryption is carried out using the private key sk.sub.ID_prov which together with the public key pk.sub.ID_prov forms the first key pair (step 215). The software application 14 then makes a secure mutually authenticated connection to the data processing device 9 (step 216). The connection can be made, for example, by means of TLS, EAC or PACE. To make the connection the software application 14 verifies the certificate Cert.sub.persoservioe of the personalization service with a fingerprint which is stored with the software application 14 in the data storage device 6 of the terminal 2 (certificate pinning). In addition, the data processing device 9 verifies a certificate Cert.sub.ID_app of the software application 14 by means of an internal database. Furthermore the nonce nonce.sub.pers is sent from the software application 14 to the data processing device 9 of the personalization service.

(27) In step 217 it is verified by the data processing device 9 of the personalization service whether the nonce nonce.sub.pers is valid. The data processing device 9 then requests the software application 14 to create a device-bound asymmetric second key pair (pk.sub.ID_app, sk.sub.ID_app) (step 218), whereupon the software application 14 creates the second key pair (pk.sub.ID_app, sk.sub.ID_app) (step 219). The public key pk.sub.ID_app is sent from the software application 14 to the data processing device 9 (step 220).

(28) In step 221 the data processing device 9 creates a certificate Cert.sub.ID_app for the public key pk.sub.ID_app and stores the certificate Cert.sub.ID_app in a public-key infrastructure (PKI) PKI.sub.ident. It can be provided that the PKI is distributed over several data processing devices. A PKI comprises a system for issuing, distributing and verifying digital (electronic) certificates. The method described can be executed with (only) a single PKI. Alternatively the use of further PKIs can be provided (cf. in particular below for FIGS. 5 to 8).

(29) The certificate Cert.sub.ID_app can in particular comprise a certificate according to the X.509v3 standard which provides additional attributes within certificates.

(30) The certificate Cert.sub.ID_app can contain hash values of each of the identity attributes attr.sub.ID of the user 1 which are calculated by means of a hash function from the identity attributes attr.sub.ID. In this way, the electronic identity can be provided using a digital certificate which contains hash values for (additional) attributes (identity attributes).

(31) The certificate Cert.sub.ID_app with the hash values of the identity attributes attr.sub.ID is encrypted by the data processing device 9 by means of the public key pk.sub.ID_app to form an encrypted certificate enc(Cert.sub.ID_app, pk.sub.ID) and the identity attributes attr.sub.ID are encrypted to form encrypted identity attributes enc(attr.sub.ID, pk.sub.ID_app). Alternatively it can be provided not to encrypt the certificate Cert.sub.ID_app.

(32) The encrypted certificate enc(Cert.sub.ID_app, pk.sub.ID_prov) (or alternatively the certificate Cert.sub.ID_app) as well as the encrypted identity attributes enc(attr.sub.ID, pk.sub.ID_app) are sent by the data processing device 9 back to the software application 14 (step 222).

(33) If the certificate Cert.sub.ID_app was encrypted and send encrypted, the software application 14 in step 223 decrypts the encrypted certificate enc(Cert.sub.ID_app, pk.sub.ID_app) with the private key sk.sub.ID_app. The software application 14 stores the certificate obtained Cert.sub.ID_app in the data storage device 6 on the terminal 2. Furthermore the software application 14 decrypts the encrypted identity attributes enc(attr.sub.ID, pk.sub.ID_app) with the private key sk.sub.ID_app and stores the decrypted identity attributes attr.sub.ID with a device-bound symmetrical key key.sub.attr on the data storage device 6 of the terminal 2.

(34) In the following step 224 the software application 14 notifies the personalization service 13 of a successful registration of the electronic identity of the user 1 on the terminal 2. The personalization service 13 notifies the website 20 of the successful registration of the electronic identity of the user 1 on the terminal 2 (step 225). In the final step 226 the data processing device 10 notifies the user 1 via the website of the successful registration of the electronic identity of the user 1 on the terminal 2.

(35) FIG. 4 shows a schematic diagram for the identification and authentication by means of the electronic identity of the user 1, a web browser 15 of the user 1 and the software application 14 with respect to the data processing device 12 of an online service. The web browser 15 and the software application 14 can be located on the same terminal 2. Alternatively the web browser 15 can be located on a further terminal, for example, the terminal 2a.

(36) In step 301 the user 1 clicks in the web browser 15 on a control on the website of the online service. The web browser 15 then sends a login request to the data processing device 12 of the online service via a secure communication channel (step 302). The secure communication channel can, for example, be produced via TLS. The login request contains the session identifier ID.sub.session. The identity of the online service is verified by a Cert.sub.EV_service. This can in particular comprise an extended validation certificate (EV certificate) according to the X.509 standard which was issued by a certification authority (CA).

(37) The data processing device 12 stores the session identifier ID.sub.session and generates an authentication request token token.sub.auth_request (step 303). The authentication request token token.sub.auth_request contains all the information required to execute the authentication with the software application 14. The data processing device 12 sends the authentication request token token.sub.auth_request to the web browser 15 (step 304).

(38) In step 305 when the software application 14 and the web browser 15 are located on the same device, a device-specific custom URL is used to send the authentication request token token.sub.auth_request to the software application 14. The device-specific custom URL can, for example comprise the following: type, method call-up, sequence of attributes, image of the QR code.

(39) If alternatively the software application 14 and the web browser 15 are located on different devices, in step 305 a 2D barcode is displayed in the web browser which contains the authentication request token token.sub.auth_request. The 2D barcode is then to be scanned by the user 1 by means of the software application 14 and the camera 8a. Instead of the 2D barcode, another opto-electronically readable code can also be provided.

(40) After the software application 14 has received the authentication request token token.sub.auth_request, the software application 14 analyzes the authentication request token token.sub.auth_request and extracts from the authentication request token token.sub.auth_request information of the online service (step 306). The software application 14 verifies the EV certificate Cert.sub.EV_service of the online service and then displays the EV certificate Cert.sub.EV_service and/or essential information on the EV certificate Cert.sub.EV_service to the user 1 on the output device 4 of the terminal 2. By means of the extracted information of the online service, the software application 14 constructs a secure, mutually authenticated connection to the data processing device 12 of the online service. The secure mutually authenticated connection can in particular be configured as a mutual TLS authentication connection (mTLS).

(41) Optionally before step 306 is executed, a connection between the software application 14 and the data processing device 12 can be set up by the software application 14 in order to request and validate the EV certificate Cert.sub.EV_service from the data processing device 12. In this optional embodiment step 306 is only executed after the EV certificate Cert.sub.EV_service has been validated.

(42) With the information extracted from the EV certificate Cert.sub.EV_service via the service, the user 1 can accept the authentication request (step 307). The accepting of the authentication request by the user 1 can be accomplished, for example, in the input device 3 by means of biometric authentication (possibly by means of input of a fingerprint of the user 1) or by means of a predefined user PIN. When the user 1 accepts the authentication request, the certificate Cert.sub.ID_app of the software application 14 and the requested identity attributes attr.sub.ID are sent to the data processing device 12 (cf. step 306).

(43) The data processing device 12 then sends a certificate validity request for the certificate Cert.sub.ID_app to the data processing device 9 of the personalization service (step 308). The data processing device 9 checks by means of the PKI PKI.sub.ident (cf. step 221) the validity of the certificate Cert.sub.ID_app and returns the result of the verification of the validity of the certificate Cert.sub.ID_app to the data processing device 12 (step 309).

(44) The data processing device 12 of the online service now checks whether the sent identity attributes attr.sub.ID are valid (step 310). This check is made by calculating hash values from the identity attributes attr.sub.ID by means of a hash function and comparing the calculated hash values with the hash values of the identity attributes attr.sub.ID stored in the certificate Cert.sub.ID_app. In particular, the hash function can comprise the same hash function as in step 221. If the calculated hash values agree with the hash values stored in the certificate Cert.sub.ID_app, a URI (Uniform Resource Identifier) is sent by the data processing device 12 to the software application 14. If the hash values do not agree the process is interrupted.

(45) The explained authentication sequence can be provided for data protection reasons. In this case, the authentication of the data processing device 12 of the online service (here the server) firstly takes place by means of the certificate Cert.sub.EV_service, then the authentication of the software application 14 (here the client) by means of the certificate Cert.sub.ID_app. Thus, in this possible embodiment it can be avoided that personal data such as the hash values of the identity attributes attr.sub.ID in the certificate Cert.sub.ID_app are sent to a non-authorized server. Such a thing does not take place.

(46) If the URI was sent from the data processing device 12 to the software application 14, the software application 14 transfers the URI together with the session identifier ID.sub.session to the web browser 15 (step 311). The web browser 15 then loads the received URI (step 312). Thus, the identification and authentication by means of the electronic identity is completed.

(47) In further exemplary embodiments, instead of one PKI PKI.sub.ident several publicly accessible PKIs can be used. In particular two different PKIs PKI.sub.2,1, PKI.sub.2,2 and three different PKIs PKI.sub.3,1, PKI.sub.3,2, PKI.sub.3,3 can be used. As a result of the distribution of individual steps over different PKIs, data protection can be improved in particular with regard to the potential trackability of the user 1 since only absolutely necessary personal data (personal identifiable information PII) are available when setting up the communication. Furthermore, when using several PKIs, different private keys can be used which can be stored in different key storage devices of the terminal 2. The extraction of several private keys when using several PKIs means a potentially higher effort for an attacker and therefore results in increased security.

(48) The steps for providing the electronic identity and for identification and authentication by means of the electronic identity which differ from the method with the only one PKI PKI.sub.ident are set out in detail hereinafter: steps relating to the method with the two PKIs PKIs PKI.sub.2,1, PKI.sub.2,2 are here characterized by the suffix “A”. Steps relating to the method with the three PKIs PKI.sub.3,1, PKI.sub.3,2, PKI.sub.3,3 are characterized by the suffix “B”. The PKIs can be stored on the data processing device 9.

(49) The steps 101 to 113 for providing the software application 14 for an electronic identity on the terminal 2 as well as the steps 201 to 220 for providing the electronic identity on the terminal 2 are carried out with several PKIs as for a single PKI.

(50) The previously described method uses (only) one PKI (Public-Key Infrastructure). Hereinafter exemplary embodiments are explained with reference to FIGS. 5 to 8 in which several PKIs are used, in particular two, as well as the PKI, i.e. one or two additional PKIs.

(51) FIG. 5 shows a schematic diagram for a method for providing the electronic identity on the terminal 2 using two PKIs PKI.sup.2,1, PKI.sub.2,2. Hereinafter the steps 221A to 223A modified with regard to the two PKIs PKI.sub.2,1, PKI.sub.2,2 for providing the electronic identity are explained. The remaining steps 201 to 220 as well as 224 to 226 for providing the electronic identity on the terminal 2 are carried out as when using a single PKI.

(52) In step 221A the data processing device 9 of a network-based personalization service generates a certificate Cert.sub.ID_app for the public key pk.sub.ID_app and stores the certificate Cert.sub.ID_app in the PKI PKI.sub.2,1.

(53) Furthermore, the data processing device 9 generates a logical data structure LDS.sub.2 comprising hash values of each of the identity attributes attr.sub.ID, the certificate Cert.sub.ID_app as well as digital signatures of the hash values of the identity attributes and the certificate Cert.sub.ID_app by means of a private key sk.sub.Perso_Ident. A public key pk.sub.Perso_Ident corresponding to the private key sk.sub.Perso_Ident is part of the certificate Cert.sub.Perso_Ident of the personalization service and is published in the PKI PKI.sub.2,2. Furthermore a digital signature of the logical data structure LDS.sub.2 is generated by means of the private key sk.sub.Perso_Ident.

(54) The logical data structure LDS.sub.2, the certificates Cert.sub.ID_app and Cert.sub.perso_Ident as well as the identity attributes attr.sub.ID are then encrypted by the data processing device 9 in each case by means of the public key pk.sub.ID_app to form an encrypted data structure enc(LDS.sub.2, pk.sub.ID_app), encrypted certificates enc(Cert.sub.ID_app, pk.sub.ID_app) and enc(Cert.sub.Perso_Ident, pk.sub.ID_app) as well as encrypted identity attributes enc(attr.sub.ID, pk.sub.ID_app).

(55) In step 222A the encrypted data structure enc(LDS.sub.2, pk.sub.ID_app), the encrypted certificates enc(Cert.sub.ID_app, pk.sub.ID_app) and enc(Cert.sub.Perso_Ident, pk.sub.ID_app) as well as the encrypted identity attributes enc(attr.sub.ID, pk.sub.ID_app) are transmitted from the data processing device 9 back to the software application 14.

(56) In step 223A the encrypted data structure enc(LDS.sub.2, pk.sub.ID_app), as well as the encrypted certificates enc(Cert.sub.ID_app, pk.sub.ID_app) and enc(Cert.sub.Perso_Ident, pk.sub.ID_app) are decrypted by the software application 14 with the private key sk.sub.Ip_app and stored in the data storage device 6 on the terminal 2. Furthermore, the software application 14 decrypts the encrypted identity attributes enc(attr.sub.ID, pk.sub.ID_app) with the private key sk.sub.ID_app and stores the decrypted identity attributes attr.sub.ID with a device-bound symmetrical key key.sub.attr on the data storage device 6 of the terminal 2.

(57) The remaining steps 224 to 226 for providing the electronic identity on the terminal 2 are carried out as with a single PKI. FIG. 6 shows a schematic diagram for identification and/or authentication by means of the electronic identity with respect to an online service using the two PKIs PKI.sub.2,1, PKI.sub.2,2. Hereinafter the steps 306A to 310A modified with respect to the two PKIs PKI.sub.2,1, PKI.sub.2,2 for identification and authentication by means of the electronic identity are explained. The remaining steps 301 to 305 as well as 311 and 312 for providing the electronic identity on the terminal 2 are carried out as with a single PKI.

(58) In step 306A the software application 14 analyzes the authentication request token token.sub.auth_request and extracts information of the online service from the authentication request token token.sub.auth_request. By means of the extracted information of the online service, the software application 14 builds up a secure mutually authenticated connection to the data processing device 12 of the online service. At this point in particular the standard protocol sequence for the TLS with a client authentication before a server authentication can be used since the certificate Cert.sub.ID_app does not contain any personal data and the hash values of the identity attributes attr.sub.ID are only found in the logical data structure LDS.sub.2. Thus, the identity attributes attr.sub.ID cannot reach a non-authenticated server.

(59) In step 307A the user 1 can accept the authentication request with the information extracted from the EV certificate Cert.sub.EV_service via the service. The accepting of the authentication request by the user 1 can be accomplished, for example, in the input device 3 by means of biometric authentication (possibly by means of input of a fingerprint of the user 1) or by means of a predefined user PIN. When the user 1 accepts the authentication request, the logical data structure LDS.sub.2 and the requested identity attributes attr.sub.ID are sent to the data processing device 12.

(60) In step 308A the data processing device 12 sends a certificate validity request for the certificate Cert.sub.ID_app to the PKI PKI.sub.2,1 and a further certificate validity request for the certificate Cert.sub.Perso_Ident to the PKI PKI.sub.2,2.

(61) In step 309A the data processing device 9 checks by means of the PKI PKI.sub.2,1 the validity of the certificate Cert.sub.ID_app and by means of PKI2,2 the validity of the certificate Cert.sub.Perso_Ident and returns the results of the verification of the respective validity of the certificates Cert.sub.ID_app and Cert.sub.Perso_Ident to the data processing device 12.

(62) In step 310A the data processing device 12 of the online service checks whether the sent identity attributes attr.sub.ID are valid. This check is made by calculating hash values from the identity attributes attr.sub.ID by means of a hash function and comparing the calculated hash values with the hash values of the identity attributes attr.sub.ID stored in the logical data structure LDS.sub.2. Furthermore the data processing device 12 verifies the signature of the logical data structure LDS.sub.2 and checks whether the certificate Cert.sub.ID_app is contained in the logical data structure LDS.sub.2.

(63) If the calculated hash values agree with the hash values stored in the logical data structure LDS.sub.2, the signature of the logical data structure LDS.sub.2 is verified, the certificate Cert.sub.ID_app is contained in the logical data structure LDS.sub.2 and the certificate Cert.sub.ID_app was validated, a URI is sent by the data processing device 12 to the software application 14. Otherwise, the process is interrupted.

(64) The remaining steps 311 and 312 are carried out as with a single PKI.

(65) FIG. 7 shows a schematic diagram for a method for providing the electronic identity on the terminal 2 using the three PKIs PKI.sub.3,1, PKI.sub.3,2, PKI.sub.3,3. Hereinafter the steps 221B to 223B modified with respect to the three PKIs PKI.sub.3,1, PKI.sub.3,2, PKI.sub.3,3 for providing the electronic identity are explained. The remaining steps 201 to 220 as well as 224 to 226 for providing the electronic identity on the terminal 2 are carried out as when using a single PKI.

(66) In step 221B the data processing device 9 selects a key pair from private key sk.sub.ID_TLS_client and public key pk.sub.ID_TLS_client. For the public key pk.sub.ID_TLS_client the data processing device 9 generates a certificate Cert.sub.ID_TLS_client and stores the certificate Cert.sub.ID_TLS_client in the PKI PKI3,1. The PKI PKI3,1 in this case does not contain the public key pk.sub.ID_app. Furthermore the data processing device 9 generates a certificate Cert.sub.ID_app for the public key pkt.sub.ID_app and stores the certificate Cert.sub.ID_app in the PKI PKI.sub.3,2.

(67) In addition the data processing device 9 generates a logical data structure LDS.sub.3 comprising hash values of each of the identity attributes attr.sub.ID, the certificate Cert.sub.ID_app, the certificate Cert.sub.ID_TLS_client as well as digital signatures of the hash values of the identity attributes attr.sub.ID, of the certificate Cert.sub.ID_app and the certificate Cert.sub.ID_TLS_client by means of a private key sk.sub.perso_Ident. A public key pk.sub.ID_TLS_client corresponding to the private key sk.sub.perso_Ident is part of a certificate Cert.sub.Perso_Ident of the personal service and is published in the PKI PKI.sub.3,3. Furthermore, a digital signature of the logical data structure LDS.sub.3 is generated by means of the private key sk.sub.perso_Ident.

(68) The logical data structure LDS.sub.3, the certificates Cert.sub.ID_app, Cert.sub.ID_TLS_client and Cert.sub.Perso_Ident, the private key sk.sub.ID_TLS_client as well as the identity attributes attr.sub.ID are then encrypted by the data processing device 9 in each case by means of the public key pk.sub.ID_app to form an encrypted data structure enc(LDS.sub.3, pk.sub.ID_app), encrypted certificates enc(Cert.sub.ID_app, pk.sub.ID_app), enc(Cert.sub.ID_TLS_client, pk.sub.ID_app) and enc(Cert.sub.Perso_Ident, pk.sub.ID_app), an encrypted private key enc(pk.sub.ID_TLS_client, Pk.sub.ID_app) as well as encrypted identity attributes enc(attr.sub.ID, pk.sub.ID_app).

(69) In step 222B the encrypted data structure enc(LDS.sub.3, pk.sub.ID_app), encrypted certificates enc(Cert.sub.ID_app, pk.sub.ID_app), enc(Cert.sub.ID_TLS_client, Pk.sub.ID_app) and enc(Cert.sub.Perso_Ident, pk.sub.ID_app), the encrypted private key enc(pk.sub.ID_TLS_client, pk.sub.ID_app) as well as the encrypted identity attributes enc(attr.sub.ID, pk.sub.ID_app) are sent by the data processing device 9 back to the software application 14.

(70) In step 223B the encrypted data structure enc(LDS.sub.3, pk.sub.ID_app), the encrypted certificates enc(Cert.sub.ID_app, pk.sub.ID_app), enc(Cert.sub.ID_TLS_client, pk.sub.ID_app) and enc(Cert.sub.Perso_Ident, Pk.sub.ID_app) are decrypted by the software application with the private key sk.sub.ID_app and stored in the data storage device 6 on the terminal 2. Furthermore the software application 14 decrypts the encrypted identity attributes enc(attr.sub.ID, pk.sub.ID_app) as well as the encrypted private key enc(pk.sub.ID_TLS_client, pk.sub.ID_app) with the private key sk.sub.ID_app and stores the identity attributes attr.sub.ID and the private key sk.sub.ID_TLS_client encrypted with a device-bound symmetrical key.sub.attr on the data storage device 6 of the terminal 2.

(71) The remaining steps 224 to 226 for providing the electronic identity on the terminal 2 are carried out as with a single PKI.

(72) FIG. 8 shows a schematic diagram for identification and/or authentication by means of the electronic identity with respect to an online service using the three PKIs PKI.sub.3,1, PKI.sub.3,2, PKI.sub.3,3. Hereinafter the steps 301B to 312B modified with respect to the three PKIs PKI.sub.3,1, PKI.sub.3,2, PKI.sub.3,3 for identification and authentication by means of the electronic identity are explained.

(73) In step 301B the user 1 clicks in an own web browser 15B (in-app browser) of the software application 14 on a control on the website of the online service. The web browser 15B then sends a login request to the data processing device 12 of the online service via a communication channel which has been mutually authenticated and secured with TLS and the certificate Cert.sub.ID_TLS_client (step 302B). The mutual authentication of the secure communication channel is a particular feature of the use of three PKIs. The login request contains a session identifier ID.sub.session. The identity of the online service is verified by an EV certificate Cert.sub.EV_service.

(74) The steps 303B to 305B take place similarly to the steps 303 to 305 but using the web browser 15B of the software application 14 instead of the web browser 15.

(75) In step 306B the software application 14 analyzes the authentication request token token.sub.auth_request and extracts from the authentication request token token.sub.auth_request information of the online service. By means of the extracted information of the online service, the software application 14 constructs a secure, mutually authenticated connection to the data processing device 12 of the online service. At this point in particular the standard protocol sequence for TLS with a client authentication can be used before a server authentication since the certificate Cert.sub.ID_app contains no personal data and the hash values of the identity attributes attr.sub.ID are only found in the logical data structure LDS.sub.2. Thus the identity attributes attr.sub.ID cannot reach a non-authenticated server.

(76) In step 307B with the information extracted from the EV certificate Cert.sub.EV_service via the service, the user 1 can accept the authentication request. The accepting of the authentication request by the user 1 can be accomplished, for example, in the input device 3 by means of biometric authentication (possibly by means of input of a fingerprint of the user 1) or by means of a predefined user PIN. When the user 1 accepts the authentication request, the logical data structure LDS.sub.3 and the requested identity attributes attr.sub.ID are sent to the data processing device 12.

(77) In step 308B the data processing device 12 of the online service then sends a certificate validity request for the certificate Cert.sub.ID_app to the PKI PKI.sub.3,1 of the personalization service, a certificate validity request for the certificate Cert.sub.Perso_ident to the PKI PKI.sub.3,2 and a certificate validity request for the certificate Cert.sub.ID_TLS_client to the PKI PKI.sub.3,3.

(78) In step 309B the data processing device 9 checks by means of the PKIs PKI.sub.3,1, PKI.sub.3,2 and/or PKI.sub.3,3 the validity of the certificates Cert.sub.ID_app, Cert.sub.Perso_ident and/or Cert.sub.ID_TLS_client and returns results of the verification of the respective validity of the certificates Cert.sub.ID_app, Cert.sub.Perso_ident and Cert.sub.ID_TTS_client to the data processing device 12.

(79) In step 310B the data processing device 12 of the online service checks whether the sent identity attributes attr.sub.ID are valid. This check is made by calculating hash values from the identity attributes attr.sub.ID by means of a hash function and comparing the calculated hash values with the hash values of the identity attributes attr.sub.ID stored in the logical data structure LDS.sub.3. Furthermore the data processing device 12 verifies the signature of the logical data structure LDS.sub.3 and checks whether the certificates Cert.sub.ID_app and Cert.sub.ID_TLS_client are contained in the logical data structure LDS.sub.3.

(80) If the calculated hash values agree with the hash values stored in the logical data structure LDS.sub.3, the signature of the logical data structure LDS.sub.3 is verified, the certificates Cert.sub.ID_app and Cert.sub.ID_TLS_client are contained in the logical data structure LDS.sub.3 and the certificates Cert.sub.ID_app and Cert.sub.ID_TLS_client have been validated, a URI is sent by the data processing device 12 to the software application 14. Otherwise the process is interrupted.

(81) If the URI was sent from the data processing device 12 to the software application 14, the software application 14 transfers the URI together with the session identifier ID.sub.session to the web browser 15B (step 311B). The web browser 15 then loads the received URI (step 312B). Thus, the identification and authentication by means of the electronic identity using three PKIs PKI.sub.3,1, PKI.sub.3,2, PKI.sub.3,3 is completed.

(82) The features disclosed in the preceding description, the claims and the drawing can be important both individually and also in any combination for the implementation of the various embodiments.