DE102018005038A1 - Smartcard als Sicherheitstoken - Google Patents

Smartcard als Sicherheitstoken Download PDF

Info

Publication number
DE102018005038A1
DE102018005038A1 DE102018005038.7A DE102018005038A DE102018005038A1 DE 102018005038 A1 DE102018005038 A1 DE 102018005038A1 DE 102018005038 A DE102018005038 A DE 102018005038A DE 102018005038 A1 DE102018005038 A1 DE 102018005038A1
Authority
DE
Germany
Prior art keywords
token server
security
key
card
smart card
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
DE102018005038.7A
Other languages
English (en)
Inventor
Volker Stöhr
Frank-Michael Kamm
Nils Gerhardt
Andreas Chalupar
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.)
Giesecke and Devrient ePayments GmbH
Original Assignee
Giesecke and Devrient Mobile Security 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 Giesecke and Devrient Mobile Security GmbH filed Critical Giesecke and Devrient Mobile Security GmbH
Priority to DE102018005038.7A priority Critical patent/DE102018005038A1/de
Priority to PCT/EP2019/000191 priority patent/WO2020001807A1/de
Priority to EP19734247.0A priority patent/EP3811584A1/de
Priority to CN201980039518.7A priority patent/CN112352410B/zh
Priority to US17/251,622 priority patent/US11341232B2/en
Priority to MX2020014189A priority patent/MX2020014189A/es
Priority to CA3101539A priority patent/CA3101539A1/en
Publication of DE102018005038A1 publication Critical patent/DE102018005038A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/45—Structures or tools for the administration of authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • 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/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • 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/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • 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
    • G06Q20/3672—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 initialising or reloading thereof
    • 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
    • G06Q20/3674—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 involving authentication
    • 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • 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/385—Payment protocols; Details thereof using an alias or single-use codes
    • 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/4018—Transaction verification using the card verification value [CVV] associated with the card
    • 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/409—Device specific authentication in transaction processing
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/067—Network architectures or network communication protocols for network security for supporting key management in a packet data network using one-time keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/34—User authentication involving the use of external additional devices, e.g. dongles or smart cards
    • G06F21/35—User authentication involving the use of external additional devices, e.g. dongles or smart cards communicating wirelessly

Abstract

Die vorliegende Erfindung ist auf ein Verfahren gerichtet zum Bereitstellen eines Sicherheitsschlüssels, wobei zu dessen Erzeugung eine erfindungsgemäß eingerichtete Smartcard Verwendung findet. Hierbei wird ein geschickter Verfahrensablauf vorgeschlagen, der es ermöglicht, dass die Smartcard im Zusammenwirken mit einem Tokenserver beispielsweise ein sogenanntes Einmalpasswort oder eine dynamische Prüfnummer bereitstellt. Die vorliegende Erfindung ist ferner gerichtet auf eine entsprechend eingerichtete Rechenanordnung sowie auf ein Computerprogrammprodukt mit Steuerbefehlen, welche das Verfahren implementieren bzw. die Rechenanordnung betreiben.

Description

  • Die vorliegende Erfindung ist auf ein Verfahren gerichtet zum Bereitstellen eines Sicherheitsschlüssels, wobei zu dessen Erzeugung eine erfindungsgemäß eingerichtete Smartcard Verwendung findet. Hierbei wird ein geschickter Verfahrensablauf vorgeschlagen, der es ermöglicht, dass die Smartcard im Zusammenwirken mit einem Tokenserver beispielsweise ein sogenanntes Einmalpasswort oder eine dynamische Prüfnummer bereitstellt. Die vorliegende Erfindung ist ferner gerichtet auf eine entsprechend eingerichtete Rechenanordnung sowie auf ein Computerprogrammprodukt mit Steuerbefehlen, welche das Verfahren implementieren bzw. die Rechenanordnung betreiben.
  • DE 10 2012 111 481 B4 zeigt ein Verfahren zur Steuerung der Installation einer Anwendung auf einem mobilen Endgerät mit einem auf dem mobilen Endgerät installierten Token-Provider, der die Netzwerkadresse eines Tokenservers kennt.
  • DE 600 23 340 T2 zeigt ein photographisches System, welches u. a. einen Tokenserver verwendet.
  • Generell ist es im Rahmen von Bezahldiensten bekannt, dass sich ein Benutzer mittels eines Passworts authentisiert und sodann eine Finanztransaktion vornehmen kann. In diesem Zusammenhang werden online sogenannte Webservices bereitgestellt, welche ein Bezahlen ermöglichen. Realweltlich sind darüber hinaus Terminals bekannt, bei denen der Kunde beispielsweise mit seiner Smartcard bezahlen kann. Bei Online-basierten Verfahren besteht der Nachteil, dass bei einem sogenannten Man-in-the-middle-Angriff eine Kommunikation zwischen einer zahlenden Entität und einer empfangenden Entität abgehört werden und sodann erneut vorgespielt werden kann. Somit könnte ein unberechtigter Dritter den Bezahlvorgang, der vorher beobachtet wurde, erneut vorspielen, und somit wird mittels des Passworts eine unberechtigte Transaktion durchgeführt. Um diesem Nachteil zu begegnen, sind sogenannte One-Time-Passwords OTP bekannt, also Einmalpasswörter, welche nach ihrem Gebrauch sofort ungültig werden. Somit wird ein unberechtigtes neues Vorspielen erkannt, und die Transaktion wird sodann nicht ausgeführt.
  • Ferner sind Prüfnummern bekannt, die sicherstellen sollen, dass dem Benutzer die Karte für eine Transaktion vorliegt. Hierzu kennt der Stand der Technik sogenannte Card Verification Codes CVC, also eine vorbestimmte Kartennummer, welche der Rückseite einer Kreditkarte zu entnehmen ist. Solche Prüfnummern sind jedoch für jeden, auch unberechtigten, Kartenbesitzer ersichtlich und somit unsicher. Dieser Nachteil wurde im Stand der Technik dadurch behoben, dass Display-Karten vorgeschlagen sind, also Smartcards, welche mit einem Display ausgestattet sind, welche zur Laufzeit eine Prüfnummer dynamisch berechnen. Hierzu hält die Display-Karte neben dem Display auch elektronische Komponenten bereit, welche entsprechende Rechenschritte durchführen.
  • Zunehmend finden Mobiltelefone bei Bezahldiensten Einsatz, da diese über die notwendige Rechenkapazität und Kommunikationsschnittstellen verfügen. So sind bei Mobiltelefonen unterschiedliche Schnittstellen bekannt, wobei zunehmend die sogenannte Nearfield-Kommunikation NFC Einsatz findet.
  • Generell wird bei der Erzeugung von sicherheitsrelevanten Schlüsseln bzw. der Autorisierung zwischen softwarebasierten Verfahren bzw. hardwarebasierten Verfahren unterschieden. Im Folgenden wird daher ein kurzer Überblick über bekannte Verfahren gegeben.
  • Software-basierte Verfahren: die Sicherheit der Software-basierten Verfahren ist im Allgemeinen nicht sehr hoch, da der geheime „Seed“-Wert, der zur Berechnung des OTP/ CVC benötigt wird, nicht sicher in Software geschützt werden kann. Ein Angreifer, der in der Lage ist, den Seed Wert zu extrahieren, kann damit gültige OTP / CVC erzeugen.
  • Hardware-basierte Verfahren: bei diesen Verfahren ist der Schutz des Seed Wertes im Allgemeinen gegeben, allerdings sind die entsprechenden Hardwaretoken oder Lesegeräte recht teuer. Für Herausgeber mit großer Nutzerbasis (z.B. Banken, Industrieuntemehmen, ..) entstehen dadurch hohe Zusatzkosten. Für Endnutzer ergibt sich die Anforderung, den Token zur Verfügung zu haben. Speziell für mobile Anwendungen (Transaktionen im Mobile Banking) ist dies sehr unbequem und in der Praxis häufig nicht gegeben. Die Verfahren mit speziellen Lesegeräten (MasterCard CAP, VISA DPA) erfordern außerdem immer die Einbeziehung des Kartenherausgebers, da die Verifikation des OTP nur mit geheimen Schlüsseln durchgeführt werden kann, die nur der Herausgeber besitzt. Das Verfahren kann auch nicht ohne weiteres auf Mobiltelefonen (ohne speziellen Leser) durchgeführt werden, da die geheime Karten-PIN verwendet werden muss und potentiell ausgespäht werden kann. Außerdem können nicht OTPs für verschiedene Webservices (Relying Parties) generiert werden.
  • Ausgehend von den Nachteilen, wie sie u. a. im Rahmen der softwarebasierten Verfahren bzw. hardwarebasierten Verfahren diskutiert wurden, besteht generell der Bedarf an einem verbesserten Verfahren, welches sicherstellt, dass Sicherheitsschlüssel in besonders einfacher Art und Weise erzeugt werden können und zudem keine unnötige Hardware verwendet wird, welche seitens des Kundens erst angeschafft werden müsste. Eine solche zusätzliche Hardware würde hierbei die Benutzerakzeptanz reduzieren und das entsprechende Verfahren somit nachteilig erscheinen lassen.
  • Es ist somit eine Aufgabe der vorliegenden Erfindung, ein verbessertes Verfahren zum Bereitstellen eines Sicherheitsschlüssels unter Verwendung einer Smartcard und eines Tokenservers bereitzustellen, welches es erlaubt, sowohl sicher als auch einfach den Sicherheitsschlüssel bereitzustellen. Ferner ist es eine Aufgabe der vorliegenden Erfindung, eine entsprechend eingerichtete Rechenanordnung vorzuschlagen, sowie ein Computerprogrammprodukt mit Steuerbefehlen, welche das Verfahren implementieren bzw. die Rechenanordnung betreiben.
  • Die Aufgabe wird gelöst mit den Merkmalen der unabhängigen Patentansprüche. Weitere vorteilhafte Ausgestaltungen sind in den Unteransprüchen angegeben.
  • Demgemäß wird ein Verfahren zum Bereitstellen eines Sicherheitsschlüssels unter Verwendung einer Smartcard als Sicherheitstoken und eines Tokenservers vorgeschlagen, umfassend ein Übermitteln einer durch den Tokenserver erzeugten zufälligen Challenge-Nachricht über eine gesicherte Datenverbindung von dem Tokenserver an ein Endgerät, ein Weiterleiten der erzeugten Challenge-Nachricht von dem Endgerät an die Smartcard, welche ein Übermitteln mindestens einer Sicherheitsinformation als Antwort-Nachricht an den Tokenserver über die gesicherte Datenverbindung veranlasst, ein Überprüfen der übermittelten Sicherheitsinformation durch den Tokenserver und bei positivem Überprüfen Erzeugen eines symmetrischen Schlüssels in Abhängigkeit der übermittelten Sicherheitsinformation, ein Berechnen eines Sicherheitsschlüssels in Abhängigkeit des erzeugten symmetrischen Schlüssels und ein Bereitstellen des berechneten Sicherheitsschlüssels mittels der gesicherten Datenverbindung von dem Tokenserver an das Endgerät. Der symmetrische Schlüssel kann auch als geheimer Schlüssel bezeichnet werden. Der Sicherheitsschlüssel kann auch als Sicherheitscode oder Sicherheitsprüfzahl bezeichnet werden.
  • Der Fachmann erkennt hierbei, dass einzelne Verfahrensschritte iterativ durchgeführt werden können und/ oder Unterschritte aufweisen können. Beispielsweise kann das Übermitteln von Nachrichten derart iterativ erfolgen, dass Teilnachrichten versendet werden und netzwerktechnisch beispielsweise einzelne Datenpakete versendet werden. Auch das Überprüfen, Erzeugen und Berechnen kann mehrere Unterschritte aufweisen.
  • Der Stand der Technik verwendet unterschiedliche Abkürzungen, welche auch im Kontext der vorliegenden Erfindung so verstanden werden sollen, wie dies der Stand der Technik vorsieht. So steht CVC für Card Validation Code bzw. eine Prüfnummer. Unter PAN wird die sogenannte Primary Account Number verstanden, welche den Kartenaussteller und das Karteninhaberkonto identifiziert. Im Rahmen der Authentifizierung sind unterschiedliche Algorithmen bekannt, welche Konzepte wie DDA, SDA und CDA verwenden. Hierbei handelt es sich um Abkürzungen für Dynamic Data Authentication DDA, Static Data Authentication SDA bzw. Combined Data Authentication CDA.
  • Generell dient ein Token als eine Hardwarekomponente zur Identifizierung und Authentifizierung eines Benutzers, der rechtmäßiger Eigentümer dieses Tokens ist. Hierbei sind sowohl Software-Token als auch Hardware-Token bekannt. Unter EMV versteht der Fachmann eine Spezifikation für Zahlungskarten, welche nach Firmen des entsprechenden Konsortiums benannt ist, nämlich Europay International, Mastercard und VISA. HSM bezeichnet ein sogenanntes Hardware-Sicherheitsmodul, welches typischerweise als ein internes oder externes Peripheriegerät für die sichere Speicherung von krypotagraphischen Schlüsseln und die effiziente und sichere Ausführung kryptographischer Operationen oder Applikationen verwendet wird.
  • Durch die Erfindung kann ein bereits bestehender und personalisierter Sicherheitstoken, beispielsweise eine Smartcard, nutzbar gemacht werden, um ein Einmalpasswort OTP, z. B. für den Login zu einem Webdienst oder die Autorisierung einer Transaktion, oder einem dynamischen CVC für eine ECommerce-Transaktion zu erzeugen. Der bestehende Token muss hierzu nicht modifiziert werden. Er dient als Hardware-Anker für die sichere Erzeugung eines Einmalpassworts bzw. einer Prüfnummer.
  • Da bereits herausgegebene Smartcards über keine universellen Fähigkeiten verfügen, ein Einmalpasswort bzw. eine Prüfnummer CVC dynamisch zu erzeugen, wird ein Tokenserver eingeführt, der die Authentisierung der Karte und die Ableitung des geheimen Seed-Wertes (symmetrischer Schlüssel/ symmetrisches Geheimnis) übernimmt. Während gemäß dem Stand der Technik ein asymmetrischer Schlüssel abgeleitet werden kann und eine Server-Challenge damit signiert wird, ist es vorteilhaft in der vorliegenden Erfindung, ein symmetrisches Geheimnis abzuleiten, in dessen Berechnung ggf. noch weitere externe Daten miteinfließen können, wie beispielsweise Transaktionsdaten oder zeitabhängige Zufallsdaten. Zur Verifikation auf Seiten des Webservices muss dieser Seed-Wert außerdem sicher exportiert werden.
  • Das Verfahren umfasst diverse Verfahrensschritte, welche in unterschiedlicher Granularität dargestellt werden können. Im Folgenden wird eine beispielhafte Ausführungsform beschrieben, die mehrere Schritte aufweist, welche auch zusammengefasst werden können. In diesem Kontext kann es auch möglich sein, weitere Unterschritte einzufügen. Im Folgenden wird die Bereitstellung des Sicherheitsschlüssels demonstriert, welcher als ein sogenanntes Einmalpasswort OTP oder eine Prüfnummer CVC vorliegen kann.
  • Das Verfahren zur OTP / CVC Generierung basiert gemäß einem Aspekt der vorliegenden Erfindung auf folgenden Schritten:
  • Schritt 1: Zwischen Endbenutzergerät (z.B. Mobiltelefon) und Tokenserver wird eine gesicherte Verbindung aufgebaut. Dies kann auf Basis bestehender und bekannter Verfahren gemäß Stand der Technik erfolgen (z.B. TLS Verbindung).
  • Schritt 2: Der Tokenserver generiert eine zufällige Challenge, die er an das Endbenutzergerät schickt.
  • Schritt 3: Der Endbenutzer wird aufgefordert, seine EMV Karte an das Mobiltelefon zu halten, bzw. in den Kartenleser (PC/Laptop) zu stecken. Optional kann er zusätzlich aufgefordert werden, eine PIN, bzw. ein Passwort einzugeben, das er in der Registrierungsphase selbst gewählt hat.
  • Schritt 4: Die Challenge des Tokenservers (Schritt 2) wird an die Karte geschickt. Die Karte antwortet mit einer Signatur und/ oder Kryptogramm, je nach verwendetem Kartentyp und Verfahren (DDA, SDA, CDA). Die Challenge fließt in die Berechnung der Signatur bzw. des Kryptogramms mit ein. Zusätzlich zur Signatur und/ oder Kryptogramm werden aus der Karte ausgelesene Daten (z.B. PAN, Cardholder Name, Expiration Date) sowie PIN/Passwort an den Tokenserver geschickt. Alternativ kann auch ein Hashwert über PIN/Passwort an den Tokenserver geschickt werden.
  • Schritt 5: Der Tokenserver überprüft gemäß einem Aspekt der vorliegenden Erfindung die Signatur bzw. das Kryptogramm der Karte auf Gültigkeit. Je nach Kartentyp kann dies mit öffentlich bekannten Schlüsseln (Public Keys) des Kartennetzwerkes erfolgen oder durch eine Anfrage beim Kartenherausgeber im Falle von Kartenkryptogrammen auf Basis symmetrischer Schlüssel. Alternativ könnten die symmetrischen Schlüssel auf dem Tokenserver hinterlegt sein. In diesem Fall kann der Tokenserver selbst das Kryptogramm überprüfen.
  • Schritt 6: Nach erfolgreicher Überprüfung der Kartensignatur leitet der Tokenserver den symmetrischen Schlüssel (Seed Wert) gemäß einem Aspekt der vorliegenden Erfindung zur OTP / CVC Erzeugung ab. Hierzu werden sowohl Kartendaten (z.B. PAN, Cardholder Name, Expiration Date, Card Sequence Number, ...) als auch PIN/Passwort des Nutzers herangezogen. Zusätzlich kann ein Server-spezifisches Geheimnis (z.B. ein in einem HSM gespeicherter Master Key) mit einbezogen werden. Zusätzlich kann auch eine spezifische Kennung des Webservice (Relying Party) in die Ableitung mit einfließen (z.B. URL). In einer beispielhaften Ausführungsform kann der Hashwert über die Karten- und Nutzerdaten gebildet werden und mit dem Master Key verschlüsselt werden.
  • Zur Ableitung eignet sich generell jede kryptographisch sichere Einwegfunktion, die die Ausgangsdaten (Kartendaten, Nutzerdaten) eindeutig und kollisionsresistent auf den Endwert (symmetrisches Geheimnis) abbildet.
  • Schritt 7: Aus dem in Schritt 6 abgeleiteten geheimen Seed Wert wird nun der eigentliche OTP bzw. CVC Wert durch den Tokenserver berechnet. Die Berechnung kann dabei auf Basis bestehender und bekannter Verfahren basieren (z.B. OATH-Protokolle wie T-OTP, H-OTP).
  • In die Berechnung des OTP können alternativ noch weitere Daten mit eingehen. Dies können z.B. Transaktionsdaten (bzw. deren Hashwerte) sein, wenn ein transaktionsspezifischer OTP zur Autorisierung einer Transaktion gebildet wird. Diese Daten sind dann zuvor vom Endbenutzergerät an den Tokenserver übermittelt worden.
  • In einer Ausführungsform kann auch eine Challenge, die entweder von einem Server übermittelt wurde oder vom User eingegeben wurde (z.B. zur Identifizierung im Telefonbanking) in die Berechnung des OTP Wertes mit einfließen.
  • In die Berechnung eines CVC kann alternativ noch ein zeitlich begrenzt gültiger Zufallswert eingehen. Dieser Zufallswert wird durch den Tokenserver oder einen weiteren Server erzeugt und ist für ein vordefiniertes Zeitintervall gültig. Durch diesen Wert wird sichergestellt, dass keine zukünftigen CVC Werte vorhersagbar sind und ein Nachweis besteht, dass die Karte, aus der der CVC Wert abgeleitet wird, zum Zeitpunkt der Transaktion dem Nutzer tatsächlich zur Verfügung stand. Dadurch wird verhindert, dass ein Angreifer, der die Karte nicht physisch vorliegen hat, mit gestohlenen Kreditkartendaten Transaktionen durchführt. Der erzeugte CVC Wert kann dann innerhalb des Zeitintervalls für eine eCommerce Transaktion verwendet werden („Card non present Transaktion“). Typische Zeitintervalle sind 1 Minute, 10 Minuten, 20 Minuten, oder 1 Stunde.
  • Schritt 8: Der in Schritt 7 erzeugte OTP/CVC Wert wird über die sichere Datenverbindung an das Endbenutzergerät exportiert. Dort kann der Wert dann angezeigt werden oder direkt an einen Webservice (Verification Server) zur dortigen Überprüfung weitergeleitet werden.
  • Alternativ kann der Tokenserver den OTP /CVC Wert direkt an einen Webservice über eine vordefinierte Schnittstelle exportieren. Hierzu muss die Zieladresse gemäß einem Aspekt der vorliegenden Erfindung zuvor vom Endbenutzergerät an den Tokenserver mitgeteilt worden sein.
  • Da in diesem Verfahren ein symmetrisches Geheimnis abgeleitet wird, muss der Web-service, der den OTP /CVC Wert überprüfen will, gemäß einem Aspekt der vorliegenden Erfindung ebenfalls über dieses Geheimnis verfügen. Hierzu gibt es mehrere Alternativen:
  • Alternative 1: Sicherer Export des Seed Wertes:
  • In dieser Alternative erfolgt initial eine User Registrierung, bei der anschließend der Seed Wert exportiert wird. Das Verfahren basiert auf folgenden Schritten:
  • Schritt 1-6: Diese Schritte verlaufen gemäß einem Aspekt der vorliegenden Erfindung analog zur Phase der OTP / CVC Generierung. In Schritt 3 kann der Nutzer bei der Registrierung erstmalig PIN/Passwort frei wählen. In Schritt 4 kann optional noch die Zieladresse des Webservice übermittelt werden, an die der geheime Seed Wert übermittelt werden soll.
  • Schritt 7: Der geheime Seed Wert wird nun an den entsprechenden Webservice exportiert. Der Webservice benötigt den Seed, um die OTP /CVC Werte später serverseitig überprüfen zu können. Im Gegensatz zum Tokenserver, der den Seed Wert bei jeder Transaktion dynamisch ableitet muss der Webservice den Seed dauerhaft und sicher speichern. Dieser Export kann über das Endbenutzergerät erfolgen, das den Wert dann an den Webservice weiterleitet, oder direkt durch den Tokenserver an den Webservice.
  • Bevorzugt sollte der Seed Wert zum Export verschlüsselt werden. Hierzu kann vom Webservice über das Endbenutzergerät ein Zertifikat und eine URL übergeben werden. Der Token Server überprüft dann anhand einer Whitelist, ob es sich um einen berechtigten Webservice handelt. Mit dem öffentlichen Schlüssel des Zertifikats wird der Seed Wert verschlüsselt und exportiert.
  • Alternative 2: Überprüfung durch Token Server
  • In dieser Variante stellt der Token Server selbst die Funktionalität bereit, den OTP /CVC Wert zu überprüfen. Dazu stellt er dem Webservice eine entsprechende Schnittstelle zur Verfügung. Der Webservice übermittelt den OTP/CVC Wert, den er vom Endbenutzer erhalten hat, an den Tokenserver. Der Tokenserver hat für die Gültigkeitsdauer des OTP/CVC Wertes den Seed Wert des Benutzers zwischengespeichert. In diesem Gültigkeitsintervall kann der Webservice den Tokenserver kontaktieren und die Gültigkeit des OTP/ CVC Wertes überprüfen lassen. Nach Ablauf des Gültigkeitsintervalls verwirft der Tokenserver den Seed Wert gemäß einem Aspekt der vorliegenden Erfindung wieder.
  • Alternative 3: ID-Based encryption
  • In dieser Variante verwendet der Webservice ein „ID-based encryption“ (IBE) Schema gemäß Stand der Technik. Der Endbenutzer übergibt bei der Registrierung einen URL oder anderen spezifischen Identifier des Webservice. Der Tokenserver verwendet diesen Identifier als öffentlichen Schlüssel (gemäß dem entsprechenden und bekannten IBE-Schema) und verschlüsselt den Seed Wert damit. Der verschlüsselte Seed Wert wird entweder an das Endbenutzergerät oder direkt an den Webservice übergeben.
  • Das vorgeschlagene Verfahren dient dem Bereitstellen eines Sicherheitsschlüssels, wie er beispielsweise bei einem Bezahlvorgang verwendet werden kann. Hierbei kann der Sicherheitsschlüssel einem Webdienst oder einem Bezahlterminal vorgehalten werden. Sodann erfolgt eine Autorisierung. Bei der Smartcard handelt es sich um eine Kreditkarte, welche elektronische Komponenten aufweist, die es ermöglichen, Rechenoperationen durchzuführen bzw. eine Datenkommunikation zu bewerkstelligen. Typischerweise umfasst eine Smartcard eine Recheneinheit, eine Speichereinheit sowie eine Induktionsspule. Die Induktionsspule dient der Stromversorgung und kann zudem die Funktion einer Antenne bezüglich der Datenkommunikation übernehmen. Alternativ kann die Stromversorgung und die Kommunikation kontaktbehaftet durchgeführt werden.
  • Die Smartcard liegt physisch vor und kann somit als Sicherheitstoken fungieren, welches der Benutzer stets mit sich führt. Bei einer Smartcard handelt es sich bekannterweise um eine Kreditkarte mit entsprechender kompakter Bauart, die den Benutzer nicht weiter stört, und somit wird die Benutzerakzeptanz nicht abgeschwächt. Insbesondere ist es erfindungsgemäß vorteilhaft, dass keine weiteren Hardwarekomponenten Verwendung finden. Der Tokenserver kann generell als ein Server bereitgestellt werden, welcher datentechnisch mit dem Endgerät verbunden ist. Bei dem Endgerät kann es sich wiederum um ein Bezahlterminal oder aber auch um ein Mobiltelefon handeln.
  • Die vorbereitenden Verfahrensschritte werden derart durchgeführt, dass eine sogenannte Challenge-Nachricht erzeugt wird, welche an das Endgerät übermittelt wird. Bei einer Challenge-Nachricht handelt es sich um eine Anfrage-Nachricht, auf die typischerweise eine Response-Nachricht bzw. eine Antwort-Nachricht folgt. Gemäß dieser Challenge-Nachricht werden Informationen seitens der Smartcard abgefragt, welche wiederum die Smartcard mittels der Response-Nachricht beantwortet.
  • Zum Einrichten der gesicherten Datenverbindung können herkömmliche Verfahren eingesetzt werden, wie beispielsweise das bekannte TLS-Verfahren. Das TLS-Verfahren dient der Absicherung der Datenkommunikation, insbesondere zwischen dem Endgerät und dem Tokenserver. Sodann wird die Smartcard mit dem Endgerät kommunikationsgekoppelt, d. h. diese Smartcard wird in ein Kartenlesegerät eingesteckt oder es kommuniziert drahtlos mit dem Endgerät.
  • Das Endgerät leitet die erzeugte Challenge-Nachricht an die Smartcard weiter, wobei auch weitere Verfahrensschritte durchgeführt werden können. Die PIN fließt in die Berechnung vom Seed und damit vom OTP / CVC mit ein. Bei einer falschen PIN wird dies erst vom Verifikationsserver entdeckt. Somit dient die PIN der Authentisierung des Benutzers gegenüber dem Verifikationsserver. Beispielsweise kann vorgesehen werden, dass zusätzlich ein vom Benutzer einzugebendes Passwort oder eine PIN in die Berechnung des geheimen Schlüssels eingeht.
  • Daraufhin generiert die Smartcard eine Antwort-Nachricht, die anhand von abgespeicherten Rechenoperationen erzeugt wird, in welche die Challenge einfließt. Hierzu kann die Smartcard auf den beschriebenen Speicher zurückgreifen, und die Recheneinheit führt hierbei Lese- bzw. Schreiboperationen aus. Bereits hier kann ein kryptographisches Verfahren Anwendung finden und die Sicherheitsinformation kann Daten der Smartcard umfassen. Die Smartcard veranlasst hierzu ein Übermitteln der sicheren Information an den Tokenserver, welches derart ausgeführt werden kann, dass die Smartcard lediglich die Daten bzw. die Information bereitstellt und die eigentliche Datenkommunikation zwischen dem Endgerät und dem Tokenserver stattfindet. Beispielsweise kann das Endgerät mittels einer drahtgebundenen Kommunikation mit dem Internet gekoppelt werden, welches eine Verbindung zu dem Tokenserver herbeiführt. Hierbei ist es auch möglich, dass das Endgerät drahtlos mittels eines Routers kommuniziert, der wiederum mit dem Internet verbunden ist. Im Falle, dass das Endgerät als ein Mobiltelefon vorliegt, können diese Schnittstellen verwendet werden und es erfolgt eine drahtlose Kommunikation mit entsprechenden Netzwerkkomponenten, die mit dem Tokenserver kommunizieren.
  • Ein Veranlassen des Übermittelns beschreibt hierbei im Wesentlichen, dass die Smartcard nicht selbsttätig die Verbindung aufbauen muss, sondern vielmehr dem Endgerät kommuniziert, dass nunmehr Daten zu übertragen sind. Folglich erfolgt die eigentliche Datenkommunikation über die Datenschnittstelle des Endgeräts.
  • Da nunmehr dem Tokenserver die Sicherheitsinformation der Smartcard vorliegt, kann der Tokenserver diese Information abprüfen. Hierbei sind entsprechende Steuerbefehle auf den Tokenserver abgespeichert und ferner sind Referenzinformationen abgespeichert, die es ermöglichen, das Überprüfen durchzuführen. So können auf dem Tokenserver Daten hinterlegt werden, welche eine zu erwartende Sicherheitsinformation beschreiben. Liegt diese erwartete Sicherheitsinformation tatsächlich auch vor, so kann ein positives Überprüfen erfolgen. Wird hingegen entdeckt, dass die Sicherheitsinformation nicht den Erwartungen entspricht, so kann es sich um einen Angriff handeln, und eine Fehlerroutine wird ausgeführt. Eine Fehlerroutine sieht vorteilhafterweise vor, dass kein Sicherheitsschlüssel erzeugt wird und das Verfahren abgebrochen wird.
  • Im Falle des positiven Überprüfens der zu erwarteten Sicherheitsinformation führt der Tokenserver ein Erzeugen eines symmetrischen Schlüssels in Abhängigkeit der übermittelten Sicherheitsinformation durch. Dieses Erzeugen basiert typischerweise wieder auf abgespeicherten Steuerbefehlen und Informationen auf dem Tokenserver. Hierbei dient die Sicherheitsinformation als ein Ausgangswert, der in eine entsprechende kryptographische Funktion eingegeben wird. Die kryptographische Funktion verarbeitet die Sicherheitsinformation und leitet daraus einen symmetrischen Schlüssel ab. Diese kryptographische Funktion kann wiederum aus einer Mehrzahl von abgespeicherten Funktionen ausgewählt werden und kann hierbei auf die Art der Sicherheitsinformation bzw. die Art des Kartentyps Rücksicht nehmen. Entsprechende Regeln können in einer Tabelle abgespeichert werden, die angibt, welche Sicherheitsinformation wie verarbeitet wird und darüber hinaus angibt, welches Verfahren zum Überprüfen, Erzeugen und zum weiteren Berechnen Verwendung findet.
  • Eben dieses Berechnen wird auf den symmetrischen Schlüssel angewendet und es entsteht der Sicherheitsschlüssel, der benötigt wird, um beispielsweise eine Finanztransaktion zu autorisieren. Somit handelt es sich bei dem Sicherheitsschlüssel um ein Passwort, ein Einmalpasswort oder eine Prüfnummer.
  • Abschließend erfolgt ein Bereitstellen des berechneten Sicherheitsschlüssels derart, dass der Verifikationsserver den Sicherheitsschlüssel verifizieren kann und somit eine Freigabe des angeforderten Dienstes bzw. der Transaktion erfolgt.
  • Gemäß einem Aspekt der vorliegenden Erfindung umfasst die Sicherheitsinformation eine Signatur und/ oder ein Kryptogramm. Dies hat den Vorteil, dass die Sicherheitsinformation einfach bereitgestellt werden kann, indem sie aus der Smartcard ausgelesen wird und zudem der Tokenserver die Gültigkeit der Smartcard überprüfen kann. Hierzu kann der Tokenserver über Steuerbefehle und Informationen verfügen, welche die Signatur beschreiben und diese ggf. entschlüsseln. Sodann kann die Signatur geprüft werden. Die Karte berechnet ein Kryptogramm mit einem geheimen Schlüssel über ein paar Daten. Die Daten und das Kryptogramm werden von der Karte an den Tokenserver übertragen. Der Tokenserver muss selbst den geheimen Schlüssel kennen, er berechnet selbst über die Daten ein Kryptogramm und vergleicht dieses mit dem Kryptogramm, welches von der Karte mitgeschickt wurde. Kann die Signatur bzw. das Kryptogramm nicht positiv evaluiert werden, so kann wiederum eine Fehlerroutine gestartet werden.
  • Gemäß einem weiteren Aspekt der vorliegenden Erfindung werden zusätzlich zu der Sicherheitsinformation aus der Karte ausgelesene Daten, eine PAN, ein bürgerlicher Name (beispielsweise des Karteninhabers), ein Ablaufdatum, eine PIN, ein Passwort, ein Hashwert, eine Kartensequenznummer und/ oder ein Kartentyp übermittelt. Dies hat den Vorteil, dass bei der Erzeugung des symmetrischen Schlüssels solche kartenspezifischen Daten Verwendung finden können. Ferner können benutzerspezifische Werte, wie z.B. eine PIN, ein Passwort, verwendet werden. In die weitere Berechnung des Sicherheitscodes können auch transaktionsspezifische Werte einfließen. Somit können sich weitere Verfahrensschritte bezüglich der Sicherheitsinformation auf vielfältige Daten beziehen und die Sicherheitsinformation wird derart umfangreich bereitgestellt, dass unterschiedliche Aspekte abgebildet werden können. So kann beispielsweise evaluiert werden, ob die Smartcard tatsächlich auf einen bestimmten, erwarteten Nutzer ausgestellt ist, wobei der bürgerliche Name des Karteninhabers ausgelesen wird. In analoger Weise kann das Ablaufdatum der Smartcard überprüft werden und weitere Daten können anhand solcher spezifischer Information erzeugt werden. Die symmetrischen Schlüssel können also in Abhängigkeit eines oder mehrerer Datentypen erstellt werden. Die genannte Aufzählung kann sodann als Eingabe für eine Funktion fungieren, welche den symmetrischen Schlüssel erzeugt.
  • Gemäß einem weiteren Aspekt der vorliegenden Erfindung erfolgt das Überprüfen in Abhängigkeit eines Kartentyps der Smartcard. Dies hat den Vorteil, dass die Sicherheitsinformation schon den Kartentyp bereitstellen kann und somit evaluiert werden kann, welche Sicherheitsinformation bereitgestellt wird, und zudem können weitere Verfahrensschritte, wie beispielsweise das Erzeugen eines symmetrischen Schlüssels bzw. das Berechnen eines Sicherheitsschlüssels in Abhängigkeit des vorliegenden Smartcard-Typs durchgeführt werden.
  • Gemäß einem weiteren Aspekt der vorliegenden Erfindung liegt der Sicherheitsschlüssel als eine Prüfnummer, ein einmaliges Passwort und/ oder ein Passwort vor. Dies hat den Vorteil, dass das vorgeschlagene Verfahren bekannte kryptographische Verfahren ersetzen bzw. ergänzen kann und dazu geeignet ist, eine sogenannte CVC zu erzeugen oder ein Passwort. Insbesondere kann es sich bei dem Passwort um ein sogenanntes One-Time-Passwort OTP handeln. Bei einem einmaligen Passwort handelt es sich um ein sogenanntes Einmalpasswort bzw. Einwegpasswort. Dieses wird entwertet, sobald es verwendet wurde. Der Sicherheitsschlüssel kann folglich beispielsweise bei einem Webdienst oder einem Bezahlvorgang zur Autorisierung einer Bezahlung dienen.
  • Gemäß einem weiteren Aspekt der vorliegenden Erfindung umfasst das Erzeugen des symmetrischen Schlüssels ein Auswählen von auf dem Tokenserver abgespeicherten Schlüsseln. Dies hat den Vorteil, dass unterschiedliche Schlüssel bereits vorhanden sein können und somit die symmetrischen Schlüssel bzw. der symmetrische Schlüssel lediglich aus dem Tokenserver ausgelesen werden muss. Hierbei kann eine Datenbank vorgehalten werden, die entsprechende Schlüssel aufweist. Bei symmetrischen Schlüsseln handelt es sich typischerweise um Schlüssel, welche beiden Instanzen bekannt sind, also der Instanz, welche verschlüsselt, und ebenso der Instanz, welche entschlüsselt. Somit kann in einem vorbereitenden Verfahrensschritt mindestens ein symmetrischer Schlüssel auf dem Tokenserver abgespeichert werden. Gemäß einem weiteren Aspekt der vorliegenden Erfindung umfasst das Erzeugen des symmetrischen Schlüssels die Verwendung eines Token Server spezifischen Schlüssels, der in die Berechnung des geheimen Schlüssels eingeht und verhindert, dass die Berechnung des geheimen Schlüssels ohne die Kenntnis des Token Server spezifischen Schlüssels erfolgen kann.
  • Gemäß einem weiteren Aspekt der vorliegenden Erfindung erfolgt das Berechnen des Sicherheitsschlüssels in Abhängigkeit des erzeugten symmetrischen Schlüssels unter Verwendung einer abgespeicherten kryptographischen Funktion. Dies hat den Vorteil, dass das Berechnen des Sicherheitsschlüssels eigenständig durch den Tokenserver durchgeführt werden kann, und ferner kann eine kryptographische Funktion bereitgestellt werden, welche den symmetrischen Schlüssel als Eingabe verwendet, um sodann den Sicherheitsschlüssel als Ausgabe zu errechnen. Somit erfolgt also ein Berechnen des Sicherheitsschlüssels in Abhängigkeit des erzeugten symmetrischen Schlüssels, wobei die Abhängigkeit durch eine kryptographische Funktion gegeben ist.
  • Gemäß einem weiteren Aspekt der vorliegenden Erfindung fungiert bei dem Berechnen des Sicherheitsschlüssels der symmetrische Schlüssel als ein Startwert. Dies hat den Vorteil, dass auch kryptographische Funktionen verwendet werden können, die einen sogenannten Seed-Wert benötigten, und dieser Startwert bzw. Seed-Wert kann eben als der symmetrische Schlüssel vorliegen. Somit können bereits implementierte kryptographische Funktionen wiederverwendet werden.
  • Gemäß einem weiteren Aspekt der vorliegenden Erfindung erfolgt das Erzeugen des symmetrischen Schlüssels anhand einer abgespeicherten kryptographischen Funktion. Dies hat den Vorteil, dass schon die symmetrischen Schlüssel ein Ausgabewert einer kryptographischen Funktion sein können, welche als Eingabe die Sicherheitsinformation bearbeitet. Bei der kryptographischen Funktion zum Erzeugen des symmetrischen Schlüssels kann es sich um gleiche oder ähnliche Funktionen handeln, wie sie bezüglich der Berechnung des Sicherheitsschlüssels Verwendung finden, und somit kann der Tokenserver diese kryptographischen Funktionen vorteilhafterweise lediglich einmal bereitstellen.
  • Gemäß einem weiteren Aspekt der vorliegenden Erfindung umfasst das Überprüfen der übermittelten Sicherheitsinformation ein Vergleichen der Sicherheitsinformation mit abgespeicherten Referenzwerten. Dies hat den Vorteil, dass das Überprüfen eigenständig durch den Tokenserver durchgeführt werden kann, und somit wird die Sicherheitsinformation lediglich dadurch überprüft, dass beispielsweise eine zu erwartende Signatur überprüft wird, und bei einem Vorliegen der Sicherheitsinformation gemäß den abgespeicherten Referenzwerten erfolgt ein positives Überprüfen. Folglich wird ein weiterer Sicherheitsmechanismus implementiert. Ein alternativer Aspekt ist, dass der Tokenserver jedesmal eine neue Challenge zufällig erzeugt, und die EMV Karte die Challenge in die Signatur mit einrechnet. Dadurch ergibt sich jedesmal eine neue Signatur, die somit nicht mit einem auf dem Tokenserver abgespeicherten Referenzwert verglichen werden kann. Der Tokenserver muss stattdessen die Signatur verifizieren und dabei die auf dem Tokenserver zwischengespeicherte Challenge mit einbeziehen.
  • Der Grund für diese Vorgehensweise ist, dass ein Angreifen nicht eine Authentisierung beobachten kann und dann selbst die gleichen Daten für eine Authentisierung missbrauchen kann (Replay Attack).
  • Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird bei einem negativen Überprüfen eine vorbestimmte Fehlerroutine gestartet. Dies hat den Vorteil, dass auf unterschiedliche Weise auf einen Angriff bzw. einen Fehler reagiert werden kann. Typischerweise kann hierbei das Verfahren entweder abbrechen oder es werden Sicherheitsmechanismen ausgeführt. So kann beispielsweise der entsprechende Benutzer gesperrt werden bzw. die weitere Datenkommunikation kann unterbunden werden, da ein Angriff, d. h. ein unberechtigter Zugriff, erwartet wird.
  • Gemäß einem weiteren Aspekt der vorliegenden Erfindung kommuniziert das Endgerät mit der Smartcard kontaktlos oder kontaktbehaftet. Dies hat den Vorteil, dass herkömmliche Smartcards wiederverwendet werden können, und ein Endgerät beispielsweise in Form eines Kartenlesegeräts vorhanden sein kann, oder aber auch ein Mobiltelefon kann als Endgerät bereitgestellt werden. Bei einer kontaktlosen Kommunikation handelt es sich bevorzugt um eine sogenannte Nearfield-Kommunikation bzw. um eine Kommunikation zwischen der Smartcard und dem Endgerät, welches über kurze Distanzen mittels induktiver Koppelung Daten an eine geeignete Smartcard übermittelt.
  • Gemäß einem weiteren Aspekt der vorliegenden Erfindung wird das Endgerät als ein Mobiltelefon oder ein Kartenlesegerät bereitgestellt. Dies hat den Vorteil, dass das vorgeschlagene Verfahren in bestehende Infrastrukturen integriert werden kann, und somit ist es möglich, das vorgeschlagene Verfahren lediglich softwaretechnisch, d. h. anhand von Steuerbefehlen, umzusetzen. Somit wird auch ein technischer Aufwand eingespart.
  • Die Aufgabe wird auch gelöst durch eine Rechenanordnung zum Bereitstellen eines Sicherheitsschlüssels unter Verwendung einer Smartcard als Sicherheitstoken und eines Tokenservers, umfassend eine Schnittstelleneinheit eingerichtet zum Übermitteln einer durch den Tokenserver erzeugten zufälligen Challenge-Nachricht über eine gesicherte Datenverbindung von dem Tokenserver an ein Endgerät, das Endgerät eingerichtet zum Weiterleiten der erzeugten Challenge-Nachricht von dem Endgerät an die Smartcard, welche eingerichtet ist, ein Übermitteln mindestens einer Sicherheitsinformation als Antwort-Nachricht an den Tokenserver über die gesicherte Datenverbindung zu veranlassen, den Tokenserver eingerichtet zum Überprüfen der übermittelten Sicherheitsinformation und bei positivem Überprüfen zum Erzeugen eines symmetrischen Schlüssels in Abhängigkeit der übermittelten Sicherheitsinformation, eine Recheneinheit eingerichtet zum Berechnen eines Sicherheitsschlüssels in Abhängigkeit des erzeugten symmetrischen Schlüssels und eine weitere Schnittstelleneinheit eingerichtet zum Bereitstellen des berechneten Sicherheitsschlüssels mittels der gesicherten Datenverbindung von dem Tokenserver an das Endgerät.
  • Der Fachmann erkennt hierbei, dass weitere Komponenten vorgesehen werden, wie Netzwerkkomponenten, welche die Datenkommunikation bewerkstelligen. Die Recheneinheit kann in dem Tokenserver integriert sein, welcher über Schnittstelleneinheiten verfügt. Analoge Schnittstelleneinheiten sind in dem Endgerät ebenfalls vorhanden. Beispielsweise kann es sich bei dem Endgerät um ein mobiles Endgerät handeln, bevorzugt um ein Mobiltelefon oder aber auch ein Laptop. Auch tragbare Endgeräte eines Kassensystems sind hier vorteilhaft.
  • Die Aufgabe wird auch gelöst durch ein Computerprogrammprodukt mit Steuerbefehlen, welche das Verfahren implementieren bzw. die vorgeschlagene Rechenanordnung betreiben.
  • Das vorgeschlagene Verfahren kann als Steuerbefehle derart implementiert werden, dass ein Kommunikationsprotokoll geschaffen wird. Bezüglich des vorgeschlagenen Verfahrens ist es vorteilhaft, dass bevorzugt die Verfahrensschritte genau derart ausgeführt werden, wie sie beansprucht werden. So mögen einzelne Verfahrensschritte dem Stand der Technik zu entnehmen sein, wobei gerade die vorgeschlagene Reihenfolge in ihrer Gesamtheit zu dem erfindungsgemäßen Vorteil führt. Somit sind also auch alle Verfahrensschritte in ihrer Gesamtheit zu berücksichtigen. Dies schließt nicht aus, dass weitere Verfahrensschritte vorgesehen werden können bzw. Unterschritte Verwendung finden.
  • Ferner ist es erfindungsgemäß besonders vorteilhaft, dass das Verfahren geeignet ist, die Rechenanordnung zu betreiben bzw. die Rechenanordnung eingerichtet ist, das Verfahren auszuführen. So umfasst das Verfahren Verfahrensschritte, welche als funktionale Komponenten der Rechenanordnung nachgebildet werden können. Strukturelle Merkmale der Rechenanordnung können auch Funktionalität bereitstellen, welche die Verfahrensschritte nachbilden.
  • Weitere vorteilhafte Ausgestaltungen werden anhand der beigefügten Figuren näher erläutert. Es zeigen:
    • 1: einen schematischen Kommunikationsfluss der beteiligten Komponenten des erfindungsgemäßen Verfahrens;
    • 2: ein Sequenzdiagramm zur Generierung eines Einmalpassworts bzw. einer Prüfnummer gemäß dem vorgeschlagenen Verfahren;
    • 3: ein Sequenzdiagramm einer Registrierung und eines Seed-Exports gemäß einem weiteren Aspekt der vorliegenden Erfindung; und
    • 4: ein schematisches Ablaufdiagramm des vorgeschlagenen Verfahrens zum Bereitstellen eines Sicherheitsschlüssels gemäß einem Aspekt der vorliegenden Erfindung.
  • 1 zeigt eine beispielhafte Rechenanordnung, wobei auf der linken Seite das Endbenutzergerät, also das Endgerät, eingezeichnet ist, welches mit einer Smartcard kommuniziert. Die Smartcard ist vorliegend als eine EMV-Karte gezeigt. In der Mitte der 1 ist der sogenannte Tokenserver eingezeichnet, welcher mit weiteren Servern netzwerktechnisch kommuniziert, beispielsweise einem Verifikationsserver und einem Salt-Server.
  • 2 zeigt weitere vorteilhafte Komponenten, wie beispielsweise eine Salt-Server-App und einen Transaktionsserver. Hierbei ist das bereits beschriebene Challenge-Response-Verfahren gezeigt und es erfolgt ein Übermitteln der Challenge-Nachricht, welche signiert wird und dann mitsamt Kartendaten zurückgegeben wird. Hierauf kann die Eingabe einer PIN bzw. eines Passworts erfolgen. Die verschlüsselte Challenge bzw. signierte Challenge mit den Kartendaten und ggf. der PIN und dem Passwort wird an den Tokenserver bereitgestellt.
  • In dem Tokenserver erfolgt eine Verifikation der signierten Challenge und die Ableitung eines Seeds bzw. eines Startwerts. Sodann erfolgt eine Kommunikation mit der Salt-Server-App, welche beispielsweise auf dem Salt-Server zur Ausführung gebracht wird. Daraufhin erfolgt eine Anfrage von Transaktionsdaten an den Transaktionsserver, der auch als ein Bezahlserver bezeichnet werden kann, und sodann auf diese angeforderten Transaktionsdaten an den Tokenserver zurückübermittelt. Daraufhin erfolgt ein Berechnen des Einmalpassworts bzw. der Prüfnummer. Das berechnete Passwort bzw. die Prüfnummer wird an das Endbenutzer-Gerät übermittelt, welches diese Daten, also den berechneten Sicherheitsschlüssel, von dem Verifikationsserver überprüfen lässt. Das Ergebnis wird sodann an den Transaktionsserver übermittelt, und bei positiver Verifikation kann die Transaktion letztendlich ausgeführt werden.
  • 3 zeigt einleitend ähnliche Verfahrensschritte, wie sie beispielsweise in 2 angeführt wurden. Zusätzlich erfolgt ein Weiterleiten des abgeleiteten Startwerts bzw. Seed-Werts an das Endbenutzer-Gerät. Dies wird vorliegend als ein Exportieren bezeichnet. Dieser Seed kann sodann von dem Endbenutzer-Gerät an den Verifikationsserver übermittelt werden und sodann bei weiteren Rechenschritten Verwendung finden.
  • 4 zeigt ein Verfahren zum Bereitstellen eines Sicherheitsschlüssels unter Verwendung einer Smartcard als Sicherheitstoken und eines Tokenservers, umfassend ein Übermitteln 101 einer durch den Tokenserver erzeugten 100 zufälligen Challenge-Nachricht über eine gesicherte Datenverbindung von dem Tokenserver an ein Endgerät, ein Weiterleiten 102 der erzeugten 100 Challenge-Nachricht von dem Endgerät an die Smartcard, welche ein Übermitteln 103 mindestens einer Sicherheitsinformation als Antwort-Nachricht an den Tokenserver über die gesicherte Datenverbindung veranlasst, ein Überprüfen 104 der übermittelten 103 Sicherheitsinformation durch den Tokenserver und bei positivem Überprüfen 104 Erzeugen 105 eines symmetrischen Schlüssels in Abhängigkeit der übermittelten 103 Sicherheitsinformation, ein Berechnen 106 eines Sicherheitsschlüssels in Abhängigkeit des erzeugten 105 symmetrischen Schlüssels und ein Bereitstellen 107 des berechneten 106 Sicherheitsschlüssels mittels der gesicherten Datenverbindung von dem Tokenserver an das Endgerät. Der Sicherheitsschlüssel kann noch an den Verifikationsserver übermittelt und verifiziert werden.
  • Bereits herausgegebene und personalisierte EMV Karten können als Sicherheitstoken für die OTP / CVC Generierung verwendet werden, ohne dass die Karten dazu originär befähigt wären. Eine Modifizierung der Karten ist nicht erforderlich (keine zusätzlichen Applets, keine Änderung des Kartenbetriebssystems, kein größerer Speicherbedarf, keine Verteuerung der Karten).
  • Der Endbenutzer muss keinen zusätzlichen Token oder ein spezielles Lesegerät (z.B. CAP Reader) bei sich tragen, der Herausgeber muss gemäß einem Aspekt der vorliegenden Erfindung keine neuen Token herausgeben. Eine Kartenbasis von >1 Mrd. herausgegebenen Karten steht unmittelbar als Sicherheitstoken zur Verfügung. Bestimmte Kartentypen (DDA-Karten, teilweise CDA Karten) können auch ohne Beteiligung des Herausgebers mit diesem Verfahren verwendet werden.
  • Gegenüber den Softwareverfahren ergibt sich eine deutlich höhere Sicherheit, da die OTP/ CVC Generierung an ein Hardware-Sicherheitselement (EMV Karte) gebunden ist. In Verbindung mit PIN/Password ergibt sich ein echtes Zweifaktorverfahren mit der kryptographischen Sicherheit der Karte. Es muss gemäß einem Aspekt der vorliegenden Erfindung kein geheimer Seed Wert auf einem (potentiell unsicheren) Kundengerät gespeichert werden. Der beteiligte Token Server muss keine nutzerspezifischen Daten speichern. Dynamisch abgeleitete Seed Werte werden unmittelbar nach der Transaktion verworfen. Somit entstehen keine Datenbanken mit Nutzerdaten, die potentiell angegriffen werden könnten
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • DE 102012111481 B4 [0002]
    • DE 60023340 T2 [0003]

Claims (15)

  1. Verfahren zum Bereitstellen eines Sicherheitsschlüssels unter Verwendung einer Smartcard als Sicherheitstoken und eines Tokenservers, umfassend: - Übermitteln (101) einer durch den Tokenserver erzeugten (100) zufälligen Challenge-Nachricht über eine gesicherte Datenverbindung von dem Tokenserver an ein Endgerät; - Weiterleiten (102) der erzeugten (100) Challenge-Nachricht von dem Endgerät an die Smartcard, welche ein Übermitteln (103) mindestens einer Sicherheitsinformation als Antwort-Nachricht an den Tokenserver über die gesicherte Datenverbindung veranlasst; - Überprüfen (104) der übermittelten (103) Sicherheitsinformation durch den Tokenserver und bei positivem Überprüfen (104) Erzeugen (105) eines symmetrischen Schlüssels in Abhängigkeit der übermittelten (103) Sicherheitsinformation; - Berechnen (106) eines Sicherheitsschlüssels in Abhängigkeit des erzeugten (105) symmetrischen Schlüssels; und - Bereitstellen (107) des berechneten (106) Sicherheitsschlüssels mittels der gesicherten Datenverbindung von dem Tokenserver an das Endgerät.
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Sicherheitsinformation eine Signatur und/ oder ein Kryptogramm umfasst.
  3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass zusätzlich zu der Sicherheitsinformation aus der Karte ausgelesene Daten, eine PAN, ein bürgerlicher Name, ein Ablaufdatum, eine PIN, ein Passwort, ein Hashwert, eine Kartensequenznummer und/ oder ein Kartentyp übermittelt (103) werden.
  4. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Überprüfen (104) in Abhängigkeit eines Kartentyps der Smartcard erfolgt.
  5. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass der Sicherheitsschlüssel als eine Prüfnummer, ein einmaliges Passwort und/ oder ein Passwort vorliegt.
  6. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Erzeugen (105) des symmetrischen Schlüssels ein Auswählen von auf dem Tokenserver abgespeicherten Schlüsseln umfasst.
  7. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Berechnen (106) des Sicherheitsschlüssels in Abhängigkeit des erzeugten (105) symmetrischen Schlüssels unter Verwendung einer abgespeicherten kryptographischen Funktion erfolgt.
  8. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei dem Berechnen (106) des Sicherheitsschlüssels der symmetrische Schlüssel als ein Startwert fungiert.
  9. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Erzeugen (105) des symmetrischen Schlüssels anhand einer abgespeicherten kryptographischen Funktion erfolgt.
  10. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Überprüfen (104) der übermittelten (103) Sicherheitsinformation ein Vergleichen der Sicherheitsinformation mit abgespeicherten Referenzwerten umfasst.
  11. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass bei einem negativen Überprüfen (104) eine vorbestimmte Fehlerroutine gestartet wird.
  12. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Endgerät mit der Smartcard kontaktlos oder kontaktbehaftet kommuniziert.
  13. Verfahren nach einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass das Endgerät als ein Mobiltelefon oder ein Kartenlesegerät bereitgestellt wird.
  14. Rechenanordnung zum Bereitstellen eines Sicherheitsschlüssels unter Verwendung einer Smartcard als Sicherheitstoken und eines Tokenservers, umfassend: - eine Schnittstelleneinheit eingerichtet zum Übermitteln (101) einer durch den Tokenserver erzeugten (100) zufälligen Challenge-Nachricht über eine gesicherte Datenverbindung von dem Tokenserver an ein Endgerät; - das Endgerät eingerichtet zum Weiterleiten (102) der erzeugten (100) Challenge-Nachricht von dem Endgerät an die Smartcard, welche eingerichtet ist ein Übermitteln (103) mindestens einer Sicherheitsinformation als Antwort-Nachricht an den Tokenserver über die gesicherte Datenverbindung zu veranlassen; - den Tokenserver eingerichtet zum Überprüfen (104) der übermittelten (103) Sicherheitsinformation und bei positivem Überprüfen (104) zum Erzeugen (105) eines symmetrischen Schlüssels in Abhängigkeit der übermittelten (103) Sicherheitsinformation; - eine Recheneinheit eingerichtet zum Berechnen (106) eines Sicherheitsschlüssels in Abhängigkeit des erzeugten (105) symmetrischen Schlüssels; und - eine weitere Schnittstelleneinheit eingerichtet zum Bereitstellen (107) des berechneten (106) Sicherheitsschlüssels mittels der gesicherten Datenverbindung von dem Tokenserver an das Endgerät.
  15. Computerprogrammprodukt mit Steuerbefehlen, welche das Verfahren gemäß einem der Ansprüche 1 bis 13 ausführen, wenn sie auf einem Computer zur Ausführung gebracht werden.
DE102018005038.7A 2018-06-25 2018-06-25 Smartcard als Sicherheitstoken Pending DE102018005038A1 (de)

Priority Applications (7)

Application Number Priority Date Filing Date Title
DE102018005038.7A DE102018005038A1 (de) 2018-06-25 2018-06-25 Smartcard als Sicherheitstoken
PCT/EP2019/000191 WO2020001807A1 (de) 2018-06-25 2019-06-18 Smartcard als sicherheitstoken
EP19734247.0A EP3811584A1 (de) 2018-06-25 2019-06-18 Smartcard als sicherheitstoken
CN201980039518.7A CN112352410B (zh) 2018-06-25 2019-06-18 使用智能卡作为安全令牌的方法和装置，可读存储介质
US17/251,622 US11341232B2 (en) 2018-06-25 2019-06-18 Smart card as a security token
MX2020014189A MX2020014189A (es) 2018-06-25 2019-06-18 Tarjeta inteligente como token de seguridad.
CA3101539A CA3101539A1 (en) 2018-06-25 2019-06-18 Smartcard as a security token

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102018005038.7A DE102018005038A1 (de) 2018-06-25 2018-06-25 Smartcard als Sicherheitstoken

Publications (1)

Publication Number Publication Date
DE102018005038A1 true DE102018005038A1 (de) 2020-01-02

Family

ID=67107368

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102018005038.7A Pending DE102018005038A1 (de) 2018-06-25 2018-06-25 Smartcard als Sicherheitstoken

Country Status (7)

Country Link
US (1) US11341232B2 (de)
EP (1) EP3811584A1 (de)
CN (1) CN112352410B (de)
CA (1) CA3101539A1 (de)
DE (1) DE102018005038A1 (de)
MX (1) MX2020014189A (de)
WO (1) WO2020001807A1 (de)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102017000768A1 (de) * 2017-01-27 2018-08-02 Giesecke+Devrient Mobile Security Gmbh Verfahren zum Durchführen einer Zweifaktorauthentifizierung
WO2020163580A1 (en) * 2019-02-06 2020-08-13 Mastercard International Incorporated Method and system for generation of a high assurance payment token
US11736466B2 (en) * 2019-09-18 2023-08-22 Bioconnect Inc. Access control system
US11336438B2 (en) * 2020-03-31 2022-05-17 EMC IP Holding Company LLC Remote approval and execution of restricted operations
FR3124285A1 (fr) * 2021-06-16 2022-12-23 Orange procédé d’authentification, dispositif et programme correspondant.

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6327578B1 (en) * 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol
DE60023340T2 (de) 1999-12-01 2006-07-27 Eoriginal Inc. Verfahren zur elektronischen speicherung und wiedergewinnung von authentifizierten originaldokumenten
US8572394B2 (en) * 2009-09-04 2013-10-29 Computer Associates Think, Inc. OTP generation using a camouflaged key
DE102012111481B4 (de) 2012-11-27 2017-02-09 Deutsche Telekom Ag Verfahren und Vorrichtung zur Erkennung von Anwendungen auf mobilen Endgeräten

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050182934A1 (en) * 2004-01-28 2005-08-18 Laszlo Elteto Method and apparatus for providing secure communications between a computer and a smart card chip
US7930554B2 (en) * 2007-05-31 2011-04-19 Vasco Data Security,Inc. Remote authentication and transaction signatures
CN101236674A (zh) * 2008-02-02 2008-08-06 东信和平智能卡股份有限公司 智能密钥设备及其与外部设备进行信息交换的方法
US8582778B2 (en) * 2011-06-01 2013-11-12 International Business Machines Corporation Integrated key server
US10880741B2 (en) * 2013-07-23 2020-12-29 Capital One Services, Llc Automated bluetooth pairing

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6327578B1 (en) * 1998-12-29 2001-12-04 International Business Machines Corporation Four-party credit/debit payment protocol
DE60023340T2 (de) 1999-12-01 2006-07-27 Eoriginal Inc. Verfahren zur elektronischen speicherung und wiedergewinnung von authentifizierten originaldokumenten
US8572394B2 (en) * 2009-09-04 2013-10-29 Computer Associates Think, Inc. OTP generation using a camouflaged key
DE102012111481B4 (de) 2012-11-27 2017-02-09 Deutsche Telekom Ag Verfahren und Vorrichtung zur Erkennung von Anwendungen auf mobilen Endgeräten

Also Published As

Publication number Publication date
MX2020014189A (es) 2021-03-09
CN112352410A (zh) 2021-02-09
CN112352410B (zh) 2023-07-25
US20210110027A1 (en) 2021-04-15
WO2020001807A1 (de) 2020-01-02
EP3811584A1 (de) 2021-04-28
CA3101539A1 (en) 2020-01-02
US11341232B2 (en) 2022-05-24

Similar Documents

Publication Publication Date Title
EP3574625B1 (de) Verfahren zum durchführen einer authentifizierung
DE102012219618B4 (de) Verfahren zur Erzeugung eines Soft-Tokens, Computerprogrammprodukt und Dienst-Computersystem
DE102018005038A1 (de) Smartcard als Sicherheitstoken
EP2962439B1 (de) Lesen eines attributs aus einem id-token
EP3748521B1 (de) Verfahren zum lesen von attributen aus einem id-token
WO2021198017A1 (de) Personalisierter, serverindividueller authentifizierungsmechanismus
EP3641369B1 (de) Absicherung einer p2p-kommunikation
EP2752785B1 (de) Verfahren zur Personalisierung eines Secure Elements (SE) und Computersystem
EP3271855B1 (de) Verfahren zur erzeugung eines zertifikats für einen sicherheitstoken
EP2909778B1 (de) Verfahren zur authentifizierung mit einem token
EP2909779B1 (de) Verfahren zur erzeugung eines one-time-password (otp)
EP3882796A1 (de) Nutzerauthentifizierung unter verwendung zweier unabhängiger sicherheitselemente
EP2381712B1 (de) Sicheres Auslesen von Daten aus einem Funkgerät mit festintegriertem TPM
EP3035270A1 (de) Kartenbasierte offline-token generierung
DE102015209073A1 (de) Verfahren zum Lesen von Attributen aus einem ID-Token
EP2916252B1 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102017128807A1 (de) Verfahren und Anordnung zum Auslösen einer elektronischen Zahlung
EP4295605A1 (de) Nutzerauthentifizierung unter verwendung zweier unabhängiger sicherheitselemente
EP2819079B1 (de) Elektronisches Transaktionsverfahren und Computersystem
DE102015017060A1 (de) Verfahren zum Lesen von Attributen aus einem ID-Token
DE102015017061A1 (de) Verfahren zum Lesen von Attributen aus einem ID-Token

Legal Events

Date Code Title Description
R163 Identified publications notified
R081 Change of applicant/patentee

Owner name: GIESECKE+DEVRIENT EPAYMENTS GMBH, DE

Free format text: FORMER OWNER: GIESECKE+DEVRIENT MOBILE SECURITY GMBH, 81677 MUENCHEN, DE

Owner name: GIESECKE+DEVRIENT MOBILE SECURITY GERMANY GMBH, DE

Free format text: FORMER OWNER: GIESECKE+DEVRIENT MOBILE SECURITY GMBH, 81677 MUENCHEN, DE

R081 Change of applicant/patentee

Owner name: GIESECKE+DEVRIENT EPAYMENTS GMBH, DE

Free format text: FORMER OWNER: GIESECKE+DEVRIENT EPAYMENTS GMBH, 81677 MUENCHEN, DE

Owner name: GIESECKE+DEVRIENT MOBILE SECURITY GERMANY GMBH, DE

Free format text: FORMER OWNER: GIESECKE+DEVRIENT EPAYMENTS GMBH, 81677 MUENCHEN, DE

R081 Change of applicant/patentee

Owner name: GIESECKE+DEVRIENT EPAYMENTS GMBH, DE

Free format text: FORMER OWNER: GIESECKE+DEVRIENT MOBILE SECURITY GERMANY GMBH, 81677 MUENCHEN, DE