DE102013022443B4 - Electronic transaction procedure and computer system - Google Patents

Abstract

Electronic transaction method using an ID token (106) that is assigned to a user (102), wherein the ID token has an electronic memory (118) with a protected memory area (124) in which one or more attributes are stored, wherein access to the protected memory area is only possible via a processor (128) of the ID token, and wherein the ID token has a communication interface (108) for communication with a reader of a user computer system (100), with the following steps:- display of an optically readable pattern on a screen (188) of a terminal (186), wherein information is encoded in the optically readable pattern that contains at least one logical address of a service computer system (150) and transaction data,- detection of the pattern using an optical sensor (190) of the user computer system and decoding of the pattern by the user computer system,- transmission of a transaction request (158) from the user computer system to the logical address of the Service computer system via the network, wherein the transaction request contains the transaction data,- transmission of a request (166) from the service computer system via the user computer system (100) to an ID provider computer system (136), wherein the transmission takes place via the network, wherein the request contains an attribute specification of the attributes to be read from the ID token for the execution of the transaction,- authentication of the user to the ID token,- authentication of the ID provider computer system to the ID token via the network,- provided that the user and the ID provider computer system are successfully authenticated to the ID token, reading the attribute(s) according to the attribute specification by the ID provider computer system from the ID token via the network with end-to-end encryption,- transmission of a response (174) from the ID provider computer system via the user computer system to the service computer system, wherein the transmission of the response takes place via the network, wherein the response contains the attribute(s) read out, and wherein the response is signed by the ID provider computer system, execution of the transaction using the transaction data and the attribute(s) by the service computer system, wherein a confirmation signal for the execution of the transaction is sent from the service computer system via the network to the user computer system and output by the user computer system as an optical pattern, wherein the terminal is designed to capture the optical pattern from the user computer system.

Description

The present patent application is a divisional application of the parent application 10 2013 212 646.8 .

Description

The invention relates to an electronic transaction method and a computer system.

Various transaction methods are known for electronic commerce, i.e. so-called eCommerce. These include common payment methods such as paper-based transfers or cash on delivery, as well as electronic payment methods such as credit card payments, payments via online banking, debt collection/billing systems, factory systems, electronic direct debits, prepaid methods, payment by telephone bill and mobile phone payment systems. Such payment methods are also sometimes used for eGovernment applications.

The invention is therefore based on the object of creating an improved electronic transaction method and a corresponding computer system.

The object underlying the invention is achieved with the features of the independent patent claims. Embodiments of the invention are specified in the dependent patent claims.

Known from the state of the art are an information processing device with an optical data reader, server, and a method for electronic commerce ( US 2003/0120555 A1 ), a technical guideline on a server to simplify electronic proof of identity in web applications (BSI TR-03130, Technical Guideline eID Server, Federal Office for Information Security, Ver. 1.6, 20.04.2012) and a technical guideline on an API framework to provide an interface that enables standardized use of chip cards (Technical Guideline TR-03112-7 eCard-API-Framework - Protocols, Federal Office for Information Security, Ver. 1.1.2, 28.02.2012).

The technical guideline TR-03110, Ver. 2.05, of the Federal Office for Information Security describes extended security mechanisms for machine-readable travel documents.

A “transaction” is understood here to mean a financial transaction, such as the payment of an amount by making a transfer, a direct debit or a credit card charge, an order process for ordering and delivering a physical good or data as well as other logistical, commercial and/or financial transactions and/or a database transaction, e.g. for storing a value, such as a consumption value, a credit or a payment amount.

A "terminal" is understood here to mean a device that has a display, i.e. a screen, for displaying an optical pattern. The terminal can simply capture information and output it via the display or it can have a user interface for entering a user's selection.

For example, the terminal can be designed as an ATM or vending machine. The user can enter a request into the terminal, such as to withdraw cash, top up a debit card or buy a specific product, such as a drink. In response to this user request, the machine displays an optically detectable pattern, such as a QR code, on its screen, with the pattern containing information to initiate the transaction. This can be the desired withdrawal amount or the purchase price of the product.

According to a further embodiment of the invention, the terminal is designed as a telecommunications device, as a so-called smart meter, for the collection of fees, e.g. for electricity or gas consumption, taximeter or smartphone with a fee collection function.

A "pattern" is understood here to be a static optical pattern that is displayed on the terminal's display and in which information is encoded, for example a barcode, in particular a one-dimensional, two-dimensional, high capacity color barcode, MaxiCode, QR code or DataMatrix code, or a chronological sequence of several patterns, whereby information is encoded by the patterns and their chronological sequence, as is the case with a flicker code, for example. The "flicker code" is known for the so-called chipTAN-comfort or Smart-TAN-optic online banking process of the savings banks and cooperative banks.

A “session” is understood here as a temporary communication connection, i.e. a so-called communication session, which according to the OSI layer model can refer to the transport layer or the application layer. In particular, a session can be an http session or an https session, where the transport layer is protected by symmetric encryption.

An "ID token" is understood here in particular to mean a portable electronic device which has at least one data memory for storing the at least one attribute and a communication interface for reading the attribute. The ID token preferably has a secure memory area for storing the at least one attribute in order to prevent the attribute stored in the memory area from being changed in an unauthorized manner or read without the necessary authorization.

In particular, the ID token can be a USB stick or a document, in particular a valuable or security document. According to the invention, a "document" is understood to mean paper-based and/or plastic-based documents, in particular electronic sovereign documents, such as electronic identification documents, in particular passports, identity cards, visas and driving licenses, vehicle registration documents, vehicle registration documents, company IDs, health cards or other ID documents as well as chip cards, means of payment, in particular banknotes, bank cards and credit cards, waybills or other proof of authorization, such as an admission ticket, in which a data storage device for storing the at least one attribute is integrated.

The ID token can be a hardware token or a soft token if it is cryptographically bound to a hardware token, for example to a so-called secure element.

In particular, such a soft token cryptographically bound to a secure element can be EN 10 2011 082 101 be generated.

An "ID provider computer system" is understood here to mean a computer system that is designed to read at least one attribute from a user's ID token. The ID provider computer system is preferably operated in a so-called trust center in order to create the highest possible level of security.

A "service computer system" is understood here to mean a computer system that has a network interface for connection to the network so that Internet pages stored or generated by the service computer system can be accessed using an Internet browser or another application program. In particular, the service computer system can be an Internet server for providing an eCommerce or eGovernment application, in particular an online shop or a government server.

A "user computer system" is understood here to be a computer system to which the user has access. This can be, for example, a personal computer (PC), a tablet PC or a mobile device, in particular a smartphone, with a standard Internet browser such as Microsoft ^® Internet Explorer ^® , Safari ^® , Google Chrome™, Firefox ^® or another application program for accessing the service computer system. The user computer system has an interface for connecting to the network, whereby the network can be a private or public network, in particular the Internet.

According to one embodiment of the invention, the request of the service computer system is a SAML request and the response of the ID provider computer system is a SAML response (cf. Security Assertion Markup Language (SAML) V2.0 Technical Overview, OASIS, Committee Draft 02, March 25, 2008).

According to one embodiment of the invention, the ID provider computer system has a certificate in which the read rights for performing the read access are specified.

A "certificate" is understood here to mean a digital certificate, which is also referred to as a public key certificate. A certificate is structured data that is used to assign a public key of an asymmetric cryptosystem to an identity, such as a person or a device. For example, the certificate can correspond to the X.509 standard or another standard. The certificate is preferably a Card Verifiable Certificate (CVC).

The certificate can specify which attribute or attributes of the user, which are stored in the protected memory area of the ID token, the ID provider computer system is authorized to perform read access to. These attributes can be personal attributes of the user, such as their name, place of residence and age. These attributes can be used in combination as user identification to access the payment information of the registered user. Alternatively or additionally, a pseudonym of the user, which is at least temporarily stored by the ID token, can also be used as user identification.

Embodiments of the invention are particularly advantageous because a computer-implemented payment method is created that is universal and also suitable for eCommerce and eGovernment applications, which is simultaneously flexible, convenient to use and secure. This is made possible in particular by the fact that the payment method is based on an ID token, whereby the prerequisite for carrying out a payment process is both the authentication of the user to the ID token and the authentication of the ID provider computer system to the ID token.

According to embodiments of the invention, the terminal is a device, for example for paying out cash, for topping up a cash card for the sale of a product, such as a travel ticket, an admission ticket or a food or beverage item.

For example, the terminal can be an ATM. In this case, the user enters a desired withdrawal amount via a user interface of the ATM. This withdrawal amount is then displayed as an optically readable pattern by the ATM on its screen and this pattern is detected by the user using an optical sensor, such as the camera of the user's computer system, which can be designed as a smartphone. The pattern displayed on the screen can also contain a logical address of the service computer system, such as a URL of the service computer system. In addition, the pattern can contain further information, such as account information of the ATM operator.

The user computer system decodes the pattern captured from the terminal screen using the optical sensor and then generates a transaction request specifying the withdrawal amount and any other transaction data included in the pattern. This transaction request is then transmitted from the user computer system to the service computer system over the network.

The service computer system then generates a request that contains an attribute specification, i.e. an indication of at least one attribute to be read from the ID token, which is required to carry out the transaction and/or which must meet a predefined test criterion so that the transaction can be carried out. For example, the attribute can be a user account connection stored in the ID token or a user pseudonym, which serves as an access key for the service computer system to pseudonymized account information of registered users stored in a database. Alternatively or additionally, the attribute can be an age specification in order to check whether the user has the legal capacity required to carry out the transaction.

The service computer system then sends the request to the ID provider computer system. After the user has been authenticated with his ID token and after the ID provider computer system has been authenticated with the ID token over the network, the ID provider computer system then reads at least one attribute from the ID token over the network using end-to-end encryption.

The ID provider computer system then generates a response that contains at least one attribute read from the ID token. The attributes and/or the response are signed by the ID provider computer system and sent to the service computer system.

The service computer system then uses the attributes to carry out the transaction, for example, to debit the user's account with the withdrawal amount, and/or to check whether a predetermined criterion, e.g. legal capacity, is met.

After the account has been debited, the service computer system generates a confirmation signal, which is transmitted to the bank terminal, for example. For example, the terminal, i.e. the ATM in this case, is connected to the network so that the confirmation signal is transmitted from the service computer system to the terminal via the network. The confirmation signal is preferably signed by the service computer system to prevent manipulation. Upon receipt of a valid confirmation signal, cash is then dispensed in the amount of the desired withdrawal amount or, alternatively, the user's debit card is topped up.

According to one embodiment of the invention, the terminal is designed as a vending machine. The user can select a desired product via a user interface of the vending machine. The vending machine then shows an optical pattern on its display in which the purchase price of the product selected by the user is encoded as well as account information for the account to which the payment of this purchase price is to be made. The optical pattern also contains Pattern the specification of a logical address, in particular a URL, of the service computer system.

The user captures this optical pattern with an optical sensor on his user computer system, for example using the camera on his smartphone. The optical pattern is then decoded and a transaction request is generated that contains the purchase price and the account information of the payee. This transaction request is transmitted from the user computer system to the service computer system using the logical address of the service computer system.

The service computer system then generates a request with the attribute specification of the attributes required for dispensing the product selected by the user. For example, it is a product that is only to be sold to adults, such as alcohol or cigarettes. In this case, the attribute specification includes the attribute "age". Based on this request, the service computer system receives a response from the ID provider computer system that includes this age information. The service computer system then checks whether the age information meets a predetermined criterion, such as being of legal age, and if this is the case, the service computer system carries out the transaction, for example by transferring the purchase price from the user's account to the payment recipient's account. The service computer system then sends a confirmation signal, for example to the vending machine, whereupon the vending machine then dispenses the product previously selected by the user.

According to a further embodiment of the invention, the terminal is designed as a consumption meter, in particular for recording electricity or gas consumption. In this case, an optical pattern is shown on the display of the terminal, which contains the current meter reading and, for example, a meter number of the consumption meter as well as the logical address of the service computer system. The corresponding transaction request then contains this meter reading and the meter number. The attribute specification of the service computer system can, for example, specify personal information of the user and/or a pseudonym or an identifier of the user, such as their customer number.

By receiving the response from the ID provider computer system, the service computer system can determine which user recorded the optical pattern from the terminal. Assuming that this user is the payer who is registered as a customer with the service computer system, the service computer system stores the meter reading reported with the transaction request and the associated meter number in a database using a database transaction. At a later point in time, the service computer system can then generate a corresponding invoice to settle the recorded consumption.

According to one embodiment of the invention, the service computer system generates a confirmation signal after the database transaction has been executed, wherein this confirmation signal is sent, for example, to the consumption counter. The consumption counter can then be reset.

According to one embodiment of the invention, the terminal is a smartphone belonging to a third party who wants to sell a product to the user. For this purpose, the smartphone has an app that the third party starts. The third party enters the purchase price and, for example, their bank details into the app. This information, as well as the logical address of the service computer system, is then displayed on the smartphone's display as an optical pattern.

The corresponding transaction request then contains the purchase price and the third party's account details. In this case, the attribute specification can, for example, relate to the user's personal information, with which the service computer system can access the user's previously registered account details. After receiving the response, the service computer system then carries out the transaction, i.e. the payment of the purchase price, using the account information of the third party and the user. The service computer system then sends a confirmation signal, for example to the third party's smartphone, so that the third party is informed of the payment and hands over the product to the user.

Instead of a smartphone, this can also be implemented in another mobile electronic device, such as a laptop or notebook computer, or in a stationary electronic system, such as the electronic cash register system of a supermarket.

In another application, the terminal is designed as a taximeter. In this case, the optical pattern contains a fare that a taxi driver charges for a taxi ride. After receiving the confirmation signal, for example from the service computer system, which confirms the execution of the corresponding payment, , the taximeter issues a corresponding receipt, i.e. a receipt.

It is particularly advantageous if the terminal has a network interface for communication via the network. In this case, the confirmation signal can be transmitted from the service computer system to the machine via the network. According to the invention, however, the confirmation signal is sent from the service computer system to the user computer system. The user computer system can then show an optical pattern on a display of the user computer system in which this confirmation is encoded. This optical pattern can then be detected by the terminal, which also has an optical sensor. This embodiment has the advantage that the terminal does not need to be connected to the network, which has security advantages.

According to a further embodiment of the invention, the service computer system is connected to, for example, the terminal via a communication channel different from the network, such as an internal company network or a virtual private network, via which the confirmation signal is transmitted from the service computer system, for example, to the terminal.

According to embodiments of the invention, a first session is first established between the Internet browser of the user computer system and the service computer system via the Internet, whereby the first session can be an http session or an https session. The user can enter a transaction request into the Internet browser, for example to initiate a payment process. For example, the user has previously ordered a product via the service computer system and would like to pay for the ordered product, for which the user enters the corresponding transaction request into the Internet browser, which is transmitted to the service computer system via the first session.

The service computer system then generates a request, i.e. a request of a request-response protocol. The request can have a predefined or standardized structure. For example, the request can be text-based, have an XML, ASN.1 or binary structure or be designed as a SAML request. The request, for example the SAML request, contains an attribute specification that specifies the attributes to be read from the ID token to carry out the transaction. These can be attributes that identify the user assigned to the ID token and/or that provide payment information, such as bank account details or credit card information, and/or attributes that relate to the ID token itself, such as its period of validity, date of issue and/or the issuing organization or authority.

According to embodiments of the invention, the request is transmitted from the service computer system via the user computer system to the ID provider computer system. Upon receipt of the request by the user computer system, the further process for generating the response, including the authentication of the user and the ID provider computer system, is triggered.

In particular, the attribute specification can include the user's date of birth if, for example, the user's age of majority is to be checked by the service computer system as a prerequisite for carrying out the transaction. The request also includes transaction data for specifying the transaction, for example a payment amount and account information, in particular the account details of the service computer system to which the payment is to be made. The request also includes a Uniform Resource Locator (URL) of the ID provider computer system, which is to read the attributes from the ID token, as well as a URL of the service computer system to specify a recipient for the response that is to be generated by the ID provider computer system based on the request.

The service computer system generates an identifier for the request that uniquely identifies the request, such as a globally unique identifier (GUID). The request contains this identifier.

The request is signed by the service computer system using a private key of a cryptographic key pair associated with the service computer system.

Based on the transaction request, a web page is transmitted from the service computer system to the user computer system via the first session and displayed by the Internet browser or the application program, in particular a so-called app. The request is transmitted together with the web page, but is not displayed.

The website has at least one input field for entering additional information required to complete the transaction. This additional information may, for example, be a user's bank account or credit card information and/or a Authentication information to authenticate the user to the service computer system. For example, the authentication information can be a one-time password (OTP). Preferably, the additional information is encrypted by the user computer system using the public key of the service computer system, so that only the encrypted additional information is then forwarded from the Internet browser or the application program to the ID provider computer system via the network via a second session.

The request is also forwarded via this second session. The second session is established by calling the URL of the ID provider computer system, which is included in the request. The second session is established as a protected communication connection, namely with an encrypted transport layer, i.e. with Transport Layer Security (TLS), which is also known as Secure Sockets Layer (SSL), in particular as an https session.

According to embodiments of the invention, the ID provider computer system generates an identifier for a third session that is yet to be established, i.e. a so-called session ID, based on the receipt of the request via the second session. The ID provider computer system stores the request and the additional information received together with the request via the second session with the session ID for the third session.

The ID provider computer system then sends a message via the second session, which contains a logical address of the ID provider computer system and, for example, the session ID of the third session. The Internet browser or application program can use this logical address to retrieve the response to the previously forwarded request at a later point in time. The logical address can be a uniform resource locator (URL) through which the response can be retrieved.

The third session is then established on the application layer between a program on the user's computer system and the ID provider's computer system, via the secure transport layer of the second session. The program can be, for example, a browser plug-in for the Internet browser or an application program other than the Internet browser.

The ID provider computer system then transmits the information about the third session to the program that is required to read the attribute(s) from the ID token. This information includes at least one certificate from the ID provider computer system, which contains an indication of the ID provider computer system's read rights to read one or more attributes.

1. a) Es wird eine lokale Verbindung zwischen dem Lesegerät des Nutzer-Computersystems und dem ID-Token aufgebaut. Bei einem ID-Token mit einer kontaktbehafteten Schnittstelle, beispielsweise einer Chipkarten-Schnittstelle, kann dies durch Einführen des ID-Tokens in das Lesegerät erfolgen. Bei einem ID-Token mit einer kontaktlosen Schnittstelle, wie zum Beispiel einer RFID oder einen NFC-Schnittstelle, kann dies dadurch erfolgen, dass der ID-Token auf das Lesegerät gelegt wird. Hier sind auch Token mit USB, BlueTooth oder microSD-Karten möglich sowie auch virtuelle SmartCards.
2. b) Der Nutzer authentifiziert sich gegenüber dem ID-Token, beispielsweise durch Eingabe seiner Personal Identification Number (PIN) oder durch Eingabe einer anderen Information, wie zum Beispiel der Erfassung eines biometrischen Merkmals des Nutzers. Bei der Authentifizierung des Nutzers gegenüber dem ID-Token wird ein Session Key vereinbart. Insbesondere kann die Vereinbarung eines Session Keys mithilfe eines Diffie-Hellman-Protokolls erfolgen.
3. c) Anschließend wird eine vierte Session auf dem Application Layer aufgebaut, und zwar zwischen einem Programm des ID-Tokens und dem ID-Provider-Computersystem, wobei diese vierte Session über die lokale Verbindung und die dritte Session verläuft und auf dem Application Layer eine zusätzliche Ende-zu-Ende Verschlüsselung mithilfe des in Schritt b vereinbarten Session Keys erfolgt.
4. d) Über die vierte Session erfolgt dann eine gegenseitige Authentifizierung des ID-Tokens und des ID-Provider-Computersystems, beispielsweise mithilfe eines Challenge-Response-Protokolls.
5. e) Das oder die Attribute gemäß der Attributspezifikation, welche das ID-Provider-Computersystem mit dem Request empfangen hat, werden nun über die vierte Session von dem ID-Provider-Computersystem aus dem ID-Token ausgelesen. Dies setzt die erfolgreiche Authentifizierung des Nutzers in Schritt b sowie die erfolgreiche gegenseitige Authentifizierung des ID-Tokens und des ID-Provider-Computersystems in Schritt d) voraus und erfolgt verschlüsselt über die vierte Session, sodass ein Maximum an Sicherheit und Vertrauenswürdigkeit hinsichtlich des oder der ausgelesenen Attribute gegeben ist.

The user computer system's program then checks whether the read rights specified in the certificate are sufficient to allow the ID provider computer system to access the attribute(s) to be read according to the attribute specification of the request. If the ID provider computer system's read rights are sufficient, the following additional steps are carried out:

1. a) A local connection is established between the reader of the user computer system and the ID token. For an ID token with a contact interface, for example a chip card interface, this can be done by inserting the ID token into the reader. For an ID token with a contactless interface, such as an RFID or NFC interface, this can be done by placing the ID token on the reader. Tokens with USB, Bluetooth or microSD cards are also possible here, as are virtual smart cards.
2. b) The user authenticates himself to the ID token, for example by entering his personal identification number (PIN) or by entering other information, such as the recording of a biometric characteristic of the user. When the user authenticates himself to the ID token, a session key is agreed. In particular, the agreement of a session key can be made using a Diffie-Hellman protocol.
3. c) A fourth session is then established on the application layer between a program of the ID token and the ID provider computer system, whereby this fourth session runs via the local connection and the third session and additional end-to-end encryption is carried out on the application layer using the session key agreed in step b.
4. d) The fourth session then provides mutual authentication of the ID token and the ID provider computer system, for example using a challenge-response protocol.
5. e) The attribute(s) according to the attribute specification that the ID provider computer system received with the request are now extracted from the ID token by the ID provider computer system via the fourth session. This requires the successful authentication of the user in step b and the successful mutual authentication of the ID token and the ID provider computer system in step d) and is carried out encrypted via the fourth session so that maximum security and trustworthiness is provided with regard to the attribute(s) read out.

The ID provider computer system then generates a response that contains the attribute(s) read out and the request identifier and/or the additional information in accordance with the request-response protocol to which the request is subject. In the case of a SAML request, a SAML response is generated accordingly. The logical assignment of request and response, i.e. the so-called binding, is established using the request identifier, which is also included in the response.

The response is signed by the ID provider computer system and stored for retrieval from the logical address previously communicated to the user computer system via the message.

The user computer system then reads this response from the ID provider computer system using the logical address, for example the URL, and forwards the response to the service computer system via the first session. Using the response identifier, it is assigned to the request and thus to the requested transaction and then the transaction is executed by the service computer system, i.e., for example, a payment process is initiated and/or an ordered product is delivered if the content of the response allows this.

According to one embodiment of the invention, the program of the user computer system is a browser plug-in of the Internet browser, whereby the Internet browser can be a standard browser program such as Microsoft ^® Internet Explorer ^® , Safari ^® , Google Chrome™ or Firefox ^® . Alternatively, the program of the user computer system can be an application program separate from the Internet browser.

According to one embodiment of the invention, the additional information entered by the user is payment information, such as a user account number from which the payment amount specified in the request is to be debited or collected.

The so-called clearing, i.e. the checking of the customer's creditworthiness, as well as the initiation of the payment process can then be initiated by the ID provider computer system, which confirms the execution of the payment with the response to the service computer system. This has the advantage that the service computer system does not need to obtain any knowledge of the user's payment information, i.e. in particular his account details.

Alternatively, the user can encrypt his payment information with the public key of the service computer system, so that only the user's encrypted payment information is transmitted to the ID provider computer system. The ID provider computer system then forwards the encrypted payment information with the response to the service computer system, which decrypts the payment information and then carries out the clearing and collects the payment amount from the user's account in accordance with the payment information. This has the advantage that the ID provider computer system does not gain knowledge of the user's payment information.

According to a further embodiment of the invention, the computer system includes a terminal, such as an ATM or a vending machine. The user can enter a request into the machine, such as to withdraw cash or to purchase a specific product, such as a drink. In response to this user request, the machine displays an optically detectable pattern, such as a QR code, on its screen, which contains information to initiate the execution of the transaction.

According to a further embodiment of the invention, the terminal is designed as a mobile telecommunications device, in particular as a so-called smart meter, for the collection of fees, e.g. for electricity or gas consumption, taximeter or smartphone with a fee collection function.

For example, the URL of the service computer system, the payment amount and the payment recipient can be displayed on a seller's smartphone in the form of an optically captured pattern and recorded with the camera of the user's computer system, which can also be designed as a smartphone. In this way, everyday payment transactions can be processed safely and conveniently.

In the following, embodiments of the invention are explained in more detail with reference to the drawings.

• 1 ein Blockdiagramm eines ID-Tokens,
• 2 eine Anordnung eines Computersystems zur Durchführung eines erfindungsgemäßen Verfahrens.

Show it:

• 1 a block diagram of an ID token,
• 2 an arrangement of a computer system for carrying out a method according to the invention.

Elements of the following figures which are identical or correspond to one another are each identified by the same reference numerals.

The 1 shows an ID token 106, which can be, for example, an electronic identity card.

The protected memory area 120 of the ID token 106 is used to store a reference value that is required for authenticating a user 102 to the ID token 106. This reference value is, for example, an identifier, in particular a so-called personal identification number (PIN), or reference data for a biometric feature of the user 102, which can be used to authenticate the user to the ID token 106.

The protected area 122 is used to store a private key and the protected storage area 124 is used to store attributes, for example of the user 102, such as his name, place of residence, date of birth, gender, and/or attributes relating to the ID token itself, such as the institution that created or issued the ID token, the validity period of the ID token, an identifier of the ID token, such as a passport number or a credit card number.

The electronic memory 118 can also have a storage area 126 for storing a certificate. The certificate contains a public key that is associated with the private key stored in the protected storage area 122. The certificate can have been created according to a public key infrastructure (PKI) standard, for example according to the X.509 standard.

The certificate does not necessarily have to be stored in the electronic memory 118 of the ID token 106. Alternatively or additionally, the certificate can also be stored in a public directory server.

The ID token 106 has a processor 128. The processor 128 is used to execute program instructions 130, 132 and 134. The program instructions 130 are used for user authentication, i.e. for authenticating the user 102 to the ID token.

When using a PIN, the user 102 enters his PIN into the ID token 106 for authentication, for example via the user computer system 100. By executing the program instructions 130, the protected memory area 120 is then accessed in order to compare the entered PIN with the reference value of the PIN stored there. In the event that the entered PIN matches the reference value of the PIN, the user 102 is considered authenticated.

Alternatively, a biometric feature of the user 102 is recorded. For example, the ID token 106 has a fingerprint sensor for this purpose or a fingerprint sensor is connected to the user computer system 100. The biometric data recorded from the user 102 are compared with the biometric reference data stored in the protected memory area 120 by executing the program instructions 130. If the biometric data recorded from the user 102 sufficiently matches the biometric reference data, the user 102 is considered authenticated.

The program instructions 134 serve to execute the steps of a cryptographic protocol relating to the ID token 106 for authenticating an ID provider computer system 136 to the ID token 106. The cryptographic protocol can be a challenge-response protocol based on a symmetric key or an asymmetric key pair.

For example, the cryptographic protocol implements an extended access control method as specified for machine-readable travel documents (MRTD) by the International Aviation Organization (ICAO). By successfully executing the cryptographic protocol, the ID provider computer system 136 authenticates itself to the ID token and thereby proves its read authorization to read the attributes stored in the protected memory area 124. The authentication can also be mutual, i.e. the ID token 106 must then also authenticate itself to the ID provider computer system 136 using the same or a different cryptographic protocol.

The program instructions 132 serve for end-to-end encryption between the ID token 106 and an ID provider computer system 136 (cf. 2 ) transmitted data, or at least the attributes read by the ID provider computer system 136 from the protected memory area 124. A symmetric key can be used for end-to-end encryption. which is agreed upon, for example, during the execution of the cryptographic protocol between the ID token 106 and the ID provider computer system 136.

The ID token 106 has an interface 108 for communication with a corresponding interface 104 of a user computer system 100 (see 2 ). The interface can be contactless or contact-based. In particular, it can be an RFID or an NFC communication interface.

Access to the protected memory area 124 to read one or more of the attributes can only be made via the processor 128 of the ID token 106, since the protected memory area 124 and the other protected memory areas 120, 122 are not directly connected to the interface 108, for example via a bus system, but only to the processor 128, i.e. access to the protected memory area 124 directly via the interface 108 is already excluded from a circuitry perspective. Only the processor 128 can therefore read the protected memory area 124 in order to then output the read attributes via the interface 108 if necessary.

The 2 shows a user computer system 100 of the user 102. The user computer system 100 can be a personal computer (PC), a portable computer, such as a laptop, notebook or tablet computer, a mobile telecommunications device, in particular a smartphone.

The user computer system has at least one processor 110 for executing an application program 112. The application program 112 is designed to communicate via a network interface 114 of the user computer system 100 over a network 116. For example, the application program is an Internet browser or another specialized application program that can communicate over the network 116, in particular an HTML-capable application program.

The processor 110 serves to execute a further program 113, which can be, for example, a plug-in for the application program 112, for example a browser plug-in if the application program 112 is designed as an Internet browser, or a program separate from the application program.

The network may be a computer network, such as the Internet. In particular, the network 116 may also include a mobile network.

The ID provider computer system 136 has a network interface 138 for communication via the network 116. The ID provider computer system 136 also has a memory 140 with a protected memory area 141 in which a private key 142 of the ID provider computer system 136 is stored, as well as the corresponding certificate 144. This certificate can also be a certificate according to a PKI standard, such as X.509.

The ID provider computer system 136 also has at least one processor 145 for executing program instructions 146 and 148. By executing the program instructions 146, the steps of the cryptographic protocol relating to the ID provider computer system 136 are executed. Overall, the cryptographic protocol is therefore implemented by executing the program instructions 134 by the processor 128 of the ID token 106 and by executing the program instructions 146 by the processor 145 of the ID provider computer system 136.

The program instructions 148 serve to implement the end-to-end encryption on the part of the ID provider computer system 136, for example based on the symmetric key that was agreed upon when the cryptographic protocol was executed between the ID token 106 and the ID provider computer system 136. In principle, any previously known method for agreeing the symmetric key for the end-to-end encryption can be used, such as a Diffie-Hellman key exchange.

The ID provider computer system 136 is preferably located in a particularly protected environment, in particular in a so-called trust center, so that the ID provider computer system 136, in combination with the need to authenticate the user 102 to the ID token 106, forms the trust anchor for the authenticity of the attributes read from the ID token 106.

A service computer system 150 can be designed to accept an order or a contract for a service or a product, in particular an online service. For example, the user 102 can open an account with a bank online via the network 116 or use another financial or banking service. The service computer system 150 can also be designed as an online department store, so that the user 102 can, for example, can purchase a mobile phone or the like online. Furthermore, the service computer system 150 can also be designed to deliver digital content, for example for downloading music and/or video data.

For this purpose, the service computer system 150 has a network interface 152 for connecting to the network 116. Furthermore, the service computer system 150 has at least one processor 154 for executing program instructions 156. By executing the program instructions 156, for example, dynamic HTML pages are generated via which the user 102 can enter his order or purchase order and carry out transactions.

Depending on the type of product or service ordered, the service computer system 150 must check one or more attributes of the user 102 and/or their ID token 106 based on one or more predetermined criteria. Only if this check is passed will the order or request of the user 102 be accepted and/or executed.

• - Der Nutzer 102 startet das Anwendungsprogramm 112 des Nutzer-Computersystems, wobei im Weiteren ohne Beschränkung der Allgemeinheit davon ausgegangen wird, dass es sich hierbei um einen Internet-Browser handelt. Der Nutzer 102 gibt eine URL des Dienst-Computersystems 150 in den Internet-Browser ein, so dass daraufhin eine erste Session 201 zwischen dem Internet-Browser 112 und dem Dienst-Computersystem 150 über das Netzwerk 116 aufgebaut wird. Der Nutzer kann dann über die erste Session 201 einen von dem Dienst-Computersystem 150 angebotenen Dienst anfordern, wie zum Beispiel ein Produkt bestellen, Daten zum Download anfordern oder die Durchführung einer finanziellen Transaktion anfordern. Hierzu wird von dem Internet-Browser 112 eine entsprechende Transaktionsanforderung 158 an das Dienst-Computersystem 150 gesendet, die diese Anforderung signalisiert.
• - Das Dienst-Computersystem empfängt also von dem Internet-Browser über die erste Session eine Transaktionsanforderung 158 des Nutzers 102.
• - Aufgrund des Empfangs der Transaktionsforderung 158 über die erste Session 201 erzeugt das Dienst-Computersystem 150 einen Request 166. Der Request 166 beinhaltet (i) eine Attributspezifikation, der aus dem ID-Token für die Durchführung der Transaktion auszulesenden Attribute. Bei diesen Attributen kann es sich um persönliche Angaben zu dem Nutzer 102 und/oder Daten betreffend den ID-Token 106 selbst oder ein Pseudonym des Nutzers 102, welches von dem ID-Token 106 verfügbar ist, handeln. Der Request beinhaltet ferner (ii) die Transaktionsdaten zur Spezifizierung der Transaktion, wie zum Beispiel einen Bezahlbetrag, der für den Kauf des bestellten Produkts oder die Durchführung des bestellten Dienstes an das Dienst-Computersystem 150 oder einen Dritten zu entrichten ist, und/oder andere Transaktionsdaten, die die durchzuführende Transaktion spezifizieren. Der Request beinhaltet ferner (iii) eine Kennung 180 des Requests, beispielsweise eine GUID, die für das sogenannte Binding des Requests und einer daraufhin empfangenen Response 174 erforderlich ist. Für die Erzeugung der Kennung kann das Dienst-Computersystem 150 einen GUID-Generator aufweisen. Die Request beinhaltet ferner (iv) eine URL des ID-Provider-Computersystems 136 und (v) eine URL des Dienst-Computersystems 150 selbst. Der Request wird von dem Dienst-Computersystem 150 signiert, nämlich mit Hilfe eines privaten Schlüssels des Dienst-Computersystems 150. Bei dem Request 166 kann es sich um einen SAML-Request oder einen anderen Request eines Request-Response-Protokolls handeln.
• - Als Antwort auf die Transaktionsanforderung 158 sendet dann das Dienst-Computersystem 150 eine Webseite 160 über die erste Session 201 an das Nutzer-Computersystem 100, wobei die Webseite 160 ein Eingabefeld 162 zur Eingabe einer Zusatzinformation durch den Nutzer 102 für die Transaktion aufweist und ferner ein Eingabeelement 164, das der Nutzer 102 zum Beispiel durch Anklicken selektieren kann, wenn die Webseite 160 durch den Internet-Browser 112 wiedergegeben wird, um die Weiterleitung des Request 166 zu erlauben. Zusammen mit der Webseite 160 wird auch der Request 166 über die erste Session 201 zu dem Internet-Browser 112 übertragen.
• - Aufgrund des Empfangs der Webseite 160 und des Requests 166 wird die Webseite 160 durch den Internet-Browser 112 wiedergegeben, so dass der Nutzer 102 die Zusatzinformation in das Eingabefeld 162 eingeben kann. Beispielsweise handelt es sich bei der Zusatzinformation um eine Kontoverbindung des Nutzers 102, eine Kreditkartennummer des Nutzers 102 oder andere ergänzende Transaktionsdaten und/oder um eine Authentifizierungsinformation zum Nachweis der Berechtigung des Nutzers 102 für die Durchführung der Transaktion, wozu der Nutzer 102 beispielsweise ein One-Time-Passwort (OTP) in das Eingabefeld 162 eingibt. Vorzugsweise wird die von dem Nutzer 102 eingegebene Zusatzinformation 168 mit dem öffentlichen Schlüssel des Dienst-Computersystems 150 durch das Nutzer-Computersystem 100 verschlüsselt, um ein entsprechendes Chiffrat zu erhalten.
• - Anschließend wird eine zweite Session 202 zwischen dem Internet-Browser 112 und dem ID-Provider-Computersystem 136 über das Netzwerk 116 aufgebaut, und zwar mit Hilfe der URL des ID-Provider-Computersystems 136, die das Nutzer-Computersystem 100 mit dem Request 166 empfangen hat. Die zweite Session 202 wird mit einem gesicherten Transportlayer aufgebaut, beispielsweise als https-Session.
• - Über die zweite Session 202 werden der Request 166 und die Zusatzinformation 168 oder nur das mit Hilfe des öffentlichen Schlüssels des Dienst-Computersystems 150 gewonnene Chiffrat der Zusatzinformation 168 von dem Nutzer-Computersystem 100 an das ID-Provider-Computersystem 136 weitergeleitet.
• - Aufgrund des Empfangs des Requests 166 durch das ID-Provider-Computersystem 136 erzeugt dieses durch Ausführen seiner Programminstruktionen 170 eine Session-ID für eine noch aufzubauende dritte Session 203. Der Request 166 und die Zusatzinformation 168 werden in dem Speicher 140 des ID-Provider-Computersystems 136 gespeichert.
• - Das ID-Provider-Computersystem 136 generiert dann eine Nachricht 172, die die Session-ID für den Aufbau der dritten Session 203 und eine logische Adresse beinhaltet. Mit Hilfe der logischen Adresse kann die von dem ID-Provider-Computersystem 136 aufgrund des Request 166 zu erzeugende Response 174 abgerufen werden. Insbesondere kann die logische Adresse als eine URL ausgebildet sein. Die Nachricht 172 wird über die zweite Session 202 von dem ID-Provider-Computersystem 136 an den Internet-Browser 112 gesendet.
• - Aufgrund des Empfangs der Nachricht 172 wird die dritte Session 203 zwischen dem Programm 113 des Nutzer-Computersystems 100 und dem ID-Provider-Computersystem 136 über den gesicherten Transportlayer der zweiten Session 202 aufgebaut. Beispielsweise handelt es sich bei dem Programm 113 um ein Browser-Plug-in des Internet-Browsers 112. Alternativ kann es sich bei dem Programm 113 auch um ein weiteres Anwendungsprogramm handeln. Es ist dabei auch möglich, die Funktionalitäten des Internet-Browsers 112 und die des Programms 113 in einem Programm zu implementieren.
• - Über die dritte Session 203 wird dann zumindest das Zertifikat 144 an das Programm 113 übertragen.
• - Durch das Programm 113 wird dann geprüft, ob die in dem Zertifikat 144 angegebenen Leserechte ausreichend sind, um einen Lesezugriff des ID-Provider-Computersystems 136 auf das oder die gemäß der Attributspezifikation, die in dem Request 166 beinhaltet ist, zu lesenden Attribute zuzulassen.

To carry out an electronic transaction, you can proceed as follows:

• - The user 102 starts the application program 112 of the user computer system, which is assumed from now on, without any loss of generality, to be an Internet browser. The user 102 enters a URL of the service computer system 150 into the Internet browser, so that a first session 201 is then established between the Internet browser 112 and the service computer system 150 via the network 116. The user can then use the first session 201 to request a service offered by the service computer system 150, such as ordering a product, requesting data for downloading, or requesting the execution of a financial transaction. To do this, the Internet browser 112 sends a corresponding transaction request 158 to the service computer system 150, signaling this request.
• - The service computer system therefore receives a transaction request 158 from the user 102 from the Internet browser via the first session.
• - Upon receipt of the transaction request 158 via the first session 201, the service computer system 150 generates a request 166. The request 166 includes (i) an attribute specification of the attributes to be read from the ID token for carrying out the transaction. These attributes can be personal information about the user 102 and/or data relating to the ID token 106 itself or a pseudonym of the user 102 which is available from the ID token 106. The request also includes (ii) the transaction data for specifying the transaction, such as a payment amount to be paid to the service computer system 150 or a third party for the purchase of the ordered product or the performance of the ordered service, and/or other transaction data specifying the transaction to be carried out. The request also includes (iii) an identifier 180 of the request, for example a GUID, which is required for the so-called binding of the request and a response 174 received thereafter. The service computer system 150 can have a GUID generator to generate the identifier. The request also includes (iv) a URL of the ID provider computer system 136 and (v) a URL of the service computer system 150 itself. The request is signed by the service computer system 150, namely with the aid of a private key of the service computer system 150. The request 166 can be a SAML request or another request of a request-response protocol.
• - In response to the transaction request 158, the service computer system 150 then sends a web page 160 to the user computer system 100 via the first session 201, the web page 160 having an input field 162 for the user 102 to enter additional information for the transaction and also an input element 164 that the user 102 can select, for example by clicking, when the web page 160 is displayed by the Internet browser 112 in order to allow the forwarding of the request 166. Together with the web page 160, the request 166 is also transmitted to the Internet browser 112 via the first session 201.
• - Due to the receipt of the web page 160 and the request 166, the web page 160 is displayed by the Internet browser 112 so that the user 102 can enter the additional information in the input field 162. For example, the additional information is an account number of the user 102, a credit card number of the user 102 or other additional transaction data and/or authentication information to prove the authorization of the user 102 to carry out the transaction, for which the user 102 enters, for example, a one-time password (OTP) in the input field 162. Before Preferably, the additional information 168 entered by the user 102 is encrypted with the public key of the service computer system 150 by the user computer system 100 in order to obtain a corresponding ciphertext.
• - A second session 202 is then established between the Internet browser 112 and the ID provider computer system 136 via the network 116, using the URL of the ID provider computer system 136 that the user computer system 100 received with the request 166. The second session 202 is established with a secure transport layer, for example as an https session.
• - The request 166 and the additional information 168 or only the ciphertext of the additional information 168 obtained with the aid of the public key of the service computer system 150 are forwarded from the user computer system 100 to the ID provider computer system 136 via the second session 202.
• - Upon receipt of the request 166 by the ID provider computer system 136, the latter generates a session ID for a third session 203 that is yet to be established by executing its program instructions 170. The request 166 and the additional information 168 are stored in the memory 140 of the ID provider computer system 136.
• - The ID provider computer system 136 then generates a message 172 which contains the session ID for setting up the third session 203 and a logical address. The logical address can be used to retrieve the response 174 to be generated by the ID provider computer system 136 based on the request 166. In particular, the logical address can be designed as a URL. The message 172 is sent from the ID provider computer system 136 to the Internet browser 112 via the second session 202.
• - Due to the receipt of the message 172, the third session 203 is established between the program 113 of the user computer system 100 and the ID provider computer system 136 via the secure transport layer of the second session 202. For example, the program 113 is a browser plug-in of the Internet browser 112. Alternatively, the program 113 can also be another application program. It is also possible to implement the functionalities of the Internet browser 112 and those of the program 113 in one program.
• - Via the third session 203, at least the certificate 144 is transferred to the program 113.
• - The program 113 then checks whether the read rights specified in the certificate 144 are sufficient to allow read access of the ID provider computer system 136 to the attribute or attributes to be read according to the attribute specification contained in the request 166.

1. a) Es wird eine lokale Verbindung 176 zwischen den Schnittstellen 104 und 108 aufgebaut. Beispielsweise erscheint auf dem Bildschirm des Nutzer-Computersystems 100 eine Aufforderung für den Nutzer 102 zum Einführen des ID-Tokens 106 in ein Lesegerät des Nutzer-Computersystems 100, welches die Schnittstelle 104 aufweist oder zum Auflegen des ID-Tokens 106 auf eine kontaktlos ausgebildete Schnittstelle 104.
2. b) Der Nutzer 102 authentifiziert sich dann gegenüber dem ID-Token beispielsweise durch Eingabe seiner PIN in das Nutzer-Computersystem 100 bzw. dessen Lesegerät. Die Authentifizierung des Nutzers kann mit Hilfe eines kryptographischen Protokolls erfolgen, beispielsweise mittels eines Challenge-Response-Protokolls oder basierend auf einem Diffie-Helman-Schlüsselaustausch, wobei im Rahmen der Authentifizierung des Nutzers ein Session-Key vereinbart wird.
3. c) Unter der Voraussetzung der erfolgreichen Authentifizierung des Nutzers wird eine vierte Session 204 zwischen dem ID-Token 106 und dem ID-Provider-Computersystem 136 aufgebaut, und zwar über die lokale Verbindung 176 und die dritte Session 203. Die vierte Session 204 wird mit einer Ende-zu-Ende-Verschlüsselung mit Hilfe des Session-Keys, der bei der Authentifizierung des Nutzers in dem Schritt b) vereinbart worden ist, geschützt.
4. d) Über die vierte Session erfolgt dann eine gegenseitige Authentifizierung des ID-Tokens 106 und des ID-Provider-Computersystems 136 mit Hilfe der jeweiligen privaten Schlüssel, das heißt den in dem geschützten Speicherbereich 122 gespeicherten privaten Schlüssels des ID-Tokens 106 und dem privaten Schlüssels 142 des ID-Provider-Computersystems 136. Für diese gegenseitige Authentifizierung können die Zertifikate des ID-Tokens 106 aus dem Speicherbereich 126 (vergleiche 1) sowie das Zertifikat 144 des ID-Provider-Computersystems 136 über die vierte Session ausgetauscht werden.
5. e) Unter der Voraussetzung der erfolgreichen Authentifizierung des Nutzers gegenüber dem ID-Token und der erfolgreichen gegenseitigen Authentifizierung des ID-Tokens 106 und des ID-Provider-Computersystems 136 liest dann das ID-Provider-Computersystem 136 das oder die Attribute gemäß der Attributspezifikation aus dem ID-Token 106 aus, wobei die Attribute durch die Ende-zu-Ende-Verschlüsselung bei der Übertragung von dem ID-Token 106 zu dem ID-Provider-Computersystem 136 geschützt werden. Hierzu sendet das ID-Provider-Computersystem über die vierte Session 204 ein Lesekommando über die vierte Session an den ID-Token 106. Das Lesekommando 182 beinhaltet die Attributspezifikation, das heißt die Auswahl derjenigen Attribute, die aus dem geschützten Speicherbereich 124 des ID-Tokens 106 ausgelesen werden sollen.

Only if these read rights are sufficient, the following steps are carried out:

1. a) A local connection 176 is established between the interfaces 104 and 108. For example, a request appears on the screen of the user computer system 100 for the user 102 to insert the ID token 106 into a reader of the user computer system 100, which has the interface 104, or to place the ID token 106 on a contactless interface 104.
2. b) The user 102 then authenticates himself to the ID token, for example by entering his PIN into the user computer system 100 or its reader. The user can be authenticated using a cryptographic protocol, for example using a challenge-response protocol or based on a Diffie-Helman key exchange, with a session key being agreed upon as part of the user authentication.
3. c) Provided that the user is successfully authenticated, a fourth session 204 is established between the ID token 106 and the ID provider computer system 136, via the local connection 176 and the third session 203. The fourth session 204 is protected with end-to-end encryption using the session key that was agreed upon during the user authentication in step b).
4. d) The fourth session then provides mutual authentication of the ID token 106 and the ID provider computer system 136 using the respective private keys, i.e. the private key of the ID token 106 stored in the protected storage area 122 and the private key 142 of the ID provider computer system 136. For this mutual authentication, the certificates of the ID token 106 from the storage area 126 (see 1 ) and the certificate 144 of the ID provider computer system tems 136 about the fourth session.
5. e) Provided that the user is successfully authenticated to the ID token and that the ID token 106 and the ID provider computer system 136 are successfully authenticated, the ID provider computer system 136 then reads the attribute(s) from the ID token 106 in accordance with the attribute specification, the attributes being protected by end-to-end encryption during transmission from the ID token 106 to the ID provider computer system 136. To do this, the ID provider computer system sends a read command to the ID token 106 via the fourth session 204. The read command 182 contains the attribute specification, i.e. the selection of the attributes that are to be read from the protected memory area 124 of the ID token 106.

• - Das Nutzer-Computersystem 100, wie zum Beispiel dessen Internet-Browser 112, liest dann mit Hilfe der logischen Adresse die Response 174 beispielsweise über die zweite Session 202 aus dem Speicher 140.
• - Die Response 174 wird dann von dem Nutzer-Computersystem 100, beispielsweise von dem Internet-Browser 112, über die erste Session 201 an das Dienst-Computersystem 150 weitergeleitet. Hierbei kann vorgesehen sein, dass der Nutzer 102 von dem Internet-Browser 112 zur Eingabe einer Bestätigung aufgefordert wird, bevor die Response 174 an das Dienst-Computersystem weitergeleitet wird. Dabei kann ferner vorgesehen sein, dass von dem Internet-Browser der Inhalt der Response 174 ganz oder teilweise angezeigt wird, insbesondere die aus dem ID-Token ausgelesenen Attribute und/oder die Zusatzinformation 168, damit sich der Nutzer 102 von der Richtigkeit dieser Daten überzeugen kann, bevor sie an das Dienst-Computersystem 150 zur Durchführung der Transaktion weitergeleitet werden.
• - Das Dienst-Computersystem 150 ordnet die empfangene Response 174 dem Request 166 anhand der übereinstimmenden Kennungen 180 des Requests 166 und der Response 174 zu.
• - Das Dienst-Computersystem 150 prüft dann die Signatur der Response 166 und liest das oder die erforderlichen Attribute aus der Response 174 aus. Anhand der Attribute wird dann geprüft, ob die angeforderte Transaktion durchgeführt werden kann, indem das oder die Attribute mit einem oder mehreren vorgegebenen Kriterien verglichen wird. Bei diesen Kriterien kann es sich zum Beispiel um das Alter oder die Kreditwürdigkeit des Nutzers 102 handeln. Bei dem Attribut kann es sich auch um ein Pseudonym des Nutzers 102 handeln, mit Hilfe dessen das Dienst-Computersystem 150 dann ein in einer Datenbank des Dienst-Computersystems 150 gespeichertes Attribut des Nutzers 102, wie zum Beispiel eine Lieferadresse ausliest. Das Prüfkriterium ist hierbei, ob ein Nutzer mit dem in der Response 174 beinhalteten Pseudonym seitens des Dienst-Computersystems 150 registriert ist.
  • Ergibt die Prüfung des Dienst-Computersystems 150, dass die Transaktion durchführbar ist, so wird die Transaktion anhand der Transaktionsdaten und der Zusatzinformation 168 durchgeführt.

By executing the program instructions 178, the ID provider computer system 136 then generates the response 174, for example a SAML response, to the request 166. The response 178 contains the attributes previously read from the ID token 106 via the fourth session 240, the additional information 168 or - alternatively - not the additional information 168, but only the ciphertext of the additional information 168, and the identifier 180 that the service computer system 150 initially assigned for the request 166. The response 174 is signed by the ID provider computer system 136 using the private key 142 and then stored in the memory 140 so that the request 166 can be retrieved from the logical address.

• - The user computer system 100, such as its Internet browser 112, then uses the logical address to read the response 174, for example via the second session 202, from the memory 140.
• - The response 174 is then forwarded by the user computer system 100, for example by the Internet browser 112, to the service computer system 150 via the first session 201. In this case, it can be provided that the user 102 is prompted by the Internet browser 112 to enter a confirmation before the response 174 is forwarded to the service computer system. It can also be provided that the Internet browser displays the content of the response 174 in whole or in part, in particular the attributes read from the ID token and/or the additional information 168, so that the user 102 can ensure that this data is correct before it is forwarded to the service computer system 150 to carry out the transaction.
• - The service computer system 150 assigns the received response 174 to the request 166 based on the matching identifiers 180 of the request 166 and the response 174.
• - The service computer system 150 then checks the signature of the response 166 and reads the required attribute(s) from the response 174. The attributes are then used to check whether the requested transaction can be carried out by comparing the attribute(s) with one or more predetermined criteria. These criteria can be, for example, the age or creditworthiness of the user 102. The attribute can also be a pseudonym of the user 102, with the help of which the service computer system 150 then reads an attribute of the user 102 stored in a database of the service computer system 150, such as a delivery address. The test criterion here is whether a user with the pseudonym contained in the response 174 is registered by the service computer system 150.
  • If the check by the service computer system 150 shows that the transaction is feasible, the transaction is carried out based on the transaction data and the additional information 168.

For example, the program 113 is a browser plug-in that is registered in a registry of an operating system of the user's computer system with a plug-in identifier, where the operating system can be, for example, a Windows operating system, Android or iOS. In this case, the message 172 from the ID provider computer system to the Internet browser 112 contains this plug-in identifier 184, so that the plug-in 113 is started upon receipt of the message.

In another example, the program 113 is an application program that is separate from the Internet browser 112, such as a so-called citizen app or ID app. This application program 113 is started by the Internet browser 112 by calling a local URL, wherein the local URL contains a fixed port number according to the TCP protocol. This local URL is transmitted together with the website 160 from the service computer system 150 to the user computer system 100, specifically via the first session 201, in order to start the application program 113 using the local URL. URL by the Internet browser 112.

In the event that only the ciphertext of the additional information 168, but not the additional information 168 itself, is transmitted from the user computer system 100 to the ID provider computer system 136 via the second session 202, the response 174 also contains only this ciphertext, but not the additional information 168 itself. In this case, the service computer system 150 decrypts the ciphertext using the private key of the service computer system 150 in order to then carry out the requested transaction using the additional information 168. This can, for example, involve carrying out a financial transaction, such as carrying out a transfer in the amount of the payment amount specified in the additional information 168.

Alternatively, it is also possible for the payment to be initiated by the ID provider computer system 136. This can be done by the ID provider computer system 136 receiving the transaction data required for this via the request 166 and the additional information 168 and then making or initiating the payment. The response 174 then contains a confirmation from the ID provider computer system 136 that the payment has been made.

Transmission of the additional information 168 to the service computer system 150 can then be omitted, which is advantageous for protecting the confidentiality of this additional information 168, because this additional information 168 then only needs to be disclosed to the trustworthy ID provider computer system 136. The actual transaction, e.g. the delivery of the ordered product, is then initiated by the service computer system 150 after receipt of the payment confirmation, which is included in the response 174.

For example, the additional information 168 contains an OTP. The service computer system 150 then checks whether the OTP is valid as an additional prerequisite for carrying out the transaction. The OTP is preferably encrypted by the user computer system 100 with the public key of the service computer system 150 and then decrypted by the service computer system 150 after receiving the additional information with the encrypted OTP in order to then check its validity.

The computer system includes a terminal 186, which can be a machine, in particular an ATM or vending machine. For example, the user 102 can enter an amount of money into the terminal 186 in order to withdraw cash from his account. A visually detectable pattern is then shown on a display 188 of the machine, such as a QR code, which contains a URL of the service computer system 150 and the amount of money desired by the user 102.

This optical pattern is captured by the display 188 using a camera 190 of the user computer system 100. The user computer system 100 then generates the transaction request 158, which specifies this amount of money. The first session 201 is set up here using the URL of the service computer system 150 captured from the optical pattern, and the transaction request 158 with the desired amount of money is transmitted to the service computer system 150 via this first session 201. The service computer system 150 then generates a corresponding request 166 to query the attributes and additional information 168 required for paying out the desired amount of money.

Then, either the ID provider computer system 136 or the service computer system 150 initiates the debiting of an account of the user 102, which the user has specified, for example, in the additional information 168. Upon receipt of the response 174 and initiation of the payment, the terminal 186 then receives a signal to dispense the desired amount of money, for example in the form of cash or to top up a cash card of the user 102. This can be done in such a way that the terminal 186 is connected directly to the service computer system 150 or via the network 116.

Alternatively, the terminal 186 may also be a vending machine, in which case no cash but a desired product, such as a can of beverages or a pack of cigarettes, is dispensed from the vending machine after the execution of the payment has been signaled by the service computer system 150.

In a further application, the terminal 186 can be a mobile telecommunications device, in particular a smartphone. If the user 102 wants to buy something from the owner of the terminal 186, the owner of the terminal 186 enters the corresponding purchase price into the terminal 186, so that this purchase price is then displayed on the display 188 in the form of the optically detectable pattern as the payment amount and the URL of the service computer system 150. After the transaction has been completed, the terminal 186 receives from the service computer system 150 a signal which indicates that the payment transaction has taken place and the owner of the terminal 186 then hands over the goods to the user 102. This can also be implemented in the cash register system of a supermarket, for example. Another application is a taximeter which records taxi fares or another consumption meter, such as a consumption meter for the electricity or gas consumption of a household, in particular a so-called smart meter.

List of reference symbols

100

User computer system

102

Users

104

interface

106

ID token

108

interface

110

processor

112

Application program/Internet browser

113

Program/Application program

114

Network interface

116

network

118

electronic storage

120

protected storage area

122

protected storage area

124

protected storage area

126

Storage area

128

processor

130

Program instructions

132

Program instructions

134

Program instructions

136

ID provider computer system

138

Network interface

140

Storage

141

protected storage area

142

private key

144

certificate

145

processor

146

Program instructions

148

Program instructions

150

Service computer system

152

Network interface

154

processor

156

Program instructions

158

Transaction request

160

website

162

input box

164

Input element

166

Request

168

extra information

170

Program instructions

172

News

174

Response

176

local connection

178

Program instructions

180

Identifier

182

Read command

184

Identifier

186

terminal

188

Display

190

camera

Claims (22)

Electronic transaction method using an ID token (106) that is assigned to a user (102), wherein the ID token has an electronic memory (118) with a protected memory area (124) in which one or more attributes are stored, wherein access to the protected memory area is only possible via a processor (128) of the ID token, and wherein the ID token has a communication interface (108) for communication with a reader of a user computer system (100), with the following steps: - display of an optically readable pattern on a screen (188) of a terminal (186), wherein information is encoded in the optically readable pattern that contains at least one logical address of a service computer system (150) and transaction data, - detection of the pattern using an optical sensor (190) of the user computer system and decoding of the pattern by the user computer system, - transmission of a transaction request (158) from the user computer system to the logical address of the Service computer system via the network, wherein the transaction request contains the transaction data, - transmission of a request (166) from the service computer system via the user computer system (100) to an ID provider computer system (136), wherein the transmission via the network takes place, the request containing an attribute specification of the attributes to be read from the ID token for carrying out the transaction, - authentication of the user to the ID token, - authentication of the ID provider computer system to the ID token via the network, - provided that the user and the ID provider computer system are successfully authenticated to the ID token, reading the attribute(s) according to the attribute specification by the ID provider computer system from the ID token via the network with end-to-end encryption, - transmission of a response (174) from the ID provider computer system via the user computer system to the service computer system, the response being transmitted via the network, the response containing the attribute(s) read out, and the response being signed by the ID provider computer system, carrying out the transaction using the transaction data and the attribute(s) by the service computer system, a confirmation signal for carrying out the transaction being sent from the service computer system via the network to the User computer system and output by the user computer system as an optical pattern, wherein the terminal is designed to detect the optical pattern from the user computer system. Procedure according to Claim 1 , with the further step of checking whether the attribute(s) satisfy a given criterion by the service computer system, whereby the transaction is only carried out if the criterion is met. Procedure according to Claim 1 or 2 , wherein the transaction data includes a payment amount and wherein the transaction is initiated by the service computer system to perform a financial transaction in the amount of the payment amount. Procedure according to Claim 3 , wherein the terminal is a bank terminal for withdrawing cash or for topping up a cash card, wherein the user selects the payment amount by entering it into the bank terminal, and a user's account is debited in the amount of the payment amount as a result of the financial transaction, whereupon the service computer system sends the confirmation signal to the user computer system and the bank terminal withdraws the cash in the amount of the payment amount or tops up the cash card in the amount of the payment amount based on the optical pattern detected by the user computer system. Procedure according to Claim 3 , wherein the terminal is a vending machine, wherein the payment amount is a sales price for a product dispensable by the vending machine, wherein the service computer system initiates the financial transaction to debit an account of the user in the amount of the payment amount, whereupon the service computer system transmits the confirmation signal to the user computer system and the vending machine dispenses the product based on the optical pattern detected by the user computer system. Procedure according to Claim 3 , wherein the terminal is a taximeter, wherein the payment amount is a transportation fee for a taxi ride, wherein the service computer system initiates the financial transaction to debit an account of the user with the payment amount, whereupon the service computer system transmits the confirmation signal to the user computer system and the taximeter issues a receipt for payment of the taxi ride based on the optical pattern detected by the user computer system. Method according to one of the preceding claims, wherein the terminal is a smartphone, wherein the optically readable pattern contains an account connection of a holder of the smartphone, wherein the service computer system initiates the financial transaction to transfer the payment amount to the account of the holder of the smartphone, whereupon the service computer system transmits the confirmation signal to the user computer system, which is issued by the smartphone via a user interface based on the optical pattern detected by the user computer system, in order to inform the holder of the smartphone of the payment. Procedure according to Claim 1 or 2 , wherein the terminal is a consumption meter, and wherein the optically readable pattern includes a consumption level recorded by the consumption meter, wherein the service computer system carries out the transaction in the form of a database transaction to store the consumption level. Method according to one of the preceding claims, comprising the following steps: - establishing a first session (201) between an application program (112) of the user computer system and the service computer system (150) via the network (116), - receiving the transaction request (158) via the first session by the service computer system from the application program (112), - generation of a request (166) by the service computer system based on receipt of the transaction request, wherein the request is signed by the service computer system and the request contains an attribute specification of the attributes to be read from the ID token for carrying out the transaction, transaction data for specifying the transaction, an identifier (180) of the request, a URL of an ID provider computer system and a URL of the service computer system, - transmission of a web page (160) and the request via the first session from the service computer system to the user computer system, wherein the web page has an input field (162) for entering additional information (168) for carrying out the transaction, - display of the web page by the application program and input of the additional information by the user in the input field, - establishment of a second session (202) between the application program (112) and the ID provider computer system via the network using the URL of the ID provider computer system, wherein the second session is established with a secure transport layer, - forwarding of the request and the additional information from the application program to the ID provider computer system via the second session, - based on the receipt of the request, generation of a session ID for a third session (203) by the ID provider computer system and storage of the request and the additional information by the ID provider computer system, - sending a message from the ID provider computer system to the application program (112) with the session ID of the third session and a logical address via the second session, - setting up the third session between a program (113) of the user computer system and the ID provider computer system via the secure transport layer of the second session, wherein the program can be different from the application program (112), - transferring at least one certificate (144) of the ID provider computer system to the program (113), wherein the certificate contains an indication of read rights of the ID provider computer system for reading one or more of the attributes stored in the ID token, wherein the certificate is transferred via the third session, - checking by the program (113) whether the read rights specified in the certificate are sufficient to enable read access by the ID provider computer system to access the attribute or attributes to be read according to the attribute specification, and only if the reading rights are sufficient: a) establishing a local connection (176) between the reader of the user computer system and the ID token, b) authenticating the user to the ID token, whereby a session key is agreed, c) establishing a fourth session (204) between the ID token and the ID provider computer system via the local connection and the third session with end-to-end encryption using the session key, d) mutual authentication of the ID token and the ID provider computer system via the fourth session, e) reading the attribute or attributes according to the attribute specification from the ID token by the ID provider computer system via the fourth session. - Generation of the response (174) which contains the read attribute(s) and at least the identifier (180) of the request, and which is signed by the ID provider computer system, - Storage of the response for retrieval using the logical address, - Reading of the response from the ID provider computer system by the user computer system by retrieving the response using a read command from the logical address via the network, - Forwarding of the response by the user computer system via the first session to the service computer system, - Assignment of the response to the request by the service computer system using the identifier contained in the response, - Execution of the transaction by the ID provider computer system using the response. Procedure according to Claim 9 , wherein the application program is an Internet browser, and the further program is a plug-in of the Internet browser, wherein the plug-in is registered in a registry of an operating system of the user computer system with a plug-in identifier (184), wherein the message from the ID provider computer system to the Internet browser contains the plug-in identifier, so that the plug-in is started upon receipt of the message. Procedure according to Claim 9 or 10 , wherein the program is a further application program which can be started by the Internet browser by calling a local URL, wherein the local URL contains a fixed port number according to the TCP protocol, wherein the local URL is transmitted together with the web page from the service computer system to the user computer system in order to cause the further application program to be started by the Internet browser using the local URL. Procedure according to Claim 9 , 10 or 11 , whereby the additional information is the user’s payment information. Procedure according to Claim 12 , wherein the additional information is encrypted by the user computer system using the public key of the service computer system and only the encrypted additional information is forwarded to the ID provider computer system via the second session, wherein the encrypted additional information is included in the response and the encrypted additional information is decrypted after receipt of the response by the service computer system using the private key of the service computer system. Method according to one of the preceding Claims 9 until 13 , wherein the request contains payment information of the service computer system and wherein the additional information contains payment information of the user, and wherein the transaction data of the request contains a payment amount, wherein the payment is initiated by the ID provider computer system, and the response does not contain the payment information of the user. Method according to one of the preceding Claims 9 until 14 , wherein the request contains payment information of the service computer system and wherein the additional information contains payment information of the user, and wherein the transaction data of the request contains a payment amount, wherein the payment is initiated by the service computer system, and the response contains the user's payment information encrypted with the public key of the service computer system. Method according to one of the preceding claims, wherein the pattern is a one-dimensional, two-dimensional, high capacity color barcode, maxicode, QR code or data matrix code or a chronological sequence of several such codes. Method according to one of the preceding claims, wherein the ID token is a value or security document. Method according to one of the preceding claims, wherein the response also contains the additional information. Procedure according to Claim 18 , wherein the additional information includes an OTP and the service computer system (150) checks the validity of the OTP, wherein the transaction is only carried out if the OTP is valid. Computer system with a terminal (186), a service computer system (150), a user computer system (100), an ID provider computer system (136) and an ID token (106) which is assigned to a user (102), wherein the ID token has an electronic memory (118) with a protected memory area (124) in which one or more attributes are stored, wherein access to the protected memory area is only possible via a processor (128) of the ID token, and wherein the ID token has a communication interface (108) for communication with a reader of a user computer system (100), wherein the terminal, the service computer system, the user computer system, the ID provider computer system and the ID token are designed to carry out the following steps: - displaying an optically readable pattern on a screen (188) of a terminal (186), wherein information is encoded in the optically readable pattern which contains at least one logical address of a service computer system (150) and transaction data, - detection of the pattern using an optical sensor (190) of the user computer system and decoding of the pattern by the user computer system, - transmission of a transaction request (158) from the user computer system to the logical address of the service computer system via the network, wherein the transaction request contains the transaction data, - transmission of a request (166) from the service computer system via the user computer system (100) to an ID provider computer system (136), wherein the transmission takes place via the network, wherein the request contains an attribute specification of the attributes to be read from the ID token for the execution of the transaction, - authentication of the user to the ID token, - authentication of the ID provider computer system to the ID token via the network, - provided that the user and the ID provider computer system are successfully authenticated to the ID token, reading the attribute or attributes according to the attribute specification by the ID provider computer system from the ID token via the network with End-to-end encryption, - transmission of a response (174) from the ID provider computer system via the user computer system to the service computer system, the response being transmitted via the network, the response containing the read attribute(s), and the response being signed by the ID provider computer system, - execution of the transaction using the transaction data and the attribute(s) by the service computer system, a confirmation signal for execution of the transaction being sent by the service computer system sent via the network to the user computer system and output by the user computer system as an optical pattern, wherein the terminal is designed to capture the optical pattern from the user computer system. Computer system according to Claim 20 , where the terminal is a machine, in particular an ATM or a vending machine. Computer system according to Claim 20 or 21 , wherein the terminal is a mobile telecommunications device, in particular a taximeter or a smartphone, with a fee recording function, or a consumption meter, in particular a smart meter, for recording a consumption value.

Images