[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

DE102018005861A1 - Verfahren zum Anonymisieren einer PAN eines Karteninhabers - Google Patents

Verfahren zum Anonymisieren einer PAN eines Karteninhabers Download PDF

Info

Publication number
DE102018005861A1
DE102018005861A1 DE102018005861.2A DE102018005861A DE102018005861A1 DE 102018005861 A1 DE102018005861 A1 DE 102018005861A1 DE 102018005861 A DE102018005861 A DE 102018005861A DE 102018005861 A1 DE102018005861 A1 DE 102018005861A1
Authority
DE
Germany
Prior art keywords
pan
database
encrypted
encrypted code
random number
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.)
Ceased
Application number
DE102018005861.2A
Other languages
English (en)
Inventor
Ajit Kulkarni
Christian Boelle
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 Mobile Security 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 DE102018005861.2A priority Critical patent/DE102018005861A1/de
Publication of DE102018005861A1 publication Critical patent/DE102018005861A1/de
Ceased 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/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • 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/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • G06F21/6254—Protecting personal data, e.g. for financial or medical purposes by anonymising data, e.g. decorrelating personal data from the owner's identification
    • 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/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G06Q20/38215—Use of certificates or encrypted proofs of transaction rights
    • 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/3827—Use of message hashing
    • 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
    • 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/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • 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/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • 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

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • General Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • Finance (AREA)
  • Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Medical Informatics (AREA)
  • Databases & Information Systems (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Storage Device Security (AREA)

Abstract

Die vorliegende Erfindung besteht darin, ein Verfahren zum Anonymisieren einer PAN eines Karteninhabers, verwendet in einer Zahlungskarte für Finanztransaktionen, bereitzustellen. Die PAN wird in einer ersten Datenbank gespeichert. Wenn die PAN zwischen der ersten Datenbank und einer entfernten Stelle ausgetauscht wird, wird die PAN verschlüsselt, um einen ersten verschlüsselten Code zu erhalten. Der erste verschlüsselte Code wird mit zumindest einer dynamisch generierten Zufallszahl noch einmal verschlüsselt, um ein Token zu generieren, wobei es das Token der entfernten Stelle ermöglicht, die tatsächliche PAN für vielfältige Zwecke zu verwenden, wodurch es das Hacken der PAN verhindert. Die Zufallszahl oder -zahlen wird bzw. werden zum Zeitpunkt des Berechnens des Tokens mit einem Algorithmus identifiziert, was dann die spätere Verwendung der tatsächlichen PAN für vielfältige Zwecke möglich macht.

Description

  • Gebiet der Erfindung
  • Die vorliegende Erfindung betrifft ein Verfahren zum Anonymisieren von sensiblen Daten. Insbesondere betrifft die Erfindung ein Verfahren zum Anonymisieren einer PAN eines Karteninhabers während der Durchführung von Finanztransaktionen und vielfältigen anderen Zwecken.
  • Hintergrund der Erfindung
  • Die PAN-Nummer oder Primary Account Number ist eine Kartenkennung und identifiziert nicht direkt die Bankkontonummer/n, mit welchem/n die Karte von dem herausgebenden Unternehmen verbunden ist. Insbesondere ist die PAN eine eindeutige Kennung, die sensible Daten enthält, die ein primäres Konto zum Durchführen von Finanztransaktionen bezeichnet. Jede PAN ist ein numerischer Code. Ein Token wird berechnet, um die PAN zu repräsentieren. Das Paar von PAN und seinem Token bezeichnet eine bestimmte Information über die Kontonummer. Diese sensible Information ist jedoch auf eine Weise verschlüsselt, dass, falls ein Hacker irgendwie den Zugang zu mehreren Token-PAN-Paaren bekommen hat, eine hohe Wahrscheinlichkeit besteht, dass der Hacker den Schlüssel oder die Logik, der bzw. die verwendet wurde, um die Tokens abzuleiten, extrahieren kann und dann eine oder alle der durch die Tokens repräsentierten sensiblen PANs identifizieren kann.
  • Eine zentrale Karteninhaber-Datenbank, zum Beispiel eine Bank, speichert sensible Karteninhaberdaten, wie beispielsweise Primary Account Number (PAN), in verschlüsselter Form. Falls Daten zwischen einer zentralen Datenbank und einer entfernten Stelle während der Durchführung einer Finanztransaktion gesendet werden, besteht die Möglichkeit des Hackens dieser Daten, und die Hacker können mehrere Transaktionen mit den abgeleiteten Daten durchführen. Daher ist ein Sichern der sensiblen Daten, wie der PAN, wichtig, um eine sichere Transaktion durchzuführen.
  • Daher besteht ein Bedarf für ein Verfahren zum Anonymisieren der PAN eines Karteninhabers während der Durchführung von Finanztransaktionen, welches einige oder alle der Nachteile der existierenden Verfahren von Finanztransaktionen überwindet.
  • Aufgaben der Erfindung
  • Eine Aufgabe der vorliegenden Erfindung ist es, ein Verfahren zum Anonymisieren einer PAN eines Karteninhabers während der Durchführung von Finanztransaktionen bereitzustellen.
  • Insbesondere ist es eine Aufgabe der vorliegenden Erfindung, ein Verfahren zum Anonymisieren einer PAN eines Karteninhabers während der Durchführung von Finanztransaktionen bereitzustellen, welches die Transaktion sichert und ein Hacken der PAN verhindert.
  • Insbesondere ist es eine Aufgabe der vorliegenden Erfindung, ein Verfahren zum Anonymisieren einer PAN eines Karteninhabers während der Durchführung von Finanztransaktionen bereitzustellen, welches eine Entschlüsselung der sensiblen Daten, um die betrügerische Transaktion auszuführen, verhindert.
  • Insbesondere ist es eine Aufgabe der vorliegenden Erfindung, ein Verfahren zum Anonymisieren einer PAN eines Karteninhabers während der Durchführung von Finanztransaktionen bereitzustellen, welches einfach im Betrieb ist.
  • Zusammenfassung der Erfindung
  • Die Aufgabe wird gelöst durch eine Erfindung, wie in den unabhängigen Ansprüchen beschrieben. Ausführungsbeispiele der Erfindung sind in abhängigen Ansprüchen beschrieben. Gemäß der Erfindung wird ein Verfahren zum Anonymisieren einer PAN eines Karteninhabers gemäß der vorliegenden Erfindung bereitgestellt. Die PAN wird in einer ersten Datenbank, zum Beispiel einer Bank-Datenbank, gespeichert und ist für den Karteninhaber für Finanztransaktionen verfügbar.
  • Beim Durchführen einer Finanztransaktion sollte eine PAN zwischen der ersten Datenbank oder einer Quelle und einer entfernten Stelle ausgetauscht werden. Die erste Datenbank ist eine Bank-Datenbank und die entfernte Stelle ist die Empfänger-Stelle, an welche die Transaktion durchgeführt werden soll. Das Verfahren stellt eine sichere Speicherung und Verwendung der PAN in der entfernten Stelle sicher. Die PAN aus der ersten Datenbank wird in einen ersten verschlüsselten Code verschlüsselt. Der erste verschlüsselte Code wird durch Zerhacken („Hashing“) der PAN unter Verwendung eines Hashing-Algorithmus erhalten, welcher von der ersten Datenbank durchgeführt wird. Es kann für einen Fachmann naheliegend sein, einen beliebigen Hashing-Algorithmus zu verwenden, um die PAN zu hashen, um den ersten verschlüsselten Code zu erhalten.
  • Sobald die PAN in den ersten verschlüsselten Code gehasht ist, dann wird die gehashte PAN von der ersten Datenbank an eine zweite Datenbank übertragen, welche die verschlüsselte PAN speichert. Die zweite Datenbank kann mit einem Applikationsmodul ausgestattet sein, welches den ersten verschlüsselten Code in einen zweiten verschlüsselten Code konvertiert. Das Applikationsmodul kann zumindest ein Salt oder eine Zufallszahl generieren, um den ersten verschlüsselten Code in einen zweiten verschlüsselten Code zu konvertieren. Das Applikationsmodul ist mit einer Nachschlagetabelle ausgestattet, welche den ersten verschlüsselten Code und die entsprechenden Zufallszahlen indiziert.
  • In einem Ausführungsbeispiel werden der erste verschlüsselte Code und die entsprechende Zufallszahl im Applikationsmodul indiziert. Der erste verschlüsselte Code und die entsprechende Zufallszahl werden in der zweiten Datenbank indiziert. In einem anderen Ausführungsbeispiel wird eine vordefinierte Zufallszahl in einer einzigen Spalte in der zweiten Datenbank indiziert.
  • In noch einem anderen Ausführungsbeispiel wird der erste verschlüsselte Code zum Generieren eines Tokens oder des zweiten verschlüsselten Codes mit einer Mehrzahl von Zufallszahlen verschlüsselt, und jede der Zufallszahlen wird in der zweiten Datenbank indiziert. Die Zufallszahlen werden in mehreren Nachschlagetabellen in der zweiten Datenbank generiert und gespeichert. Die gegebene generierte Zufallszahl wird an der durch den Index in der Nachschlagetabelle gegebenen Position gespeichert. Der zweite verschlüsselte Code oder das Token wird durch Verschlüsseln des ersten verschlüsselten Codes und der entsprechenden Zufallszahl(en) oder Salt(s) berechnet. Das Token wird in der Datenbank der entfernten Stelle für vielfältige Zwecke gespeichert, wodurch es ein Hacken der PAN verhindert.
  • Kurze Beschreibung der Zeichnungen
  • Die Vorteile und Merkmale der vorliegenden Erfindung werden mit Bezug auf die folgende detaillierte Beschreibung und Ansprüche, genommen in Verbindung mit den begleitenden Zeichnungen, besser verstanden, wobei gleiche Elemente mit gleichen Symbolen identifiziert sind, und in welchen:
  • 1 ein Blockdiagramm darstellt, das einen Ablauf eines Verfahrens zum Anonymisieren einer PAN eines Karteninhabers gemäß der vorliegenden Erfindung wiedergibt.
  • Detaillierte Beschreibung der Erfindung
  • Die offenbarten Ausführungsbeispiele sind lediglich beispielhaft für die Erfindung, welche in vielfältigen Formen verkörpert sein kann.
  • Nun bezugnehmend auf 1 ist ein Blockdiagramm dargestellt, das den Ablauf eines Verfahrens zum Anonymisieren einer PAN eines Karteninhabers gemäß der vorliegenden Erfindung wiedergibt. Die PAN ist in einer Zahlungskarte zum Durchführen von Finanztransaktionen eingebettet. Die PAN ist auch in einer ersten Datenbank 100 gespeichert, wie beispielsweise einer Bank-Datenbank, und ist in der Zahlungskarte des Karteninhabers zum Durchführen von Finanztransaktionen bereitgestellt. Jede Zahl oder jedes Zahlenpaar in der PAN bezeichnet bestimmte sensible Informationen, welche zum Identifizieren der Kontonummer des Karteninhabers benötigt werden.
  • Zum Beispiel sollte beim Durchführen einer Finanztransaktion die PAN zwischen der ersten Datenbank 100 oder einer Quelle und einer entfernten Stelle 300 ausgetauscht werden. Die erste Datenbank 100 ist eine Bank-Datenbank und die entfernte Stelle 300 ist die Empfänger-Stelle, an welche die Transaktion durchgeführt werden soll. Das Verfahren stellt eine sichere Übertragung der PAN an die entfernte Stelle 300 sicher. Beim Durchführen der Transaktion wird die PAN von der ersten Datenbank 100 in einen ersten verschlüsselten Code verschlüsselt. Der erste verschlüsselte Code wird durch Hashen der PAN unter Verwendung eines Hashing-Algorithmus, welcher von der ersten Datenbank 100 durchgeführt wird, erhalten. Es kann für einen Fachmann naheliegend sein, einen beliebigen Hashing-Algorithmus zu verwenden, um die PAN zu hashen, um den ersten verschlüsselten Code zu erhalten.
  • Sobald die PAN in den ersten verschlüsselten Code gehasht ist, dann wird die gehashte PAN von der ersten Datenbank 100 an eine zweite Datenbank 200 übertragen, welche die verschlüsselte PAN speichert. Die zweite Datenbank 200 kann ein Server sein und kann mit einem Applikationsmodul ausgestattet sein, welches den ersten verschlüsselten Code in einen zweiten verschlüsselten Code konvertiert. Das Applikationsmodul generiert zumindest einen Salt oder eine Zufallszahl, um den ersten verschlüsselten Code in einen zweiten verschlüsselten Code zu konvertieren. Das Applikationsmodul ist mit einer Nachschlagetabelle ausgestattet, welche den ersten verschlüsselten Code und die entsprechenden Zufallszahlen indiziert. Des Weiteren wird die Zuordnung der für eine gegebene PAN verwendeten Zufallszahl durch den Algorithmus zum Zeitpunkt der ersten Berechnung des Tokens oder zu einem anderen Zeitpunkt sichergestellt. Die Zufallszahl oder -zahlen wird bzw. werden mit einem Algorithmus zum Zeitpunkt des Berechnens des Tokens identifiziert, was dann die spätere Verwendung der tatsächlichen PAN für vielfältige Zwecke möglich macht.
  • In einem Ausführungsbeispiel werden der erste verschlüsselte Code und die entsprechende Zufallszahl im Applikationsmodul indiziert. Die Zufallszahl wird zur Laufzeit dynamisch generiert und wird in der zweiten Datenbank 200 gespeichert. Die generierte Zufallszahl wird an der durch den Index in der Nachschlagetabelle gegebenen Position gespeichert.
  • Zum Beispiel,
  • Index Salt
    524018319832495 2237155484316918743
    393008010178192 3017539582807679362
    .... ....
  • Die Zahlen in der Index-Spalte geben den numerischen Wert des ersten verschlüsselten Codes an und sind mit einer entsprechenden Zufallszahl indiziert. In dem Ausführungsbeispiel muss die Länge (Anzahl von Zeilen) der Tabelle, die in dem Algorithmus verwendete Variable „tableLength“, nicht die tatsächliche Länge sein, sondern eine beabsichtigte Länge, aber der Algorithmus stellt sicher, dass der „Index“ immer kleiner ist als diese Länge. Die Tabellenlänge ist die beabsichtigte Anzahl von Zeilen in der Nachschlagetabelle. Die Nachschlagetabelle wird dynamisch befüllt, indem für jede anonymisierte PAN eine Zeile hinzugefügt wird.
  • Der zweite verschlüsselte Code oder das Token wird durch Verschlüsseln des ersten verschlüsselten Codes (durch einen Hash der PAN erhaltener Wert) und der entsprechenden Zufallszahl oder des Salts berechnet. Der zweite verschlüsselte Code kann unter Verwendung eines von dem Applikationsmodul besessenen zugehörigen Schlüssels weiter verschlüsselt werden, während er in der zweiten Datenbank 200 gespeichert wird. Das Token wird für die Transaktionen, wie eine Suche nach der tatsächlichen PAN, verwendet, aber gleichzeitig kann die PAN aus dem Token nicht extrahiert oder gehackt werden.
  • In einem anderen Ausführungsbeispiel wird eine vordefinierte Zufallszahl in einer einzigen Spalte indiziert. In diesem Ausführungsbeispiel muss die Nachschlagetabelle eine vordefinierte Zufallszahl enthalten, welche über den Lebenszyklus der Benutzerinformation intakt bleibt.
  • Zum Beispiel,
    Salt
    2237155484316918743
    3017539582807679362
    ......
  • Die Nachschlagetabelle weist nur eine Spalte auf, die die Zufallszahlen speichert. Die zu verwendende Zufallszahl wird basierend auf der Indexposition identifiziert.
  • Zum Beispiel in der obigen Tabelle, falls der für eine gegebene PAN berechnete Index 2 ist, dann ist die verwendete Zufallszahl 3017539582807679362. Da die Zufallszahl- oder Salt-Spalte indiziert ist, wäre ein Lokalisieren des n-ten Eintrags für die Datenbanken nicht zeitintensiv. Des Weiteren muss die Länge der Tabelle, die in dem Algorithmus verwendete Variable „tableLength“, die tatsächliche Anzahl von Zeilen in der Tabelle sein.
  • In einem anderen Ausführungsbeispiel wird der erste verschlüsselte Code zum Generieren eines Tokens mit einer Mehrzahl von Zufallszahlen verschlüsselt, und jede der Zufallszahlen wird indiziert. In diesem Ausführungsbeispiel kann die Nachschlagetabelle mehrere Nachschlagetabellen enthalten, die Zufallszahlen wie einen SALT1, einen SALT2, einen SALT3, und so weiter enthalten.
  • Des Weiteren könnte in diesem Ausführungsbeispiel die Länge oder Anzahl von Zeilen der Nachschlagetabellen unterschiedlich sein, z.B. SALT1 = 10000, SALT2 = 1000, SALT3 = 500 und dergleichen.
  • Zum Beispiel wird aus dem ersten verschlüsselten Code ein Index berechnet, um in die SALTI-Tabelle hineinzugehen. Hier muss die „tableLength“ gleich einer tatsächlichen Länge der SALTI-Tabelle sein. Danach wird aus dem ersten verschlüsselten Code + Salt1 (Salt-Wert aus der SALT1-Tabelle) ein Index berechnet, um in die SALT2-Tabelle hineinzugehen. Hier muss die verwendete „tableLength“ größer als die tatsächliche Länge der SALT2-Tabelle sein, um die Möglichkeit für eine „Index außerhalb der Grenzen“-Situation zu haben. Dann wird aus dem ersten verschlüsselten Code + Salt1 + Salt2, der Index berechnet, um in die SALT3 hineinzugehen. Hier muss die verwendete „tableLength“ größer als die tatsächliche Länge der SALT3-Tabelle sein, um die Möglichkeit für eine „Index außerhalb der Grenzen“-Situation zu haben.
  • Die Logik, die nächste Zufallszahl zu identifizieren, hängt von der früheren Zufallszahl oder den früheren Zufallszahlen ab, die aus den Nachschlagetabellen verwendet wurde bzw. wurden. Je mehr Nachschlagetabellen, desto höher ist die Sicherheit. Die Zufallszahlen erschweren es, die nachfolgende Zufallszahl oder die nachfolgenden Zufallszahlen (Salt oder Salts) zu kennen, die zum Berechnen des Tokens verwendet wurde bzw. wurden. Jede Nachschlagtabelle wird nicht notwendigerweise für jede gegebene Berechnung verwendet. Dies wird zur Laufzeit festgestellt. Die Reihenfolge und die Länge der verwendeten Tabellen sind jedoch fest, um sicherzustellen, dass garantiert wird, dass der gleiche Salt (oder Salts) für einen gegebenen Hash einer PAN verwendet wird, während das Token berechnet wird.
  • Daher hat die vorliegende Erfindung einen Vorteil beim Bereitstellen eines Verfahrens zum Anonymisieren einer PAN eines Karteninhabers während der Durchführung von Finanztransaktionen, welches die Transaktion sichert und ein Hacken sensibler Daten der PAN verhindert. Das Verfahren verhindert auch ein Entschlüsseln der sensiblen Daten, um die betrügerische Transaktion zu blockieren.

Claims (6)

  1. Verfahren zum Anonymisieren einer in einer Zahlungskarte für Finanztransaktionen verwendeten PAN eines Karteninhabers, wobei die PAN in einer ersten Datenbank 100 gespeichert ist; wobei die PAN zwischen der ersten Datenbank 100 und einer entfernten Stelle 300 ausgetauscht wird, wobei die PAN verschlüsselt wird, um einen ersten verschlüsselten Code zu erhalten, und der erste verschlüsselte Code mit zumindest einer dynamisch generierten Zufallszahl noch einmal verschlüsselt wird, um ein Token zu generieren, wobei es das Token der entfernten Stelle 300 ermöglicht, die tatsächliche PAN für vielfältige Zwecke zu verwenden, wodurch es ein Hacken der PAN verhindert.
  2. Verfahren nach Anspruch 1, wobei der erste verschlüsselte Code und die entsprechende Zufallszahl in einer zweiten Datenbank 200 indiziert werden.
  3. Verfahren nach Anspruch 1, wobei eine vordefinierte Zufallszahl in einer einzigen Spalte in einer zweiten Datenbank 200 indiziert wird.
  4. Verfahren nach Anspruch 1 und 2, wobei der erste verschlüsselte Code zum Generieren eines Tokens mit einer Mehrzahl von Zufallszahlen verschlüsselt wird, und jede der Zufallszahlen in einer zweiten Datenbank 200 indiziert wird.
  5. Verfahren nach Anspruch 1, wobei die Zuordnung einer für eine gegebene PAN verwendeten Zufallszahl durch den Algorithmus zum Zeitpunkt der ersten Berechnung des Tokens oder zu einem anderen Zeitpunkt sichergestellt wird.
  6. Verfahren nach Anspruch 1, wobei der erste verschlüsselte Code durch Hashen der PAN unter Verwendung eines Hashing-Algorithmus erhalten wird.
DE102018005861.2A 2018-07-25 2018-07-25 Verfahren zum Anonymisieren einer PAN eines Karteninhabers Ceased DE102018005861A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE102018005861.2A DE102018005861A1 (de) 2018-07-25 2018-07-25 Verfahren zum Anonymisieren einer PAN eines Karteninhabers

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE102018005861.2A DE102018005861A1 (de) 2018-07-25 2018-07-25 Verfahren zum Anonymisieren einer PAN eines Karteninhabers

Publications (1)

Publication Number Publication Date
DE102018005861A1 true DE102018005861A1 (de) 2020-03-12

Family

ID=69620908

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102018005861.2A Ceased DE102018005861A1 (de) 2018-07-25 2018-07-25 Verfahren zum Anonymisieren einer PAN eines Karteninhabers

Country Status (1)

Country Link
DE (1) DE102018005861A1 (de)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0387599B1 (de) * 1989-03-14 1995-09-27 Tandem Computers Incorporated Verfahren zum Chiffrieren von übertragenen Daten, das einen Einheitsschlüssel anwendet
US20080040284A1 (en) * 2004-09-07 2008-02-14 Hazel Patrick K Method and system for secured transactions
US20120039469A1 (en) * 2006-10-17 2012-02-16 Clay Von Mueller System and method for variable length encryption
US20140287816A1 (en) * 2011-11-09 2014-09-25 Novomatic Ag Method of and device for generating true random numbers and a gaming system
US20150019443A1 (en) * 2013-07-15 2015-01-15 John Sheets Secure remote payment transaction processing
US20150312038A1 (en) * 2014-04-23 2015-10-29 Karthikeyan Palanisamy Token security on a communication device

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0387599B1 (de) * 1989-03-14 1995-09-27 Tandem Computers Incorporated Verfahren zum Chiffrieren von übertragenen Daten, das einen Einheitsschlüssel anwendet
US20080040284A1 (en) * 2004-09-07 2008-02-14 Hazel Patrick K Method and system for secured transactions
US20120039469A1 (en) * 2006-10-17 2012-02-16 Clay Von Mueller System and method for variable length encryption
US20140287816A1 (en) * 2011-11-09 2014-09-25 Novomatic Ag Method of and device for generating true random numbers and a gaming system
US20150019443A1 (en) * 2013-07-15 2015-01-15 John Sheets Secure remote payment transaction processing
US20150312038A1 (en) * 2014-04-23 2015-10-29 Karthikeyan Palanisamy Token security on a communication device

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
Oracle® Hospitality Simphony. PA-DSS Implementation Guide. Release 2.8. Part Number: E66804-01, April 2016. URL: https://docs.oracle.com/cd/E66669_01/doc.28/e66804.pdf [abgerufen am 26. März 2019] *
Oracle® Hospitality Simphony. PA-DSS Implementation Guide. Release 2.8. Part Number: E66804-01, April 2016. URL: https://docs.oracle.com/cd/E66669_01/doc.28/e66804.pdf [abgerufen am 26. März 2019]
TransArmor® / Tokenization. Payeezy.com, 22. März 2018. URL: https://support.payeezy.com/hc/en-us/articles/203731189-TransArmor-Tokenization- [abgerufen am 26. März 2019] *
TransArmor® / Tokenization. Payeezy.com, 22. März 2018. URL: https://support.payeezy.com/hc/en-us/articles/203731189-TransArmor-Tokenization- [abgerufen am 26. März 2019]

Similar Documents

Publication Publication Date Title
DE69334091T2 (de) Zugangskontrollen-Untersystem und Verfahren für ein verteiltes Rechensystem, das lokal gespeicherte Authentifizierungsdaten benutzt
EP3256977B1 (de) Computerimplementiertes verfahren zur zugriffskontrolle
DE69424729T2 (de) Verfahren zur Verifizierung von Unterschriften in einem Kommunikationssystem
EP3452941B1 (de) Verfahren zur elektronischen dokumentation von lizenzinformationen
DE112016006077T5 (de) Systeme und verfahren zur bereitstellung einer blockketten-basierten multifaktor-identitätsprüfung von personen
EP2735991B1 (de) Computerimplementiertes Verfahren zum Ersetzen eines Datenstrings
DE112012005033B4 (de) Systemübergreifende sichere Anmeldung
EP3735650B1 (de) Persönliche dokumentenblockchain-struktur
DE102021004548A1 (de) Verfahren und transaktionssystem zum übertragen von token in einem elektronischen transaktionssystems
DE69736283T2 (de) Zugangskontrollsystem zu einer funktion, in der die chiffrierung mehrere dynamische veränderliche enthält
DE60100363T2 (de) Sequenznummerierungsmechanismus zur sicherung der ausführungsordnungs-integrietät von untereinander abhängigen smart-card anwendungen
EP3480724B1 (de) Computerimplementiertes verfahren zum ersetzen eines datenstrings durch einen platzhalter
WO2023011756A1 (de) Sicheres element, verfahren zum registrieren von token und tokenreferenzregister
EP3629516B1 (de) Dezentralisierte identitätsmanagement-lösung
DE102018005861A1 (de) Verfahren zum Anonymisieren einer PAN eines Karteninhabers
DE112020005557B4 (de) Registrierungseinrichtung, suchoperationseinrichtung, datenverwaltungseinrichtung, registrierungsprogramm, suchoperationsprogramm und datenverwaltungsprogramm
DE102014018892A1 (de) Verfahren zum Betreiben einer Computereinheit sowie eine solche Computereinheit
WO2018130426A1 (de) Anonymisierung einer blockkette
DE102018204447B4 (de) Automatisiertes Verfahren zum Schutz von elektronischen Daten zum Zwecke der Datenverarbeitung durch Dritte unter Einbezug transparenter und unterbrechungssicherer Vergütung
DE202021100647U1 (de) Personendatenanonymisierungssystem (PDAS) mit kundenspezifischem Token
DE102018006313A1 (de) Verfahren mit Safe-Error-Abwehrmaßnahme
EP3734486B1 (de) Computerimplementiertes verfahren zum ersetzen eines datenstrings
DE102008002588B4 (de) Verfahren zur Erzeugung eines asymmetrischen kryptografischen Schlüsselpaares und dessen Anwendung
DE202024104854U1 (de) Vorrichtung zur Sicherung empfangener Transaktionen
DE112021000709T5 (de) Schlüsselattributüberprüfung

Legal Events

Date Code Title Description
R012 Request for examination validly filed
R016 Response to examination communication
R002 Refusal decision in examination/registration proceedings
R003 Refusal decision now final