EP3014540A1 - Elektronisches transaktionsverfahren und computersystem - Google Patents

Elektronisches transaktionsverfahren und computersystem

Info

Publication number
EP3014540A1
EP3014540A1 EP14726573.0A EP14726573A EP3014540A1 EP 3014540 A1 EP3014540 A1 EP 3014540A1 EP 14726573 A EP14726573 A EP 14726573A EP 3014540 A1 EP3014540 A1 EP 3014540A1
Authority
EP
European Patent Office
Prior art keywords
computer system
user
token
transaction
request
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP14726573.0A
Other languages
English (en)
French (fr)
Inventor
Frank Dietrich
Manfred Paeschke
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Bundesdruckerei GmbH
Original Assignee
Bundesdruckerei GmbH
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Bundesdruckerei GmbH filed Critical Bundesdruckerei GmbH
Publication of EP3014540A1 publication Critical patent/EP3014540A1/de
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3274—Short range or proximity payments by means of M-devices using a pictured code, e.g. barcode or QR-code, being displayed on the M-device
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07C—TIME OR ATTENDANCE REGISTERS; REGISTERING OR INDICATING THE WORKING OF MACHINES; GENERATING RANDOM NUMBERS; VOTING OR LOTTERY APPARATUS; ARRANGEMENTS, SYSTEMS OR APPARATUS FOR CHECKING NOT PROVIDED FOR ELSEWHERE
    • G07C9/00—Individual registration on entry or exit
    • G07C9/20—Individual registration on entry or exit involving the use of a pass
    • G07C9/22—Individual registration on entry or exit involving the use of a pass in combination with an identity check of the pass holder
    • G07C9/25—Individual registration on entry or exit involving the use of a pass in combination with an identity check of the pass holder using biometric data, e.g. fingerprints, iris scans or voice recognition
    • G07C9/257—Individual registration on entry or exit involving the use of a pass in combination with an identity check of the pass holder using biometric data, e.g. fingerprints, iris scans or voice recognition electronically

Definitions

  • the invention relates to an electronic transaction method and a computer system.
  • the object of the invention is to provide an improved electronic transaction method and a corresponding computer system.
  • a “transaction” here means a financial transaction, such as the payment of a payment by making a transfer, direct debit or credit card debit, an ordering process for the ordering and delivery of a physical good or data, and other logistic, trade and / or or financial transactions and / or a database transaction, for example, for storing a value, such as a consumption value, a credit, or a payment amount.
  • Terminal is here understood to mean a device which has a display, ie a screen, for displaying a has optical pattern. The terminal can only capture information and output via the display, or it can have a user interface for inputting a selection of a user.
  • the terminal may be designed as a cash machine or vending machine.
  • the user may enter a request into the terminal, such as to withdraw cash, charge a cash card, or purchase a particular product, such as a drink.
  • the automaton displays an optically detectable pattern, such as a QR code, on its screen in response to this user request, the pattern containing information to initiate the transaction execution. This may be the desired cash amount or the purchase price of the product.
  • the terminal is designed as a telecommunication device, as a so-called smart meter, for the billing of, for example, electricity or gas consumption, taximeters or smartphones with a billing function.
  • a “pattern” is here understood to mean a static optical pattern which is output on the display of the terminal and into which information is coded, for example a barcode, in particular a one-dimensional, two-dimensional, high-capacity color barcode, MaxiCode, QR code or DataMatrix code, or a temporal order of several patterns, whereby the patterns and their chronological order encode information, as is the case, for example, with a flicker code
  • the "flicker code” is in itself for the so-called chipTAN-comfort or smart-code TAN-optic online banking procedures of the savings banks and hidingbanks known.
  • a “session” here means 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 ("transport layer”) or the application layer (“application layer”) a session is an http session or an https session, whereby in the latter case the transport layer is protected by symmetric encryption.
  • transport layer transport layer
  • application layer application layer
  • ID token here is understood in particular to mean a portable electronic device which has at least one data memory for storing the at least one attribute and a communication interface for reading out the attribute of the at least one attribute in order to prevent the attribute stored in the memory area from being altered in an unauthorized manner or read out without the authorization required for this purpose, in particular the ID token may be a USB stick or a document, in particular a
  • a "document” means paper-based and / or plastic-based documents, in particular electronic sovereign documents, such as, for example, electronic identification documents, in particular passports, personal ID cards, visas and driver's licenses, vehicle registration documents, vehicle letters, company ID cards, health cards or other ID documents as well as chip cards, means of payment, in particular banknotes, bank cards and credit cards, waybills or other credentials, 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 bound to a hardware token, that is to say to a so-called secure element, for example.
  • a J D provider computer system 1 is here understood to mean a computer system which is designed to read out at least one attribute from the ID token of a user.
  • the ID provider computer system is operated in a so-called trust center to provide 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 an internet browser or another application program can be used to access web pages stored or generated by the service computer system the service computer system is an Internet server for the provision of an e-commerce or e-government 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, 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 Inter- net Explorer, Safari, Google Chrome, Firefox or any other application to access the service computer system.
  • the user computer system has an interface for connection to the network, wherein the network may be a private or public network, in particular the Internet.
  • the request of the service computer system is a SAML request and the response of the ID provider computer system to this is a SAML response (see Security Assurance Markup Language (SAML) V2. 0 Technical Overview, OASIS, Committee Draft 02, March 25, 2008).
  • SAML Security Assurance Markup Language
  • 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 as a digital certificate, which is also referred to as a public-key certificate, which is a structured data that serves to identify a public key of an asymmetric cryptosystem of an identity, such as
  • the certificate may conform to the X.509 standard or another standard, and preferably, the certificate is a Card Verifiable Certificate (CVC)
  • CVC Card Verifiable Certificate
  • the attribute or attributes of the user stored in the protected storage area of the ID token entitle the ID provider computer system to perform the read access, which attributes may be personal attributes of the user, such as his name , Place of residence and age. These attributes can be used in their combination as user recognition be used to access the payment information of the registered user.
  • a pseudonym of the user which is stored at least temporarily by the ID token, can also be used as the user identifier.
  • Embodiments of the invention are particularly advantageous since a computer-implemented payment method that is suitable universally and also for e-commerce and e-government applications is created, which is at the same time flexible, easy to handle and secure. This is made possible, in particular, by the fact that the payment method is based on an ID token, whereby the prerequisite for the performance of a payment transaction is both the authentication of the user to the ID token and the authentication of the ID provider computer system to the ID token is.
  • the terminal is a device, for example for the payment of cash, for charging a cash card for the sale of a product, such as a ticket, a ticket or a food or beverage.
  • the terminal may be a cash dispenser.
  • the user enters a desired payout amount via a user interface of the cash machine.
  • This payout amount is then displayed on the screen as an optically readable pattern by the cash dispenser, and this pattern is detected by the user using an optical sensor, such as the camera of the user computer system, which may be a smartphone.
  • the pattern displayed on the screen may further include a logical address of the service computer system, such as a URL of the service computer system.
  • further information may be included in the pattern, such as account information of the operator of the ATM.
  • the user computer system decodes the pattern acquired from the screen of the terminal using the optical sensor and then generates a transaction request indicating the amount of payout and, if applicable, the other transaction data included in the pattern.
  • This transaction request is then transmitted from the user computer system to the service computer system via 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 out of the ID token, which is required for the execution of the transaction and / or which has to fulfill a predetermined checking criterion so that the Transaction can be performed.
  • the attribute may be a user's account account stored in the ID token or a user's pseudonym which serves as the access key to pseudonymized account information of registered users for the service computer system.
  • the attribute may be an age indication to verify that the user has the business skills required to complete the transaction.
  • the service computer system then sends the request to the 1D provider computer system.
  • the at least one attribute is then read from the ID token by the I D provider computer system via the Network with end-to-end encryption.
  • the I D provider computer system then generates a response that includes the at least one attribute read from the ID token.
  • the attributes and / or the response are signed by the 1D provider computer system and sent to the service computer system.
  • the service computer system then uses the attributes to perform the transaction, that is, for example, debiting the user's account with the payout amount, and / or verifying that a given criterion, eg, business ability, is met.
  • the service computer system After this debit of the account has occurred, the service computer system generates an acknowledgment signal, which is transmitted at the bank terminal.
  • the terminal that is to say the ATM here, is connected to the network so that the acknowledgment signal is transmitted from the service computer system via the network to the terminal.
  • Vorzugswei- the signing signal is signed by the service computer system to avoid tampering. Due to the receipt of a valid confirmation signal then takes place the issue of cash in the amount of the desired payout amount or alternatively the charging of a cash card of the user.
  • the terminal is designed as a vending machine.
  • a user interface of the vending machine allows the user to select a desired product.
  • the vending machine will then display on its display an optical pattern in which the purchase price of the selected by the user! product, as well as the account information of the account to which payment of this purchase price must be made.
  • the optical pattern includes the indication of a logical address, in particular a URL, of the service computer system.
  • the user captures this optical pattern with an optical sensor of his user computer system, for example using the camera of his smartphone.
  • the optical pattern is then decoded and a transaction request is generated that includes the payee's purchase price and account information. This transaction request is received from the user computer system
  • the service computer system then generates a request with the attribute specification of that required to deliver the product selected by the user
  • the service computer system receives a response from the 1D provider computer system that includes this age.
  • the service computer system carries out the transaction by, for example, transferring the purchase price from the user's account to the payee's account. Subsequently, the service Computer system from a confirmation signal from the vending machine, whereupon this then delivers the product previously selected by the user.
  • the terminal is designed as a consumption counter, in particular for detecting a consumption of electricity or gas.
  • an optical pattern is displayed on the display of the terminal, which includes the current meter reading and, for example, a counter number of the consumption meter and also the logical address of the service computer system.
  • the corresponding transaction request then contains this count as well as the counter number.
  • the attribute specification of the service computer system may specify, for example, personal information of the user and / or a pseudonym or an identifier of the user, such as the customer number. Due to receipt of the response from the ID provider computer system, the service computer system may determine which user has captured the optical pattern from the terminal.
  • the service computer system stores the count reported with the transaction request and the associated counter number in a database by means of a database Transaction. At a later time, a corresponding invoice can then be generated by the service computer system in order to settle the recorded consumption.
  • the service computer system generates an acknowledgment signal after the database transaction has been executed, sending this acknowledgment signal to the utility meter. The consumption meter can then be reset.
  • the terminal is a smartphone of a third party who wishes to sell the product to the user.
  • the smartphone has an app that starts the third party. In the app, the third party enters the purchase price and, for example, his bank account. This information as well the logical address of the service computer system are then output on the display of the smartphone as an optical pattern.
  • the corresponding transaction request then includes the purchase price and the account details of the third party.
  • the attribute specification in this case may, for example, relate to the personal information of the user by means of which the service computer system can access the previously registered account connection of the user.
  • the service computer system After receipt of the response, the service computer system then carries out the transaction, that is, the payment of the purchase price, using the account information of the third party and the user.
  • the service computer system then sends an acknowledgment signal to the third party's smartphone so that it is informed of the payment made and delivers the product to the user.
  • the terminal is designed as a taximeter.
  • the optical pattern includes a fare that bills a taxi driver for a taxi ride.
  • the taximeter Upon receipt of the confirmation signal from the service computer system confirming the execution of the corresponding payment, the taximeter outputs a corresponding receipt, that is, an acknowledgment.
  • the terminal has a network interface for communication over the network.
  • the acknowledgment signal may be transmitted from the Dtenst computer system over the network to the vending machine.
  • the acknowledgment signal is sent from the service computer system to the user computer system.
  • the user computer system may then display on a display of the user computer system an optical pattern in which this confirmation is encoded.
  • This optical pattern can then be detected by the terminal, which also has an optical sensor.
  • This embodiment has the advantage that the terminal does not need to be connected to the network, which has safety advantages.
  • the service computer system is connected to the terminal via a communication channel other than the network, such as an internal corporate network or a virtual private network via which the acknowledgment signal is transmitted from the service computer system to the terminal.
  • a first session is first established between the internet browser of the user computer system and the service computer system via the Internet, wherein the first session may 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.
  • the user has previously ordered a product via the service computer system and would like to pay for this ordered product, for which purpose 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, ie a request for a request-response protocol.
  • the request can have a predefined or standardized structure.
  • the request may be text-based, have an XML, ASN.1 or binary structure or be configured as a SAML request.
  • the request for example the SAML request, contains an attribute specification which specifies the attributes to be read from the ID token for the execution of the transaction. These may be attributes that identify the user associated with the ID token and / or that provide payment information, such as an account or credit card information, and / or attributes that include the ID token itself such as the period of validity, the date of issue and / or the issuing organization or authority.
  • the request is transmitted from the service computer system via the user computer system to the ID provider computer system. Due to the receipt of the request by the user computer system, the further procedure for generating the response, including the authentication of the user and the ID provider computer system, is triggered.
  • the attribute specification may include the date of birth of the user if, for example, the age of majority of the user is to be verified by the service computer system as a prerequisite for the transaction to be performed.
  • the request also contains transaction data for specifying the transaction, that is, for example, a payment amount and account information, in particular the account connection of the service computer system on which the payment is to be made.
  • the request includes 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 based on the request from the ID provider computer system is to generate.
  • the service computer system generates an identifier for the request which uniquely identifies the request, e.g. a globally unique identifier (GUID). The request contains this identifier.
  • GUID globally unique identifier
  • the request is signed by the service computer system using a private key of a cryptographic key pair associated with the service computer system.
  • a web page is transmitted from the service computer system to the user computer system via the first session and displayed by the internet browser or the application program, in particular a so-called app. Together with the website, the request is transmitted, but it is not displayed.
  • the website has at least one input field for inputting additional information which is required for carrying out the transaction.
  • This additional information may be, for example, an account or credit card information of the user and / or authentication information to authenticate the user to the service computer system.
  • the authentication information may be a one-time password (OTP).
  • OTP one-time password
  • the additional information is encrypted using the public key of the service computer system by the user computer system, so that only the encrypted additional information is subsequently forwarded via a second session from the Internet browser or the application program to the ID provider computer system via the network.
  • This request also forwards the request via this second session.
  • the structure of the second session is carried out by calling the URL of the I D provider computer system, which is included in the request.
  • the second session is set up as a protected communication connection, namely with an encrypted transport layer, ie with Transport Layer Security (TLS), which is also referred to as Secure Sockets Layer (SSL), in particular as an https session.
  • TLS Transport Layer Security
  • SSL Secure Sockets Layer
  • the ID provider computer system generates an identifier for a still-to-be-established third session due to the receipt of the request over the second session, i. a so-called session ID.
  • the ID provider computer system stores the request and the additional information received along with the request for 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 includes a logical address of the ID provider computer system and, for example, the session ID of the third session. From this logical address, the Internet browser or the application program can later retrieve the response to the previously forwarded request.
  • the logical address may be a uniform resource locator (URL) through which the response is retrievable.
  • the third session is established on the application layer between a program of the user computer system and the I D provider computer system, via the secured transport layer of the second session.
  • the program may be a browser plug-in of the Internet browser or an application program other than the Internet browser.
  • the I D provider computer system transmits to the program the third session information needed to read the attribute (s) from the ID token.
  • This information includes at least one certificate of the ID provider computer system, which includes an indication of read rights of the ID provider computer system for reading one or more attributes.
  • the program of the user computer system checks whether the read rights specified in the certificate are sufficient to allow read access by the ID provider computer system to the attribute (s) to be read according to the attribute specification of the request. If the reading rights of the ID provider computer system are sufficient, the following further steps are performed: 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 a contact-type interface, for example a chip card interface, this can be done by inserting the ID token into the reader.
  • a contact-type interface for example a chip card interface
  • an ID token with a non-contact interface such as an RFID or an N FC interface
  • this can be done by placing the ID token on the reader.
  • Tokens with USB, BlueTooth or microSD cards as well as virtual SmartCards are also possible here.
  • the user authenticates himself to the ID token, for example by entering his Personal Identification Number (PIN) or by entering other information, such as the detection of a biometric metric feature of the user.
  • PIN Personal Identification Number
  • a session key is agreed.
  • the agreement of a session key can be made using a Diffie-Hellman protocol.
  • a fourth session is set up on the application layer, 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 using the session key agreed in step b.
  • a mutual authentication of the ID token and the 1 D provider computer system takes place, for example by means of a challenge-response protocol.
  • the attribute or attributes according to the attribute specification, which the ID provider computer system has received with the request, are now read out of the ID token via the fourth session by the ID provider computer system. 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 a maximum of security and trustworthiness in terms of given attributes is given.
  • the ID provider computer system then generates a response that includes the read out attributes and the identifier of the request and / or the additional information according to the request-response protocol to which the request is subject. In the case of a SAML request, therefore, a SAML response is generated accordingly.
  • the identifier of the request which is also contained in the response, the logical assignment of request and response, ie the so-called binding, is established here
  • the response is signed by the I D provider computer system and stored for retrieval by 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, such as the URL, and forwards the response to the service computer system through the first session.
  • this is assigned to the request and thus to the requested transaction, and then the transaction is executed by the service computer system, that is, for example, triggering a payment transaction and / or delivering an ordered product, if the content of the response permits.
  • the program of the user computer system is a browser plug-in of the Internet browser, wherein the Internet browser is a common browser program such as Microsoft Internet Explorer, Safari, Google Chrome or Firefox can.
  • the program of the user computer system may be an application program separate from the Internet browser.
  • 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 should be debited or withdrawn.
  • the so-called clearing that is the examination of the creditworthiness of the customer, as well as the initiation of the payment process can then be initiated by the I D 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 has no knowledge of the payment information of the user, that is, in particular his account connection must obtain.
  • the user may encrypt his payment information with the public key of the service computer system so that only the encrypted payment information of the user is transmitted to the ID provider computer system.
  • the I D provider computer system then forwards the encrypted payment information with the response to the service computer system, which decrypts the payment information and then performs the clearing and collects the payment amount from the user's account according to the payment information.
  • the computer system includes a terminal, such as an ATM or a vending machine.
  • a terminal such as an ATM or a vending machine.
  • the user may enter a request into the machine, such as for withdrawing cash or purchasing a particular product, such as a drink.
  • the vending machine displays an optically detectable pattern, such as a QR code, on its screen containing information to initiate the transaction, in response to this user request.
  • the terminal is used as a mobile telecommunication device, in particular as a so-called smart meter, for billing e.g. of electricity or gas consumption, taximeter or smartphone with a billing function.
  • the URL of the service computer system For example, on the smartphone of a seller, the URL of the service computer system, the payment amount and the payee in the form of a visually recorded pattern and recorded with the camera of the user computer system, which may also be configured as a smartphone, are detected. In this way, everyday payment transactions can be processed safely and conveniently.
  • FIG. 1 shows a block diagram of an embodiment of an ID token according to the invention
  • Fig. 2 shows an arrangement of an embodiment of an inventive
  • FIG. 1 shows an ID token 106, which may be, for example, an electronic identity card.
  • the protected memory area 120 of the ID token 106 is used to store a reference value needed for authentication of a user 102 against the! D token 106.
  • This reference value is, for example, an identifier, in particular a so-called personal identification number (PIN), or reference data for a biometric feature of the user 102, which can be used for the authentication of the user against the ID token 106.
  • PIN personal identification number
  • the protected area 122 is for storing a private key
  • the protected memory area 124 is for storing attributes, such as user 102, such as name, place of residence, date of birth, gender, and / or attributes including the ID token itself, such as the institution that created or issued the ID token, the validity period of the ID token, an identifier of the ID token, such as a passport number or a credit card number.
  • the electronic memory 118 may also have a memory area 126 for storing a certificate.
  • the certificate includes a public key associated with the private key stored in the protected storage area 122.
  • the certificate may have been created according to a public key infrastructure (PKI) standard, for example according to the X.509 standard.
  • PKI public key infrastructure
  • the certificate does not necessarily have to be stored in the electronic memory 118 of the ID token 106.
  • the certificate can also be stored in a public directory server.
  • the ID token 106 has a processor 128.
  • the processor 128 is for executing program instructions 130, 132, and 134.
  • the program instructions 130 are for user authentication, that is, for authenticating the user 102 to the ID token.
  • the user 102 inputs his PIN to his authentication in the ID token 106, for example via the user computer system 100.
  • Execution of the program instructions 130 then accesses the protected memory area 120 to store the entered PIN with the PIN to compare there stored reference value of the PIN. In the event that the entered PIN matches the reference value of the PIN, the user 102 is considered authenticated.
  • a biometric feature of the user 102 is captured.
  • the ID token 106 has a fingerprint sensor or a fingerprint sensor is connected to the user's computer system 100.
  • the biometric data acquired by the user 102 is compared to the biometric reference data stored in the protected memory area 120 by executing the program instructions 130 in this embodiment. If the biometric data acquired by the user 102 sufficiently matches the biometric reference data, the user 102 is considered authenticated.
  • the program instructions 134 are used to execute the steps of a cryptographic protocol concerning the ID token 106 for the purpose of authenticating an I D provider computer system 136 with respect to the ID token 106.
  • the cryptographic protocol can be a challenge-response protocol act based on a symmetric key or an asymmetric key pair.
  • the cryptographic protocol implements an Extended Access Control method as specified for machine-readable travel documents (MRTD) by the International Aviation Authority (ICAO).
  • MRTD machine-readable travel documents
  • ICAO International Aviation Authority
  • the 1D provider computer system 136 Upon successful completion of the cryptographic protocol, the 1D provider computer system 136 authenticates against the ID token, thereby verifying its readability to read the attributes stored in the protected storage area 124.
  • the authentication can also be mutually exclusive, ie the ID token 106 must then also authenticate itself to the ID provider computer system 136 according to the same or another cryptographic protocol.
  • the program instructions 132 are for end-to-end encryption of data transferred between the ID token 106 and an ID provider computer system 136 (see Fig. 2), or at least the data from the ID provider computer system 136 of protected memory area 124 read attributes.
  • a symmetric key may be used, which is agreed, for example, during the execution of the cryptographic protocol between the ID token 106 and the ID provider computer system 136.
  • the ID token 106 has an interface 108 for communicating with a corresponding interface 104 of a user computer system 00 (see FIG. 2).
  • the interface may be contactless or contact-based. In particular, it may be an RFID or an NFC communication interface.
  • the access to the protected memory area 124 for reading one or more of the attributes can only take place via the processor 128 of the ID token 06, since the protected memory area 124 as well as the other protected memory areas 120, 122 are not directly, for example via a bus system are connected to the interface 108, but only with the processor 128, that is, an access via the interface 08 directly to the protected memory area 124 is already excluded circuit technology. Only the processor 128 can that is read access to the protected memory area 124, then optionally output the read attributes via the interface 108.
  • FIG. 2 shows a user computer system 100 of the user 02.
  • the user computer system 100 may be a personal computer (PC) for a portable computer, such as a laptop, notebook or tablet computer, a mobile telecommunication device , especially a smartphone.
  • PC personal computer
  • portable computer such as a laptop, notebook or tablet computer
  • mobile telecommunication device especially a smartphone.
  • the user computer system has at least one processor 110 for executing an application program 1 12.
  • the application program 112 is configured to communicate via a network interface 114 of the user computer system 100 via a network 116.
  • the application program is an Internet browser or other specialized application program that can communicate over the network 116, in particular an HTML-capable application program.
  • the processor 1 10 is used to execute another program 1 3, which may be, for example, a plug-in for the application program 1 12, for example, a browser plug-in when the application program 12 is designed as an Internet browser , or a program separate from the application program.
  • another program 1 3 may be, for example, a plug-in for the application program 1 12, for example, a browser plug-in when the application program 12 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.
  • the network 16 may also include a mobile radio network.
  • the I D provider computer system 136 has a network interface 138 for communication over the network 116.
  • the ID provider computer system 136 further has a memory 140 with a protected memory area 141 in which a private key 142 of the I D provider And also the corresponding certificate 144.
  • This certificate can also be, for example, a certificate according to a PKI standard, such as X.509.
  • the ID provider computer system 136 further has at least one processor 145 for executing program instructions 146 and 148. By executing the program instructions 146, the steps of the cryptographic protocol concerning the ID provider computer system 136 are executed.
  • the cryptographic protocol is implemented by executing the program instructions 134 by the processor 128 of the ID token 106 and by executing the program instructions 146 by the processor 145 of the ID provider computer system 136.
  • the program instructions 148 are for implementing the end-to-end encryption on the I D provider computer system 136 side, for example, based on the symmetric key involved in executing the cryptographic protocol between the ID token 106 and the ID provider - Computer system 136 has been agreed.
  • any method known per se for agreeing the symmetric key for end-to-end encryption such as a Diffie-Hellman key exchange, may be used.
  • the ID provider computer system 136 is preferably located in a particularly protected environment, in particular in a so-called trust center, so that the ID provider computer system 36 in combination with the necessity of authentication of the user 102 against the ID token 06 forms the trust anchor for the authenticity of the attributes issued from the ID token 106.
  • a service computer system 150 may be configured to receive an order or order for a service or product, particularly an online service.
  • the user 102 may open an account online with a bank via the network 116, or may use other financial or banking services.
  • the service computer system 150 may also be configured as an on-line department store so that the user 102 may, for example, purchase a mobile phone or the like online.
  • the service computer system 150 may also be configured to provide digital content, such as for downloading music and / or video data.
  • the service computer system 150 has for this purpose a network interface 152 for connection to the network 1 16.
  • the service computer system 150 has at least one processor 154 for executing program instructions 156. By executing the program instructions 156, for example, dynamic HTML pages are generated, via which the user 102 can enter his order or his order, as well as transactions.
  • the service computer system 50 must review one or more attributes of the user 102 and / or its ID token 106 based on one or more predetermined criteria. Only if this check is passed will the order or order of the user 102 be accepted and / or executed. To carry out an electronic transaction, you can proceed as follows:
  • the user 102 starts the application program 1 12 of the user computer system, it being further assumed that this is an Internet browser without restriction of generality.
  • the user 102 enters a URL of the service computer system 150 in the Internet browser, so that then a first session 201 between the Internet browser 1 12 and the service computer system 150 is established via the network 1 16.
  • the user may then request via the first session 201 a service offered by the service computer system 50, such as ordering a product, requesting data for download, or requesting the execution of a financial transaction.
  • the Internet browser 1 2 sends a corresponding transaction request 158 to the service computer system 150, which signals this request.
  • the service computer system thus receives from the Internet browser via the first session a transaction request 158 of the user 02. Due to the receipt of the transaction request 158 via the first session 201, the service computer system 150 generates a request 166.
  • Request 166 includes (i) an attribute specification, the attribute to be read from the iD token for performing the transaction. These attributes may be personal information about the user 102 and / or data regarding the ID token 106 itself or a pseudonym of the user 102 available from the ID token 106.
  • the request further includes (ii) the transaction data specifying the transaction, such as a payment amount to be paid for the purchase of the ordered product or the performance of the ordered service to the service computer system 150 or a third party, and / or others Transaction data specifying the transaction to be performed.
  • the request furthermore contains (iii) an identifier 180 of the request, for example a GUID, which is required for the so-called binding of the request and a subsequently received response 74.
  • the service computer system 150 may include a GUI D generator.
  • the request also includes (iv) a URL of the I D provider computer system 136 and (v) a URL of the service computer system 150 itself.
  • the request is signed by the service computer system 150, namely by means of a private key of the service provider.
  • the request 166 may be a SAML request or another request of a request-response protocol.
  • the service computer system 150 sends a web page 160 to the user computer system 100 via the first session 201, the web page 160 having an input field 162 for inputting additional information by the user 102 for the transaction, and further Input element 164, which the user 102 can select by clicking, for example, when the web page 160 is rendered by the Internet browser 112 to allow the forwarding of the request 166.
  • the request 166 is also transmitted to the internet browser 112 via the first session 201. Due to the reception of the web page 160 and the request 166, the web page 160 is rendered by the internet browser 112 so that the user 102 can input the additional information into the input field 162.
  • the additional information is an account connection of the user 02, a credit card number of the user 102 or other supplementary transaction data and / or an authentication information for proving the authorization of the user 02 for carrying out the transaction, for which purpose the user 02, for example One-time password (OTP) in the input field 162 enters.
  • OTP One-time password
  • the additional information 168 entered by the user 102 is encrypted with the public key of the service computer system 150 by the user computer system 100 to obtain a corresponding ciphertext.
  • a second session 202 is established between the Internet browser 112 and the ID provider computer system 136 via the network 6, using the URL of the I D provider computer system 136, the user computer system 100 with the request 166 received.
  • the second session 202 is established with a secure transport layer, for example as an https session.
  • the request 166 and the additional information 168 or only the ciphertext of the additional information 168 obtained with the aid of the public key of the service computer system 150 are forwarded from the user computer system 100 to the ID provider computer system 136.
  • the ID provider computer system 136 Due to the receipt of the request 166 by the ID provider computer system 136, the latter generates a session ID for a still to be established third session 203 by executing its program instructions 170.
  • the request 166 and the additional information 168 are stored in the memory 140 of the iD provider computer.
  • Computer system 136 stored.
  • the ID provider computer system 136 then generates a message 172 that includes the Session ID for the construction of the third session 203 and a logical address.
  • the response 174 to be generated by the ID provider computer system 136 on the basis of the request 166 can be retrieved; in particular, the logical address can be embodied as a URL.
  • the message 172 is sent via the second session 202 from the ID provider computer system 136 to the Internet browser 112.
  • the third session 203 is established between the program 113 of the user computer system 100 and the ID provider computer system 136 via the secure transport layer of the second session 202.
  • program 113 is a browser plug-in of Internet browser 112.
  • program 113 may be another application program. It is also possible to implement the functionalities of the Internet browser 112 and those of the program 1 3 in a program.
  • At least the certificate 144 is then transmitted to the program 113 via the third session 203.
  • the program 113 then checks whether the read rights specified in the certificate 144 are sufficient to allow read access by the ID provider computer system 36 to the attribute (s) to be read according to the attribute specification included in the request 166. Only if these read rights are sufficient, the following steps are performed: a) A local connection 176 is established between the interfaces 104 and 108. For example, on the screen of the user computer system 100, a request for the user 102 to insert the ID token 106 into a reading device of the user computer system 100, which has the cut parts 104, or appears for placing the ID token 106 on a contactless interface 104.
  • the user 02 then authenticates himself to the ID token, for example by entering his PIN in the user computer system 100 or its reader.
  • the authentication of the user can take place with the aid of a cryptographic protocol, for example by means of a challenge-response protocol or based on a Diffie-Helman key exchange, wherein a session key is agreed as part of the authentication of the user.
  • a fourth session 204 is established between the ID token 106 and the I D provider computer system 136 via the local connection 176 and the third session 203.
  • the fourth session 204 is executed with a End-to-end encryption using the session key, which has been agreed in the authentication of the user in step b) protected.
  • the fourth session is then used to mutually authenticate the ID token 106 and the ID provider computer system 136 with the aid of the respective private key, that is to say the private key of the ID token 106 stored in the protected memory area 122 and the private one Key 142 of the ID provider computer system 136.
  • the certificates of the ID token 106 may be exchanged from the storage area 126 (see FIG. 1) as well as the certificate 144 of the ID provider computer system 136 over the fourth session.
  • the I D provider computer system 136 Given the successful authentication of the user to the ID token and the successful mutual authentication of the ID token 106 and the ID provider computer system 136, the I D provider computer system 136 then reads the attribute or attributes according to the attribute specification the ID Token 106, wherein the attributes are protected by the end-to-end encryption in the transmission of the ID token 106 to the I D provider computer system 136. For this purpose, the I D provider computer system sends a read command via the fourth session 204 to the ID token 106 via the fourth session.
  • the read command 182 contains the attribute specification, that is to say the selection of those attributes which originate from the protected memory area 124 of the ID Tokens 106 should be read.
  • the response 174 is then generated on the request 166 by the I D provider computer system 136.
  • the response 178 includes the attributes previously issued via the fourth session 240 from the ID token 106, the additional information 168 or, depending on the embodiment, not the additional information 168, but only the ciphertext of the additional information 168, and the identifier 180 indicating the service Computer system 150 has initially assigned to the request 166.
  • the response 174 is signed by the ID provider computer system 136 using the private key 142 and then stored in the memory 140 so that the request 166 is retrievable from the logical address.
  • the user computer system 100 such as, for example, its Internet browser 112, then reads the response 174 from the memory 140, for example via the second session 202, with the aid of the logical address.
  • the response 174 is then forwarded from the user computer system 100, for example from the Internet browser 12, via the first session 201 to the service computer system 150.
  • the user 102 is requested by the Internet browser 112 to enter a confirmation before the response 174 is forwarded to the service computer system.
  • the content of the response 174 is displayed in whole or in part by the Internet browser, in particular the information read from the ID token. tribute and / or additional information 168 to allow the user 102 to verify the accuracy of this data before continuing to the service computer system 150 to complete the transaction.
  • the service computer system 150 allocates the received response 174 to the request 166 based on the matching identifiers 180 of the request 166 and the response 174.
  • the service computer system 150 then checks the signature of the response 166 and reads out the required attribute (s) from the response 174.
  • the attributes are then used to check whether the requested transaction can be performed by comparing the attribute (s) to one or more predetermined criteria. These criteria may be, for example, the age or credit of user 102.
  • the attribute may also be a pseudonym of the user 102, by means of which the service computer system 150 then reads out an attribute of the user 102 stored in a database of the service computer system 150, such as a delivery address.
  • the test criterion here is whether a user is registered with the pseudonym included in the response 174 on the part of the service computer system 150.
  • the transaction is performed based on the transaction data and the additional information 168.
  • the program 113 is a browser plug-in which is registered in a registry of an operating system of the user computer system with a plug-in identifier, wherein the operating system is, for example, a Windows operating system, Android or iOS can be.
  • the message 172 from the ID provider computer system to the Internet browser 112 includes this plug-in identifier 184, so that the plug-in 113 is started due to the receipt of the message.
  • the program 113 is a separate application program from the Internet browser 112, such as a so-called citizen app or ID card app.
  • This application program 113 is started by the Internet browser 112 by calling a local URL, the local URL including a fixed port number according to the TCP protocol.
  • This local URL is transmitted together with the web page 160 from the service computer system 150 to the user computer system 100 via the first session 201 in order to start the application program 113 using the local URL by the internet browser 112. ken.
  • the service computer system 150 decrypts the ciphertext using the private key of the service computer system 150 to then perform the requested transaction using the additional information 168. This may 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 specified in the additional information 168.
  • the implementation of the payment by the I D provider computer system 136 is triggered. This can be done so that the l D provider computer system 136 receives the requisite transaction data about the request 166 and the additional information 168 and then performs or causes the payment.
  • the response 174 then includes an acknowledgment from the I D provider computer system 36 that the payment has been made.
  • submission of the additional information 168 to the service computer system 150 can then be omitted, which is advantageous for protecting the confidentiality of this additional information 168, since this additional information 168 then only needs to be disclosed to the trusted ID provider computer system 136.
  • the actual transaction eg the delivery of the ordered product, becomes then upon receipt of the payment confirmation included in the response 174, prompted by the service computer system 150.
  • the additional information 168 includes an OTP.
  • the service computer system 150 checks whether the OTP is valid as an additional prerequisite for the transaction to be performed.
  • the OTP is encrypted by the user's computer system 100 with the public key of the service computer system 150 and then decrypted by the service computer system 150 upon receipt of the additional information with the encrypted OTP, to then check its validity.
  • the computer system includes a terminal 186, which may be, for example, a vending machine, in particular a cash machine or vending machine.
  • a terminal 186 which may be, for example, a vending machine, in particular a cash machine or vending machine.
  • the user 102 may enter into the terminal 186 a sum of money to withdraw cash from his account.
  • An optically detectable pattern is then displayed on a display 188 of the machine, such as a QR code that includes a URL of the service computer system 150 and the amount of money desired by the user 102.
  • This optical pattern is detected by the display 88 by means of a camera 190 of the user computer system 100.
  • the user computer system 100 then generates the transaction request 158 indicating this amount of money.
  • the first session 201 is constructed here using the URL of the service computer system 150 captured from the optical pattern and the transaction request 158 with the desired amount of money is transmitted to the service computer system 150 via this first session 201.
  • the service computer system 150 then generates a corresponding request 166 to retrieve the attributes and additional information 168 required for the payment of the desired amount of money.
  • the ID provider computer system 136 or the service computer system 150 then causes the debit of an account of the user 102, which has indicated this, for example, in the additional information 168. Due to the receipt of the response 174 and the cause of the Payment then receives the terminal 186 a signal to issue the desired amount of money, for example in the form of cash or to charge a cash card of the user 102. This can be done so that the terminal 186 is directly connected to the Diensf computer system 150 or via the network 116.
  • the terminal 186 may also be a vending machine, whereupon no cash but a desired product, such as a soda can or cigarette pack, is dispensed from the vending machine after the payment is signaled by the service computer system 150 has been.
  • a desired product such as a soda can or cigarette pack
  • terminal 186 may be a mobile telecommunications device, particularly a smartphone. If the user 102 wants to buy something from the owner of the terminal 186, the holder of the terminal 186 enters the corresponding purchase price in the terminal 186, so that then on the display 188 in the form of the optically detectable pattern turn this purchase price as a payment amount and the URL of the service computer system 150 is output. Upon completion of the transaction, the terminal 186 receives from the service computer system 150 a signal indicating that the payment has been made and the owner of the terminal 186 then delivers the product to the user 102. This can also be implemented in the POS system of, for example, a supermarket.
  • Another application is a taximeter that detects taxi charges or another utility meter, such as a utility meter for household electricity or gas consumption, especially a so-called smart meter.

Abstract

Die Erfindung betrifft ein Elektronisches Transaktionsverfahren unter Verwendung eines ID-Tokens (106), der einem Nutzer (102) zugeordnet ist, wobei der ID-Token einen elektronischen Speicher (118) mit einem geschützten Speicherbereich (124) aufweist, in dem ein oder mehrere Attribute gespeichert sind, wobei ein Zugriff auf den geschützten Speicherbereich nur über einen Prozessor (128) des ID-Tokens möglich ist, und wobei der ID-Token eine Kommunikations-Schnittstelle (108) zur Kommunikation mit einem Lesegerät eines Nutzer-Computersystems (100) aufweist.

Description

Elektronisches Transaktionsverfahren und Computersystem
B e s c h r e i b u n g
Die Erfindung betrifft ein elektronisches Transaktionsverfahren sowie ein Computer- System.
Für den elektronischen Handel, das heißt den sogenannten eCommerce, sind verschiedene Transaktionsverfahren bekannt. Dazu gehören übliche Zahlungsverfahren wie zum Beispiel eine papiergebundenen Überweisung oder die Zahlung per Nachnahme sowie elektronische Zahlungsverfahren, wie zum Beispiel Kreditkartenzahlung, die Zahlung per Online-Banking, Inkasso/Biiling-Systeme, Factory- Systeme, elektronische Lastschrift, Prepaidverfahren, Zahlung per Telefonrechnung sowie Handy-Payment-Systeme. Solche Zahlungsverfahren werden zum Teil auch für eGovernment Anwendungen eingesetzt.
Der Erfindung liegt demgegenüber die Aufgabe zugrunde, ein verbessertes eiektro- nisches Transaktionsverfahren sowie ein entsprechendes Computersystem zu schaffen.
Die der Erfindung zugrunde liegende Aufgabe wird jeweils mit den Merkmalen der unabhängigen Patentansprüche erfüllt. Ausführungsformen der Erfindung sind in den abhängigen Patentansprüchen angegeben.
Unter einer„Transaktion" wird hier eine finanzielle Transaktion, wie zum Beispiel die Bezahlung eines Bezahlbetrags durch Vornahme einer Überweisung, eines Lastschrifteinzugs oder Belastung einer Kreditkarte, ein Bestellvorgang zur Bestellung und Lieferung eines physischen Gutes oder von Daten sowie andere logistische, Handels- und/oder Finanztransaktionen und/oder eine Datenbanktransaktion z.B. zur Speicherung eines Werts, wie z.B. eines Verbrauchswerts, eines Guthaben, o- der eines Zahlungsbetrags verstanden. Unter einem„Terminal" wird hier eine Vorrichtung verstanden, die ein Display, d.h. einen Bildschirm, zur Anzeige eines optischen Musters hat. Das Terminal kann lediglich Informationen erfassen und über das Display ausgeben oder es kann eine Nutzerschnittstelle zur Eingabe einer Auswahl eines Nutzers aufweisen. Zum Beispiel kann das Terminal als Bankautomat oder Verkaufsautomat ausgebildet sein. Der Nutzer kann eine Anforderung in das Terminal eingeben, wie zum Beispiel zur Abhebung von Bargeid, Aufladen einer Geldkarte oder zum Kauf eines bestimmten Produkts, wie zum Beispiel eines Getränks. Der Automat zeigt auf diese Nutzeranforderung hin ein optisch erfassbares Muster, wie zum Beispiel einen QR- Code, auf seinem Bildschirm an, wobei das Muster eine Information beinhaltet, um die Durchführung der Transaktion zu initiieren. Hierbei kann es sich um den gewünschten Auszahlungsbetrag oder den Kaufpreis der Produkts handeln. Nach einer weiteren Ausführungsform der Erfindung ist das Terminal als Telekommunikationsgerät, als sog. Smartmeter, für die Gebührenerfassung z.B. des Strom oder Gasverbrauchs, Taxameter oder Smartphone mit einer Gebührenerfassungsfunktion ausgebildet.
Unter einem„Muster" wird hier ein statisches optisches Muster verstanden, das auf dem Display des Terminals ausgegeben wird, und in das Informationen codiert sind, beispielsweise ein Barcode, insbesondere ein eindimensionaler, zweidimensionaler, high capacity color Barcode, MaxiCode, QR-Code oder DataMatrix-Code, oder eine zeitliche Reihenfolge mehrerer Muster, wobei durch die Muster und deren zeitliche Reihenfolge eine Information codiert ist, wie das z.B. bei einem Flickercode der Fall ist. Der„Flickercode" ist an sich für das sogenannte chipTAN-comfort oder Smart- TAN-optic online Banking Verfahren der Sparkassen bzw. Volksbanken bekannt. Unter einer„Session" wird hier eine temporäre Kommunikationsverbindung, das heißt eine sog. Communication Session, verstanden, die sich gemäß OSI- Schichtmodell auf die Transportschicht („transport layer") oder die Anwendungsschicht („application layer") beziehen kann. Insbesondere kann es sich bei einer Session um eine http-Session oder um eine https-Session handeln, wobei bei letzte- rer der Transportlayer durch eine symmetrische Verschlüsselung geschützt ist.
Unter einem„ID-Token" wird hier insbesondere ein tragbares elektronisches Gerät verstanden, welches zumindest einen Datenspeicher zur Speicherung des zumindest einen Attributs und eine Kommunikations-Schnittstelle zum Auslesen des Attri- buts aufweist. Vorzugsweise hat der ID-Token einen gesicherten Speicherbereich zur Speicherung des zumindest einen Attributs, um zu verhindern, dass das in dem Speicherbereich gespeicherte Attribut in unerlaubter Weise verändert oder ohne die dafür erforderliche Berechtigung ausgelesen wird. Insbesondere kann es sich bei dem ID-Token um einen USB-Stick handeln oder ein Dokument, insbesondere ein Wert- oder Sicherheitsdokument. Unter einem„Dokument" werden erfindungsgemäß papierbasierte und/oder kunststoffbasierte Dokumente verstanden, insbesondere elektronische hoheitliche Dokumente, wie zum Beispiel elektronische Ausweisdokumente, insbesondere Reisepässe, Personal- ausweise, Visa sowie Führerscheine, Fahrzeugscheine, Fahrzeugbriefe, Firmenausweise, Gesundheitskarten oder andere ID-Dokumente sowie auch Chipkarten, Zahlungsmittel, insbesondere Banknoten, Bankkarten und Kreditkarten, Frachtbriefe oder sonstige Berechtigungsnachweise, in die ein Datenspeicher zur Speicherung des zumindest einen Attributs integriert ist.
Bei dem ID-Token kann es sich um einen Hardwaretoken handeln oder um einen Softtoken, wenn dieser kryptografisch an einen Hardwaretoken, das heißt beispielsweise an ein sogenanntes Secure Element, gebunden ist,
Insbesondere kann ein solcher kryptografisch an ein Secure Element gebundener Softtoken gemäß DE 10 2011 082 101 , deren Offenbarungsgehalt voll umfänglich zum Offenbarungsgehalt der vorliegenden Patentanmeldung gemacht wird, erzeugt werden.
Unter einem J D-Provider-Computersystem1' wird hier ein Computersystem verstanden, welches dazu ausgebildet ist, zumindest ein Attribut aus dem ID-Token eines Nutzers auszulesen. Vorzugsweise wird das ID-Provider-Computersystem in einem sogenannten Trustcenter betrieben, um ein möglichst hohes Maß an Sicherheit zu schaffen.
Unter einem„Dienst-Computersystem" wird hier ein Computersystem verstanden, welches über eine Netzwerk-Schnittstelle zur Verbindung mit dem Netzwerk verfügt, sodass mithilfe eines Internetbrowsers oder eines anderen Anwendungsprogramms auf von dem Dienst-Computersystem gespeicherte oder generierte Internetseiten zugegriffen werden kann. Insbesondere kann es sich bei dem Dienst- Computersystem um einen Internetserver zur Verfüg ungstellung einer eCommerce- oder eGovernment-Anwendung handeln, insbesondere einen Onlineshop oder einen Behördenserver.
Unter einem„Nutzer-Computersystem" wird hier ein Computersystem verstanden, auf welches der Nutzer Zugriff hat. Hierbei kann es sich zum Beispie! um einen Personal Computer (PC), ein Tablet PC oder ein Mobilfunkgerät, insbesondere ein Smartphone, mit einem üblichen Internetbrowser, wie zum Beispiel Microsoft Inter- net Explorer, Safari, Google Chrome, Firefox oder einem anderen Anwendungsprogramm zum Zugriff auf das Dienst-Computersystem handeln. Das Nutzer- Computersystem hat eine Schnittstelle zur Verbindung mit dem Netzwerk, wobei es sich bei dem Netzwerk um ein privates oder öffentliches Netzwerk handeln kann, insbesondere das Internet.
Nach einer Ausführungsform der Erfindung handelt es sich bei der Anforderung des Dienst-Computersystems um einen SAML-Request und bei der Antwort des ID- Provider-Computersystems hierauf um eine SAML-Response (vgl. Security Asserti- on Markup Language (SAML) V2.0 Technical Overview, OASIS, Committee Draft 02, 25. März 2008).
Nach einer Ausführungsform der Erfindung hat das ID-Provider-Computersystem ein Zertifikat, in dem die Leserechte für die Durchführung des Lesezugriffs spezifi- ziert sind.
Unter einem„Zertifikat" wird hier ein digitales Zertifikat verstanden, welches auch als Public-Key-Zertifikat bezeichnet wird. Bei einem Zertifikat handelt es sich um strukturierte Daten, die dazu dienen, einen öffentlichen Schlüssel eines asymmetri- sehen Kryptosystems einer Identität, wie zum Beispie! einer Person oder einer Vorrichtung, zuzuordnen. Beispielsweise kann das Zertifikat dem Standard X.509 oder einem anderen Standard entsprechen. Vorzugsweise handelt es sich bei dem Zertifikat um ein Card Verifiable Certificate (CVC). In dem Zertifikat kann spezifiziert sein, für welches Attribut oder welche Attribute des Nutzers, die in dem geschützten Speicherbereich des ID-Tokens gespeichert sind, das ID-Provider-Computersystem zur Durchführung des Lesezugriffs berechtigt ist. Bei diesen Attributen kann es sich um persönliche Attribute des Nutzers handeln, wie zum Beispiel seinen Namen, Wohnort und sein Alter. Diese Attribute können in ihrer Kombination als Nutzererkennung verwendet werden, um auf die Bezahlinformation des registrierten Nutzers zuzugreifen. Alternativ oder zusätzlich kann auch ein Pseudonym des Nutzers, welches zumindest temporär von dem ID- Token gespeichert wird, als Nutzerkennung verwendet werden. Ausführungsformen der Erfindung sind besonders vorteilhaft, da ein universell und auch für eCommerce- und eGovernment-Anwendungen geeignetes computerim- piementiertes Bezahlverfahren geschaffen wird, welches gleichzeitig flexibel, bequem in der Handhabung und sicher ist. Dies wird insbesondere dadurch ermög- licht, dass das Bezahlverfahren auf einem ID-Token basiert, wobei Voraussetzung für die Durchführung eines Bezahlvorgangs sowohl die Authentifizierung des Nutzers gegenüber dem ID-Token als auch die Authentifizierung des ID-Provider- Computersystems gegenüber dem ID-Token ist. Nach Ausführungsformen der Erfindung handelt es sich bei dem Terminal um eine Vorrichtung, zum Beispiel zur Auszahlung von Bargeld, zur Aufladung einer Geldkarte zum Verkauf eines Produkts, wie zum Beispiel einer Fahrkarte, einer Eintrittskarte oder eines Nahrungs- oder Genussmittels. Beispielsweise kann es sich bei dem Terminal um einen Bankautomaten handeln. In diesem Fall gibt der Nutzer über eine Nutzerschnittstelle des Bankautomaten einen gewünschten Auszahlungsbetrag ein. Dieser Auszahlungsbetrag wird dann als ein optisch lesbares Muster von dem Bankautomaten auf dessen Bildschirm angezeigt und dieses Muster wird von dem Nutzer mithilfe eines optischen Sensors erfasst, wie zum Beispiel durch die Kamera des Nutzer-Computersystems, welches als Smartphone ausgebildet sein kann. Das auf dem Bildschirm angezeigte Muster kann ferner eine logische Adresse des Dienst-Computersystems beinhalten, wie zum Beispiel eine URL des Dienst-Computersystems. Darüber hinaus können in dem Muster weitere Informationen beinhaltet sein, wie zum Beispiel eine Kontoin- formation des Betreibers des Bankautomaten.
Das Nutzer-Computersystem decodiert das von dem Bildschirm des Terminals mithilfe des optischen Sensors erfasste Muster und generiert dann eine Transaktionsanforderung, die den Auszahlungsbetrag und ggf. die weiteren Transaktionsdaten , die in dem Muster beinhaltet sind, angibt. Diese Transaktionsanforderung wird dann von dem Nutzer-Computersystem an das Dienst-Computersystem über das Netzwerk übertragen. Das Dienst-Computersystem erzeugt daraufhin einen Request, der eine Attributspe- zifikation beinhaltet, das heißt eine Angabe zumindest eines aus dem ID-Token auszulesenden Attributs, welches für die Durchführung der Transaktion erforderlich ist und/oder weiches ein vorgegebenes Prüfkriterium erfüllen muss, damit die Transaktion durchgeführt werden kann. Beispielsweise kann es sich bei dem Attribut um eine in dem ID-Token gespeicherte Kontoverbindung des Nutzers handeln oder um ein Pseudonym des Nutzers, welches für das Dienst-Computersystem als Zugriffsschlüssel auf in einer Datenbank pseudonymisiert gespeicherte Kontoinformationen von registrierten Nutzern dient. Alternativ oder zusätzlich kann es sich bei dem Attribut um eine Altersangabe handeln, um zu überprüfen, ob der Nutzer die für die Durchführung der Transaktion erforderliche Geschäftsfähigkeit aufweist.
Das Dienst-Computersystem sendet dann den Request an das 1 D-Provider- Computersystem. Nach Authentifizierung des Nutzers gegenüber seinem ID-Token und nach Authentifizierung des I D-Provider-Computersystems gegenüber dem ID- Token über das Netzwerk erfolgt dann das Auslesen des zumindest einen Attributs aus dem ID-Token durch das I D-Provider-Computersystem über das Netzwerk mit Ende-zu-Ende-Verschlüsselung. Das I D-Provider-Computersystem erzeugt daraufhin eine Response, die das zumindest eine aus dem ID-Token ausgelesene Attribut beinhaltet. Die Attribute und/oder die Response wird von dem 1 D-Provider-Computersystem signiert und an das Dienst-Computersystem gesendet. Das Dienst-Computersystem verwendet dann die Attribute zur Durchführung der Transaktion, das heißt hier zum Beispiel der Belastung des Kontos des Nutzers mit dem Auszahlungsbetrag, und/oder zur Prüfung, ob ein vorgegebenes Kriterium, z.B: die Geschäftsfähigkeit erfüll ist. Nachdem diese Belastung des Kontos erfolgt ist, erzeugt das Dienst- Computersystem ein Bestätigungssignal, welches an dem Bankterminal übertragen wird. Beispielsweise ist hierzu der Terminal, das heißt hier der Bankautomat, mit dem Netzwerk verbunden, sodass das Bestätigungssignal von dem Dienst- Computersystem über das Netzwerk an das Terminal übertragen wird. Vorzugswei- se wird das Bestätigungssignal von dem Dienst-Computersystem signiert, um Manipulationen zu vermeiden. Aufgrund des Empfangs eines validen Bestätigungssignals erfolgt dann die Ausgabe des Bargelds in Höhe des gewünschten Auszahlungsbetrags oder alternativ die Aufladung einer Geldkarte des Nutzers.
5
Nach einer Ausführungsform der Erfindung ist das Terminal als Verkaufsautomat ausgebildet. Über eine Nutzerschnittstelle des Verkaufsautomat kann der Nutzer ein gewünschtes Produkt auswählen. Der Verkaufsautomat zeigt dann auf seinem Display ein optisches Muster an, in dem der Kaufpreis des von dem Nutzer ausgewählte! ten Produkts codiert ist sowie auch eine Kontoinformation desjenigen Kontos, auf welches die Zahlung dieses Kaufpreises zu leisten ist. Ferner beinhaltet das optische Muster die Angabe einer logischen Adresse, insbesondere einer URL, des Dienst-Computersystems.
15 Der Nutzer erfasst dieses optische Muster mit einem optischen Sensor seines Nutzer-Computersystems, beispielsweise mithilfe der Kamera seines Smartphones. Das optische Muster wird dann decodiert und es wird eine Transaktionsanforderung generiert, die den Kaufpreis und die Kontoinformation des Zahlungsempfängers beinhaltet. Diese Transaktionsanforderung wird von dem Nutzer-Computersystem an
20 das Dienst-Computersystem übertragen, und zwar mithilfe der logischen Adresse des Dienst-Computersystems.
Das Dienst-Computersystem generiert daraufhin einen Request mit der Attributspezifikation der für die Abgabe des von dem Nutzer gewählten Produkts erforderlichen
25 Attribute. Beispielsweise handelt es sich um ein Produkt, das nur an Volljährige abzugeben ist, wie zum Beispiel Alkohol oder Zigaretten. In diesem Fall beinhaltet die Attributspezifikation das Attribut„Alter". Aufgrund dieser Anforderung erhält das Dienst-Computersystem von dem 1 D-Provider-Computersystem eine Response, die diese Altersangabe beinhaltet. Das Dienst-Computersystem prüft dann, ob die AI-
30 tersangabe ein vorgegebenes Kriterium erfüllt, beispielsweise also die Volljährigkeit, und wenn dies der Fall ist, führt das Dienst-Computersystem die Transaktion durch, indem hier beispielsweise der Kaufpreis von dem Konto des Nutzers auf das Konto des Zahlungsempfängers überwiesen wird. Anschließend gibt das Dienst- Computersystem ein Bestätigungssignai an den Verkaufsautomaten ab, woraufhin dieser dann das von dem Nutzer zuvor ausgewählte Produkt abgibt.
Nach einer weiteren Ausführungsform der Erfindung ist das Terminal als Ver- brauchszähler, insbesondere zur Erfassung eines Strom- oder Gasverbrauchs, ausgebildet. In diesem Fall wird auf dem Display des Terminals ein optisches Muster angezeigt, welches den aktuellen Zählerstand und zum Beispiel eine Zählernummer des Verbrauchszählers beinhaltet sowie auch die logische Adresse des Dienst- Computersystems. Die entsprechende Transaktionsanforderung beinhaltet dann diesen Zählerstand sowie die Zählernummer. Die Attributspezifikation des Dienst- Computersystems kann zum Beispiel persönliche Angaben des Nutzers spezifizieren und/oder ein Pseudonym oder eine Kennung des Nutzers, wie zum Beispiel dessen Kundennummer. Aufgrund des Empfangs der Response von dem ID-Provider-Computersystem kann das Dienst-Computersystem feststellen, welcher Nutzer das optische Muster von dem Terminal erfasst hat. Unter der Voraussetzung, dass es sich bei diesem Nutzer um den Zahlungspflichtigen handelt, der bei dem Dienst-Computersystem als Kunde registriert ist, speichert das Dienst-Computersystem den mit der Transaktionsan- forderung gemeldeten Zählerstand und die zugehörige Zählernummer in einer Datenbank mittels einer Datenbank-Transaktion ab. Zu einem späteren Zeitpunkt kann dann von dem Dienst-Computersystem eine entsprechende Rechnung generiert werden, um den erfassten Verbrauch abzurechnen. Nach einer Ausführungsform der Erfindung generiert das Dienst-Computersystem ein Bestätigungssignal, nachdem die Datenbanktransaktion ausgeführt worden ist, wobei dieses Bestätigungssignal an den Verbrauchszähler gesendet wird. Der Verbrauchszähler kann daraufhin zurückgesetzt werden. Nach einer Ausführungsform der Erfindung handelt es sich bei dem Terminal um ein Smartphone eines Dritten, der dem Nutzer ein Produkt verkaufen möchte. Hierzu hat das Smartphone eine App, die der Dritte startet. In die App gibt der Dritte den Kaufpreis und zum Beispiel seine Bankverbindung ein. Diese Informationen sowie die logische Adresse des Dienst-Computersystems werden dann auf dem Display des Smartphones als optisches Muster ausgegeben.
Die entsprechende Transaktionsanforderung beinhaltet dann den Kaufpreis sowie die Kontoverbindung des Dritten. Die Attributspezifikation kann in diesem Fall zum Beispiel die persönlichen Angaben des Nutzers betreffen, mithilfe derer das Dienst- Computersystem auf die zuvor registrierte Kontoverbindung des Nutzers zugreifen kann. Nach Empfang der Response führt das Dienst-Computersystem dann die Transaktion, das heißt hier die Zahlung des Kaufpreises, mithilfe der Kontoinforma- tionen des Dritten und des Nutzers durch. Das Dienst-Computersystem sendet dann ein Bestätigungssignal an das Smartphone des Dritten, sodass dieser von der erfolgten Zahlung informiert wird und das Produkt an den Nutzer abgibt.
Anstelle eines Smartphones kann dies auch in einem anderen mobilen elektroni- sehen Gerät, wie zum Beispiel einem Laptop- oder Notebook-Computer oder in einem stationären elektronischen System, wie zum Beispiel dem elektronischen Kassensystem eines Supermarkts, implementiert werden.
In einer weiteren Anwendung ist das Terminal als Taxameter ausgebildet. In diesem Fall beinhaltet das optische Muster ein Fahrentgelt, welches ein Taxifahrer für eine Taxifahrt abrechnet. Nach Empfang des Bestätigungssignals von dem Dienst- Computersystem, welches die Durchführung der entsprechenden Zahlung bestätigt, gibt das Taxameter einen entsprechenden Beleg, das heißt eine Quittung, aus. Besonders vorteilhaft ist, wenn das Terminal eine Netzwerk-Schnittstelle zur Kommunikation über das Netzwerk aufweist. In diesem Fall kann das Bestätigungssignal von dem Dtenst-Computersystem über das Netzwerk an den Automat übertragen werden. Eine andere Möglichkeit ist, dass das Bestätigungssignal von dem Dienst- Computersystem an das Nutzer-Computersystem gesendet wird. Das Nutzer- Computersystem kann daraufhin auf einem Display des Nutzer-Computersystems ein optisches Muster anzeigen, in welches dieses Bestätigung codiert ist. Dieses optische Muster kann dann von dem Terminal, der ebenfalls einen optischen Sensor hat, erfasst werden. Diese Ausführungsform hat den Vorteil, dass das Terminal nicht mit dem Netzwerk verbunden zu sein braucht, was sicherheitstechnische Vorzüge hat.
Nach einer weiteren Ausführungsform der Erfindung ist das Dienst-Computersystem mit dem Terminal über einen von dem Netzwerk verschiedenen Kommunikationskanal verbunden, wie zum Beispiel ein internes Firmennetzwerk oder ein Virtual Private Network, über welches das Bestätigungssignal von dem Dienst- Computersystem an das Terminal übertragen wird. Nach Ausführungsformen der Erfindung wird zunächst eine erste Session zwischen dem internetbrowser des Nutzer-Computersystems und dem Dienst- Computersystem über das Internet aufgebaut, wobei es sich bei der ersten Session um eine http-Session oder eine https-Session handeln kann. Der Nutzer kann eine Transaktionsanforderung in den Internetbrowser eingeben, beispielsweise zur Ver- anlassung eines Bezahlvorgangs. Beispielsweise hat der Nutzer zuvor über das Dienst-Computersystem eine Ware bestellt und möchte diese bestellte Ware bezahlen, wozu der Nutzer die entsprechende Transaktionsanforderung in den Internetbrowser eingibt, welche an das Dienst-Computersystem über die erste Session übertragen wird.
Das Dienst-Computersystem erzeugt daraufhin eine Anforderung, d.h. einen Request eines Request-Response Protokolls. Der Request kann eine vordefinierte oder standardisierte Struktur haben. Beispielsweise kann der Request textbasiert sein, eine XML, ASN.1 oder binär-Struktur aufweisen oder als SAML-Request ausgebil- det sein. Der Request, beispielsweise also der SAML-Request, beinhaltet eine Attributspezifikation, welche die aus dem ID-Token für die Durchführung der Transaktion auszulesenden Attribute spezifiziert. Hierbei kann es sich um Attribute handeln, welche den Nutzer, der dem ID-Token zugeordnet ist, identifizieren und/oder die eine Bezahlinformation angeben, wie zum Beispiel eine Kontoverbindung oder Kre- ditkarteninformationen, und/oder Attribute, welche den ID-Token selbst betreffen, wie zum Beispiel dessen Gültigkeitsdauer, Ausstellungsdatum und/oder die ausstellende Organisation oder Behörde. Nach Ausführungsformen der Erfindung wird der Request von dem Dienst- Computersystem über das Nutzer-Computersystem an das ID-Provider- Computersystem übertragen. Aufgrund des Empfangs des Request durch das Nutzer-Computersystem wird der weitere Ablauf zur Erzeugung der Response, ein- schließlich der Authentisierung des Nutzers und des ID-Provider-Computersystems, ausgelöst.
Insbesondere kann die Attributspezifikation das Geburtsdatum des Nutzers beinhalten, falls zum Beispiel die Volljährigkeit des Nutzers als Voraussetzung für die Durchführung der Transaktion von dem Dienst-Computersystem zu prüfen ist. Der Request beinhaltet ferner Transaktionsdaten zur Spezifizierung der Transaktion, das heißt zum Beispiel einen Bezahlbetrag sowie Kontoinformationen, insbesondere die Kontoverbindung des Dienst-Computersystems, auf welche die Zahlung zu leisten ist. Ferner beinhaltet der Request einen Uniform Ressource Locator (URL) des ID-Provider-Computersystems, welches die Attribute aus dem ID-Token auslesen soll, sowie eine URL des Dienst-Computersystems zur Angabe eines Empfängers für die Response, die aufgrund der Request von dem ID-Provider-Computersystem zu generieren ist. Das Dienst-Computersystem erzeugt für den Request eine Kennung, die den Request eindeutig identifiziert, wie z.B. einen globally unique identifier (GUID). Der Request beinhaltet diese Kennung.
Der Request wird von dem Dienst-Computersystem signiert, und zwar mithilfe eines privaten Schlüssels eines kryptografischen Schlüsselpaars, welches dem Dienst- Computersystem zugeordnet ist.
Aufgrund der Transaktionsanforderung wird über die erste Session eine Webseite von dem Dienst-Computersystem an das Nutzer-Computersystem übertragen und durch den Internetbrowser bzw. das Anwendungsprogramm, insbesondere eine sog. App, angezeigt. Zusammen mit der Webseite wird der Request übertragen, der jedoch nicht angezeigt wird. Die Webseite hat zumindest ein Eingabefeld zur Eingabe von Zusatzinformationen, welche für die Durchführung der Transaktion benötigt werden. Bei dieser Zusatzinformation kann es sich zum Beispiel um eine Kontoverbindung oder Kreditkarteninformationen des Nutzers handeln und/oder um eine Authentifizierungsinformation, um den Nutzer gegenüber dem Dienst-Computersystem zu authentifizieren. Zum Beispiel kann es sich bei der Authentifizierungsinformation um ein One-Time Password (OTP) handeln. Vorzugsweise wird die Zusatzinformation mithilfe des öffentlichen Schlüsseis des Dienst-Computersystems durch das Nutzer-Computersystem verschlüsselt, sodass nur die verschlüsselte Zusatzinformation anschließend über eine zweite Session von dem Internetbrowser bzw. dem Anwendungsprogramm an das ID-Provider-Computersystem über das Netzwerk weitergeleitet wird.
Über diese zweite Session wird auch der Request weitergeleitet. Der Aufbau der zweiten Session erfolgt durch Aufruf der URL des I D-Provider-Computersystems, welche in dem Request beinhaltet ist. Die zweite Session wird dabei als geschützte Kommunikationsverbindung aufgebaut, und zwar mit einer verschlüsselten Transportschicht, das heißt mit Transport Layer Security (TLS), die auch als Secure So- ckets Layer (SSL) bezeichnet wird, insbesondere als https-Session. Nach Ausführungsformen der Erfindung erzeugt das ID-Provider-Computersystem aufgrund des Empfangs des Requests über die zweite Session einen Identifikator für eine noch aufzubauende dritte Session, d.h. eine sog. Session-ID. Das ID- Provider-Computersystem speichert den Request sowie die zusammen mit dem Request über die zweite Session empfangene Zusatzinformation mit der Session-ID für die dritte Session.,
Das ID-Provider-Computersystem sendet dann eine Nachricht über die zweite Session, welche eine logische Adresse des ID-Provider-Computersystems und beispielsweise auch die Session-ID der dritten Session beinhaltet. Von dieser logi- sehen Adresse kann der Internetbrowser bzw. das Anwendungsprogramm zu einem späteren Zeitpunkt die Response auf den zuvor weitergeleiteten Request abrufen. Bei der logischen Adresse kann es sich um einen uniform resource locator (URL) handeln, durch den die Response abrufbar ist. Anschließend wird die dritte Session auf dem Application Layer zwischen einem Programm des Nutzer-Computersystems und dem I D-Provider-Computersystem aufgebaut, und zwar über den gesicherten Transportlayer der zweiten Session. Bei dem Programm kann es sich zum Beispiel um ein Browser-Plug-in des Internet- browsers oder ein von dem Internetbrowser verschiedenes Anwendungsprogramm handeln.
Das I D-Provider-Computersystem überträgt dann diejenigen Informationen über die dritte Session an das Programm, die für das Auslesen des oder der Attribute aus dem ID-Token benötigt werden. Diese Informationen beinhalten zumindest ein Zertifikat des ID-Provider-Computersystems, welches eine Angabe von Leserechten des ID-Provider-Computersystems zum Lesen von einem oder mehrerer Attribute beinhaltet. Das Programm des Nutzer-Computersystems prüft dann, ob die in dem Zertifikat angegebenen Leserechte ausreichend sind, um einen Lesezugriff des ID-Provider- Computersystems auf das oder die gemäß der Attributspezifikation des Requests zu lesenden Attribute zuzulassen. Wenn die Leserechte des ID-Provider- Computersystems ausreichend sind, werden die folgenden weiteren Schritte durch- geführt: 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 Schnittsteile, wie zum Beispiel einer RFID oder einen N FC-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 SmartCa- rds. 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 bio- metrischen 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. c) Anschließend wird eine vierte Session auf dem Application Layer aufgebaut, und zwar zwischen einem Programm des lD-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. d) Über die vierte Session erfolgt dann eine gegenseitige Authentifizierung des ID-Tokens und des 1 D-Provider-Computersystems, beispielsweise mithilfe eines Challenge-Response-Protokolls. 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.
Das ID-Provider-Computersystem erzeugt dann eine Response, die das oder die ausgelesenen Attribute und die Kennung des Request und/oder die Zusatzinformation beinhaltet und zwar gemäß dem Request-Response Protokoll, dem der Request unterliegt. Bei einer SAML-Request wird also dementsprechend eine SAML- Response erzeugt. Über die Kennung des Request, die auch in der Response beinhaltet ist, wird hier die logische Zuordnung von Request und Response, d.h. das sog. Binding, hergestellt Die Response wird von dem I D-Provider-Computersystem signiert und zum Abrufen von der zuvor dem Nutzer-Computersystem über die Nachricht mitgeteilten logischen Adresse gespeichert. Das Nutzer-Computersystem liest dann diese Response von dem ID-Provider- Computersystem mit Hilfe der logischen Adresse, beispielsweise der URL, und leitet die Response über die erste Session an das Dienst-Computersystem weiter. Mithilfe der Kennung der Response wird diese dem Request und damit der angeforderten Transaktion zugeordnet und dann wird die Transaktion von dem Dienst- Computersystem ausgeführt, das heißt beispielsweise ein Bezahlvorgang ausgelöst und/oder ein bestelltes Produkt geliefert, wenn dies der Inhalt der Response erlaubt.
Nach einer Ausführungsform der Erfindung handelt es sich bei dem Programm des Nutzer-Computersystems um ein Browser-Plug-in des Internetbrowsers, wobei es sich bei dem Internetbrowser um ein übliches Browserprogramm, wie zum Beispiel Microsoft Internet Explorer, Safari, Google Chrome oder Firefox handeln kann. Alternativ kann es sich bei dem Programm des Nutzer-Computersystems um ein von dem Internetbrowser separates Anwendungsprogramm handeln. Nach einer Ausführungsform der Erfindung handelt es sich bei der von dem Nutzer eingegebenen Zusatzinformaiion um eine Bezahlinformation, wie zum Beispiel eine Kontoverbindung des Nutzers von der der in dem Request angegebene Bezahlbetrag abgebucht oder eingezogen werden soll. Das sogenannte Clearing, das heißt die Prüfung der Bonität des Kunden, sowie die Veranlassung des Zahlvorgangs kann dann durch das I D-Provider-Computersystem veranlasst werden, welches die Durchführung der Bezahlung mit der Response dem Dienst-Computersystem bestätigt. Dies hat den Vorteil, dass das Dienst- Computersystem keine Kenntnis hinsichtlich der Bezahlinformation des Nutzers, das heißt insbesondere seiner Kontoverbindung, erlangen muss.
Alternativ kann der Nutzer seine Bezahlinformation mit dem öffentlichen Schlüssel des Dienst-Computersystems verschlüsseln, sodass nur die verschlüsselte Bezahlinformation des Nutzers an das ID-Provider-Computersystem übertragen wird. Das I D-Provider-Computersystem leitet dann die verschlüsselte Bezahlinformation mit der Response an das Dienst-Computersystem weiter, welches die Bezahlinformation entschlüsselt, und dann das Clearing durchführt sowie den Zahlbetrag von dem Konto des Nutzers gemäß der Bezahlinformation einzieht. Dies hat den Vorteil, dass das ID-Provider-Computersystem keine Kenntnis von den Bezahlinformationen des Nutzers erlangt.
Nach einer weiteren Ausführungsform der Erfindung gehört zu dem Computersystem ein Terminal, wie zum Beispiel ein Bankautomat oder ein Verkaufsautomat. Der Nutzer kann eine Anforderung in den Automat eingeben, wie zum Beispiel zur Abhebung von Bargeld oder zum Kauf eines bestimmten Produkts, wie zum Beispiel eines Getränks. Der Automat zeigt auf diese Nutzeranforderung hin ein optisch erfassbares Muster, wie zum Beispiel einen QR-Code, auf seinem Bildschirm an, das eine Information beinhaltet, um die Durchführung der Transaktion zu initiieren.
Nach einer weiteren Ausführungsform der Erfindung ist das Terminal als mobiles Telekommunikationsgerät, insbesondere als sog. Smartmeter, für die Gebührenerfassung z.B. des Strom oder Gasverbrauchs, Taxameter oder Smartphone mit einer Gebührenerfassungsfunktion ausgebildet.
Beispielsweise kann auf dem Smartphone eines Verkäufers die URL des Dienst- Computersystems, der Bezahlbetrag sowie der Zahlungsempfänger in Form eines optisch erfassten Musters ausgegeben und mit der Kamera des Nutzer- Computersystems, welches ebenfalls als Smartphone ausgebildet sein kann, erfasst werden. Auf diese Art und Weise können alltägliche Bezahlvorgänge auf sichere und bequeme Art und Weise sicher abgewickelt werden.
Im Weiteren werden Ausführungsformen der Erfindung mit Bezugnahme auf die Zeichnungen näher erläutert.
Es zeigen: ein Blockdiagramm einer Ausführungsform eines erfindungsgemäßen ID-Tokens, Fig. 2 eine Anordnung einer Ausführungsform eines erfindungsgemäßen
Computersystems zur Durchführung einer Ausführungsform eines erfindungsgemäßen Verfahrens.
Elemente der Ausführungsformen der nachfolgenden Figuren, die zueinander identisch sind oder einander entsprechen, sind jeweils mit denselben Bezugszeichen gekennzeichnet. Die Figur 1 zeigt einen ID-Token 106, bei dem es sich zum Beispiel um einen elektronischen Personalausweis handeln kann.
Der geschützte Speicherbereich 120 des ID-Token 106 dient zur Speicherung eines Referenzwerts, der für die Authentifizierung eines Nutzers 102 gegenüber dem !D- Token 106 benötigt wird. Bei diesem Referenzwert handelt es sich beispielsweise um eine Kennung, insbesondere eine so genannte Personal Identification Number (PIN), oder um Referenzdaten für ein biometrisches Merkmal des Nutzers 102, welches für die Authentifizierung des Nutzers gegenüber dem ID-Token 106 verwendet werden kann.
Der geschützte Bereich 122 dient zur Speicherung eines privaten Schlüsseis und der geschützte Speicherbereich 124 dient zur Speicherung von Attributen, zum Beispiel des Nutzers 102, wie zum Beispiel dessen Name, Wohnort, Geburtsdatum, Geschlecht, und/oder von Attributen, die den ID-Token selbst betreffen, wie zum Beispiel die Institution, die den ID-Token erstellt oder ausgegeben hat, die Gültigkeitsdauer des ID-Tokens, einen Identifikator des ID-Tokens, wie zum Beispiel eine Passnummer oder eine Kreditkartennummer.
Der elektronische Speicher 1 18 kann ferner einen Speicherbereich 126 zur Spei- cherung eines Zertifikats aufweisen. Das Zertifikat beinhaltet einen öffentlichen Schlüssel, der dem in dem geschützten Speicherbereich 122 gespeicherten privaten Schlüssel zugeordnet ist. Das Zertifikat kann nach einem Public Key Infrastruktur (PKI) Standard erstellt worden sein, beispielsweise nach dem X.509 Standard. Das Zertifikat muss nicht zwangsläufig in dem elektronischen Speicher 118 des ID- Tokens 106 gespeichert sein. Alternativ oder zusätzlich kann das Zertifikat auch in einem öffentlichen Verzeichnisserver gespeichert sein. Der ID-Token 106 hat einen Prozessor 128. Der Prozessor 128 dient zur Ausführung von Programminstruktionen 130, 132 und 134. Die Programminstruktionen 130 dienen zur Nutzerauthentifizierung, d.h. zur Authentifizierung des Nutzers 102 gegenüber dem ID-Token. Bei einer Ausführungsform mit PIN gibt der Nutzer 102 seine PIN zu seiner Authentifizierung in den ID-Token 106 ein, beispielsweise über das Nutzer- Computersystem 100. Durch Ausführung der Programminstruktionen 130 wird dann auf den geschützten Speicherbereich 120 zugegriffen, um die eingegebene PIN mit dem dort gespeicherten Referenzwert der PIN zu vergleichen. Für den Fall, dass die eingegebene PIN mit dem Referenzwert der PIN übereinstimmt, gilt der Nutzer 102 als authentifiziert.
Alternativ wird ein biometrisches Merkmal des Nutzers 102 erfasst. Beispielsweise hat der ID-Token 106 hierzu einen Fingerabdrucksensor oder ein Fingerabdruck- sensor ist an das Nutzer-Computersystem 100 angeschlossen. Die von dem Nutzer 102 erfassten biometrischen Daten werden durch Ausführung der Programminstruktionen 130 bei dieser Ausführungsform mit den in dem geschützten Speicherbereich 120 gespeicherten biometrischen Referenzdaten verglichen. Bei hinreichender Übereinstimmung der von dem Nutzer 102 erfassten biometrischen Daten mit den biometrischen Referenzdaten gilt der Nutzer 102 als authentifiziert.
Die Programminstruktionen 134 dienen zur Ausführung der den ID-Token 106 betreffenden Schritte eines kryptographischen Protokolls zur Authentifizierung eines I D-Provider-Computersystems 136 gegenüber dem ID-Token 106. Bei dem krypto- graphischen Protokoll kann es sich um ein Challenge-Response-Protokoll basierend auf einem symmetrischen Schlüssel oder einem asymmetrischen Schlüsselpaar handeln. Beispielsweise wird durch das kryptographische Protokoll ein Extended Access Control-Verfahren implementiert, wie es für maschinenlesbare Reisedokumente (machine-readable travel documents - MRTD) von der internationalen Luftfahrtbehörde (ICAO) spezifiziert ist. Durch erfolgreiche Ausführung des kryptographischen Protokolls authentifiziert sich das 1 D-Provider-Computersystem 136 gegenüber dem ID-Token und weist dadurch seine Leseberechtigung zum Lesen der in dem geschützten Speicherbereich 124 gespeicherten Attribute nach. Die Authentifizierung kann auch gegenseitig sein, d.h. auch der ID-Token 106 muss sich dann gegenüber dem ID-Provider-Computersystem 136 nach demselben oder einem anderen kryp- tographischen Protokoll authentifizieren.
Die Programminstruktionen 132 dienen zur Ende-zu-Ende-Verschlüsselung von zwischen dem ID-Token 106 und einem ID-Provider-Computersystem 136 (vgl. Fig. 2) übertragenen Daten, zumindest aber der von dem ID-Provider-Computersystem 136 aus dem geschützten Speicherbereich 124 ausgelesenen Attribute. Für die Ende-zu-Ende-Verschlüsselung kann ein symmetrischer Schlüssel verwendet werden, der beispielsweise anlässlich der Ausführung des kryptographischen Protokolls zwischen dem ID-Token 106 und dem ID-Provider-Computersystem 136 vereinbart wird.
Der ID-Token 106 hat eine Schnittstelle 108 zur Kommunikation mit einer entsprechenden Schnittstelle 104 eines Nutzer-Computersystems 00 (vergleiche Figur 2). Die Schnittstelle kann kontaktlos oder kontaktbehaftet ausgebildet sein. Insbesondere kann es sich um eine RFID- oder um eine NFC-Kommunikationsschnittstelle handeln.
Der Zugriff auf den geschützten Speicherbereich 124 zum Lesen einer oder mehrerer der Attribute kann nur über den Prozessor 128 des ID-Tokens 06 erfolgen, da der geschützte Speicherbereich 124 sowie auch die weiteren geschützten Spei- cherbereiche 120, 122 nicht unmittelbar zum Beispiel über ein Bussystem mit der Schnittstelle 108 verbunden sind, sondern nur mit dem Prozessor 128, das heißt ein Zugriff über die Schnittstelle 08 unmittelbar auf den geschützten Speicherbereich 124 ist bereits schaltungstechnisch ausgeschlossen. Allein der Prozessor 128 kann also lesend auf den geschützten Speicherbereich 124 zugreifen, um dann gegebenenfalls die ausgelesenen Attribute über die Schnittstelle 108 auszugeben.
Die Figur 2 zeigt ein Nutzer-Computersystem 100 des Nutzers 02. Bei dem Nutzer- Computersystem 100 kann es sich um einen Personal-Computer (PC)f einen tragbaren Computer, wie zum Beispiel einen Laptop, Notebook oder Tablet-Computer, ein mobiles Telekommunikationsgerät, insbesondere ein Smartphone handeln.
Das Nutzer-Computersystem hat zumindest einen Prozessor 110 zur Ausführung eines Anwendungsprogramms 1 12. Das Anwendungsprogramm 112 ist dazu ausgebildet, über eine Netzwerk-Schnittstelle 114 des Nutzer-Computersystems 100 über ein Netzwerk 116 zu kommunizieren. Beispielsweise handelt es sich bei dem Anwendungsprogramm um einen Internet-Browser oder ein anderes spezialisiertes Anwendungsprogramm, welches über das Netzwerk 116 kommunizieren kann, ins- besondere ein html-fähiges Anwendungsprogramm.
Der Prozessor 1 10 dient zur Ausführung eines weiteren Programms 1 3, bei dem es sich beispielsweise um ein Plug-in für das Anwendungsprogramm 1 12 handeln kann, beispielsweise um ein Browser-Plug-in, wenn das Anwendungsprogramm 12 als Internet-Browser ausgebildet ist, oder um ein von dem Anwendungsprogramm separates Programm.
Bei dem Netzwerk kann es sich um ein Computernetzwerk, wie zum Beispiel das Internet, handeln. Insbesondere kann das Netzwerk 16 auch ein Mobilfunknetz- werk beinhalten.
Das I D-Provider-Computersystem 136 hat eine Netzwerk-Schnittstelle 138 zur Kommunikation über das Netzwerk 116. Das ID-Provtder-Computersystem 136 hat ferner einen Speicher 140 mit einem geschützten Speicherbereich 141 , in dem ein privater Schlüssel 142 des I D-Provider-Computersystems 136 gespeichert ist, sowie auch das entsprechende Zertifikat 144. Auch bei diesem Zertifikat kann es sich beispielsweise um ein Zertifikat nach einem PKI-Standard, wie zum Beispiel X.509 handeln. Das ID-Provider-Computersystem 136 hat ferner zumindest einen Prozessor 145 zur Ausführung von Programminstruktionen 146 und 148. Durch Ausführung der Programminstruktionen 146 werden die das ID-Provider-Computersystem 136 betreffende Schritte des kryptographischen Protokolls ausgeführt. Insgesamt wird also das kryptographische Protokoll durch Ausführung der Programminstruktionen 134 durch den Prozessor 128 des ID-Tokens 106 sowie durch Ausführung der Programminstruktionen 146 durch den Prozessor 145 des ID-Provider- Computersystems 136 implementiert. Die Programminstruktionen 148 dienen zur Implementierung der Ende-zu-Ende- Verschlüsselung auf Seiten des I D-Provider-Computersystems 136, beispieisweise basierend auf dem symmetrischen Schlüssel, der anlässlich der Ausführung des kryptographischen Protokolls zwischen dem ID-Token 106 und dem ID-Provider- Computersystem 136 vereinbart worden ist. Prinzipiell kann jedes an sich vor be- kannte Verfahren zur Vereinbarung des symmetrischen Schlüssels für die Ende-zuEnde-Verschlüsselung verwendet werden, wie zum Beispiel ein Diffie-Hellman- Schlüsselaustausch.
Das ID-Provider-Computersystem 136 befindet sich vorzugsweise in einer beson- ders geschützten Umgebung, insbesondere in einem so genannten Trust-Center, sodass das ID-Provider-Computersystem 36 in Kombination mit der Notwendigkeit der Authentifizierung des Nutzers 102 gegenüber dem ID-Token 06 den Vertrauensanker für die Authentizität der aus dem ID-Token 106 ausgeiesenen Attribute bildet.
Ein Dienst-Computersystem 150 kann zur Entgegennahme einer Bestellung oder eines Auftrags für eine Dienstleistung oder ein Produkt, insbesondere eine Online- Dienstleistung, ausgebildet sein. Beispielsweise kann der Nutzer 102 online über das Netzwerk 116 ein Konto bei einer Bank eröffnen oder eine andere Finanz- oder Bankdienstleistung in Anspruch nehmen. Das Dienst-Computersystem 150 kann auch als Online-Warenhaus ausgebildet sein, sodass der Benutzer 102 beispieisweise online ein Mobiltelefon oder dergleichen erwerben kann. Ferner kann das Dienst-Computersystem 150 auch zur Lieferung von digitalen Inhalten ausgebildet sein, beispielsweise für den Download von Musik- und/oder Videodaten. Das Dienst-Computersystem 150 hat hierzu eine Netzwerk-Schnittstelle 152 zur Verbindung mit dem Netzwerk 1 16. Ferner hat das Dienst-Computersystem 150 zumindest einen Prozessor 154 zur Ausführung von Programminstruktionen 156. Durch Ausführung der Programminstruktionen 156 werden beispielsweise dynamische HTML-Seiten generiert, über die der Nutzer 102 seinen Auftrag oder seine Bestellung eingeben kann, sowie Transaktionen durchgeführt.
Je nach der Art des beauftragten oder bestellten Produkts oder der Dienstleistung muss das Dienst-Computersystem 50 ein oder mehrere Attribute des Nutzers 102 und/oder dessen ID-Token 106 anhand eines oder mehrerer vorgegebener Kriterien überprüfen. Nur wenn diese Prüfung bestanden wird, wird die Bestellung oder der Auftrag des Nutzers 102 entgegengenommen und/oder ausgeführt. Zur Durchführung einer elektronischen Transaktion kann wie folgt vorgegangen werden:
Der Nutzer 102 startet das Anwendungsprogramm 1 12 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 1 12 und dem Dienst-Computersystem 150 über das Netzwerk 1 16 aufgebaut wird. Der Nutzer kann dann über die erste Session 201 einen von dem Dienst-Computersystem 50 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 1 2 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 02. 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 femer (iii) eine Kennung 180 des Requests, beispielsweise eine GUID, die für das sogenannte Binding des Requests und einer daraufhin empfangenen Response 74 erforderlich ist. Für die Erzeugung der Kennung kann das Dienst-Computersystem 150 einen GUI D-Generator aufweisen. Die Request beinhaltet ferner (iv) eine URL des I D-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 02, eine Kreditkartennummer des Nutzers 102 oder andere ergänzende Transaktionsdaten und/oder um eine Authentifizierungs- Information zum Nachweis der Berechtigung des Nutzers 02 für die Durchführung der Transaktion, wozu der Nutzer 02 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 6 aufgebaut, und zwar mit Hilfe der URL des I D-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 1 3 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 36 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: 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 Schnittsteile 104 aufweist oder zum Auflegen des ID-Tokens 106 auf eine kontaktlos ausgebildete Schnittstelle 104.
Der Nutzer 02 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-Protokoils oder basierend auf einem Diffie-Helman-Schlüsselaustausch, wobei im Rahmen der Authentifizierung des Nutzers ein Session-Key vereinbart wird.
Unter der Voraussetzung der erfolgreichen Authentifizierung des Nutzers wird eine vierte Session 204 zwischen dem ID-Token 106 und dem I D-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.
Über die vierte Session erfolgt dann eine gegenseitige Authentifizie- rung 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 Figur 1) sowie das Zertifikat 144 des ID-Provider- Computersystems 136 über die vierte Session ausgetauscht werden.
Unter der Voraussetzung der erfolgreichen Authentifizie ung 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 I D-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 I D-Provider-Computersystem 136 geschützt werden. Hierzu sendet das I D-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 I D-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 ausgeiesenen Attribute, die Zusatzinformation 168 oder - je nach Ausführungsform - 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 12, ü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 At- tribute 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 weiterge!eitet 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.
Nach einer Ausführungsform der Erfindung handelt es sich bei dem Programm 113 um einen Browser-Plug-in, das in einer Registry eines Betriebssystems des Nutzer- Computersystems mit einer Plug-in-Kennung registriert ist, wobei es sich bei dem Betriebssystem zum Beispiel um ein Windows-Betriebssystem, Android oder iOS handein kann. In diesem Fall beinhaltet die Nachricht 172 von dem ID-Provider- Computersystem an den Internet-Browser 112 diese Plug-in-Kennung 184, so dass das Plug-in 113 aufgrund des Empfangs der Nachricht gestartet wird. Nach einer weiteren Ausführungsform der Erfindung handelt es sich bei dem Programm 113 ein von dem Internet-Browser 112 separates Anwendungsprogramm, wie zum Beispiel eine sogenannte Bürger-App oder Ausweis-App. Dieses Anwendungsprogramm 113 wird von dem Internet-Browser 112 durch Aufruf einer lokalen URL gestartet, wobei die lokale URL eine fest vorgegebener Portnummer gemäß dem TCP-Protokoll beinhaltet. Diese lokale URL wird zusammen mit der Webseite 160 von dem Dienst-Computersystem 150 an das Nutzer-Computersystem 100 übertragen und zwar über die erste Session 201 , um das Starten des Anwendungsprogramms 113 mit Hilfe der lokalen URL durch den Internet-Browser 112 zu bewir- ken.
Für den Fall, dass nur das Chiffrat der Zusatzinformation 168, nicht aber die Zusatzinformation 168 selbst über die zweite Session 202 von dem Nutzer- Computersystem 100 an das ID-Provider-Computersystem 136 übertragen wird, beinhaltet auch die Response 174 nur dieses Chiffrat, nicht aber die Zusatzinformation 168 selbst. In diesem Fall entschlüsselt das Dienst-Computersystem 150 das Chiffrat mit Hilfe des privaten Schlüssels des Dienst-Computersystems 150, um dann mit Hilfe der Zusatzinformation 168 die angeforderte Transaktion durchzuführen. Hierbei kann es sich zum Beispiel um die Durchführung einer finanziellen Transaktion, wie zum Beispiel die Durchführung einer Überweisung in der Höhe des Bezahlbetrags handeln, der in der Zusatzinformation 168 angegeben ist.
Alternativ ist es aber auch möglich, dass die Durchführung der Zahlung seitens des I D-Provider-Computersystems 136 ausgelöst wird. Dies kann so erfolgen, dass das l D-Provider-Computersystem 136 die hierfür erforderlichen Transaktionsdaten über den Request 166 und die Zusatzinformationen 168 empfängt und dann die Zahlung durchführt oder veranlasst. Die Response 174 beinhaltet dann eine Bestätigung des I D-Provider-Computersystems 36, dass die Zahlung erfolgt ist. Eine Übermittlung der Zusatzinformation 168 an das Dienst-Computersystem 150 kann dann unterbleiben, was zum Schutz der Vertraulichkeit dieser Zusatzinformationen 168 vorteilhaft ist, denn diese Zusatzinformationen 168 müssen dann nur gegenüber dem vertrauenswürdigen ID-Provider-Computersystem 136 offengelegt werden. Die eigentliche Transaktion, z.B. die Lieferung des bestellten Produkts, wird dann nach Empfang der Zahlungsbestätigung, die in der Response 174 beinhaltet ist, von dem Dienst-Computersystem 150 veranlasst.
Nach einer Ausführungsform der Erfindung beinhaltet die Zusatzinformation 168 ein OTP. Das Dienst-Computersystem 150 prüft dann als zusätzliche Voraussetzung für die Durchführung der Transaktion, ob das OTP gültig ist. Vorzugsweise wird das OTP durch das Nutzer-Computersystem 100 mit dem öffentlichen Schlüssel des Dienst-Computersystems 150 verschlüsselt und dann von dem Dienst- Computersystems 150 nach dem Empfang der Zusatzinformation mit dem ver- schlüsselten OTP entschlüsselt, um dann dessen Validität zu prüfen.
Nach einer Ausführungsform der Erfindung gehört zu dem erfindungsgemäßen Computersystem ein Terminal 186, bei dem es sich zum Beispiel um einen Automat, insbesondere einen Bankautomat oder Verkaufsautomat, handeln kann. Bei- spielsweise kann der Nutzer 102 in das Terminal 186 einen Geldbetrag eingeben, um Bargeld von seinem Konto abzuheben. Auf einem Display 188 des Automat wird dann ein optisch erfassbares Muster angezeigt, wie zum Beispiel ein QR-Code, der ein URL des Dienst-Computersystems 150 sowie den von dem Nutzer 102 gewünschten Geldbetrag beinhaltet.
Dieses optische Muster wird von dem Display 88 mit Hilfe einer Kamera 190 des Nutzer-Computersystems 100 erfasst. Das Nutzer-Computersystem 100 erzeugt dann die Transaktionsanforderung 158, die diesen Geldbetrag angibt. Die erste Session 201 wird hier mit Hilfe der aus dem optischen Muster erfassten URL des Dienst-Computersystems 150 aufgebaut und die Transaktionsanforderung 158 mit dem gewünschten Geldbetrag wird über diese erste Session 201 an das Dienst- Computersystem 150 übermittett. Das Dienst-Computersystem 150 erzeugt dann einen entsprechenden Request 166, um die für die Auszahlung des gewünschten Geldbetrags erforderlichen Attribute und Zusatzinformationen 168 abzufragen.
Je nach Ausführungsform wird dann durch die ID-Provider-Computersystem 136 oder durch das Dienst-Computersystem 150 die Belastung eines Kontos des Nutzers 102, welches dieser zum Beispiel in der Zusatzinformation 168 angegeben hat, veranlasst. Aufgrund des Empfangs der Response 174 und der Veranlassung der Zahlung empfängt dann das Terminal 186 ein Signal zur Ausgabe des gewünschten Geldbetrags zum Beispiel in Form von Bargeld oder zur Aufladung einer Cash-Card des Nutzers 102. Dies kann so erfolgen, dass das Terminal 186 unmittelbar mit dem Diensf-Computersystem 150 verbunden ist oder über das Netzwerk 116.
Alternativ kann es sich bei dem Terminal 186 auch um einen Verkaufsautomat handeln, wobei dann kein Bargeld, sondern ein gewünschtes Produkt, wie zum Beispiel eine Getränkedose oder eine Zigarettenschachtel von dem Verkaufsautomaten abgegeben wird, nachdem die Durchführung der Zahlung von dem Dienst- Computersystem 150 signalisiert worden ist.
In einer weiteren Anwendung kann es sich bei dem Terminal 186 um ein mobiles Telekommunikationsgerät, insbesondere ein Smartphone handein. Wenn der Nutzer 102 von dem Inhaber des Terminals 186 etwas kaufen möchte, so gibt der Inhaber des Terminals 186 den entsprechenden Kaufpreis in das Terminal 186 ein, so dass dann auf dem Display 188 in Form des optisch erfassbaren Musters wiederum dieser Kaufpreis als Bezahlbetrag sowie die URL des Dienst-Computersystems 150 ausgegeben wird. Nach Beendigung der Transaktion empfängt das Terminal 186 von dem Dienst-Computersystem 150 ein Signal, welches anzeigt, dass der Be- zahlvorgang erfolgt ist und der Inhaber des Terminals 186 gibt dann die Ware an den Nutzer 102 ab. Dies kann auch in dem Kassensystem zum Beispiel eines Supermarkts implementiert sein. Eine weitere Anwendung ist ein Taxameter, weiches Taxigebühren erfasst oder ein anderer Verbrauchszähler, wie zum Beispiel ein Verbrauchszähler für den Strom- oder Gasverbrauch eines Haushalts, insbesondere ein sog. Smartmeter.
Bezu gszeichen liste
100 Nutzer-Computersystem
102 Nutzer
104 Schnittstelle
106 ID-Token
108 Schnittstelle
110 Prozessor
112 Anwendungsprogramm/Internet-Browser
113 Programm/Anwendungsprogramm
114 Netzwerk-Schnittstelle
116 Netzwerk
118 elektronischer Speicher
120 geschützter Speicherbereich
122 geschützter Speicherbereich
124 geschützter Speicherbereich
126 Speicherbereich
128 Prozessor
130 Programminstruktionen
132 Programminstruktionen
134 Programminstruktionen
136 ID-Provider-Computersystem
138 Netzwerk-Schnittstelle
140 Speicher
141 geschützter Speicherbereich
142 privater Schlüsse!
144 Zertifikat
145 Prozessor
146 Programminstruktionen
148 Programminstruktionen
150 Dienst-Computersystem
152 Netzwerk-Schnittstelle
154 Prozessor Programminstruktionen
Transaktionsanforderung
Webseite
Eingabefeld
Eingabeelement
Request
Zusatzinformation
Programminstruktionen
Nachricht
Response
lokale Verbindung
Programminstruktionen
Kennung
Lesekommando
Kennung
Terminal
Display
Kamera

Claims

P a t e n t a n s p r ü c h e
1. Elektronisches Transaktionsverfahren unter Verwendung eines ID-Tokens (106), der einem Nutzer (102) zugeordnet ist, wobei der ID-Token einen elektronischen Speicher (118) mit einem geschützten Speicherbereich ( 24) aufweist, in dem ein oder mehrere Attribute gespeichert sind, wobei ein Zugriff auf den geschützten Speicherbereich nur über einen Prozessor (128) des ID- Tokens möglich ist, und wobei der ID-Token eine Kommunikatsons- Schnittstelle (108) zur Kommunikation mit einem Lesegerät eines Nutzer-
Computersystems (100) aufweist, mit folgenden Schritten:
- Anzeige eines optisch lesbaren Musters auf einem Bildschirm (188) eines Terminals (186), wobei in dem optisch lesbaren Muster eine Information co- diert ist, die zumindest eine logische Adresse, insbesondere eine URL, eines
Dienst-Computersystems (150) und Transaktionsdaten beinhaltet,
- Erfassung des Musters mithilfe eines optischen Sensors (190) des Nutzer- Computersystems und Decodierung des Musters durch das Nutzer- Computersystem,
- Übertragung einer Transaktionsanforderung (158) von dem Nutzer- Computersystem an die logische Adresse des Dienst-Computersystems über das Netzwerk, wobei die Transaktionsanforderung die Transaktionsdaten beinhaltet,
- Übertragung eines Request (166) von dem Dienst-Computersystem über das Nutzer-Computersystems (100) an ein l D-Provider-Computersystem (136), wobei die Übertraung über das Netzwerk erfolgt, wobei der Request eine Attributspezifikation, der aus dem ID-Token für die Durchführung der Transaktion auszulesenden Attnbute beinhaltet,
- Authentifizierung des Nutzers gegenüber dem ID-Token,
- Authentifizierung des I D-Provider-Computersystems gegenüber dem ID- Token über das Netzwerk,
- unter der Voraussetzung der erfolgreichen Authentifizierung des Nutzers und des ID-Provider-Computersystems gegenüber dem ID-Token, Auslesen des oder der Attribute gemäß der Attributspezifikation durch das ID-Provider- Computersystem aus dem ID-Token über das Netzwerk mit Ende-zu-Ende- Verschlüsselung,
- Übertragung einer Response (174) von dem ID-Provider-Computersystem über das Nutzer-Computersystem an das Dienst-Computersystem, wobei die Übertragung der Response über das Netzwerk erfolgt, wobei die Response das oder die ausgelesenen Attribute beinhaltet, und wobei die Response von dem ID-Provider-Computersystem signiert ist,
- Durchführung der Transaktion mithilfe der Transaktionsdaten und des oder der Attribute durch das Dienst-Computersystem.
2. Verfahren nach Anspruch 1 , mit dem weiteren Schritt der Prüfung, ob das oder die Attribute ein vorgegebenes Kriterium erfüllen durch das Dienst- Computersystem, wobei die Transaktion nur durchgeführt wird, wenn das Kriterium erfüllt ist.
3. Verfahren nach Anspruch 1 oder 2, wobei die Transaktionsdaten einen Zahlungsbetrag beinhalten und wobei die Transaktion von dem Dienst- Computersystem initiiert wird, um eine finanzielle Transaktion in Höhe des Zahlungsbetrags durchzuführen.
4. Verfahren nach Anspruch 3, wobei es sich bei dem Terminal um ein Bankterminal zur Auszahlung von Bargeld oder zur Aufladung einer Geldkarte handelt, wobei der Nutzer den Zahlungsbetrag durch Eingabe in den Bankterminal auswählt, und ein Konto des Nutzers aufgrund der finanziellen Transaktion in Höhe des Zahlungsbetrags belastet wird, woraufhin das Dienst-Computersystem ein Bestätigungssignal an das Bankterminal sendet, und das Bankterminal aufgrund des Bestätigungssignals das Bargeid in Höhe des Zahlungsbetrags auszahlt oder die Geldkarte in Höhe des Zahlungsbetrags auflädt.
5. Verfahren nach Anspruch 3, wobei es sich bei dem Terminal um einen Verkaufsautomat handelt, wobei es sich bei dem Zahlungsbetrag um einen Verkaufspreis für ein von dem Verkaufsautomat abgebbares Produkt handelt, wie zum Beispiel um eine Fahrkarte, Eintrittskarte, Nahrungs- oder Genussmittel, wobei das Dienst-Computersystem die finanzielle Transaktion initiiert, um ein Konto des Benutzers in Höhe des Zahiungsbetrags zu belasten, woraufhin das Dienst-Computersystem ein Bestätigungssigna! an den Verkaufsautomat überträgt, und der Verkaufsautomat aufgrund des Empfangs des Bestätigungssignais das Produkt abgibt.
6. Verfahren nach Anspruch 3, wobei es sich bei dem Terminal um ein Taxameter handelt, wobei es sich bei dem Zahlungsbetrag um ein Beförderungsentgelt für eine Taxifahrt handelt, wobei das Dienst-Computersystem die finanzielle Transaktion initiiert, um ein Konto des Nutzers mit dem Zahlungsbetrag zu belasten, woraufhin das Dienst-Computersystem ein Bestätigungssignal an das Taxameter überträgt, und das Taxameter aufgrund des Empfangs des Betätigungssignals einen Beleg für die Bezahlung der Taxifahrt ausgibt.
7. Verfahren nach einem der vorhergehenden Ansprüche, wobei es sich bei dem Terminal um ein Smartphone handelt, wobei das optisch lesbare Muster eine Kontoverbindung eines Inhabers des Smartphones beinhaltet, wobei das Dienst-Computersystem die finanzielle Transaktion initiiert, um den Zahlungsbetrag auf das Konto des Inhabers des Smartphones zu überweisen, woraufhin das Dienst-Computersystem ein Bestätigungssignal an das Smartphone überträgt, welches von dem Smartphone über eine Nutzerschnittstelle ausgegeben wird, um dem Inhaber des Smartphones von der Zahlung zu informieren.
8. Verfahren nach Anspruch 1 oder 2 , wobei es sich bei dem Terminal um einen Verbrauchszähler, insbesondere zur Erfassung eines Strom- oder Gasverbrauchs, handelt, und wobei das optisch lesbare Muster einen von dem Verbrauchszähler erfassten Verbrauchsstand beinhaltet, wobei das Dienst- Computersystem die Transaktion in Form einer Datenbank-Transaktion durchführt, um den Verbrauchsstand zu speichern, wobei das Dienst- Computersystem vorzugsweise ein Bestätigungssignal an den Verbrauchszähler sendet, nachdem die Speicherung erfolgt ist.
9. Verfahren nach einem der vorhergehenden Ansprüche 4 bis 7, wobei das Bestätigungssignal über das Netzwerk von dem Dienst-Computersystem gesendet wird.
10. Verfahren nach Anspruch 9, wobei das Bestätigungssignal an das Nutzer- Computersystem gesendet und von dem Nutzer-Computersystem als optisches Muster ausgegeben wird, wobei das Terminal zur Erfassung des optischen Musters von dem Nutzer-Computersystem ausgebildet ist.
1 1. Verfahren nach einem der vorhergehenden Ansprüche, mit folgenden Schritten
- Aufbau einer ersten Session (201) zwischen einem Anwendungsprogramm (1 2), insbesondere einem Internetbrowser des Nutzer- Computersystems und dem Dienst-Computersystem ( 50) über das Netzwerk (1 6),
- Empfang der Transaktionsanforderung (158) über die erste Session durch das Dienst-Computersystem von dem Anwendungsprogramm (112),
- Erzeugung eines Request (166) durch das Dienst-Computersystem aufgrund des Empfangs der Transaktionsanforderung, wobei der Request von dem Dienst-Computersystem signiert wird und der Request eine At- tributspezifikation, der aus dem ID-Token für die Durchführung der Transaktion auszulesenden Attribute, Transaktionsdaten zur Spezifizierung der Transaktion, eine Kennung (180) des Request, eine URL eines ID-Provider-Computersystems und eine URL des Dienst- Computersystems beinhaltet,
- Übertragung einer Webseite (160) und des Request über die erste Session von dem Dienst-Computersystem an das Nutzer-Computersystem, wobei die Webseite ein Eingabefeld (162) zur Eingabe einer Zusatzinformation ( 68) für die Durchführung der Transaktion aufweist,
- Anzeige der Webseite durch das Anwendungsprogramm und Eingabe der Zusatzinformation durch den Nutzer in das Eingabefeld,
- Aufbau einer zweiten Session (202) zwischen dem Anwendungsprogramm ( 12) und dem ID-Provider-Computersystem über das Netzwerk mithilfe der URL des ID-Provider-Computersystems, wobei die zweite Session mit einem gesicherten Transportlayer aufgebaut wird,
- Weiterleitung des Request und der Zusatzinformation von dem Anwendungsprogramm an das I D-Provider-Computersystem über die zweite Session,
- aufgrund des Empfangs des Request, Erzeugung einer Session-ID für eine dritte Session (203) durch das ID-Provider-Computersystem und Speicherung des Request sowie der Zusatzinformation durch das ID- Provider-Computersystem,
- Senden einer Nachricht von dem ID-Provider-Computersystem an das
Anwendungsprogramm (1 12) mit der Session-ID der dritten Session und einer logischen Adresse, insbesondere einer URL, über die zweite Session,
- Aufbau der dritten Session zwischen einem Programm (113) des Nutzer- Computersystems und dem ID-Provider-Computersystem über den gesicherten Transportlayer der zweiten Session, wobei das Programm von dem Anwendungsprogramm (112) verschieden sein kann,
- Übertragung zumindest eines Zertifikats (144) des ID-Provider- Computersystems an das Programm (1 13), wobei das Zertifikat eine An- gäbe von Leserechten des I D-Provider-Computersystems zum Lesen von einem oder mehreren der in dem ID-Token gespeicherten Attribute beinhaltet, wobei die Übertragung des Zertifikats über die dritte Session erfolgt,
- Prüfung durch das Programm (1 13), ob die in dem Zertifikat angegebe- nen Leserechte ausreichend sind, um einen Lesezugriff des ID-Provider-
Computersystems auf das oder die gemäß der Attributspezifikation zu lesenden Attribute zu zulassen, und nur wenn die Leserechte ausreichend sind:
a) Aufbau einer lokalen Verbindung (176) zwischen dem Lesegerät des Nutzer-Computersystems und dem ID-Token,
b) Authentifizierung des Nutzers gegenüber dem ID-Token, wobei ein Session-Key vereinbart wird, c) Aufbau einer vierten Session (204) zwischen dem ID-Token und dem ID-Provider-Computersystem über die lokale Verbindung und die dritte Session mit einer Ende-zu-Ende Verschlüsselung mithilfe des Session-Key,
d) Gegenseitige Authentifizierung des ID-Tokens und des I D-Provider- Computersystems über die vierte Session,
e) Auslesen des oder der Attribute gemäß der Attributspezifikation
durch das ID-Provider-Computersystem über die vierte Session aus dem ID-Token.
- Erzeugung der Response (174), die das oder die ausgelesenen Attribute und zumindest die Kennung (180) des Request beinhaltet, und die von dem ID-Provider-Computersystem signiert wird,
- Speicherung der Response zum Abrufen mit Hilfe der logischen Adresse,
- Lesen der Response von dem ID-Provider-Computersystem durch das Nutzer-Computersystem durch Abruf der Response mittels eines Lesekommandos von der logischen Adresse über das Netzwerk,
- Weiterleitung der Response durch das Nutzer-Computersystem über die erste Session an das Dienst-Computersystem,
- Zuordnung der Response zu dem Request mit Hilfe der Kennung, die in der Response beinhaltet ist, durch das Dienst-Computersystem,
- Durchführung der Transaktion mithilfe der Response durch das ID- Provider-Computersystem.
12 Verfahren nach Anspruch 11 , wobei es sich bei dem Anwendungsprogramm um einen Internetbrowser handelt, und das weitere Programm ein Plug-in des Internetbrowsers ist, wobei das Plug-in in einer Registry eines Betriebssystems des Nutzer-Computersystems mit einer Plug-in-Kennung ( 84) registriert ist, wobei die Nachricht von dem ID-Provider-Computersystem an den internetbrowser die Plug-in-Kennung beinhaltet, sodass das Plug-in aufgrund des Empfangs der Nachricht gestartet wird.
13. Verfahren nach Anspruch 11 oder 12, wobei es sich bei dem Programm um ein weiteres Anwendungsprogramm handelt, welches von dem Internetbrow- ser durch einen Aufruf einer lokalen URL gestartet werden kann, wobei die lokale URL eine fest vorgegebene Portnummer gemäß dem TCP-Protokoll beinhaltet, wobei die lokale URL zusammen mit der Webseite von dem Dienst-Computersystem an das Nutzer-Computersystem übertragen wird, um das Starten des weiteren Anwendungsprogramms mithilfe der lokalen URL durch den Internetbrowser zu bewirken,
14. Verfahren nach Anspruch 11 , 12 oder 13, wobei es sich bei der Zusatzinformation um eine Bezahlinformation des Nutzers, insbesondere eine Kontover- bindung oder Kreditkarteninformation, handelt. 5. Verfahren nach Anspruch 14, wobei die Zusatzinformation durch das Nutzer- Computersystem mithilfe des öffentlichen Schlüssels des Dienst- Computersystems verschlüsselt wird und nur die verschlüsselte Zusatzinformation an das ID-Provider-Computersystem über die zweite Session weitergeleitet wird, wobei die verschlüsselte Zusatzinformation in die Response eingeht und die verschlüsselte Zusatzinformation nach Empfang der
Response durch das Dienst-Computersystem mithilfe des privaten Schlüssels des Dienst-Computersystems entschlüsselt wird.
16. Verfahren nach einem der vorhergehenden Ansprüche 11 bis 15, wobei der Request eine Bezahlinformation des Dienst-Computersystems, wie zum Beispiel eine Kontoverbindung, beinhaltet und wobei die Zusatzinformation eine Bezahlinformation des Nutzers, wie zum Beispie! eine Kontoverbindung oder Kreditkarteninformationen des Nutzers, beinhaltet, und wobei die Transaktionsdaten des Request einen Zahlungsbetrag beinhalten, wobei die Zahlung durch das ID-Provider-Computersystem veranlasst wird, und die Response nicht die Bezahlinformation des Nutzers beinhaltet. 17. Verfahren nach einem der vorhergehenden Ansprüche 1 bis 16, wobei der Request eine Bezahiinformation des Dienst-Computersystems, wie zum Beispiel eine Kontoverbindung, beinhaltet und wobei die Zusatzinformation eine Bezahlinformation des Nutzers, wie zum Beispiel eine Kontoverbindung oder Kreditkarteninformationen des Nutzers, beinhaltet, und wobei die Transakti- onsdaten des Request einen Zahlungsbetrag beinhalten, wobei die Zahlung durch das Dienst-Computersystem veranlasst wird, und die Response die mit dem öffentlichen Schlüssel des Dienstcomputersystems verschlüsselte Bezahlinformation des Nutzers beinhaltet.
18. Verfahren nach einem der vorhergehenden Ansprüche, wobei es sich bei dem Muster um einen eindimensionalen, zweidimensionalen, High Capacity Color Barcode, Maxicode, QR-Code oder Data Matrix-Code oder eine zeitliche Reihenfolge mehrerer solcher Codes handelt. 9. Verfahren nach einem der vorhergehenden Ansprüche, wobei es sich bei dem ID-Token um ein Wert- oder Sicherheitsdokument handelt, das heißt insbesondere ein Ausweisdokument, das heißt ein ID-Dokument, insbesondere einen elektronischen Personalausweis, Reisepass, Führerschein, Firmenausweis oder ein Zahlungsmittel, wie zum Beispiel eine Banknote, eine Kreditkarte oder einen sonstigen Berechtigungsnachweis, wie zum Beispiel eine Eintrittskarte, einen Frachtbrief oder ein Visum, insbesondere eine Chipkarte, insbesondere mit RFID- und/oder NFC-Schnittstelle.
20. Verfahren nach einem der vorhergehenden Ansprüche, wobei die Response auch die Zusatzinformationen beinhaltet.
2 . Verfahren nach Anspruch 20, wobei die Zusatzinformation ein OTP beinhaltet und das Dienst-Computersystem (150) die Validität des OTP prüft, wobei die Transaktion nur durchgeführt wird, wenn das OTP valide ist.
22. Computersystem mit einem Terminal (186), einem Dienst-Computersystem (150), einem Nutzer-Computersystem (100) einem ID-Provider-
Comp utersystem (136) und einem ID-Token (106), der einem Nutzer (102) zugeordnet ist, wobei der ID-Token einen elektronischen Speicher ( 8) mit einem geschützten Speicherbereich (124) aufweist, in dem ein oder mehrere Attribute gespeichert sind, wobei ein Zugriff auf den geschützten Speicherbereich nur über einen Prozessor (128) des ID-Tokens möglich ist, und wobei der ID-Token eine Kommunikations-Schnittstelle (108) zur Kommunikation mit einem Lesegerät eines Nutzer-Computersystems (100) aufweist, wobei der Terminal, das Dienst-Computersystem, das Nutzer- Computersystem, das I D-Provider-Computersystem und der ID-Token zur Durchführung der folgenden Schritte ausgebildet sind:
- Anzeige eines optisch lesbaren Musters auf einem Bildschirm (188) eines Terminals (186), wobei in dem optisch lesbaren Muster eine Information codiert ist, die zumindest eine logische Adresse, insbesondere eine URL, eines Dienst-Computersystems (150) und Transaktionsdaten beinhaltet,
- Erfassung des Musters mithilfe eines optischen Sensors (190) des Nutzer- Computersystems und Decodierung des Musters durch das Nutzer- Computersystem,
~ Übertragung einer Transaktionsanforderung (158) von dem Nutzer- Computersystem an die logische Adresse des Dienst-Computersystems über das Netzwerk, wobei die Transaktionsanforderung die Transaktionsdaten beinhaltet,
- Übertragung eines Request (166) von dem Dienst-Computersystem über das Nutzer-Computersystems (100) an ein I D-Provider-Computersystem (136), wobei die Übertraung über das Netzwerk erfolgt, wobei der Request eine Attributspezifikation, der aus dem ID-Token für die Durchführung der Transaktion auszulesenden Attribute beinhaltet,
- Authentifizierung des Nutzers gegenüber dem ID-Token,
- Authentifizierung des ID-Provider-Computersystems gegenüber dem ID- Token über das Netzwerk,
- unter der Voraussetzung der erfolgreichen Authentifizierung des Nutzers und des ID-Provider-Computersystems gegenüber dem ID-Token, Auslesen des oder der Attribute gemäß der Attributspezifikation durch das ID-Provider- Computersystem aus dem ID-Token über das Netzwerk mit Ende-zu-Ende- Verschlüsselung,
- Übertragung einer Response (174) von dem I D-Provider-Computersystem über das Nutzer-Computersystem an das Dienst-Computersystem, wobei die Übertragung der Response über das Netzwerk erfolgt, wobei die Response das oder die ausgeiesenen Attribute beinhaltet, und wobei die Response von dem I D-Provider-Computersystem signiert ist,
Durchführung der Transaktion mithilfe der Transaktionsdaten und des oder der Attribute durch das Dienst-Computersystem.
23. Computersystem nach Anspruch 22, wobei es sich bei dem Terminal um einen Automat, insbesondere einen Bankautomat oder einen Verkaufsautomat, handelt. 24. Computersystem nach Anspruch 22 oder 23, wobei es sich bei dem Terminal um ein mobiles Telekommunikationsgerät, insbesondere ein Taxameter oder ein Smartphone, mit einer Gebührenerfassungsfunktion, oder einen Verbrauchszähler, insbesodnere ein Smartmeter, zur Erfassung eines Verbrauchswerts handelt.
EP14726573.0A 2013-06-28 2014-05-22 Elektronisches transaktionsverfahren und computersystem Pending EP3014540A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102013212646.8A DE102013212646B4 (de) 2013-06-28 2013-06-28 Elektronisches Transaktionsverfahren und Computersystem
PCT/EP2014/060540 WO2014206659A1 (de) 2013-06-28 2014-05-22 Elektronisches transaktionsverfahren und computersystem

Publications (1)

Publication Number Publication Date
EP3014540A1 true EP3014540A1 (de) 2016-05-04

Family

ID=50828891

Family Applications (1)

Application Number Title Priority Date Filing Date
EP14726573.0A Pending EP3014540A1 (de) 2013-06-28 2014-05-22 Elektronisches transaktionsverfahren und computersystem

Country Status (3)

Country Link
EP (1) EP3014540A1 (de)
DE (1) DE102013212646B4 (de)
WO (1) WO2014206659A1 (de)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102016117134A1 (de) 2016-09-13 2018-03-15 Martin Schwemmer Verfahren zum bargeldlosen Bezahlen an einem Bezahlterminal und Bezahlterminal
CN106875162B (zh) * 2016-12-30 2020-12-04 朗新科技集团股份有限公司 数据抓取方法、数据抓取装置、软收银对接接口及终端
CN111192036B (zh) * 2019-08-01 2023-06-20 腾讯科技（深圳）有限公司 账号资源更新方法、装置、计算机设备以及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050080681A1 (en) * 2003-10-08 2005-04-14 Shinichi Ohnishi System for providing information of automatic transaction apparatus
DE102008000067A1 (de) * 2008-01-16 2009-07-23 Bundesdruckerei Gmbh Verfahren zum Lesen von Attributen aus einem ID-Token
WO2012088512A2 (en) * 2010-12-23 2012-06-28 Paydiant, Inc. Mobile phone atm processing methods and systems

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030120555A1 (en) * 2000-03-09 2003-06-26 Takashi Kitagawa Information processing apparatus with optical data reader, servers, and electronic commerce method
DE102011082101B4 (de) 2011-09-02 2018-02-22 Bundesdruckerei Gmbh Verfahren zur Erzeugung eines Soft-Tokens, Computerprogrammprodukt und Dienst-Computersystem
DE102011089580B3 (de) * 2011-12-22 2013-04-25 AGETO Innovation GmbH Verfahren zum Lesen von Attributen aus einem ID-Token

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050080681A1 (en) * 2003-10-08 2005-04-14 Shinichi Ohnishi System for providing information of automatic transaction apparatus
DE102008000067A1 (de) * 2008-01-16 2009-07-23 Bundesdruckerei Gmbh Verfahren zum Lesen von Attributen aus einem ID-Token
WO2012088512A2 (en) * 2010-12-23 2012-06-28 Paydiant, Inc. Mobile phone atm processing methods and systems

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of WO2014206659A1 *

Also Published As

Publication number Publication date
WO2014206659A1 (de) 2014-12-31
DE102013212646B4 (de) 2018-11-22
DE102013212646A1 (de) 2014-12-31

Similar Documents

Publication Publication Date Title
EP2949094B1 (de) Verfahren zur authentisierung eines nutzers gegenüber einem automat
DE102011082101B4 (de) Verfahren zur Erzeugung eines Soft-Tokens, Computerprogrammprodukt und Dienst-Computersystem
DE102012219618B4 (de) Verfahren zur Erzeugung eines Soft-Tokens, Computerprogrammprodukt und Dienst-Computersystem
EP2454705B1 (de) Verfahren zum lesen von attributen aus einem id-token und one-time passwort generator
WO2015154536A1 (zh) 一种基于可见码的多重安全组合机制的支付方法和系统
EP2817758B1 (de) Computerimplementiertes bezahlverfahren
DE102011116489A1 (de) Mobiles Endgerät, Transaktionsterminal und Verfahren zur Durchführung einer Transaktion an einem Transaktionsterminal mittels eines mobilen Endgeräts
DE102013212627B4 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102013212646B4 (de) Elektronisches Transaktionsverfahren und Computersystem
WO2013093026A1 (de) Verfahren zur durchführung authentifizierter zahlungen
DE102011079317A1 (de) Mobiles system für finanztransaktionen
EP2879073B1 (de) Elektronisches transaktionsverfahren und computersystem
DE102013022436B3 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102013022434B3 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102013022433B3 (de) Elektronisches Transaktionsverfahren und Computersystem
EP2916252B1 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102013022438B3 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102013022445B3 (de) Elektronisches Transaktionsverfahren und Computersystem
EP2819079B1 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102013022447B3 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102013022435B3 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102013022448B3 (de) Elektronisches Transaktionsverfahren und Computersystem
WO2003070493A2 (de) Datenverarbeitungssystem und verfahren zur elektronischen zahlungsvermittlung

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20160128

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

AX Request for extension of the european patent

Extension state: BA ME

DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

17Q First examination report despatched

Effective date: 20170802

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS

P01 Opt-out of the competence of the unified patent court (upc) registered

Effective date: 20230526