DE102013022436B3 - Electronic transaction process and computer system - Google Patents

Abstract

Electronic transaction method using an ID token (106) which is assigned to a user (102), the ID token having an electronic memory (118) with a protected memory area (124) in which one or more attributes are stored, The protected memory area can only be accessed via a processor (128) of the ID token, and 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, 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, - construction of a first Se ssion (201) between an application program (112) of the user computer system, and the service computer system (150) via the network (116), - receipt of a transaction request (158) via the first session by the service computer system from the application program ( 112), the transaction request containing the transaction data, - generation of a request (166) by the service computer system on the basis of the receipt of the transaction request, the request being signed by the service computer system and the request an attribute specification from the ID token for the execution of the transaction includes attributes to be read out, 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 website (160) and the request via the first session from the service computer system to the user computer system, the website being an input field (162) for entering additional information (168) for executing the transaction, - displaying the website by the application program and entering the additional information by the user in the input field, - establishing 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, the second session being established with a secure transport layer, forwarding the request and the additional information from the application program to the ID provider computer system via the second Session, - due to 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, - establishing 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, the program being able to be different from the application program (112), - transmission at least one certificate (144) of the ID provider computer system to the program (113), the certificate including an indication of read rights of the ID provider computer system for reading one or more of the attributes stored in the ID token, the The certificate is transmitted over the third session, - the program (113) checks whether the read rights specified in the certificate are sufficient to permit read access by the ID provider computer system to the attribute or attributes to be read in accordance with the attribute specification, and only if the reading rights are sufficient: a) Establishing a local connection (176) between the reading device of the user computer system ems and the ID token, b) authenticating the user to the ID token, a session key being agreed, c) establishing a fourth session (204) between the ID token and the ID provider computer system via the local one 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 out the attribute or attributes according to the attribute specification the ID provider computer system via the fourth session from the ID token, generating a response (174) which contains the attribute or attributes read out and at least the identifier (180) of the request, and that of the ID provider computer system is signed, - storage of the response for retrieval with the aid of the logical address, - reading of the response from the ID provider computer system by the user computer system by retrieval of the response by means of a read command from the logical n 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 using the identifier contained in the response by the service computer system, - Execution of the transaction using the response by the ID provider computer system, 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 contain a payment amount, the payment by the ID provider computer system is initiated, and the response does not include the payment information of the user.

Description

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

Various transaction methods are known for electronic trading, that is to say the so-called eCommerce. This includes common payment methods such as a paper-based transfer or cash on delivery as well as electronic payment methods such as credit card payment, payment via online banking, collection / billing systems, factory systems, electronic direct debit, prepaid methods, payment by telephone bill and mobile-payment systems. Such payment methods are also used in part for e-government applications.

In contrast, the object of the invention is to create an improved electronic transaction method and a corresponding computer system.

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

Known from the prior art are an information processing device with an optical data reader, server, and a method for electronic trading ( 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, April 20, 2012) and a technical guideline on API framework for the provision of an interface that enables a 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, the Federal Office for Information Security describes advanced security mechanisms for machine-readable travel documents.

A "transaction" is a financial transaction, such as the payment of a payment amount by making a transfer, direct debit or credit card, an order process for ordering and delivering physical goods or data, as well as other logistical, commercial and / or financial transactions and / or a database transaction eg to store a value, e.g. a consumption value, a credit, or a payment amount understood.

A “terminal” is understood here to mean a device that has a display, i.e. has a screen for displaying an optical pattern. The terminal can only acquire information and output it on the display, or it can have a user interface for entering a selection of a user.

For example, the terminal can be designed as an automated teller machine or vending machine. The user can enter a request in the terminal, such as for withdrawing cash, topping up a cash card or to 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, the pattern containing information in order to initiate the execution of the transaction. This can be the desired payment amount or the purchase price of the product.

According to a further embodiment of the invention, the terminal is used as a telecommunication device, as a so-called smart meter, for charging, e.g. of electricity or gas consumption, taximeter or smartphone with a fee entry function.

A “pattern” is understood here to mean a static optical pattern which is output on the display of the terminal and in which information is encoded, for example a bar code, in particular a one-dimensional, two-dimensional, high capacity color bar code, MaxiCode, QR code or DataMatrix code, or a chronological order of several patterns, with the patterns and their chronological order encoding information such as, for example is the case with a flicker code. The "flicker code" is known for the so-called chipTAN-comfort or Smart-TAN-optic online banking procedure of the savings banks or Volksbanks.

A “session” is understood here to mean a temporary communication connection, that is to say 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, with the transport layer being protected by symmetrical encryption in the latter.

An “ID token” is understood here to mean in particular a portable electronic device which has at least one data store Storage of the at least one attribute and a communication interface for reading out the attribute. The ID token preferably has a secured 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 being read out without the authorization required for this.

In particular, the ID token can be a USB stick or a document, in particular a value or security document. According to the invention, a “document” is understood to mean paper-based and / or plastic-based documents, in particular electronic government documents, such as, for example, electronic identification documents, in particular passports, identity cards, visas and driving licenses, vehicle licenses, vehicle letters, company ID cards, health cards or other ID documents and also chip cards , Means of payment, in particular banknotes, bank cards and credit cards, waybills or other credentials, such as an admission ticket, in which a data memory 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 linked to a hardware token, that is to say, for example, to a so-called secure element.

In particular, such a soft token cryptographically linked to a secure element can be used in accordance with DE 10 2011 082 101 be generated.

An “ID provider computer system” is understood here to mean a computer system which 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 which 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 providing an eCommerce or eGovernment application, in particular an online shop or a government server.

A “user computer system” is understood here to mean 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 conventional Internet browser, such as Microsoft Internet Explorer, Safari, Google Chrome, Firefox or another application program for accessing act the service computer system. The user computer system has an interface for connection to the network, which network can be a private or public network, in particular the Internet.

According to one embodiment of the invention, the request from the service computer system is a SAML request and the response from the ID provider computer system is a SAML response (cf. Security Assertion Markup Language (SAML) V2 .0 Technical Overview, OASIS, Committee Draft 02 . 25 , March 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 conform to the X.509 standard or another standard. The certificate is preferably a Card Verifiable Certificate (CVC).

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

Embodiments of the invention are particularly advantageous since a computer-implemented payment method that is universal and also suitable for eCommerce and eGovernment applications is created, which is flexible, convenient to use and secure at the same time. 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 authentication of the user against the ID token and authentication of the ID provider computer system against 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 for example a ticket, an entry card or a food or luxury item.

For example, the terminal can be an automated teller machine. In this case, the user enters a desired payment amount via a user interface of the automated teller machine. This payment amount is then displayed as an optically readable pattern by the automated teller machine on its screen and this pattern is detected by the user with the aid of an optical sensor, for example by the camera of the user computer system, which can be designed as a smartphone. The pattern displayed on the screen may also include 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 operator of the automated teller machine.

The user computer system decodes the pattern captured by the screen of the terminal using the optical sensor and then generates a transaction request that specifies the payment amount and possibly the further transaction data that are contained 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 which contains an attribute specification, that is to say an indication of at least one attribute to be read from the ID token, which is required for the execution of the transaction and / or which has to meet a predetermined check criterion in order for the transaction to be carried out can be. For example, the attribute can be an account connection of the user stored in the ID token or a pseudonym of the user which serves for the service computer system as an access key to account information of registered users stored in a database in a pseudonymized manner. As an alternative or in addition, the attribute can be an indication of age 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 authentication of the user against his ID token and after authentication of the ID provider computer system against the ID token via the network, the at least one attribute from the ID token is then read out by the ID provider computer system via the network end-to-end encryption.

The ID provider computer system then generates a response which contains the at least one attribute read from the ID token. The attributes and / or the response is 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, i.e. here, for example, the debiting of the user's account with the payment amount, and / or to check whether a predetermined criterion, e.g. the legal capacity is fulfilled.

After this account has been debited, the service computer system generates a confirmation signal which is transmitted to the bank terminal. For example, for this purpose the terminal, that is to say the automated teller machine here, is connected to the network, so that the confirmation signal is transmitted from the service computer system to the terminal via the network. The acknowledgment signal is preferably signed by the service computer system in order to avoid manipulation. On receipt of a valid confirmation signal, the cash is then issued in the amount of the desired payment amount or, alternatively, the user is charged with a cash card.

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 on its display an optical pattern in which the purchase price of the product selected by the user is coded, as well as account information of the account to which the purchase price is to be paid. Furthermore, the optical pattern includes the specification of a logical address, in particular a URL, of the service computer system.

The user detects this optical pattern with an optical sensor of his user computer system, for example with the help of the camera on his smartphone. The optical pattern is then decoded and a transaction request is generated that includes the purchase price and the payee's account information. This transaction request is processed by the user Transfer 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 the delivery of the product selected by the user. For example, it is a product that can only be sold to adults, such as alcohol or cigarettes. In this case, the attribute specification includes the attribute "age". On the basis of this requirement, the service computer system receives a response from the ID provider computer system which contains this age information. The service computer system then checks whether the age specification fulfills a predetermined criterion, for example the age of majority, and if this is the case, the service computer system carries out the transaction by, for example, the purchase price from the user's account to the account of the user Is transferred to the payee. The service computer system then issues a confirmation signal to the vending machine, whereupon the latter then issues 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 details of the user and / or a pseudonym or an identifier of the user, such as his customer number.

Based on the receipt of the response from the ID provider computer system, the service computer system can determine which user has acquired the optical pattern from the terminal. Provided that this user is the debtor 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 by means of a database transaction , At a later point in time, the service computer system can then generate a corresponding invoice in order to bill the recorded consumption.

According to one embodiment of the invention, the service computer system generates an acknowledgment signal after the database transaction has been carried out, this acknowledgment signal being sent to the consumption meter. The consumption counter can then be reset.

According to one embodiment of the invention, the terminal is a third-party smartphone that 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, his bank details into the app. This information and the logical address of the service computer system are then output on the smartphone display as an optical pattern.

The corresponding transaction request then includes the purchase price and the account details of the third party. In this case, the attribute specification can relate, for example, to the user's personal information, by means of which the service computer system can access the previously registered account connection of the user. After receiving the response, the service computer system then carries out the transaction, that is to say the payment of the purchase price here, using the account information of the third party and the user. The service computer system then sends a confirmation signal to the smartphone of the third party, so that the third party is informed of the payment and delivers 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 till system of a supermarket.

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

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

According to a further embodiment of the invention, the service computer system is connected to the terminal via a communication channel that is 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 to the terminal.

According to 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, it being possible for the first session to be an http session or an https session. The user can enter a transaction request in 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 in 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 can be designed as a SAML request. The request, for example the SAML request, contains an attribute specification which specifies the attributes to be read out from the ID token for the execution of the transaction. These can be attributes which identify the user who is assigned to the ID token and / or which provide payment information, for example an account connection or credit card information, and / or attributes which relate to the ID token itself, such as its validity period, date of issue and / or the issuing organization or authority.

According to the invention, the request is transmitted from the service computer system to the ID provider computer system via the user 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 date of birth of the user if, for example, the legal age of the user is to be checked as a prerequisite for the execution of the transaction by the service computer system. The request also contains transaction data for specifying the transaction, that is to say, for example, a payment amount and account information, in particular the account details of the service computer system, to which payment is to be made. Furthermore, the request contains a Uniform Resource Locator (URL) of the ID provider computer system, which is to read the attributes from the ID token, and a URL of the service computer system for specifying a recipient for the response, which is the result of the request by the ID provider computer system is to be generated.

The service computer system generates an identifier for the request that uniquely identifies the request, e.g. 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 that is assigned to the service computer system.

On the basis of the transaction request, a website 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 website, but is not displayed.

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

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 set up as a protected communication connection, specifically with an encrypted transport layer, that is to say with Transport Layer Security (TLS), which is also referred to as Secure Sockets Layer (SSL), in particular as an https session.

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

The ID provider computer system then sends a message about the second session, which contains a logical address of the ID provider computer system and, for example, also the session ID of the third session. The Internet browser or the application program can call up the response to the previously forwarded request from this logical address at a later time. The logical address can be a uniform resource locator (URL) through which the response can be called up.

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

The ID provider computer system then transmits to the program the information about the third session that is required for reading out the attribute or attributes from the ID token. This information includes at least one certificate of the ID provider computer system, which contains an indication of reading rights of the ID provider computer system for reading 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 program of the user computer system then checks whether the read rights specified in the certificate are sufficient to permit read access by the ID provider computer system to the attribute or attributes to be read in accordance with the attribute specification of the request. If the reading rights of the ID provider computer system are sufficient, the following further steps are carried out:

1. a) A local connection is established between the reader of the user computer system and the ID token. In the case of an ID token with an interface with contacts, for example a chip card interface, this can be done by inserting the ID token into the reading device. In the case of an ID token with a contactless interface, such as an RFID or an 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 SmartCards.
2. b) The user authenticates himself against the ID token, for example by entering his personal identification number (PIN) or by entering other information, such as the registration of a biometric feature of the user. A session key is agreed when the user is authenticated against the ID token. In particular, a session key can be agreed using a Diffie-Hellman protocol.
3. c) A fourth session is then set up on the application layer, specifically between a program of the ID token and the ID provider computer system, this fourth session running over the local connection and the third session and an additional one on the application layer End-to-end encryption takes place using the session key agreed in step b.
4. d) The fourth session then involves mutual authentication of the ID token and the ID provider computer system, for example using a challenge-response protocol.
5. e) The attribute or attributes according to the attribute specification which the ID provider computer system received with the request are now read out from the ID token by the ID provider computer system over 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 encrypted over the fourth session, so that maximum security and trustworthiness with regard to the or read attributes is given.

The ID provider computer system then generates a response which contains the attribute or attributes read out and the identifier of the request and / or the additional information, specifically in accordance with the request response protocol to which the request is subject. So with a SAML request a SAML response is generated accordingly. The logical assignment of request and response, ie the so-called binding, is established here via the identifier of the request, which is also contained 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 identifier of the response, it is assigned to the request and thus to the requested transaction and then the transaction is carried out by the service computer system, that is to say, for example, a payment process is triggered 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, the Internet browser being a conventional browser program, such as Microsoft Internet Explorer, Safari, Google Chrome or Firefox can. Alternatively, the program of the user computer system can be an application program that is separate from the Internet browser.

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

The so-called clearing, that is, the checking of the customer's creditworthiness, as well as the initiation of the payment process, is 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 have to be aware of the payment information of the user, that is to say in particular his account details.

According to a further embodiment of the invention, the computer system includes a terminal, such as an automated teller machine or a vending machine. The user can enter a request into the machine, such as withdrawing cash or buying 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 that contains information to initiate the execution of the transaction.

According to a further embodiment of the invention, the terminal can be used as a mobile telecommunication device, in particular as a so-called smart meter, for charging e.g. of electricity or gas consumption, taximeter or smartphone with a fee entry function.

For example, the URL of the service computer system, the payment amount and the payment recipient can be output in the form of an optically recorded pattern on the smartphone of a seller and recorded with the camera of the user computer system, which can also be designed as a smartphone. In this way, everyday payment transactions can be carried out 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 performing a method according to the invention.

Elements of the following figures that are identical to 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 storage area 120 of the ID token 106 serves to store a reference value, which is used to authenticate a user 102 towards the ID token 106 is needed. 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 is used to authenticate the user against the ID token 106 can be used.

The protected area 122 is used to store a private key and the protected storage area 124 is used to store attributes, for example the user 102 , such as its name, place of residence, date of birth, gender, and / or attributes that contain the ID token themselves, such as the institution that created or issued the ID token, relate to the period of validity 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 memory area 126 to store a certificate. The certificate contains a public key that is in the protected storage area 122 stored private key is assigned. The certificate may have been created according to a public key infrastructure (PKI) standard, for example the X.509 standard.

The certificate does not necessarily have to be in the electronic store 118 of the ID token 106 be saved. 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 carry out program instructions 130 . 132 and 134 , The program instructions 130 are used for user authentication, ie for authenticating the user 102 towards the ID token.

When using a PIN, the user gives 102 his PIN for his authentication in the ID token 106 a, for example via the user computer system 100 , By executing the program instructions 130 is then on the protected memory area 120 accessed 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 applies 102 as authenticated.

Alternatively, a biometric feature of the user 102 detected. For example, the ID token has 106 for this purpose, a fingerprint sensor or a fingerprint sensor is attached to the user computer system 100 connected. From the user 102 Biometric data are collected by executing the program instructions 130 with those in the protected storage area 120 stored biometric reference data compared. If the user agrees sufficiently 102 The biometric data recorded with the biometric reference data applies to the user 102 as authenticated.

The program instructions 134 are used to execute the ID token 106 relevant steps of a cryptographic protocol for the authentication of an ID provider computer system 136 towards the ID token 106 , The cryptographic protocol can be a challenge-response protocol based on a symmetrical key or an asymmetrical key pair.

For example, the cryptographic protocol implements an extended access control method as specified by the international aviation authority (ICAO) for machine-readable travel documents (MRTD). The ID provider computer system authenticates itself by successfully executing the cryptographic protocol 136 towards the ID token and thereby assigns its read authorization to read those in the protected memory area 124 saved attributes. The authentication can also be mutual, ie also the ID token 106 must then face the ID provider computer system 136 authenticate using the same or a different cryptographic protocol.

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

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

Access to the protected memory area 124 Reading one or more of the attributes can only be done through the processor 128 of the ID token 106 done because of the protected memory area 124 as well as the other protected storage areas 120 . 122 not directly, for example, via a bus system with the interface 108 are connected, but only to the processor 128 , that is access via the interface 108 directly to the protected memory area 124 is already excluded in terms of circuitry. The processor alone 128 can read on the protected memory area 124 then access the read attributes via the interface 108 issue.

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

The user computer system has at least one processor 110 to execute an application program 112 , The application program 112 is trained to use a network interface 114 of the user computer system 100 over a network 116 to communicate. For example, the application program is an Internet browser or another specialized application program that is available over the network 116 can communicate, especially an HTML-capable application program.

The processor 110 is used to execute another program 113 , which is, for example, a plug-in for the application program 112 can act, for example, a browser plug-in when the application program 112 is designed as an Internet browser, or a program separate from the application program.

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

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

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 become the ID provider computer system 136 relevant steps of the cryptographic protocol performed. Overall, the cryptographic protocol is then executed by executing the program instructions 134 through the processor 128 of the ID token 106 and by executing the program instructions 146 through the processor 145 of the ID provider computer system 136 implemented.

The program instructions 148 are used to implement end-to-end encryption on the part of the ID provider computer system 136 , for example based on the symmetric key that is used to execute the cryptographic protocol between the ID token 106 and the ID provider computer system 136 has been agreed. In principle, any method known per se for agreeing the symmetrical key for 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 TrustCenter, so that the ID provider computer system 136 in combination with the need to authenticate the user 102 towards the ID token 106 the anchor of trust for the authenticity of the ID token 106 read attributes.

A service computer system 150 can be designed to receive an order or an order for a service or a product, in particular an online service. For example, the user 102 online over the network 116 open an account with a bank 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 for example, can purchase a cell phone or the like online. Furthermore, the service computer system 150 also be designed to deliver digital content, for example for downloading music and / or video data.

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

Depending on the type of product or service ordered or ordered, the service computer system 150 one or more attributes of the user 102 and / or its ID token 106 check using one or more specified criteria. The order or the order of the user will only be accepted if this test is passed 102 received 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. Nur dann, wenn diese Leserechte ausreichend sind, werden die folgenden Schritte durchgeführt:
  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. Durch Ausführung der Programminstruktionen 178 wird dann von dem ID-Provider-Computersystem 136 die Response 174, beispielsweise ein SAML-Response, auf dem Request 166 erzeugt. Die Response 178 beinhaltet die zuvor über die vierte Session 240 aus dem ID-Token 106 ausgelesenen Attribute, die Zusatzinformation 168 oder - alternativ - nicht die Zusatzinformation 168, sondern nur das Chiffrat der Zusatzinformation 168, sowie die Kennung 180, die das Dienst-Computersystem 150 initial für den Request 166 vergeben hat. Die Response 174 wird von dem ID-Provider-Computersystem 136 mit Hilfe des privaten Schlüssels 142 signiert und dann in dem Speicher 140 gespeichert, so dass die Request 166 von der logischen Adresse abrufbar ist.
• - 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.

An electronic transaction can be carried out as follows:

• - The user 102 starts the application program 112 of the user computer system, it being assumed below without restriction of generality that it is this is an internet browser. The user 102 gives a URL of the service computer system 150 in the Internet browser, so that there is a first session 201 between the internet browser 112 and the service computer system 150 over the network 116 is built up. The user can then go through the first session 201 one from the service computer system 150 Request the service offered, such as ordering a product, requesting data for download or requesting a financial transaction. For this, the Internet browser 112 a corresponding transaction request 158 to the service computer system 150 sent, which signals this request.
• The service computer system therefore receives a transaction request from the Internet browser over the first session 158 of the user 102 ,
• - Due to the receipt of the transaction request 158 about the first session 201 creates the service computer system 150 a request 166 , The request 166 includes (i) an attribute specification of the attributes to be read from the ID token for the execution of 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 of the ID token 106 is available to act. The request further includes (ii) the transaction data for specifying the transaction, such as a payment amount, for the purchase of the ordered product or the performance of the ordered service to the service computer system 150 or payable to a third party, and / or other transaction data specifying the transaction to be performed. The request also includes (iii) an identifier 180 of the request, for example a GUID, for the so-called binding of the request and a response received thereupon 174 is required. The service computer system can be used to generate the identifier 150 have a GUID generator. 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 from the service computer system 150 signed, namely with the help of a private key of the service computer system 150 , With the request 166 it can be a SAML request or another request of a request response protocol.
• - In response to the transaction request 158 then sends the service computer system 150 a website 160 about the first session 201 to the user computer system 100 , the website 160 an input field 162 for entering additional information by the user 102 for the transaction and also an input element 164 that the user 102 for example by clicking if the website 160 through the internet browser 112 is reproduced to forward the request 166 to allow. Together with the website 160 also the request 166 about the first session 201 to the internet browser 112 transfer.
• - Due to the receipt of the website 160 and the request 166 becomes the website 160 through the internet browser 112 reproduced so that the user 102 the additional information in the input field 162 can enter. For example, the additional information is an account connection of the user 102 , a user's credit card number 102 or other additional transaction data and / or authentication information to prove the authorization of the user 102 for the execution of the transaction, for which the user 102 for example, a one-time password (OTP) in the input field 162 enters. It is preferred by the user 102 Additional information entered 168 with the public key of the service computer system 150 through the user's computer system 100 encrypted to get a corresponding ciphertext.
• - Then there is a second session 202 between the internet browser 112 and the ID provider computer system 136 over the network 116 built, using the URL of the ID provider computer system 136 that the user computer system 100 with the request 166 has received. The second session 202 is set up with a secure transport layer, for example as an https session.
• - About the second session 202 become the request 166 and the additional information 168 or only that with the help of the public key of the service computer system 150 cipher of additional information obtained 168 from the user computer system 100 to the ID provider computer system 136 forwarded.
• - Due to the receipt of the request 166 through the ID provider computer system 136 creates this by executing its program instructions 170 a session ID for a third session to be set up 203 , The request 166 and the additional information 168 are in the store 140 of the ID provider computer system 136 saved.
• - The ID provider computer system 136 then generates a message 172 which is the session ID for establishing the third session 203 and contains a logical address. Using the logical address can be that of the ID provider computer system 136 based on the request 166 Response to be generated 174 be retrieved. In particular, the logical address can be designed as a URL. The message 172 is about the second session 202 from the ID provider computer system 136 to the internet browser 112 Posted.
• - Due to the receipt of the message 172 becomes the third session 203 between the program 113 of the user computer system 100 and the ID provider computer system 136 via the secured transport layer of the second session 202 built up. For example, the program 113 a browser plug-in of the internet browser 112 , Alternatively, the program 113 also act as another application program. It is also possible to use the functionalities of the Internet browser 112 and that of the program 113 to implement in a program.
• - About the third session 203 then at least becomes the certificate 144 to the program 113 transfer.
• - Through the program 113 it is then checked whether the in the certificate 144 specified read rights are sufficient to provide read access to the ID provider computer system 136 to the one or more according to the attribute specification specified in the request 166 is included to allow attributes to be read. The following steps are only carried out if these read rights are sufficient:
  1. a) There will be a local connection 176 between the interfaces 104 and 108 built up. For example, appears on the screen of the user computer system 100 a request for the user 102 to insert the ID token 106 into a reader of the user computer system 100 which is the interface 104 or to hang up the ID token 106 to a contactless trained interface 104 ,
  2. b) The user 102 then authenticates itself to the ID token, for example by entering its PIN in the user computer system 100 or its reader. The user can be authenticated using a cryptographic protocol, for example by means of a challenge-response protocol or based on a Diffie-Helman key exchange, a session key being agreed as part of the authentication of the user.
  3. c) Provided the user is successfully authenticated, a fourth session is held 204 between the ID token 106 and the ID provider computer system 136 established, 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 in step b) when authenticating the user.
  4. d) The fourth session then carries out mutual authentication of the ID token 106 and the ID provider computer system 136 with the help of the respective private key, that is to say that in the protected memory area 122 stored private key of the ID token 106 and the private key 142 of the ID provider computer system 136 , The certificates of the ID token can be used for this mutual authentication 106 from the storage area 126 (see 1 ) as well as the certificate 144 of the ID provider computer system 136 be exchanged over the fourth session.
  5. e) Provided the user is successfully authenticated against the ID token and the mutual authentication of the ID token is successful 106 and the ID provider computer system 136 then reads the ID provider computer system 136 the attribute or attributes according to the attribute specification from the ID token 106 from, the attributes by the end-to-end encryption in the transmission of the ID token 106 to the ID provider computer system 136 to be protected. For this purpose, the ID provider computer system sends over the fourth session 204 a read command for the fourth session to the ID token 106 , The read command 182 contains the attribute specification, i.e. the selection of those attributes that come from the protected memory area 124 of the ID token 106 should be read out. By executing the program instructions 178 is then from the ID provider computer system 136 the response 174 , for example a SAML response, on the request 166 generated. The response 178 includes the previous one over the fourth session 240 from the ID token 106 read attributes, the additional information 168 or - alternatively - not the additional information 168 , but only the code of the additional information 168 , as well as the identifier 180 that the service computer system 150 initial for the request 166 has forgiven. The response 174 is from the ID provider computer system 136 using the private key 142 signed and then in the store 140 saved so the request 166 can be called up from the logical address.
• - The user computer system 100 , such as its Internet browser 112 , then read the response using the logical address 174 for example about the second session 202 from memory 140 ,
• - The response 174 is then from the user computer system 100 , for example from the Internet browser 112 , about the first session 201 to the service computer system 150 forwarded. It can be provided that the user 102 from the internet browser 112 prompted for confirmation before the response 174 is forwarded to the service computer system. It can also be provided that the content of the response from the Internet browser 174 is displayed 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 verify the accuracy of this data before sending it to the service computer system 150 forwarded to complete the transaction.
• - The service computer system 150 arranges the response received 174 the request 166 based on the matching identifiers 180 of the request 166 and the response 174 to.
• - The service computer system 150 then checks the signature of the response 166 and reads the required attribute or attributes from the response 174 out. The attributes are then used to check whether the requested transaction can be carried out by comparing the attribute or attributes with one or more predefined criteria. These criteria can be, for example, the age or creditworthiness of the user 102 act. The attribute can also be a pseudonym of the user 102 act with the help of which the service computer system 150 then one in a database of the service computer system 150 stored attribute of the user 102 , such as reading a delivery address. The check criterion here is whether a user with the in the response 174 included a pseudonym on the part of the service computer system 150 is registered. Results in the check of the service computer system 150 that the transaction is feasible, the transaction is based on the transaction data and the additional information 168 carried out.

For example, the program 113 a browser plug-in, which is registered in a registry of an operating system of the user computer system with a plug-in identifier, the operating system being a Windows operating system, Android or iOS, for example. In this case, the message includes 172 from the ID provider computer system to the Internet browser 112 this plug-in identifier 184 so the plug-in 113 is started based on the receipt of the message.

In another example, the program is 113 one from the internet browser 112 separate application program, such as a so-called citizen app or ID card app. This application program 113 is from the internet browser 112 started by calling a local URL, the local URL containing a fixed port number according to the TCP protocol. This local URL is shared with the website 160 from the service computer system 150 to the user computer system 100 transmitted and that over the first session 201 to start the application program 113 using the local URL through the internet browser 112 to effect.

In the event that only the cipher of the additional information 168 , but not the additional information 168 even about the second session 202 from the user computer system 100 to the ID provider computer system 136 is transmitted also includes the response 174 only this cipher, but not the additional information 168 itself. In this case, the service computer system decrypts 150 the cipher with the help of the private key of the service computer system 150 to then use the additional information 168 to complete the requested transaction. This can be, for example, the execution of a financial transaction, such as the execution of a transfer in the amount of the payment amount, which is in the additional information 168 is specified.

Alternatively, however, it is also possible for the ID provider computer system to carry out the payment 136 is triggered. This can be done so that the ID provider computer system 136 the transaction data required for this via the request 166 and the additional information 168 receives and then makes or initiates the payment. The response 174 then includes confirmation of the ID provider computer system 136 that the payment has been made.

A transmission of the additional information 168 to the service computer system 150 can then be omitted, what to protect the confidentiality of this additional information 168 is advantageous because this additional information 168 then only have to face the trusted ID provider computer system 136 be disclosed. The actual transaction, such as the delivery of the ordered product, is then made after receipt of the payment confirmation, which is in the response 174 is included by the service computer system 150 causes.

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

A terminal belongs to the computer system 186 , which can be, for example, an automatic machine, in particular an automated teller machine or vending machine. For example, the user 102 into the terminal 186 enter a cash amount to withdraw cash from his account. On a display 188 The machine then displays an optically detectable pattern, such as a QR code, which is a URL of the service computer system 150 as well as that of the user 102 includes the desired amount of money.

This optical pattern is from the display 188 with the help of a camera 190 of the user computer system 100 detected. The user computer system 100 then generates the transaction request 158 that indicates this amount of money. The first session 201 is here with the help of the URL of the service computer system captured from the optical pattern 150 built and the transaction request 158 with the desired amount of money will go through this first session 201 to the service computer system 150 transmitted. The service computer system 150 then generates a corresponding request 166 to the attributes and additional information required for the payment of the desired amount of money 168 query.

Then either through the ID provider computer system 136 or through the service computer system 150 the debiting of a user's account 102 which of these, for example, in the additional information 168 has specified. Due to the receipt of the response 174 and the terminal then receives the initiation of payment 186 a signal to issue the desired amount of money, for example in the form of cash or to top up a user's cash card 102 , This can be done so that the terminal 186 directly with the service computer system 150 connected or over the network 116 ,

Alternatively, it can be at the terminal 186 also act as a vending machine, in which case no cash, but a desired product, such as a beverage can or a cigarette pack, is dispensed by the vending machine after the payment has been made by the service computer system 150 has been signaled.

In another application, the terminal can 186 act as a mobile telecommunication device, in particular a smartphone. If the user 102 by the owner of the terminal 186 wants to buy something, says the owner of the terminal 186 the corresponding purchase price in the terminal 186 on so that then on the display 188 in the form of the optically detectable pattern, this purchase price as the payment amount and the URL of the service computer system 150 is issued. After the transaction is completed, the terminal receives 186 from the service computer system 150 a signal which indicates that the payment process has been carried out and the owner of the terminal 186 then gives the goods to the user 102 from. This can also be implemented in the checkout system, for example of a supermarket. Another application is a taximeter, which records taxi fees, 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 NUMBERS

100

User computer system

102

user

104

interface

106

ID token

108

interface

110

processor

112

Application / Internet browser

113

Program / application program

114

Network interface

116

network

118

electronic memory

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

message

174

response

176

local connection

178

program instructions

180

ID

182

read command

184

ID

186

terminal

188

display

190

camera

Claims (18)

Electronic transaction method using an ID token (106) which is assigned to a user (102), the ID token having an electronic memory (118) with a protected memory area (124) in which one or more attributes are stored, The protected memory area can only be accessed via a processor (128) of the ID token, and 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, which contains at least one logical address of a service computer system (150) and transaction data, Pattern using an optical sensor (190) of the user computer system and decoding of the pattern by the user computer system, - construction of a first Session (201) between an application program (112) of the user computer system, and the service computer system (150) via the network (116), - the application computer receives a transaction request (158) for the first session via the service computer system ( 112), the transaction request containing the transaction data, - generation of a request (166) by the service computer system on the basis of the receipt of the transaction request, the request being signed by the service computer system and the request an attribute specification from the ID token for the execution of the transaction includes attributes to be read out, 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 website (160) and the request via the first session from the service computer system to the user computer system, the web page providing an input efeld (162) for entering additional information (168) for the execution of the transaction, - displaying the website by the application program and entering the additional information by the user in the input field, - establishing 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, the second session being set up with a secure transport layer, forwarding the request and the additional information from the application program to the ID provider computer system via the second session, - due to 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 one en address via the second session, - establishment of the third session between a program (113) of the user computer system and the ID provider computer system via the secured transport layer of the second session, the program being able to be different from the application program (112), - Transmission of at least one certificate (144) of the ID provider computer system to the program (113), the certificate including an indication of reading rights of the ID provider computer system for reading one or more of the attributes stored in the ID token, wherein the certificate is transmitted via the third session, - the program (113) checks whether the read rights specified in the certificate are sufficient to permit read access by the ID provider computer system to the attribute or attributes to be read in accordance with the attribute specification , and only if the reading rights are sufficient: a) establishing a local connection (176) between the reading device of the user computer system and the ID token, b) authentication of the user against the ID token, a session key being 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 one end e-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 of the attribute or attributes according to the attribute specification by the ID provider computer system the fourth session from the ID token, - generation of a response (174) which contains the attribute or attributes read out and at least the identifier (180) of the request and which is signed by the ID provider computer system, - storage of the response to retrieve using the logical address, - reading the response from the ID provider computer system by the user computer system by retrieving the response by means of a read command from the logical address via the network, - forwarding the response by the user computer system via the first session to the service computer system, - assignment of the response to the request by means of the identifier contained in the response by the service computer system stem, - Execution of the transaction using the response by the ID provider computer system, 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 contain a payment amount, wherein the payment is initiated by the ID provider computer system, and the response does not include the payment information of the user. Procedure according to Claim 1 , with the further step of checking whether the attribute or attributes fulfill a predetermined criterion by the service computer system, the transaction being carried out only if the criterion is fulfilled. Procedure according to Claim 1 or 2 , wherein the transaction data includes an amount of payment, and wherein the transaction is initiated by the service computer system to carry out a financial transaction in the amount of the amount of payment. Procedure according to Claim 3 , wherein the terminal is a bank terminal for paying out cash or topping up a cash card, the user selects the payment amount by inputting it into the bank terminal, and an account of the user is debited due to the financial transaction in the amount of the payment amount, whereupon the service computer system sends a confirmation signal to the bank terminal, and the bank terminal uses the confirmation signal to pay out the cash in the amount of the payment or to top up the cash card in the amount of the payment. Procedure according to Claim 3 , wherein the terminal is an automatic vending machine, the payment amount being a sales price for a product that can be dispensed by the automatic vending machine, the service computer system initiating the financial transaction in order to add an account to the user in the amount of the payment amount load, whereupon the service computer system transmits a confirmation signal to the vending machine, and the vending machine delivers the product based on the receipt of the confirmation signal. Procedure according to Claim 3 , the terminal being a taximeter, the payment amount being a transportation fee for a taxi ride, the service computer system initiating the financial transaction to debit an account of the user with the payment amount, whereupon the service -Computer system transmits an acknowledgment signal to the taximeter, and the taximeter issues a receipt for the payment of the taxi ride based on the receipt of the actuation signal. Method according to one of the preceding claims, wherein the terminal is a smartphone, the optically readable pattern including an account connection of an owner of the smartphone, the service computer system initiating the financial transaction to transfer the payment amount to the account of the owner of the To transfer smartphones, whereupon the service computer system transmits a confirmation signal to the smartphone, which is output by the smartphone via a user interface in order to inform the owner 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 detected by the consumption counter, wherein the service computer system carries out the transaction in the form of a database transaction in order to store the consumption level. Method according to one of the preceding Claims 4 to 7 the acknowledgment signal being sent over the network from the service computer system. Procedure according to Claim 9 , wherein the confirmation signal is sent to the user computer system and is output by the user computer system as an optical pattern, the terminal being designed to detect the optical pattern from the user computer system. Procedure according to Claim 1 , wherein the application program is an Internet browser, and the further program is a plug-in of the Internet browser, the plug-in being 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 due to the receipt of the message. Procedure according to Claim 1 or 11 , wherein the program is another application program that can be started by the Internet browser by calling up a local URL, the local URL containing a fixed port number according to the TCP protocol, the local URL together with the website is transmitted from the service computer system to the user computer system in order to cause the further application program to be started using the local URL by the Internet browser. Procedure according to Claim 1 . 11 or 12 , the additional information being payment information from the user. 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 order of several such codes. Method according to one of the preceding claims, wherein the ID token is a value or security document. 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), the ID token having an electronic memory (118) with a protected memory area (124) in which one or more attributes are stored, the protected memory area being accessible only via a processor (128) of the ID token, and wherein the ID token has a communication interface (108) for communicating with a reader of a user computer system (100), the terminal, the service computer system, the user computer system, the ID provider computer system and the ID Tokens are designed to carry out the following steps: - display of an optically readable pattern on a screen (188) of a terminal (186), wherein information that encodes at least one logi 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, - establishment of a first session (201) between an application program ( 112) of the user computer system, and the service computer system (150) via the network (116), - the application computer (112) receives a transaction request (158) via the first session from the service computer system, wherein the transaction request contains the transaction data includes - generation of a request (166) by the service computer system on the basis of the receipt of the transaction request, the request being signed by the service computer system and the request an attribute specification of the attributes, transaction data, to be read out from the ID token for the execution of the transaction to specify the transaction, an identifier (180) of the request, a U RL of an ID provider computer system and a URL of the service computer system includes - transmission of a website (160) and the request via the first session from the service computer system to the user computer system, the website providing an input field (162) for Entering additional information (168) for executing the transaction, - displaying the website by the application program and entering the additional information by the user in the input field, - establishing a second session (202) between the application program (112) and the ID provider -Computer system over the network using the URL of the ID provider computer system, 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, - due to the receipt of the request, generation of a session ID for a third session (203) 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 one Address via the second session, - establishment of the third session between a program (113) of the user computer system and the ID provider computer system via the secured transport layer of the second session, the program being able to differ from the application program (112), Transmission of at least one certificate (144) of the ID provider computer system to the program (113), the certificate being an A Specification of reading rights of the ID provider computer system for reading one or more of the attributes stored in the ID token, wherein the transfer of the certificate takes place over the third session, - Check by the program (113) whether the in the certificate specified reading rights are sufficient to allow read access by the ID provider computer system to 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 reading device of the user Computer system and the ID token, b) authentication of the user against the ID token, a session key being agreed, c) establishment of a fourth session (204) between the ID token and the ID provider computer system via the local one 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 systems via the fourth session, e) reading out the attribute or attributes in accordance with the attribute specification by the ID provider computer system via the fourth session from the ID token, - generating a response (174) which contains the attribute or attributes read out 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 retrieval the response by means of 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 using the identifier which is contained in the response , by the service computer system, - execution of the transaction using the response by the ID provider computer system, the request being a payment Formation of the service computer system and wherein the additional information includes payment information of the user, and wherein the transaction data of the request contain a payment amount, the payment being initiated by the ID provider computer system, and the response does not include the payment information of the user. Computer system after Claim 16 , the terminal being an automatic machine. Computer system after Claim 16 or 17 , wherein the terminal is a mobile telecommunication device with a charge recording function, or a consumption counter for recording a consumption value.

Images