<Desc/Clms Page number 1>
Die Erfindung betrifft ein Terminal für gesichertes Bestätigen von Daten, wie für das Anbringen einer digitalen Signatur an elektronischen Dokumenten und/oder für Zahlvorgänge mit elektronischen Zahlungsmitteln sowie ein Verfahren zum gesicherten Bestätigen von Daten.
Unter"digitaler Signatur"versteht man ein Verfahren, mit welchem die Echtheit elektronischer Dokumente und Dateien beliebiger Art sichergestellt werden kann. Das Verfahren beruht auf einem asymmetrischen Verschlüsselungsalgorithmus.
Für jeden Beteiligten am Signatursystem wird ein Schlüsselpaar generiert, ein geheimer und ein öffentlicher Schlüssel, die in einem bestimmten mathematischen Verhältnis zueinander stehen. Zum Erzeugen der digitalen Signatur benutzt der Absender seinen geheimen Schlüssel, praktisch als spezielles Unterschriftsmerkmal. Der zu unterschreibende Text wird zunächst mit einem sogenannten Hash-Verfahren komprimiert, das so entstandene Komprimat nach einem vorgegebenen Algorithmus mit dem geheimen Schlüssel verknüpft und das Ergebnis als digitale Signatur dem zu übertragenden Brief angehängt. Der Empfänger komprimiert nun ebenfalls den Text und vergleicht dieses Komprimat mit dem in der digitalen Signatur enthaltenen Komprimat, das sich durch Entschlüsseln der Signatur mit dem öffentlichen Schlüssel des Absenders ergibt.
Bei
<Desc/Clms Page number 2>
Übereinstimmung steht fest, dass der gesendete und empfangene Text gleich sind, es also weder Manipulationen noch Übertragungsfehler gegeben hat. Es steht aber auch fest, dass nur der Absender, der im Besitz des geheimen Schlüssels ist, die Signatur erzeugt haben kann, weil sonst der öffentliche Schlüssel nicht "passen" würde, also keine Transformation auf das ursprüngliche Komprimat hätte erfolgen können.
Die Kommunikationspartner erhalten dabei zunächst jeweils ein individuelles Schlüsselpaar, bestehend aus einem öffentlichen und einem dazu komplementären geheimen Schlüssel.
Die öffentlichen Schlüssel sind beiden Partnern bekannt und darüber hinaus im Prinzip auch jedem weiteren potentiellen Kommunikationspartner zugänglich. Die geheimen Schlüssel dagegen verbleiben beim einzelnen Kommunikationspartner, der sie sicher aufbewahrt (z. B. in einer persönlichen Chipkarte).
Neben der kryptologischen Sicherheit des angewandten Signaturverfahrens ist auch die Sicherheit der Implementierung eine wesentliche Voraussetzung für die rechtliche Relevanz digitaler Signaturen. Denn aus der Sicht des Anwenders ist eine digitale Signatur natürlich nur dann brauchbar, wenn er sich während des Signaturprozesses sicher sein kann, dass genau das, was er auf seinem Bildschirm vor sich sieht, signiert wird und nichts anderes ("What you see is what you sign"). In der Fachliteratur spricht man in diesem Zusammenhang auch von der Forderung nach einem sog. "Secure Viewer", also einem (Software-) System, das genau diese Sicherheitsfunktion garantieren soll.
In den verbreiteten offenen Systemarchitekturen für PCs
<Desc/Clms Page number 3>
ist diese Forderung aber nur sehr schwer zu erfüllen. Das Problem besteht darin, dass Computerviren, Trojanische Pferde oder andere unautorisierte Programme das Dokument vor der Signatur verfälschen können, ohne dass dies der Benutzer bemerkt. Der Benutzer würde in diesem Fall ein gefälschtes Dokument mit einer echten Unterschrift versehen. Was das z. B. für die Unterzeichnung von Verträgen oder die Abwicklung von Bankgeschäften bedeuten würde, lässt sich unschwer ausmalen. Für die gesetzliche Anerkennung digitaler Signaturen als rechtsgültige Unterschriften ist eine zufriedenstellende Lösung dieses Problems unbedingt erforderlich.
Bezüglich der digitalen Signatur ist es bekannt, dass Unterschriftssysteme entweder in Hard- oder in Software implementiert werden können. Eine bekannte Softwareimplementierung ist z. B. PGP"Prettty Good Privacy", für Hardwareimplementierungen werden in letzter Zeit zusehends Smart Cards mit entsprechenden Kartenlesern herangezogen.
Die Smart Cards sind üblicherweise mittels einer Geheimzahl (PIN) oder biometrischer Methoden gegen Missbrauch gesichert. Signaturterminals enthalten einen Kartenleser zur Aufnahme der Smart-Card und optional auch eine Tastatur zur Eingabe der PIN bzw. Software. zur Berechnung des Hash-Komprimats der zu signierenden Datei.
Diese Lösungen existieren für die unterschiedlichsten Systemumgebungen, lösen aber allesamt das oben adressierte Problem des Secure Viewer nicht. Denn auch eine Implementierung des Signaturverfahrens in einer Smart-Card sichert nur den Signaturvorgang selbst, schützt aber nicht vor einer unautorisierten Veränderung der zu signierenden Datei durch z. B. Computerviren vor dem eigentlichen Signaturvorgang.
<Desc/Clms Page number 4>
Bekannt sind auch Softwarelösungen für Secure Viewer für unterschiedlichste Dateiformate. Diese bieten jedoch entweder keinen ausreichenden Schutz gegen unautorisierte Programme oder setzen bestimmte sichere Betriebssysteme voraus. Eine solche Lösung bietet allenfalls einen gewissen Schutz des eigenen PCs des Benutzers. Einen sicheren Signaturvorgang an öffentlichen Terminals kann sie aber nicht ermöglichen.
In einer offenen Systemumgebung kann der Benutzer auf dem Bildschirm grundsätzlich nicht erkennen, ob ein Secure Viewer oder ein unautorisiertes Programm aktiv ist.
Das Bezahlen mit elektronischen Zahlungsmitteln, wie Kreditkarte, Bankomatkarte oder elektronischer Geldbörse, ist sehr beliebt. In den letzten Jahren setzt sich vor allem die elektronische Geldbörse immer mehr durch. Darunter versteht man ein Zahlungsverfahren, bei dem der Kunde Geldbeträge von seinem Bankkonto in die elektronische Geldbörse laden kann. Im allgemeinen ist die elektronische Geldbörse in einer Smart Card implementiert, welche von einer Bank ausgegeben wird. Der Ladevorgang erfolgt normalerweise in einer Online-Transaktion zum Bankrechner. Dabei tritt die elektronische Geldbörse zum authentifizierten Laden des Geldbetrags in eine kryptografische End-zu-End-Sitzung mit einem Sicherheitsmodul der Bank. Der Zahlungvorgang erfolgt hingegen im allgemeinen offline und ohne PIN-Eingabe.
Bei der Zahlung tritt die elektronische Geldbörse in eine kryptografische Interaktion mit einer speziellen Karte des Zahlungspartners (Händlers). Der Transaktionsbetrag wird vom in der elektronischen Geldbörse gespeicherten Guthaben abgebucht und der Karte des Händlers gutgeschrieben. Da sämtliche Interaktionen durch kryptografische End-zu-End-Protokolle abgesichert sind, spielt die Entfernung und Systeminfrastruktur der Transaktionspartner sicherheitstechnisch keine Rolle. Sowohl die Ladung als auch die Zahlung kann
<Desc/Clms Page number 5>
daher über potentiell unsichere Medien (z. B. Internet) erfolgen, ohne dass eine Gefahr für die Systemsicherheit besteht. Die elektronische Geldbörse ist daher grundsätzlich für sichere Zahlungen in solchen Medien sehr gut geeignet.
Sieht man die Sicherheitsaspekte bei Zahlungen mit der elektronischen Geldbörse in unsicheren Medien (z. B. Internet) an, erkennt man, wie gesagt, dass die elektronische Geldbörse vom kryptologischen Standpunkt her grundsätzlich sichere Zahlungen im Internet ermöglicht. Im Prinzip benötigt man dafür nur einen Smart Card Reader samt geeigneter Software, der an den PC des Kunden angeschlossen wird. Doch stellt sich-in Analogie zum Problem"What you see is what you sign" bei der digitalen Signatur - hier das Problem"What you see is what you pay". Der Kunde muss beim Zahlvorgang sicher sein, dass ihm nur der am Bildschirm angezeigte und von ihm freigegebene Betrag von der elektronischen Geldbörse abgebucht wird.
Bei Zahlungen an Bankterminals und an Zahlungsterminals in Geschäften ist dies insofern sichergestellt, als das Terminal konstruktionsbedingte Vorkehrungen gegen Manipulationen aufweist und Hersteller sicherheitstechnische Gutachten vorlegen müssen. In einer unsicheren Umgebung wie dem Internet ist dies jedoch grundsätzlich anders.
Das Problem besteht darin, dass Internet-Programme betrügerischer Händler oder unautorisierte Programmroutinen (Viren, Trojanische Pferde, etc. ) auf dem PC des Anwenders die Betragsanzeige verfälschen können. Die Folge : Dem Kunden wird ein höherer Betrag von seiner Geldbörse abgebucht, als er tatsächlich freigegeben hat. Solche Manipulationen können erst nach der Transaktion durch eine Überprüfung des Börsensaldos festgestellt werden. Für den Anwender ist es im allgemeinen unmöglich, derartige zu Unrecht abgebuchte Beträge zurück zu erhalten, da es sich bei der elektronischen Geldbörse um eine anonyme Zah-
<Desc/Clms Page number 6>
lungsmethode ohne Aufzeichnung von Einzeltransaktionen handelt.
Die vorliegende Erfindung löst sowohl das Problem des Secure Viewers als auch der sicheren Zahlung mit einem elektronischen Zahlungsmittel, wie der elektronischen Geldbörse bzw. einer Kredit-oder Debitkarte auf Smart Card-Basis, indem es den zu signierenden Text bzw. den abzubuchenden Betrag aus dem Computersystem, mit dem die zu signierenden Daten bzw. die Rechnungsbeträge erstellt werden, in eine separate Hardware auslagert.
Erfindungsgemäss ist ein mikroprozessorgesteuertes Terminal zum gesicherten Bestätigen von-in einem Computersystem erzeugten Daten vorgesehen, das über beliebige Schnittstellen am Computersystem angeschlossen ist, ein gegen unautorisierte Softwareeinbringung abgesichertes bzw.
proprietäres Betriebssystem, eine Schnittstelle zur Aufnahme eines persönlichen Datenverarbeitungselementes des Benützers, vorzugsweise einer Smartcard, eine Tastatur zur Eingabe des persönlichen Code-des Benutzers, zur Steuerung des Terminals und/oder zur Dateneingabe, einen Bildschirm beliebiger Grösse und Bauart, optional Hardund Software zur biometrischen Benutzerauthentifizierung und Software zur Anzeige und Bearbeitung der vom Computersystem an das Terminal übertragenen Daten sowie zum Lesen und gegebenenfalls auch zum Bearbeiten der Daten auf dem persönlichen Datentverarbeitungselement aufweist.
Vorzugsweise ist das persönliche Datenverarbeitungselement des Benützers ein Signaturtoken und die Bearbeitungssoftware ist unter anderem Software zur Anzeige von gängigen Dateiformaten auf dem eingebauten Bildschirm, vorzugsweise Formate von Text-, TabellenkalkulationsGrafik-, oder Bankdateien, und Software, durch die auf Veranlassung des Benutzers ein Signaturvorgang unter Ver-
<Desc/Clms Page number 7>
wendung des vom Benutzer eingeführten Signaturtokens durchgeführt wird und die resultierenden Signaturdaten an das Computersystem ausgegeben werden.
EMI7.1
EMI7.2
EMI7.3
dar.
Dabei wird insbesondere bevorzugt, dass Software vorgesehen ist, die sicherstellt, dass von aussen keinerlei lauffähige Softwareprogramme eingebracht werden können, es sei denn, die Softwareprogramme weisen eine korrekte digitale Signatur einer Trusted Party auf, vorzugsweise des Herstellers des Terminals oder des Betreibers des Signatursystems.
Ist das persönliche Datenverarbeitungselement des Benützers ein elektronisches Zahlungsmittel, wie eine elektronische Geldbörse, so enthält die Bearbeitungssoftware unter anderem Software zur Interpretation von Transaktionen mit dem elektronischen Zahlungsmittel, wie der elektronischen Geldbörse, zur Anzeige der relevanten Daten auf dem eingebauten Bildschirm und zur Steuerung von Transaktionen mit dem elektronischen Zahlungsmittel, wie der elektronische Geldbörse.
Dabei wird die angezeigte Zahlungs- oder Ladetransaktion auf Veranlassung des Benutzers unter Verwendung des elektronische Zahlungsmittels, wie der elektronischen Geldbörse freigegeben.
Bei dem erfindungsgemässen Verfahren zum gesicherten Bestätigen von in einem Computersystem erzeugten Daten werden die Daten in die separate Hardware eines mikroprozessorgesteuerten Terminals ausgelagert, das ein gegen unau-
<Desc/Clms Page number 8>
torisierte Softwareeinbringung abgesichertes bzw. proprietäres Betriebssystem und Bearbeitungssoftware enthält, worauf die Daten auf einem Bildschirm des Terminals angezeigt werden, vom Benutzer bestätigt werden und die bestätigten Daten an das Computersystem zurückgegeben werden.
Wenn die Daten zu signierende Dateien sind, die am Bildschirm des Terminals durch die Bearbeitungssoftware, vorzugsweise im Format einer Text-, Tabellen-, Kalkulations-, Grafik oder Bankdatei angezeigt werden, wird die Datei erfindungsgemäss gegebenenfalls nach Authentifizie-
EMI8.1
metrischen Benutzerauthentifizierung im Terminal auf Veranlassung des Benutzers einem Signaturvorgang unter Verwendung eines vom Benutzer dem Terminal übergebenen oder im Terminal fix integrierten Signaturtokens, vorzugsweise einer Smart Card, unterworfen und die signierte Datei wird an das Computersystem zurückgegeben.
Wird erfindungsgemäss der elektronische Zahlungsvorgang mit einer elektronischen Geldbörse oder einem sonstigen elektronischen Zahlungsmittel, das auf persönlichen Datenverarbeitungselementen (z. B. in Form einer Smart Card) beruht, durchgeführt, die vom Benutzer dem Terminal übergeben wurde, gibt die Bearbeitungssoftware den durch die bestätigten Daten gegebenen Betrag für die gewünschte Transaktion mit dem elektronischen Zahlungsmittel frei.
Dieses Bestätigungsterminal 10, wie es schematisch in Fig. l dargestellt ist, enthält unter anderem die folgenden Komponenten : - ein Interface 1 zur Aufnahme eines persönlichen Daten- verarbeitungselementes wie des Signatur-Tokens des An- wenders, also beispielsweise einen Smart Card Reader
<Desc/Clms Page number 9>
(falls eine Smartcard als Signaturtoken verwendet wird), - alternativ oder zusätzlich ein Interface (Smart Card
Reader) für das elektronische Zahlungsmittel wie die elektronische Geldbörse des Anwenders, - einen Bildschirm 2 (z.
B. LCD-Display) für die Anzeige des zu signierenden Dokuments bzw. der Transaktionsda- ten mit dem elektronischen Zahlungsmittel, wie der elektronischen Geldbörse, - eine Tastatur 3 zur Eingabe der PIN (für Signatur) bzw. zur Freigabe von Zahlungen mit der Elektronischen Geld- börse und zur Steuerung des Terminals 10, - optional Hardware für die Benutzerauthentifizierung mittels biometrischer Verfahren, - ein Standardinterface 4 zum Computer 5 in beliebiger
Ausprägung (z. B. serielle Schnittstelle, Infrarot,
Netzwerk, etc.), - Viewer-Software für die Darstellung von Dokumenten in beliebigen Dateiformaten (z. B.
Textverarbeitungsdatei- en, Tabellenkalkulationsdateien, Grafikdateien, Bank- Überweisungsdaten, Buchhaltungsdaten, etc.), - Software zur Erstellung des für die Signatur erforder- lichen Hash-Komprimats nach verschiedenen Algorithmen, - Software für die Interpretation und Steuerung sämtli- cher Transaktionen mit dem elektronischen Zahlungsmit- tel, wie der elektronischen Geldbörse.
Das Bestätigungsterminal 10 besitzt ein proprietäres Betriebssystem und erlaubt es nicht, ausführbare Programme von aussen zu laden. Aus diesem Grund können von Dritten keine unautorisierten Programme (Viren, Trojanische Pferde) in das Terminal 10 geschmuggelt werden. Die auf dem Bildschirm 2 des Terminals 10 dargestellten Dateiinhalte stimmen daher vollkommen mit der zu signierenden elektronischen Datei bzw. mit den Transaktionsdaten der elektronische Geldbörse überein. Die Forderungen "What you see
<Desc/Clms Page number 10>
is what you sign" bzw "What you see is what you pay" sind daher erfüllt.
Softwareupdates für das Bestätigungsterminal 10 (z. B. Änderung oder Hinzufügen von Viewerprogrammen, Unterstützung weiterer Signaturverfahren, Unterstützung weiterer Börsen etc. ) erfolgen ausnahmslos in authentifizierter Form. Das heisst, dass jede Software, die von aussen in das Terminal geladen wird, vom Hersteller des Terminals bzw.
Systembetreiber digital signiert sein muss. Beim Einbringungsprozess überprüft das Terminal 10 diese digitale Signatur und akzeptiert nur Updates mit einem positiven Prüfergebnis. Updates mit einem negativen Ergebnis werden als unautorisiert abgelehnt. Auf diese Weise ist die völlige Softwareintegrität sichergestellt.
Natürlich können Hard- und Software des Terminals 10 und sein Softwaremanagement auch den Zertifizierungsverfahren unterzogen werden, wie sie im Rahmen der sich abzeichnenden Signaturgesetze vorgesehen sind.
Das Terminal kann nach Art eines PDA (Personal Digital Assistant) auch tragbar gestaltet sein, bzw. ist es auch denkbar, die Funktionen des signaturterminals in einen Standard-PDA zu integrieren (zB Palm Pilot, PSIONorganiser, Cassiopeia, etc).
In das offene Computersystem 5 können Programme und Daten über die Datenleitung oder den Internetzugang 6 sowie über die Tastatur 9 und entsprechende Laufwerke eingebracht werden. Je nach Verwendung und Anforderung können die Daten vom Benutzer unter Kontrolle am Bildschirm 7 verändert werden, bis die gewünschten Dokumente bzw. der gewünschte Zahlungsvorgang angezeigt wird. Dann werden die Daten über das Interface 4 an das Terminal 10 abgegeben. Da das Terminal 10 ein proprietäres Betriebssystem
<Desc/Clms Page number 11>
aufweist, das es nicht erlaubt, ausführbare Programme von aussen zu laden, die keine entsprechende digitale Signatur einer Trusted Party aufweisen, können normalerweise nur die reinen Daten übertragen werden, die dann unter Zuhilfnahme von im Terminal 10 vorhandenen Software im entsprechenden Format am Bildschirm 2 angezeigt werden.
Das Angezeigte entspricht nun der Forderung, what you see is what you sign, bzw. what you see is what you pay und der Benutzer muss jetzt in das Interface 1, das z. B. als Smart Card Reader ausgebildet ist, sein persönliches Datenverarbeitungselement einbringen, d. h., z. B. seine Signaturkarte oder sein elektronisches Zahlungsmittel einstecken, gegebenenfalls über die Tastatur einen Benutzercode eingeben und den Bestätigungsvorgang durchführen. Handelt es sich dabei um einen Signaturvorgang, so wird das Dokument z. B. mit einer geeigneten Hash-Software komprimiert und mit der digitalen Signatur versehen. Das signierte, komprimierte Dokument wird dann über das Interface 4 an das Computersystem 5 zurückgegeben und kann von dort mit anderen Dateien kombiniert weitergeleitet werden.
Handelt es sich bei dem Bestätigungsvorgang um einen Zahlungsvorgang, so muss, wenn erforderlich, auch über die Tastatur ein entsprechender Code eingegeben werden und der Betrag, der am Bildschirm 2 ausgewiesen ist, z. B. durch Betätigung einer Taste bestätigt werden. Ist das persönliche Datenverarbeitungselement ein elektronisches Zahlungsmittel, so kann eine geeignete Software auf dem Terminal 10 die Transaktion zwischen dem Computersystem 5 und dem elektronischen Zahlungsmittel freigeben. Der Benutzer kann sich sicher sein, dass er tatsächlich das Dokument, das er am Bildschirm 2 gesehen hat, signiert hat bzw. den Zahlungsbetrag, den er am Bildschirm 2 gesehen hat, gezahlt hat.
<Desc / Clms Page number 1>
The invention relates to a terminal for secure confirmation of data, such as for attaching a digital signature to electronic documents and / or for payment transactions with electronic means of payment, and a method for secure confirmation of data.
"Digital signature" is a process by which the authenticity of electronic documents and files of any kind can be ensured. The method is based on an asymmetrical encryption algorithm.
For each party involved in the signature system, a key pair is generated, a secret and a public key, which have a certain mathematical relationship to one another. The sender uses his secret key to generate the digital signature, practically as a special signature feature. The text to be signed is first compressed using a so-called hash method, the resulting compression is linked to the secret key using a predetermined algorithm and the result is attached to the letter to be transmitted as a digital signature. The recipient now also compresses the text and compares this compressed file with the compressed file contained in the digital signature, which is obtained by decrypting the signature with the sender's public key.
At
<Desc / Clms Page number 2>
Agreement is clear that the sent and received text are the same, so there have been no manipulations or transmission errors. However, it is also certain that only the sender who has the secret key can have generated the signature, because otherwise the public key would not "fit", ie no transformation to the original compressed file could have taken place.
The communication partners each receive an individual key pair, consisting of a public key and a complementary secret key.
The public keys are known to both partners and, in principle, are also accessible to any other potential communication partner. The secret keys, on the other hand, remain with the individual communication partner, who keeps them safe (e.g. in a personal chip card).
In addition to the cryptological security of the signature procedure used, the security of the implementation is an essential prerequisite for the legal relevance of digital signatures. From the point of view of the user, a digital signature can of course only be used if he can be sure during the signature process that exactly what he sees on his screen is signed and nothing else ("What you see is what you sign "). In this context, the specialist literature also speaks of the requirement for a so-called "Secure Viewer", ie a (software) system that is supposed to guarantee exactly this security function.
In the widespread open system architectures for PCs
<Desc / Clms Page number 3>
however, this requirement is very difficult to meet. The problem is that computer viruses, Trojan horses, or other unauthorized programs can tamper with the document before the signature without the user noticing. In this case, the user would provide a genuine signature with a forged document. What the z. B. would mean for the signing of contracts or the processing of banking transactions, is easy to color. A satisfactory solution to this problem is absolutely necessary for the legal recognition of digital signatures as legally valid signatures.
With regard to the digital signature, it is known that signature systems can be implemented either in hardware or in software. A known software implementation is e.g. B. PGP "Prettty Good Privacy", for hardware implementations, smart cards with appropriate card readers have recently been increasingly used.
The smart cards are usually secured against misuse by means of a secret number (PIN) or biometric methods. Signature terminals contain a card reader for inserting the smart card and optionally also a keyboard for entering the PIN or software. to calculate the hash compression of the file to be signed.
These solutions exist for a wide variety of system environments, but all of them do not solve the problem of the Secure Viewer addressed above. Because an implementation of the signature process in a smart card only secures the signature process itself, but does not protect against unauthorized changes to the file to be signed by e.g. B. Computer viruses before the actual signature process.
<Desc / Clms Page number 4>
Software solutions for Secure Viewer for various file formats are also known. However, these either do not offer sufficient protection against unauthorized programs or require certain secure operating systems. At best, such a solution offers some protection for the user's own PC. However, it cannot enable a secure signature process at public terminals.
In an open system environment, the user cannot see on the screen whether a Secure Viewer or an unauthorized program is active.
Paying with electronic means of payment such as credit card, debit card or electronic wallet is very popular. In recent years, the electronic wallet in particular has become increasingly popular. This is a payment process in which the customer can load money from his bank account into the electronic wallet. In general, the electronic wallet is implemented in a smart card, which is issued by a bank. The loading process usually takes place in an online transaction to the bank computer. The electronic wallet enters an end-to-end cryptographic session with a bank security module to authentically load the amount of money. The payment process, on the other hand, is generally offline and without entering a PIN.
When paying, the electronic wallet enters into a cryptographic interaction with a special card of the payment partner (merchant). The transaction amount is debited from the credit stored in the electronic wallet and credited to the merchant's card. Since all interactions are secured by cryptographic end-to-end protocols, the distance and system infrastructure of the transaction partners does not play a role in terms of security. Both the cargo and the payment can
<Desc / Clms Page number 5>
therefore take place via potentially insecure media (e.g. Internet) without there being any risk to system security. The electronic wallet is therefore very well suited for secure payments in such media.
If you look at the security aspects of payments with the electronic wallet in insecure media (e.g. the Internet), you can see, as I said, that the electronic wallet basically enables secure payments on the Internet from a cryptological point of view. In principle, all you need is a smart card reader and suitable software that is connected to the customer's PC. But in analogy to the problem "What you see is what you sign" arises with the digital signature - here the problem "What you see is what you pay". During the payment process, the customer must be sure that only the amount shown on the screen and released by him is debited from the electronic wallet.
This is ensured for payments to bank terminals and to payment terminals in shops insofar as the terminal has design-related measures against manipulation and manufacturers have to provide safety-related reports. In an unsafe environment like the Internet, however, this is fundamentally different.
The problem is that Internet programs by fraudulent traders or unauthorized program routines (viruses, Trojan horses, etc.) on the user's PC can falsify the amount displayed. The result: the customer is debited a higher amount from his wallet than he has actually released. Such manipulations can only be determined after the transaction by checking the stock exchange balance. It is generally impossible for the user to get back such wrongly debited amounts because the electronic wallet is an anonymous payment.
<Desc / Clms Page number 6>
method without recording individual transactions.
The present invention solves both the problem of the secure viewer and the secure payment with an electronic means of payment, such as the electronic wallet or a credit or debit card based on a smart card, by extracting the text to be signed or the amount to be debited from the Computer system with which the data to be signed or the invoice amounts are created is outsourced to separate hardware.
According to the invention, a microprocessor-controlled terminal is provided for the secure confirmation of data generated in a computer system, which is connected to the computer system via any interfaces, and is secured or unauthorized against software introduction.
proprietary operating system, an interface for receiving a personal data processing element of the user, preferably a smart card, a keyboard for entering the personal code of the user, for controlling the terminal and / or for data entry, a screen of any size and design, optional hardware and software for biometric Has user authentication and software for displaying and processing the data transmitted from the computer system to the terminal and for reading and possibly also for processing the data on the personal data processing element.
Preferably, the personal data processing element of the user is a signature token and the processing software is, among other things, software for displaying common file formats on the built-in screen, preferably formats of text, spreadsheet graphics or bank files, and software by means of which the user initiates a signature process Sales
<Desc / Clms Page number 7>
is carried out using the signature token introduced by the user and the resulting signature data are output to the computer system.
EMI7.1
EMI7.2
EMI7.3
represents.
It is particularly preferred that software is provided which ensures that no executable software programs can be introduced from the outside, unless the software programs have a correct digital signature of a trusted party, preferably the manufacturer of the terminal or the operator of the signature system.
If the user's personal data processing element is an electronic means of payment, such as an electronic wallet, the processing software contains, among other things, software for interpreting transactions with the electronic means of payment, such as the electronic wallet, for displaying the relevant data on the built-in screen and for controlling transactions with the electronic means of payment, such as the electronic wallet.
At the instigation of the user, the displayed payment or loading transaction is released using the electronic means of payment, such as the electronic wallet.
In the method according to the invention for the secure confirmation of data generated in a computer system, the data are stored in the separate hardware of a microprocessor-controlled terminal, which is protected against inaccurate
<Desc / Clms Page number 8>
Torized software incorporation secured or proprietary operating system and processing software contains, whereupon the data is displayed on a screen of the terminal, confirmed by the user and the confirmed data is returned to the computer system.
If the data are files to be signed and are displayed on the screen of the terminal by the processing software, preferably in the format of a text, table, calculation, graphic or bank file, the file is, according to the invention, optionally after authentication.
EMI8.1
Subject to metric user authentication in the terminal at the instigation of the user a signature process using a signature token handed over to the terminal or permanently integrated in the terminal, preferably a smart card, and the signed file is returned to the computer system.
If, according to the invention, the electronic payment process is carried out with an electronic wallet or another electronic means of payment, which is based on personal data processing elements (e.g. in the form of a smart card), which the user has handed over to the terminal, the processing software gives the data confirmed by the data the amount given for the desired transaction using the electronic means of payment.
This confirmation terminal 10, as is shown schematically in FIG. 1, contains, among other things, the following components: an interface 1 for receiving a personal data processing element such as the user's signature token, for example a smart card reader
<Desc / Clms Page number 9>
(if a smart card is used as a signature token), - alternatively or additionally an interface (smart card
Reader) for the electronic means of payment such as the user's electronic wallet, - a screen 2 (z.
B. LCD display) for displaying the document to be signed or the transaction data with the electronic means of payment, such as the electronic wallet, - a keyboard 3 for entering the PIN (for signature) or for releasing payments with the electronic Wallet and to control the terminal 10, - optionally hardware for user authentication using biometric methods, - a standard interface 4 to the computer 5 in any
Specification (e.g. serial interface, infrared,
Network, etc.), - Viewer software for displaying documents in any file format (e.g.
Word processing files, spreadsheet files, graphic files, bank transfer data, accounting data, etc.), - Software for creating the hash file required for the signature according to various algorithms, - Software for the interpretation and control of all transactions with the electronic Means of payment, such as the electronic wallet.
The confirmation terminal 10 has a proprietary operating system and does not allow executable programs to be loaded from the outside. For this reason, third parties cannot smuggle unauthorized programs (viruses, Trojan horses) into Terminal 10. The file contents shown on the screen 2 of the terminal 10 therefore completely agree with the electronic file to be signed or with the transaction data of the electronic wallet. The demands "What you see
<Desc / Clms Page number 10>
is what you sign "or" What you see is what you pay "are therefore fulfilled.
Software updates for the confirmation terminal 10 (e.g. change or addition of viewer programs, support for further signature processes, support for other exchanges etc.) are all carried out in an authenticated form. This means that any software that is loaded into the terminal from the outside is made by the manufacturer of the terminal or
System operators must be digitally signed. During the insertion process, Terminal 10 checks this digital signature and only accepts updates with a positive test result. Updates with a negative result are rejected as unauthorized. This ensures complete software integrity.
Of course, the hardware and software of the terminal 10 and its software management can also be subjected to the certification procedures as provided for in the emerging signature laws.
The terminal can also be designed to be portable in the manner of a PDA (Personal Digital Assistant), or it is also conceivable to integrate the functions of the signature terminal into a standard PDA (for example Palm Pilot, PSIONorganiser, Cassiopeia, etc.).
Programs and data can be introduced into the open computer system 5 via the data line or the Internet access 6 as well as via the keyboard 9 and corresponding drives. Depending on the use and requirement, the data can be changed by the user under control on the screen 7 until the desired documents or the desired payment process is displayed. Then the data are delivered to the terminal 10 via the interface 4. Because Terminal 10 is a proprietary operating system
<Desc / Clms Page number 11>
has, which does not allow executable programs to be loaded from outside, which do not have a corresponding digital signature of a trusted party, normally only the pure data can be transmitted, which is then displayed with the help of software in the terminal 10 in the appropriate format on the screen 2 become.
The display now corresponds to the requirement, what you see is what you sign, or what you see is what you pay and the user must now enter interface 1, which e.g. B. is designed as a smart card reader, bring his personal data processing element, d. i.e., e.g. B. insert his signature card or his electronic means of payment, enter a user code on the keyboard if necessary and carry out the confirmation process. If it is a signature process, the document is z. B. compressed with a suitable hash software and provided with the digital signature. The signed, compressed document is then returned to the computer system 5 via the interface 4 and can be forwarded from there combined with other files.
If the confirmation process is a payment process, then if necessary, a corresponding code must also be entered via the keyboard and the amount shown on the screen 2, e.g. B. be confirmed by pressing a button. If the personal data processing element is an electronic means of payment, suitable software on the terminal 10 can release the transaction between the computer system 5 and the electronic means of payment. The user can be sure that he has actually signed the document that he saw on screen 2 or paid the payment amount that he saw on screen 2.