<Desc/Clms Page number 1>
Die vorliegende Erfindung betrifft ein System zur Durchführung des elektronischen Zahlungsverkehrs an Bankautomaten (wie z. B. Geldausgabeautomaten), Point-of-Sale-Terminals und Automaten jeder Art, bei dem alle sicherheitsrelevanten Daten in Chipkarten und Sicherheitsmodulen geschützt verwaltet werden, wichtige anwendungsspezifischen Daten in Terminalkarten oder Chipkarten verwaltet werden, die auch die Schlüssel dieser Anwendung verwahren und die Terminals über eine oder mehrere Chipkartenleseeinheiten für Terminalkarten verfügen, sodass sie dahingehend konzipiert sein konnen, dass eine Erweiterung des Systems um zusätzliche Anwendungen sehr einfach durch Stecken weiterer Terminalkarten erfolgen kann.
Der hier beschriebene elektronische Zahlungsverkehr nützt die integrierten Sicherheitsmechanismen von Mikroprozessorkarten, um sowohl für den Kunden als auch für den Systembetreiber höchste Sicherheit gewährleisten zu können. Dabei wird jedoch darauf geachtet, dass trotz aller Sicherheitsvorkehrungen der schnelle und reibungslose Ablauf des Zahlungsverkehrs nicht beeinträchtigt wird.
Derartige Systeme sind in vielen Publikationen (z. B. The ESPRIT Projekt CAFE - High Security Digital Payment Systems ; D. Chaum : Untraceable Electronic Mail, Return Adresses, and Digital Pseudonyms ; A. Beutelspacher, T. Hueske, A. Pfau : Kann man mit Bits bezahlen ?) beschrieben, patentiert (z. B. US 4 961 142 A, DE 4 126 809 A1, EP 0 439 609 A1, EP 0 616 447 A2, WO 96/26586 A1) und z. B. in CEN EN 1546 in einer Norm dargestellt. In diesen Publikationen werden Online- und Offline-orientierte Systeme beschrieben, die meist nicht mit anderen Systemen kombinierbar sind.
Ausserdem enthalten die offline-orientierten Systeme oftmals zentrale Kontrollmechanismen, die aber auf keine eigenen (rein zentralen) Schlüsseln basieren. Die Erfindung verringert bzw. eliminiert die Nachteile dieser Systeme und sie erlaubt es, die Verfügbarkeit zu erhöhen.
Die EP 0 439 609 A 1 enthält ein System mit Magnetstreifenkarten, die keine elektronischen Unterschriften erzeugen können. Dieses Patent unterscheidet sich deshalb schon wesentlich vom im Anmeldungsgegenstand beschriebenen Zahlungsverkehrssystem, das im Anspruch 1 von zwei elektronischen Unterschriften ausgeht, die durch Kundenkarten erzeugt werden. Alle weiteren Ansprüche beziehen sich auf Anspruch 1. Die EP 0 616 447 A2 und die WO 96/26586 A1 enthalten Systeme mit asymmetrischer Kryptographie. Diese Systeme benötigen zwei Schlüssel (die ein zusammengehöriges Schlüsselpaar bilden), wovon einer davon öffentlich und der andere geheim ist. Ein Schlüssel wird zur Verschlüsselung, der andere zur Entschlüsselung benötigt.
Die vorliegende Patentanmeldung benötigt in der Kundenkarte ebenso zwei Schlussel Es werden aber beide Schlüssel zur Erzeugung der elektronischen Unterschrift (d. h. zur Verschlüsselung) benutzt und nicht ein Schlüssel zur Verschlüsselung und einer zur Entschlüsselung. Diese beiden Schlüssel können gegenseitig nicht abgeleitet werden (stehen also in keinem gegenseitigen Bezug und bilden auch kein Schlüsselpaar) und sind von keiner PIN abhängig. Die Existenz zweier unabhängiger Schlüssel basiert beim Anmeldungsgegenstand auf der Idee, dass eine elektronische Unterschrift dezentral und eine zentral überprüft werden kann.
Auch die anderen oben angegebenen Patente und die Norm CEN 1546 verwenden keine zwei elektronischen Unterschriften zur Absicherung von Transaktionen. Sie unterscheiden sich deshalb schon wesentlich vom im Anmeldungsgegenstand beschriebenen Zahlungsverkehrssystem, das im Anspruch 1 von zwei elektronischen Unterschriften ausgeht, die durch Kundenkarten erzeugt werden. Alle weiteren Ansprüche beziehen sich auf Anspruch 1.
Im Anmeldungsgegenstand sind alle wichtigen Daten (personenbezogene Daten, Schlüssel, in Chipkarten und in Sicherheitsmodulen an Zentralrechnern geschützt. Der Zugriff auf diese Daten ist nur mit Kenntnis der entsprechenden Schlüssel und nach gegenseitiger Authentifikation zwischen Kundenkarte und Terminalkarte (bzw. Sicherheitsmodul am Zentralrechner) möglich.
Die Authentifikation zwischen den beiden Chipkarten erfolgt mittels symmetrischer oder asymmetrischer Verschlüsselung, wobei sowohl statische als auch dynamische Authentifikation vorgesehen sind. Authentifikation mit statischer asymmetrischer Verschlüsselung bedeutet, dass vereinbarte Datenfelder der Kundenkarte, die von der Terminalkarte frei gelesen werden können, zum Zeitpunkt der Kartenausgabe asymmetrisch verschlüsselt werden und dieser Wert (Zertifikat) in der Karte gespeichert wird. Bei der Authentifikation übergibt die Kundenkarte der Terminalkarte diese vereinbarten Werte und das Zertifikat. Die Terminalkarte entschlüsselt das Zertifikat und vergleicht das Ergebnis gegen die angelieferten Datenfelder.
Bei der dynamischen asymmetrischen Ver-
<Desc/Clms Page number 2>
schlüsselung wird zum Zeitpunkt der Authentifikation von der Terminalkarte eine Zufallszahl bzw. eine ständig veränderte Zahl (z. B. Zähler) an die Kundenkarte übertragen, von dieser mittels eines asymmetrischen Algorithmus (z. B. RSA) verschlüsselt und dieser Wert an die Terminalkarte zurückgeschickt. Die Terminalkarte entschlüsselt den rückgemeldeten Wert und vergleicht den errechneten Wert mit der zuvor übertragenen Zahl.
Ebenso wird grosser Wert auf leichte Erweiterbarkeit gelegt, vor allem, dass es bei einer Erweiterung des Systems zu keinen Änderungen der Terminals und/oder des Zahlungsablaufes kommt.
Im Hinblick auf die Erweiterbarkeit, aber auch aus sicherheitstechnischen Gründen, erfolgt das Erkennen einer unterstützten bzw. die Ablehnung einer unbekannten Anwendung sowie die Verwaltung der Schlüssel nicht im Terminal sondern durch eine Terminaikarte. Diese Terminalkarte ist ebenfalls eine Chipkarte und besitzt ihre eigene Sicherheitslogik. Die Terminals verfügen über einen Chipkartenieser für die Kundenkarten und ein oder mehrere Chipkartenleser (Chipkartenkontaktiereinheiten) für Terminalkarten, die aus Platzgründen auch als Plug-In ausgeführt sein können.
Die Erweiterung um zusätzliche Applikationen (z. B. weitere Geldbörsen) erfolgt unter anderem durch das Stecken zusätzlicher Terminalkarten, die die Schlüssel und Daten dieser Applikationen beinhalten und verwalten. Ebenso kann die Umstellung von einer Kartengeneration auf die nächste durch das Stecken einer weiteren Terminalkarte erfolgen, sodass für die Dauer der Umstellung zwei Terminalkarten die selbe Anwendung, jedoch unterschiedliche Kundenkarten, servicieren (eine Terminalkarte für die auslaufende Kartengeneration und eine Terminalkarte für die neuen Kundenkarten).
Die Erfindung zeichnet sich vor allem durch spezielle Sicherheitsmerkmale aus.
Ein Sicherheitsmerkmal ist der Schutz aller Daten, die zwischen Terminal und Zentralrechner übertragen werden. Dieser Schutz tritt bereits im Terminal und in der Terminalkarte in Kraft und zeichnet sich durch die Verwendung eines 2-Schlüssel-Systemes aus. Die Daten werden zudem mindestens doppelt gespeichert (bei der elektronischen Geldbörse alle Summensätze und die letzten n Einzeitransaktionen, bei Offline-POS alle Transaktionen), um bei Ausfall einer Komponente ein "Recovery" durchführen zu können. Die Sicherheit und Integrität der Daten wird durch die Verwendung von zwei elektronischen Unterschriften, die mit unterschiedlichen Schlüsseln der Kundenkarte erzeugt werden, gewährleistet.
Zur Erzeugung der elektronischen Unterschriften kann jeder dafür geeignete kryptografische Algorithmus benutzt werden (sowohl symmetrische Verfahren wie z. B. der DES-Algorithmus als auch asymmetrische Verfahren wie z. B. RSA oder DSS).
Von diesen beiden elektronischen Unterschriften kann eine bereits im Terminal überprüft werden, da sie mit einem lokalen (dezentralen) Schlüssel generiert wird, der auch der Terminalkarte bekannt ist bzw. von dieser aus anderen Schlüsseln ein- oder mehrstufig ermittelt werden kann. Für die zweite Unterschrift wird ein zentraler Schlüssel verwendet, der nur am Zentralrechner bekannt ist bzw. dessen Ableitung von einem Masterkey nur am Zentralrechner nachvollzogen werden kann, da auch der zugehörige Masterkey nur dort bekannt ist. Sie kann daher erst im Rechenzentrum überprüft werden und bietet so einen zusätzlichen, erhöhten Schutz gegen Fälschungen von Transaktionen, da selbst bei Kenntnis des dezentralen Schlüssels (korruptes Terminal) keine korrekt unterschriebene Transaktion an den Zentralrechner übermittelt werden kann.
Der Datensatz, der von der Kundenkarte (KK) an das Terminal geschickt wird, hat unter anderem folgenden Aufbau :
Transaktionsdaten (Kartennr, Betrag,...), lokale Unterschrift (KK), zentrale Unterschrift (KK)
Die Unterschrift mit dem lokalen Schlüssel wird vor Ort in der Terminalkarte geprüft und nicht an den Zentralrechner übermittelt.
Dafür wird jede Transaktion (bei Geldbörsenzahlungen der Summensatz des jeweiligen Geldbörsenpools = Verrechnungskonto) von der Terminalkarte unterschrieben, wobei ein zentraler Schlüssel verwendet wird. Wurde bei einer Geldbörsenzahlung eine Einzeltransaktion (Kontrolle) erzeugt, so wird auch diese von der Terminalkarte (TK) unterschrieben. Jede Transaktion, die am Zentralrechner eingereicht wird, ist somit durch zwei Unterschriften mit zentralen Schlüsseln gesichert.
Transaktionsdaten (Kartennr., Betrag,...), zentrale Unterschrift (KK), zentrale Unterschrift (TK)
Jede lokale Summe eines Geldbörsenpools wird nur von der Terminalkarte des Händlers unter Verwendung eines zentralen Schlüssels unterschrieben.
Transaktionsdaten (Zähler, Währung,...), lokale Geldbörsenpoolsumme, zentrale Unterschrift
<Desc/Clms Page number 3>
(TK)
Somit werden bei Geldbörsenzahlungen eine bzw. drei (wenn eine Einzeltransaktion erzeugt wurde) elektronische Unterschriften (zentraler Schlüssel der Terminalkarte auf Poolsumme, zentraler Schlüssel der Kundenkarte auf Einzeltransaktion, zentraler Schlüssel der Terminalkarte auf Einzeltransaktion) erzeugt.
Bei der Anwendung "elektronische Geldbörse" werden aus Kostengründen (und aus Gründen der Anonymität bei Geldbörsenzahlungen) je zugeordnetem Geldbörsenpool (Verrechnungskonto, das z. B. einer Bank zugeordnet ist) nur Summenzähler um den zu bezahlenden Betrag erhöht und von der Terminalkarte unterschrieben. Diese Summentransaktion wird immer erzeugt, da im Falle eines Terminalsystemzusammenbruches die letzte Summentransaktion notwendig ist. Zur Erhöhung der Sicherheit und der Kontrolle werden zufällig bzw. durch Systemparameter gesteuert Einzeltransaktionen erzeugt (müssen von der Kundenkarte und der Terminalkarte unterschrieben werden) und gespeichert.
Zusätzlich merkt sich die Karte die letzten n Transaktionen je Anwendung (elektronische Geldbörse, POS, ATM) in Logfiles, sodass auch der Karteninhaber über ein Beweismittel für bzw. gegen die Rechtmässigkeit von Transaktionen verfügt. Er wird somit einerseits nicht mehr die Rechtmässigkeit korrekt verbuchter Transaktionen bestreiten, kann andererseits aber auch beweisen, wenn eine Abbuchung zu Unrecht erfolgte.
Ein System kann eventuell mehrere "Geldbörsen pools" enthalten, in denen das elektronische Geld "geladen" wird. In diesem Fall müssen auch die Terminals die einzelnen Bezahlungen für die entsprechenden Pools trennen, d. h. pro Pool einen eigenen Summenzähler und eigene Summentransaktionen erzeugen.
Auf Seite der Kundenkarte wird die Sicherheit durch eine mindestens doppelte Speicherung des Geldbörsensaldos gesteigert, wobei der Saldo mindestens einmal in Form eines Betrages in der Karte steht. Die Kontrolle des Saldos erfolgt durch einen verschlüsselten Wert, der von der Karte intern bei jeder korrekten Transaktion (Laden oder Bezahlen) aus dem Geldbetrag errechnet wird und extern (Terminal, Zentralrechner) überprüft werden kann. Dadurch können sowohl Manipulationen am Betrag als auch der Abbruch einer Geldbörsentransaktion zu einem kritischen Zeitpunkt erkannt werden, da in solchen Fällen Saldo und Kontrollwert nicht übereinstimmen.
Das Datum für den Kontrollwert kann nur von der Karte selbst oder mit Kenntnis der entsprechenden Schlüssel beschrieben werden, sodass bei einer Manipulation des Saldos kein korrekter Kontrollwert in der Karte stehen kann. Eine Differenz zwischen Saldo und Kontrollwert kann nur durch einen Absturz des Terminals zwischen Abbuchung des Betrags vom Saldo und Erzeugung des Kontrollwerte verursacht werden, wenn das Terminal daraufhin nicht mehr in Betrieb geht oder die Korrekturfunktion der Terminalkarte nicht erfolgreich aufgerufen werden kann. Im Fall einer Unstimmigkeit zwischen Saldo und Kontrollwert kann aufgrund der Einträge im Logfile der
EMI3.1
gen soll.
Einen zusätzlichen Schutz gegen Manipulationen stellen die Einträge im Ladetransaktionslogfile dar. Sie werden bei jeder Geldbörsenladung vom Zentralrechner mit einer asymmetrischen Unterschrift (z. B. RSA) versehen angeliefert und von der Karte ins Logfile übernommen. Aufgrund der Unterschrift kann jedes Terminal, das den zugehörigen öffentlichen Schlüssel kennt, überprüfen, ob die letzte Geldbörsenladung von einem bestimmten Zentralrechner (Sicherheitsmodul) autorisiert wurde und somit korrekt erfolgte. allgemeine Transaktionsdaten, asymmetr. Unterschrift (Zähler, Geldbörsenaldo, Ladewert,...)
Zusätzlich können der Geldbörsensaldo und der Transaktionszähler (Einzeltransaktionen) aufgrund der Einträge im Ladetransaktionslogfile der Karte auf ihre Plausibilität geprüft werden.
Diese Prüfung kann bei jeder Transaktion erfolgen, sollte jedoch zumindest bei jeder Ladetransaktion vorgenommen werden. Weiters werden die zufällig erzeugten Einzeltransaktionen (enthalten Geldbörsensaldo) bei den Einreichungen gegen die zuletzt erfolgte Ladetransaktion auf ihre Plausibilität geprüft, wobei Transaktionszähler und Geldbörsensaldo der letzten Ladung mit den aktuellen Werten der Karte verglichen werden und dabei auch alle anderen vorliegenden Einzeltransaktionen der Karte berücksichtigt werden.
Die Erfindung zeichnet sich auch dadurch aus, dass auf der Terminalkarte neben einer Wäh-
<Desc/Clms Page number 4>
rung noch mehrere "Währungen" für geschlossene Geldbörsen und im Terminal eine Währungstabelle für offene Geldbörsen anderer Länder angegeben werden können. Eine Währung ist die Hauptwährung (in der Regel die Landeswährung). Beim Bezahlvorgang wird zuerst von der Termi- nalkarte überprüft, ob die Währung der Kundenkarte mit der der Terminalkarte oder mit einer "Währung" für geschlossene Geldbörsen der Terminalkarte übereinstimmt. Wenn hier eine Übereinstimmung vorliegt, kann bezahlt werden. Ohne Übereinstimmung muss auf eine andere im Terminal eingebaute Terminalkarte oder eine Online im Zugriff stehende Terminalkarte umgeschaltet werden.
Wenn die Währung der Kundenkarte nicht die Hauptwährung darstellt, muss die Währung der Kundenkarte in der Währungstabelle enthalten sein, ansonsten wird die Kundenkarte abgelehnt.
Die Währungstabelle ist in der Regel im Terminal gespeichert (und nicht in der Terminalkarte), da verschiedene Währungen oft verschiedene Terminalkarten erfordern. Sie enthält die aktuellen Kurse der angegebenen Währungen. Mit Hilfe der Währungstabelle kann mit der Kundenkarte stets in der eigenen Währung bezahlt werden, auch wenn sie im Ausland verwendet wird. Wenn die Währung der Kundenkarte nicht mit der Hauptwährung des Terminals übereinstimmt, sollte das Terminal den Zahlungsbetrag in beiden Währungen anzeigen.
EMI4.1
dienen nur für geschlossene Geldbörsen).
PATENTANSPRÜCHE :
1. System zur Durchführung des elektronischen Zahlungsverkehrs an Bankautomaten (wie z.B. Geldausgabeautomaten), Point-of-Sale-Terminals und Automaten jeder Art, bei dem alle sicherheitsrelevanten Daten in Chipkarten und Sicherheitsmodulen geschützt verwaltet werden, wichtige anwendungsspezifischen Daten in Terminalkarten oder Chipkarten ver- waltet werden, die auch die Schlüssel dieser Anwendung verwahren und die Terminals über eine oder mehrere Chipkartenieseeinheiten für Terminalkarten verfügen, sodass sie dahingehend konzipiert sein können, dass eine Erweiterung des Systems um zusätzliche
Anwendungen sehr einfach durch Stecken weiterer Terminalkarten erfolgen kann, da- durch gekennzeichnet,
dass der Sicherheitsmechanismus zum Schutz von Transaktio- nen durch Verwendung elektronischer Unterschriften sich dadurch auszeichnet, dass jede
Transaktion von der Kundenkarte zweimal unterschrieben wird und zwar unter Verwen- dung von zwei auf der Karte gespeicherten Schlüsseln, die nicht gegenseitig abgeleitet werden können und bei denen es sich um einen "dezentral verwalteteten Offline-Schlüs- sel" und um einen "zentral verwalteten Online-Schlüssel" handelt, wobei die Unterschrift mit dem dezentralen Schlüssel vor Ort Im Terminal überprüft wird, was eine sofortige Ab- lehnung einer Transaktion durch das Terminal ermöglicht und wobei die Unterschrift mit dem zentral verwalteten Schlüssel erst am Zentralrechner verifiziert werden kann,
sodass selbst durch manipulierte Terminalsoftware mit Kenntnis oder Korrumpierung des dezent- ralen Schlüssels eine manipulierte Transaktion am Zentralrechner als verfälscht erkannt wird.
<Desc / Clms Page number 1>
The present invention relates to a system for carrying out electronic payment transactions at automated teller machines (such as, for example, cash dispensers), point-of-sale terminals and all types of machines, in which all security-relevant data in chip cards and security modules are protected, important application-specific data are managed in terminal cards or chip cards, which also store the keys of this application and the terminals have one or more chip card reading units for terminal cards, so that they can be designed in such a way that the system can be expanded to include additional applications simply by inserting additional terminal cards.
The electronic payment transactions described here use the integrated security mechanisms of microprocessor cards in order to guarantee the highest security for both the customer and the system operator. However, care is taken to ensure that, despite all security measures, the quick and smooth flow of payment transactions is not impaired.
Such systems are found in many publications (e.g. The ESPRIT project CAFE - High Security Digital Payment Systems; D. Chaum: Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms; A. Beutelspacher, T. Hueske, A. Pfau: Kann to pay with bits?), patented (e.g. US 4 961 142 A, DE 4 126 809 A1, EP 0 439 609 A1, EP 0 616 447 A2, WO 96/26586 A1) and e.g. B. in CEN EN 1546 in a standard. In these publications, online and offline-oriented systems are described, which usually cannot be combined with other systems.
In addition, the offline-oriented systems often contain central control mechanisms, which are not based on their own (purely central) keys. The invention reduces or eliminates the disadvantages of these systems and allows the availability to be increased.
EP 0 439 609 A1 contains a system with magnetic stripe cards which cannot generate electronic signatures. This patent therefore differs significantly from the payment system described in the subject of the application, which in claim 1 is based on two electronic signatures that are generated by customer cards. All other claims relate to claim 1. EP 0 616 447 A2 and WO 96/26586 A1 contain systems with asymmetric cryptography. These systems require two keys (which form a related pair of keys), one of which is public and the other secret. One key is used for encryption, the other for decryption.
The present patent application also requires two keys in the customer card. However, both keys are used to generate the electronic signature (i.e. for encryption) and not one key for encryption and one for decryption. These two keys cannot be derived from each other (they are not related to each other and do not form a key pair) and are not dependent on a PIN. The existence of two independent keys is based on the idea that an electronic signature can be checked decentrally and one centrally.
The other patents mentioned above and the CEN 1546 standard also do not use two electronic signatures to secure transactions. They therefore differ significantly from the payment system described in the subject of the application, which in claim 1 is based on two electronic signatures that are generated by customer cards. All other claims relate to claim 1.
All important data (personal data, keys, in chip cards and in security modules on central computers) are protected in the object of registration. Access to this data is only possible with knowledge of the corresponding key and after mutual authentication between the customer card and the terminal card (or security module on the central computer).
The authentication between the two chip cards takes place by means of symmetrical or asymmetrical encryption, both static and dynamic authentication being provided. Authentication with static asymmetric encryption means that agreed data fields on the customer card, which can be read freely by the terminal card, are encrypted asymmetrically at the time the card is issued and this value (certificate) is saved in the card. During authentication, the customer card transfers these agreed values and the certificate to the terminal card. The terminal card decrypts the certificate and compares the result against the data fields supplied.
With the dynamic asymmetrical connection
<Desc / Clms Page number 2>
encryption, a random number or a constantly changing number (e.g. counter) is transferred from the terminal card to the customer card at the time of authentication, encrypted by the customer card using an asymmetrical algorithm (e.g. RSA) and this value is sent back to the terminal card , The terminal card decrypts the reported value and compares the calculated value with the previously transmitted number.
Great importance is also attached to easy expandability, especially that there is no change to the terminals and / or the payment process when the system is expanded.
With regard to the expandability, but also for security reasons, the detection of a supported application or the rejection of an unknown application and the management of the keys is not carried out in the terminal but by means of an appointment card. This terminal card is also a chip card and has its own security logic. The terminals have a chip card reader for customer cards and one or more chip card readers (chip card contacting units) for terminal cards, which can also be designed as a plug-in for reasons of space.
Additional applications (e.g. additional wallets) can be expanded by inserting additional terminal cards that contain and manage the keys and data of these applications. The changeover from one card generation to the next can also be done by inserting another terminal card, so that two terminal cards serve the same application, but different customer cards, for the duration of the changeover (one terminal card for the expiring card generation and one terminal card for the new customer cards) ,
The invention is characterized above all by special security features.
A security feature is the protection of all data that is transferred between the terminal and the central computer. This protection already comes into effect in the terminal and in the terminal card and is characterized by the use of a 2-key system. The data is also stored at least twice (in the electronic wallet all totals records and the last n one-time transactions, in offline POS all transactions) in order to be able to carry out a "recovery" in the event of a component failure. The security and integrity of the data is guaranteed by the use of two electronic signatures, which are generated with different keys of the customer card.
Any suitable cryptographic algorithm can be used to generate the electronic signatures (both symmetrical methods such as the DES algorithm and asymmetrical methods such as RSA or DSS).
One of these two electronic signatures can already be checked in the terminal, since it is generated with a local (decentralized) key, which is also known to the terminal card or can be determined from this key in one or more stages from other keys. A central key is used for the second signature, which is only known on the central computer or whose derivation from a master key can only be understood on the central computer, since the associated master key is only known there. It can therefore only be checked in the data center and thus offers additional, increased protection against counterfeiting of transactions, since even if the decentralized key (corrupt terminal) is known, no correctly signed transaction can be transmitted to the central computer.
The data record that is sent from the customer card (KK) to the terminal has the following structure, among others:
Transaction data (card number, amount, ...), local signature (KK), central signature (KK)
The signature with the local key is checked on site in the terminal card and is not transmitted to the central computer.
For this purpose, every transaction (in the case of wallet payments, the total rate of the respective wallet pool = clearing account) is signed by the terminal card, using a central key. If a single transaction (control) was generated when paying for a wallet, this is also signed by the terminal card (TC). Every transaction that is submitted to the central computer is thus secured by two signatures with central keys.
Transaction data (card number, amount, ...), central signature (KK), central signature (TK)
Each local sum of a purse pool is only signed by the merchant's terminal card using a central key.
Transaction data (counter, currency, ...), local wallet pool total, central signature
<Desc / Clms Page number 3>
(TK)
With wallet payments, one or three (if a single transaction was created) electronic signatures (central key of the terminal card for pool total, central key of the customer card for single transaction, central key of the terminal card for single transaction) are generated.
In the "electronic wallet" application, for cost reasons (and for reasons of anonymity for wallet payments), only the totalizer is increased by the amount to be paid per signed wallet pool (clearing account, which is assigned to a bank, for example) and signed by the terminal card. This total transaction is always generated because in the event of a terminal system breakdown, the last total transaction is necessary. To increase security and control, individual transactions are generated randomly or controlled by system parameters (must be signed by the customer card and the terminal card) and saved.
In addition, the card remembers the last n transactions per application (electronic wallet, POS, ATM) in log files, so that the cardholder also has evidence for or against the legality of transactions. On the one hand, he will no longer dispute the legality of correctly booked transactions, but on the other hand, he can also prove if a wrongful debit was made.
A system can possibly contain several "wallet pools" in which the electronic money is "loaded". In this case, the terminals must also separate the individual payments for the corresponding pools. H. Generate their own total counter and their own total transactions for each pool.
On the customer card side, security is increased by storing the wallet balance at least twice, the balance being shown in the card at least once in the form of an amount. The balance is checked using an encrypted value, which the card calculates internally for each correct transaction (loading or paying) from the amount of money and can be checked externally (terminal, central computer). This enables both manipulation of the amount and the termination of a wallet transaction to be recognized at a critical time, since in such cases the balance and control value do not match.
The date for the control value can only be written by the card itself or with knowledge of the corresponding key, so that if the balance is manipulated, the correct control value cannot be found on the card. A difference between the balance and the control value can only be caused by a crash of the terminal between the debiting of the amount from the balance and the generation of the control values if the terminal then no longer operates or the correction function of the terminal card cannot be called up successfully. In the event of a discrepancy between the balance and the control value, the
EMI3.1
should.
The entries in the loading transaction log file provide additional protection against manipulation. Each time the wallet is loaded, the central computer delivers them with an asymmetrical signature (e.g. RSA) and transfers them from the card to the log file. Based on the signature, every terminal that knows the associated public key can check whether the last purse load was authorized by a specific central computer (security module) and was therefore carried out correctly. general transaction data, asymmetric. Signature (counter, wallet balance, loading value, ...)
In addition, the wallet balance and the transaction counter (individual transactions) can be checked for plausibility based on the entries in the card's loading transaction log file.
This check can be done with every transaction, but should at least be done with every loading transaction. Furthermore, the plausibility of the randomly generated individual transactions (including wallet balance) in the submissions against the last loading transaction was checked, whereby the transaction counter and wallet balance of the last load are compared with the current values of the card and all other existing individual transactions on the card are also taken into account.
The invention is also characterized in that in addition to a dialing
<Desc / Clms Page number 4>
Several "currencies" for closed wallets and a currency table for open wallets in other countries can be specified in the terminal. A currency is the main currency (usually the national currency). During the payment process, the terminal card first checks whether the currency of the customer card matches that of the terminal card or a "currency" for closed wallets on the terminal card. If there is a match, you can pay. If there is no match, you must switch to another terminal card installed in the terminal or a terminal card that is accessible online.
If the customer card currency is not the main currency, the customer card currency must be included in the currency table, otherwise the customer card will be rejected.
The currency table is usually stored in the terminal (and not in the terminal card), since different currencies often require different terminal cards. It contains the current exchange rates of the specified currencies. With the help of the currency table, the customer card can always be used to pay in your own currency, even if it is used abroad. If the currency of the customer card does not match the main currency of the terminal, the terminal should display the payment amount in both currencies.
EMI4.1
serve only for closed purses).
PATENT CLAIMS:
1. System for carrying out electronic payment transactions at automated teller machines (such as, for example, cash dispensers), point-of-sale terminals and all types of machines, in which all security-relevant data in chip cards and security modules are protected, important application-specific data in terminal cards or chip cards who also keep the keys of this application and the terminals have one or more chip card reader units for terminal cards, so that they can be designed in such a way that the system can be expanded by additional ones
Applications can be done very simply by inserting further terminal cards, characterized by
that the security mechanism for protecting transactions by using electronic signatures is characterized in that each
Transaction is signed twice by the customer card, using two keys stored on the card that cannot be derived from each other and which are a "decentrally managed offline key" and a "centrally managed online" "Key", whereby the signature with the decentralized key is checked on site in the terminal, which enables an immediate rejection of a transaction by the terminal, and the signature with the centrally managed key can only be verified on the central computer,
so that even through manipulated terminal software with knowledge or corruption of the decentralized key, a manipulated transaction on the central computer is recognized as falsified.