DE69828971T2

DE69828971T2 - Symmetrisch gesichertes elektronisches Kommunikationssystem

Info

Publication number: DE69828971T2
Application number: DE69828971T
Authority: DE
Inventors: W. Paul DENT
Original assignee: Ericsson Inc
Current assignee: Ericsson Inc
Priority date: 1997-07-11
Filing date: 1998-06-22
Publication date: 2006-01-26
Anticipated expiration: 2018-06-23
Also published as: JP2001509630A; AU8374398A; WO1999003079A1; DE69828971D1; EP0995177B1; AU751404B2; BR9810579A; AR013643A1; EP0995177A1; US6311171B1

Description

Die vorliegende Erfindung betrifft allgemein Techniken und Systeme zum Sichern und Synchronisieren von elektronischen Kommunikationen zwischen Parteien, z.B. über das Internet, und insbesondere von elektronischen Kommunikationen, die Finanztransaktionen beinhalten.
Verfahren zum Bereitstellen von elektronischem oder virtuellem Geld durch Verwendung von beispielsweise "Smart"-Cards, die darin eingebettete Mikroprozessoren aufweisen, sind in der Technik als eine Alternative zu den traditionellen Kunststoff-Kreditkarten bekannt, um eine Zahlung von einem Käufer zu einem Verkäufer zu gewährleisten. Diese bekannten vorgeschlagenen Verfahren sichern den Handel lediglich in einer Richtung, sie bieten nämlich eine Garantie für den Verkäufer, dass er bezahlt wird, aber sie gewährleisten dem Käufer nicht, dass er die erwarteten Waren, Eigentum oder Dienstleistungen empfangen hat oder empfangen wird.
Eine Beschreibung von Techniken, die sich auf Smart-Cards und ähnliches beziehen, kann beispielsweise im Internet bei WWW.DIGICASH.COM gefunden werden. Diese Techniken beschäftigen sich mit der Vermeidung von Unannehmlichkeiten für den Händler, die mit dem Erfordernis in Beziehung stehen, die Authentizität von Kreditkarten zu verifizieren, indem ein Telefonanruf mit der ausgebenden Organisation durchgeführt wird. Solche Systeme sind primär dann geeignet, wenn beispielsweise die Handelsware in der Verkaufsstelle physikalisch überprüft und von dem Käufer akzeptiert worden ist. Die Sicherheitsgarantie in eine Richtung, die durch elektronisches Geld zur Verfügung gestellt wird, verwendet Verschlüsselungsalgorithmen mit einem öffentlichen Schlüssel, z.B. RSA, bei denen eine Nachricht mit einem Geheimschlüssel verschlüsselt aber mit einem öffentlichen Schlüssel entschlüsselt werden kann, oder umgekehrt, abhängig davon, ob es gewünscht ist sicherzustellen, dass keine falschen Nachrichten gesendet werden können, oder ob es gewünscht ist, zu verhindern, dass Nachrichten abgefangen und entschlüsselt werden. Es ist ebenfalls bekannt, dass beide Techniken verwendet werden können, um die Quelle zu authentifizieren und um ein Abfangen zu verhindern.
1 zeigt ein herkömmliches System, das im Web-Dokument "http://digicash.com/publish/digsig/digbig.html" beschrieben ist. Darin gibt eine virtuelle Bank 10 virtuelle Münzen 12 in verschiedenen Stückelungen aus, die "unterzeichnet" sind, indem sie mit einem Geheimschlüssel der Bank verschlüsselt werden. Die Münzen bestehen aus digitalen Bitmustern, die auf einfache Weise unter Verwendung des von der Bank veröffentlichten öffentlichen Schlüssels entschlüsselt werden können.
Die virtuellen Münzen, die von der Bank an einen bestimmten Kunden herausgegeben werden, werden in einer elektronischen Kreditkarte oder "Smart-Card" 11 gespeichert. Sie können auch in irgendeiner anderen Form von Speichervorrichtung gespeichert werden, wie beispielsweise in der Speichervorrichtung von einem drahtlosen Hand-Telefon. Wenn die Speichervorrichtung tragbar ist, wie beispielsweise eine Smart-Card oder ein zellulares Hand-Telefon, dann wird die Funktion des Speicherns von virtuellem Geld normalerweise als eine "elektronische Brieftaschen"-Funktion bezeichnet.
Eine Smart-Card kann verwendet werden, um in einem Ladengeschäft Handelswaren zu kaufen, das ausgerüstet ist, um auf elektronische Weise die Smart-Card zu lesen. Ein Ladenkassen-Terminal 13 kann beispielsweise eine Schnittstelle für Smart-Cards aufweisen, die eine Anschlussvorrichtung oder eine drahtlose Schnittstelle sein kann, die unter Verwendung von Funk-, Infrarot- und optischen Frequenzen arbeitet. Eine solche optische Schnittstelle enthält eine LCD-Anzeige an der Karte, die verwendet wird, um Strich-Codes anzuzeigen, die durch einen herkömmlichen Laser-Scanner gelesen werden können, wie sie bereits in vielen Ladengeschäften gefunden werden können.
Das Ladenkassen-Terminal 13 sendet eine Nachricht an die Karte 11, und zwar über die Standard-Schnittstelle, wobei die Zahlung eines bestimmten Betrages angefordert wird, beispielsweise $ 13,00. Die Karte antwortet durch Senden einer Mitteilung, die die Bitmuster von virtuellen Münzen enthält, deren Stückelungen zu dem angeforderten Betrag addiert werden – zum Beispiel eine $ 8-Münze, eine $ 4-Münze und eine $1-Münze in dem Beispiel von $ 13. Das Ladenkassen-Terminal 13 entschlüsselt die Bitmuster der übertragenen Münzen unter Verwendung des öffentlichen Schlüssels der herausgebenden virtuellen Bank 10. Die Münzen werden in lesbare Bitmuster entschlüsselt, wodurch deren Stückelungen verifiziert werden, und zwar nur dann, wenn sie original sind, da nur die Bank unter Verwendung ihres Geheimschlüssels Bitmuster erzeugen kann, die unter Verwendung ihres öffentlichen Schlüssels entschlüsselt werden können, wodurch Fälschungen unmöglich gemacht werden. Ein Klonen ist jedoch möglich, indem einfach die Bitmuster von originalen virtuellen Münzen kopiert werden. Ein Klonen kann durch dieses System gemäß dem Stand der Technik nicht verhindert werden, aber es kann zumindest erfassbar gemacht werden, indem an jede Münze eine Seriennummer vergeben wird. Bei einer eventuellen Einlösung von einer durch die Bank herausgegebenen Münze durch den Verkäufer bei der Bank kann die Bank prüfen, ob diese seriennummerierte Münze bereits eingelöst wurde. Aber auch mit diesem Erfassungsschema ist es nicht klar, welche Kopie der Klone ist, da die erste Ausgabe nicht notwendigerweise eine echte Kopie impliziert. Wo auch immer virtuelle Münzen gespeichert werden, besteht daher eine Anfälligkeit gegenüber Hackern, die Zugriff auf die Bitmuster erlangen und diese klonen.
Andere Formen des elektronischen Handels haben sich im Zusammenhang mit Aktien-Märkten und Wertpapier-Handel ergeben, wie beispielsweise die NASDAQ, die Chicago-Getreidebörse und ähnliches, deren Zweck darin besteht, die Händler-Dienstleistungen zu erleichtern, indem eine Computer-Unterstützung bei der Vorbereitung der herkömmlichen Papierarbeit bereitgestellt wird, wie beispielsweise Transaktions-Bestätigungen und Abrechnungen. Die Art der elektronischen Handelsunterstützung, die durch diese Computersysteme zur Verfügung gestellt wird, die an den großen Handelsmärkten verwendet wird, betrifft daher nicht das Bereitstellen einer automatisierten Einrichtung zum Registrieren des Eigentums von Anlagen und zum Garantieren der Eigenschaften und des Vorhandenseins von Anlagen, sondern das Bereitstellen von Mechanismen für traditionelle Händler, um Transaktionen effizienter durchzuführen. Solche Systeme sind beispielsweise in den US-Patenten 5,375,055, 5,297,031, 5,297,032, 5,101,353 und 5,305,200 beschrieben. Die Eigenschaften und das Vorhandensein von zu handelnden Anlagen in diesen herkömmlichen Handelssystemen basieren auf der Gewährleistung durch einen vertrauenswürdigen menschlichen Händler.
Üblicherweise existieren viele parallele Systeme zum Registrieren des Eigentums von großen Anlagen, einschließlich beispielsweise die Kraftfahrzeug Behörde (Department of Motor Vehicles DMV) zur Registrierung des Eigentums von Fahrzeugen, lokale Gerichte zur Registrierung des Eigentums und der Beschreibung von Immobilien, sowie Wertpapierhäuser und Banken zur Registrierung des Eigentums an Geld, Wertpapieren, Anleihen und anderen kommerziellen Papieren. Diese Systeme gemäß Stand der Technik, die ursprünglich dazu gedacht waren, um vollständig durch menschliches Personal betrieben zu werden, wurden in relativ junger Zeit entwickelt, um Computer zu verwenden, um die Handhabung von Papier zu erleichtern, und zwar gemäß den traditionellen Prinzipien, um ein größeres Volumen von Transaktionen mit geringerem Einsatz an Mitarbeitern zu erreichen. Es wäre daher wünschenswert, neue Systeme und Techniken bereitzustellen, um Handelskommunikationen abzusichern und zu synchronisieren, und zwar ohne die Einbindung traditioneller menschlicher Händler oder vertrauenswürdiger Organisationen, um eine zusätzliche Transaktionseffizienz zu erhalten.
Gemäß der vorliegenden Erfindung ist ein Verfahren zum Registrieren eines Bitmusters vorgesehen, das eine Anlage darstellt, und zwar gemäß dem beiliegenden Anspruch 1, ein Verfahren zum Handeln elektronisch hergestellter Anlagen gemäß Anspruch 8 und ein Verfahren zum Bereitstellen von sicheren elektronischen Handeln gemäß Anspruch 16. Bevorzugte Ausführungsbeispiele sind in den abhängigen Ansprüchen definiert.
Diese und andere Aufgaben, Eigenschaften und Vorteile der vorliegenden Erfindung werden für den Fachmann beim Lesen der nachfolgenden detaillierten Beschreibung zusammen mit den Zeichnungen leicht verständlich, in denen:
1 ein herkömmliches elektronisches Kommunikationssystem darstellt;
2 ein elektronisches Kommunikationssystem darstellt;
3 ein elektronisches Kommunikationssystem gemäß einem Ausführungsbeispiel der vorliegenden Erfindung darstellt;
4(a) einen Datenstrom gemäß beispielhafter Sicherheitstechniken der vorliegenden Erfindung darstellt;
4(b) einen weiteren Datenstrom gemäß exemplarischer Sicherheitstechniken der vorliegenden Erfindung darstellt;
5 ein Flussdiagramm ist, das ein Verfahren zum Verhindern von Betrug gemäß der vorliegenden Erfindung darstellt;
6 eine nicht-lineare CRC-Code-Erzeugung gemäß einem Ausführungsbeispiel der vorliegenden Erfindung darstellt;
7 ein weiteres Beispiel von symmetrischen sicheren elektronischen Kommunikationen gemäß der vorliegenden Erfindung zeigt; und
8 ein beispielhaftes Nachrichtenformat für eine Nachricht zwischen einer Partei und einer Registrierung gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ist.
Ausführungsbeispiele der vorliegenden Erfindung verwenden einen Verschlüsselungsalgorithmus mit einem öffentlichen Schlüssel, um verschlüsselte Beschreibungen von Anlagen zu erzeugen, die in einer elektronischen Datenbank als vertrauenswürdige Registrierung aufgezeichnet werden. Es können einige solcher Registrierungen existieren, wodurch ein verteiltes System ermöglicht wird. Die Beschreibung einer Anlage wird durch eine korrekt autorisierte und regulierte Ausgabe-Organisation erzeugt, wie beispielsweise eine Bank, und die Beschreibung wird unter Verwendung eines Geheimschlüssels verschlüsselt, der nur dieser Organisation bekannt ist. An dieser Stelle kann die Beschreibung der Anlage entschlüsselt und von jedem unter Verwendung des veröffentlichten "öffentlichen Schlüssels" der autorisierten Organisation gelesen werden. Beispielsweise können staatlich versicherte Einlagen durch eine Datenbankaufzeichnung beschrieben sein, die unter Verwendung eines Geheimschlüssels verschlüsselt sind, der lediglich der Bundesbank bekannt ist, aber die Aufzeichnung kann unter Verwendung des öffentlichen Schlüssels der Bundesbank entschlüsselt und gelesen werden. Eine Person, die die Aufzeichnung entschlüsselt, kann sicher sein, dass die Aufzeichnung nur von der Bundesbank erzeugt worden ist, da keine andere Person Zugriff auf den korrekten Verschlüsselungsschlüssel hat.
Gemäß einem ersten Aspekt der Erfindung ist ein Verfahren zum Registrieren eines Bitmusters vorgesehen, welches eine Anlage darstellt, mit den Schritten: Erzeugen einer Beschreibung der Anlage; Verschlüsseln der Beschreibung unter Verwendung eines Geheimschlüssels einer Organisation; Verschlüsseln der verschlüsselten Beschreibung unter Verwendung eines öffentlichen Schlüssels des Halters dieser Anlage, um das Bitmuster zu erzeugen; Übertragen des Bitmusters an eine Registrierung, wobei die Registrierung das Bitmuster speichert, welches die Anlage darstellt; Entschlüsseln der Beschreibung unter Verwendung des öffentlichen Schlüssels der Organisation; und Authentifizieren der Herkunft von der Beschreibung.
Gemäß einem zweiten Aspekt der Erfindung ist ein Verfahren zum Handeln elektronisch dargestellter Anlagen vorgesehen, mit den Schritten: Senden, durch eine erste Partei, von einer Anfrage an eine erste Registrierung, welche eine erste elektronisch dargestellte Anlage zurückzieht; Übertragen, durch die erste Registrierung, einer Kopie der ersten elektronisch dargestellten Anlage an die erste Partei; Kennzeichnen, durch die erste Registrierung, der ersten elektronisch dargestellten Anlage als nicht erhältlich; Entschlüsseln, durch die erste Partei, der ersten elektronisch dargestellten Anlage unter Verwendung des Geheimschlüssels der ersten Partei; Wiederverschlüsseln, durch die erste Partei, der ersten elektronisch dargestellten Anlage unter Verwendung eines öffentlichen Schlüssels der zweiten Partei; und Übertragen der ersten elektronisch dargestellten Anlage an die zweite Partei.
Gemäß einem dritten Aspekt der Erfindung ist ein Verfahren zum Bereitstellen von sicheren elektronischen Handeln vorgesehen, und zwar zwischen einer ersten Partei, welche einem Handel mit einer ersten Anlage zustimmt, und einer zweiten Partei, welche einem Handel mit einer zweiten Anlage zustimmt, und zwar als Gegenleistung für die ersten Anlage, mit den Schritten: Kommunizieren, durch die erste Partei, mit einer ersten Finanzorganisation, um ein erstes Datensymbolmuster zu erlangen, welches die erste Anlage beschreibt, wobei das erste Symbolmuster unter Verwendung eines ersten Codeschlüssels verschlüsselt wird, welcher nur der ersten Organisation bekannt ist, und ferner unter Verwendung eines zweiten Codeschlüssels verschlüsselt wird, welcher durch die erste Partei zugeführt wird; Kommunizieren, durch die zweite Partei, mit einer zweiten Finanzorganisation, um ein zweites Datensymbolmuster zu erlangen, welches die zweite Anlage beschreibt, wobei das zweite Symbolmuster unter Verwendung eines dritten Codeschlüssels verschlüsselt wird, welcher nur der zweiten Organisation bekannt ist, und ferner unter Verwendung eines vierten Codeschlüssels verschlüsselt wird, welcher durch die zweite Partei zugeführt wird; Entschlüsseln des ersten Symbolmusters durch die erste Partei unter Verwendung eines Codeschlüssels, welcher invers zum zweiten Codeschlüssel ist, welcher nur der ersten Partei bekannt ist, und Wiederverschlüsseln des ersten Symbolmusters unter Verwendung des vierten Codeschlüssels; Entschlüsseln des ersten Symbolmusters durch die zweite Partei unter Verwendung eines Codeschlüssels, welcher invers zu dem vierten Codeschlüssel ist, welcher nur der zweiten Partei bekannt ist, und Wiederverschlüsseln des zweiten Symbolmusters unter Verwendung des zweiten Codeschlüssels; Übertragen des wiederverschlüsselten ersten Symbolmusters durch die erste Partei an eine Registrierung; Übertragen des wiederverschlüsselten zweiten Symbolmusters durch die zweite Partei an die Registrierung; und Austauschen des wiederverschlüsselten ersten und zweiten Symbolmusters durch elektronische Übertragung zwischen der ersten Partei und der zweiten Partei.
Das vorliegende System verwendet eine weitere Verschlüsselung von Datenbank-Aufzeichnungen unter Verwendung des öffentlichen Schlüssels des Halters der Anlagen, die die Aufzeichnung beschreibt. Diese doppelt verschlüsselten Aufzeichnungen können lediglich unter Verwendung des Geheimschlüssels des Halters entschlüsselt werden, ohne den sie eine wertlose Ansammlung von scheinbar zufälligen binären Bits oder Computersymbolen sind. Daher ist es für eine dritte Person wertlos, eine solche Aufzeichnung ohne Kenntnis des Geheimschlüssels des Halters zu stehlen, da diese nicht in etwas konvertiert werden kann, das einen handelbaren Wert hat.
Wenn eine erste Partei einwilligt, eine Anlage zu einer zweiten Partei zu übertragen, und zwar als Teil eines elektronischen Handels, dann erhält der Halter die doppelt verschlüsselte Anlage-Beschreibung von der Datenbank und entschlüsselt sie unter Verwendung seines Geheimschlüssels. Die erste Partei verschlüsselt dann wieder die Anlage unter Verwendung des öffentlichen Schlüssels der anderen Partei und überträgt das Ergebnis an die zweite Partei. Lediglich die zweite Partei kann die übertragene Nachricht unter Verwendung ihres Geheimschlüssels entschlüsseln, so dass die Information bei der Übertragung nicht gestohlen werden kann. Die zweite Partei entschlüsselt die Nachricht unter Verwendung ihres Geheimschlüssels und verschlüsselt sie dann wieder unter Verwendung des öffentlichen Schlüssels der herausgebenden oder garantierenden Organisation. Wenn die Beschreibung der Anlage mit den Erwartungen der zweiten Partei übereinstimmt, kann diese sicher sein, dass die Anlage existiert und deren Handelbarkeit durch die herausgebende Organisation garantiert ist, ohne mit der herausgebenden Organisation in Kontakt treten zu müssen.
Umgekehrt überträgt die zweite Partei die Beschreibung einer zweiten Anlage, die gegen die Anlage der ersten Partei ausgetauscht wird. Diese zweite Anlage kann beispielsweise eine Geldeinlage sein, die von einer anderen Organisation garantiert wird, und zwar unter Verwendung des gleichen Verfahrens, d.h. unter Verwendung des Geheimschlüssels der garantierenden Organisation, um die Beschreibung der Einlage zu "unterzeichnen". Die Nachricht von der zweiten Partei zu der ersten Partei wird auf ähnliche Weise unter Verwendung des öffentlichen Schlüssels der ersten Partei verschlüsselt, um eine Offenlegung bei der Übertragung zu verhindern.
Wenn beide Parteien mit den jeweiligen Beschreibungen der auszutauschenden Anlage einverstanden sind, senden beide Parteien jeweilige Nachrichten zu der vertrauenswürdigen elektronischen Registrierung oder Registrierungen, und zwar verschlüsselt mit ihren Geheimschlüsseln, die die Registrierung unter Verwendung der öffentlichen Schlüssel der Parteien entschlüsseln kann, um so deren Authentizität zu verifizieren. Jede Nachricht identifiziert die Aufzeichnung in der Registrierung, dass der jeweilige Halter mit dem Handel einverstanden ist, indem beispielsweise der Registrierung ein verschlüsseltes Symbolmuster jener Aufzeichnung geliefert wird, wie sie derzeit in der Registrierung gespeichert ist, und des wiederverschlüsselten Symbolmusters, das darstellt, dass die Anlag zu dem neuen Halter gehört. Diese Nachricht informiert die Registrierung außerdem darüber, dass das verschlüsselte Symbolmuster in dem Handel von der anderen Partei des Austausches empfangen wurde.
Die Registrierung selbst muss keine Kenntnis davon haben, was diese Bitmuster darstellen, sondern lediglich, dass die handelnden Parteien damit einverstanden sind, damit zu handeln. Wenn die Registrierung eine Übereinstimmung zwischen einerseits dem Symbolmuster, dessen Empfang von der zweiten Partei durch die erste Partei erwartet wird, und andererseits des Symbolmusters erfasst, dass von der zweiten Partei empfangen wird, und umgekehrt, dann überschreibt der Computer der automatisierten Registrierung die ursprünglichen Anlagebeschreibungen, die mit dem öffentlichen Schlüssel des ursprünglichen Halters verschlüsselt sind, durch die neuen Anlagebeschreibungen, die mit den öffentlichen Schlüsseln der jeweiligen neuen Halter verschlüsselt sind, wodurch der Handel synchronisiert wird.
Bei der Durchführung des vorliegenden Systems führen zwei Parteien einen elektronischen Handel, über beispielsweise das Internet, mit Anlagen durch, die durch eine oder mehrere herausgebenden Organisationen garantiert sind, ohne dass mit den ursprünglichen Organisationen Kontakt aufgenommen wird und ohne die Notwendigkeit, einen menschlichen Händler zu involvieren, um die Transaktionspapiere in herkömmlicher Weise auszufüllen, wodurch eine größere Geschwindigkeit und Sicherheit des Handels erreicht wird.
Dieses Problem wird beispielsweise dadurch gelöst, indem Münzen in einer Form gespeichert sind, die mit dem Verschlüsselungsschlüssel verschlüsselt sind, der öffentlich nicht bekannt ist, z.B. dem Geheimschlüssel des Halters, oder zumindest in einer verschlüsselten Form, die lediglich unter Verwendung des Geheimschlüssels des Halters entschlüsselt werden kann. Beispielsweise können die Münzen unter Verwendung des öffentlichen Schlüssels des Halters verschlüsselt werden und dann lediglich unter Verwendung des Geheimschlüssels des Halters entschlüsselt werden.
Eine Verbesserung gegenüber dem herkömmlichen System aus 1 beinhaltet daher folgende Schritte:

(a) Die virtuelle Bank verschlüsselt auch die Münzen unter Verwendung des öffentlichen Schlüssels der Smart-Card oder der elektronischen Brieftasche, wohin sie übertragen werden.
(b) Die Karte oder die Brieftasche entschlüsselt die Münzen unter Verwendung ihres Geheimschlüssels, wenn an einem Ladenkassen-Terminal gezahlt wird. Die Brieftasche verschlüsselt außerdem die Münzen, bevor sie ausgegeben werden, unter Verwendung des öffentlichen Schlüssels des Ladenkassen-Terminals, an das sie gezahlt werden.

Da lediglich die Karte oder die Brieftasche Münzen verschlüsseln kann, die von der Bank gesendet werden, sind diese gegenüber einem Abfangen bei der Übertragung nicht anfällig, die beispielsweise eine drahtlose Verbindung beinhalten kann. Die Münzen sind ebenfalls nicht anfällig gegenüber einem Diebstahl aus der Brieftasche, da sie ohne den Geheimschlüssel nicht verwendet werden können, und der Geheimschlüssel kann in einem Speicher gespeichert werden, auf den von außen nicht zugegriffen werden kann. Beispielsweise können die Karte oder die Brieftasche einen integrierten Prozessor oder Speicherchip mit einer externen E/A-Schnittstelle durch den Prozessor aufweisen. Der Prozessor kann ein festes Programm beinhalten, der Informationen über diese E/A-Schnittstelle liest, die Informationen zusammen mit dem Geheimschlüssel verarbeitet, auf den lediglich der Prozessor zugreifen kann, und abhängig von der eingelesenen Information und dem Geheimschlüssel ein Ergebnis ausgibt. Der Prozessor würde jedoch kein Programm haben, das auf eine Anfrage über die E/A-Schnittstelle antwortet oder diese zumindest versteht, um den Geheimschlüssel aufzufinden und auszugeben. Außerdem kann die Brieftasche bei der Bezahlung einer Summe aus der Brieftasche an ein Ladenkassen-Terminal nicht nur die Münzen unter Verwendung des Geheimschlüssels der Brieftasche entschlüsseln, sondern kann sie unter Verwendung des öffentlichen Schlüssels des Ladenkassen-Terminals wieder verschlüsseln, so dass die Münzen bei der Übertragung nicht gestohlen werden können, da sie nur unter Verwendung des Geheimschlüssels des Ladenkassen-Terminals entschlüsselt werden können. Diese Münzen sind gegenüber einem Diebstahl aus dem Speicher des Ladenkassen-Terminals nicht anfällig, da sie in einer verschlüsselten Form gespeichert sind. Wenn das Ladenkassen-Terminal außerdem eines von vielen in einem großen Geschäft ist, kann es mit einem zentralen gemeinsamen Computer verbunden sein, der sich in einem sicheren Gebiet befindet, wobei der gemeinsame Geheimschlüssel in dem zentralen Computerbereich gespeichert ist. Das Ladenkassen-Terminal würde verschlüsselte Münzen, die aus Brieftaschen empfangen wurden, zu dem gemeinsamen Computer zwecks Verifizierung senden, wobei dies eine Prozedur ist, die für den Kassierer und den Kunden nahezu ohne Verzögerung zu erfolgen scheint.
Das vorstehend beschriebene Verfahren zur Verbesserung der Sicherheit ist in 2 dargestellt. Die virtuelle Bank 20 gibt virtuelle Münzen 21 an die Smart-Card 22 eines Kunden aus, wobei die Münzen zuerst unter Verwendung des Geheimschlüssels der Bank und zweitens unter Verwendung des der Bank bekannten öffentlichen Schlüssels des Kunden verschlüsselt werden. Die verschlüsselten Münzen werden in der Smart-Card 22 des Kunden gespeichert, und zwar zusammen mit dem geheimen Verschlüsselungsschlüssel des Kunden, wie vorstehend beschrieben. Ein Ladenkassen-Terminal 23 in einem Ladengeschäft fordert eine Zahlung über eine bestimmte Summe, die in Münzen zu erfolgen hat, die mit dem öffentlichen Schlüssel des Geschäfts verschlüsselt sind, der mit der elektronischen Forderung gekoppelt ist. Das Senden des öffentlichen Schlüssels mit der Forderung ist eine Alternative zur Speicherung von Schlüsseln für alle möglichen Ladengeschäfte, obwohl eine begrenzte Untergruppe darin gespeichert sein kann. Die Smart-Card entschlüsselt die angeforderten Münzen unter Verwendung des Geheimschlüssels des Kunden und verschlüsselt sie dann wieder unter Verwendung des öffentlichen Schlüssels des Ladengeschäfts, wobei beide Operationen in dem Prozessor der Smart-Card erfolgen. Die durch das Ladengeschäft verschlüsselten Münzen werden dann zu dem Ladenkassen-Terminal 23 gesendet, und optional zu dem gemeinsamen Computer 25 des Ladengeschäfts, um verifiziert zu werden. Der gemeinsame Computer 25 entschlüsselt die Münzen unter Verwendung des Geheimschlüssels des Geschäfts und entschlüsselt die Münzen weiter unter Verwendung des öffentlichen Schlüssels der Bank. An dieser Stelle werden die Münzen lesbar, und es kann verifiziert werden, ob sie von der virtuellen Bank 20 stammen und die erwarteten Werte haben. Der gemeinsame Computer 25 sendet eine "Akzeptieren"-Nachricht an das Ladenkassen-Terminal 23, dass die Zahlung akzeptiert wurde, oder alternativ eine "Zurückweisen"-Nachricht. Die Verfahren bei Zurückweisung werden nicht detailliert beschrieben, sie können aber beispielsweise einen elektronischen Kontakt mit der virtuellen Bank 20 zusammen mit dem Namen des Kunden oder der ID-Nummer der Smart-Card und den Bitmustern der gefälschten Münzen beinhalten, um zu bestimmen, welche Aktion durchgeführt werden soll.
Weder das vorstehend beschriebene System unter Bezugnahme auf 1, noch die vorstehend beschriebenen Verbesserungen mit Hilfe von 2 stehen mit der Garantie der Handelsware für den Käufer in Beziehung, stehen aber statt dessen mit der Garantie der Zahlung an den Verkäufer in Beziehung. Von Handelswaren, die an Ladenkassen-Terminals gekauft werden, wird angenommen, dass sie inspiziert, akzeptiert und von dem Käufer geprüft werden, bevor er das Ladengeschäft verlässt. Ausführungsbeispiele der vorliegenden Erfindung betreffen das Handeln mit Anlagen, die eine breitere Definition als lediglich Bargeld oder virtuelles Geld haben, d.h., sie beinhalten alle Wertgegenstände, die mit einer verschlüsselten Beschreibung beschrieben werden können, die anschließend als ein ICON bezeichnet werden. Ein ICON ist ein bestimmtes Bitmuster, dass dann, wenn es entschlüsselt ist, die Eigenschaft der Anlage aufdeckt und garantiert, für die es steht. Ein Verfahren zum Erzeugen von ICONs, die Wertgegenstände darstellen, und das Handeln mit diesen, werden nun mit Hilfe von 3 beschrieben.
Zumindest eine vertrauenswürdige Registrierung 40 ist dazu ausgestaltet, um über einen öffentlichen Telekommunikationsservice zu kommunizieren, wie beispielsweise das Internet. Kommunikationen können durch Verwendung von dem geheimen bzw. öffentlichen Schlüsselpaar der Registrierung gemäß allgemein bekannten herkömmlichen Techniken sicher gemacht werden.
Eine vertrauenswürdige Organisation, wie beispielsweise eine Bank 20 oder andere garantierende Organisation 30 kann mit einer Registrierung kommunizieren, die sich irgendwo anders befindet, und zwar unter Verwendung von Kommunikations-Links, die mit den Bezugszeichen L3, L4 bezeichnet sind, und solche Organisationen sind die alleinigen Einheiten, von denen die Registrierung EINLAGEN von ICONs akzeptiert, im Gegensatz zu HANDELn von ICONs. Der Unterschied zwischen einer EINLAGE und einem HANDEL besteht darin, dass eine Einlage ein neues ICON in der Registrierung erzeugt, ohne dass es notwendig ist, durch Löschung eines bereits existierenden ICONs angepasst zu werden. Wie die Registrierung Organisationen 20, 30 von Nicht-Organisations-Kunden 31, 32 unterscheidet, wird später beschrieben.
Es wird nun angenommen, dass ein Kunde 31 eine Bargeldeinlage über einen Wertgegenstand, wie beispielsweise das Eigentum an einer Immobilie, durch ein ICON darstellen möchte, das in einer ausgewählten Registrierung 40 gespeichert ist. Der Kunde bestimmt zuerst eine Organisation, die einwilligt, hinter dem Wert oder der Eigenschaft des hinterlegten ICONs zu stehen, und solch ein ICON erzeugt. Wenn das ICON beispielsweise Bargeld darstellt, dann kann die Organisation anfordern, dass der Kunde über ein Treuhandkonto oder über ein anderes gesperrtes Konto einen Betrag an realem Geld hinterlegt, dass der Menge an virtuellem Geld entspricht, das durch das ICON dargestellt ist. Das Treuhandkonto bzw. das gesperrte Konto, obwohl ursprünglich im Auftrag eines bestimmten Kunden eingerichtet, wird zu einem anonymen Konto, wenn das ICON in der Registrierung 40 plaziert ist, da das ICON von dieser Stelle an viele Veränderungen bezüglich des Eigentums durchlaufen kann, obwohl es gegen den Inhalt des Treuhandkontos getilgt werden kann.
Wenn das ICON als ein alternatives Beispiel eine Immobilie darstellen soll, dann kann die garantierende Organisation eine Untersuchung durchführen, um das Eigentum an der Immobilie zu verifizieren und um eine physikalische Inspektion durchzuführen, bevor das ICON erzeugt wird. Darüber hinaus wird die Organisation höchstwahrscheinlich anfordern, die Immobilien-Verträge so lange zu halten, wie das ICON zirkuliert, da das ICON eventuell durch die Organisation für den Wert eingelöst wird, den es darstellt und der darin beschrieben wird. Zumindest ein Teil der Verhandlung zwischen der Bank 20 und ihrem möglichen Kunden 31 kann auf elektronischem Wege erfolgen, zum Beispiel unter Verwendung sicherer Internet-Links, die durch L1, L2 bezeichnet sind, über das Telefon oder traditionell durch ein persönliches Gespräch.
Wenn die Organisation 20 oder 30 einwilligt, ein ICON zu erzeugen und zu garantieren, das eine Anlage darstellt, dann erzeugt sie eine Volltext-Beschreibung der Anlage und verschlüsselt dann diese Beschreibung (d.h. sie unterzeichnet sie) unter Verwendung des Geheimschlüssels der Organisation. Die Organisation kann dann das ICON unter Verwendung des öffentlichen Schlüssels des Kunden 31 oder 32 weiter verschlüsseln und dann das verschlüsselte ICON unter Verwendung der Links L3, L4 zusammen mit einer Anfrage an die Registrierung 40 übertragen, das ICON zusammen mit der ID des Kunden zu speichern.
Der Kunde kann als eine Alternative durch seinen öffentlichen Schlüssel eindeutig identifiziert werden. Die gesamte Nachricht von der Organisation 20 oder 30 an die Registrierung 40 kann unter Verwendung des Geheimschlüssels der Organisation und des öffentlichen Schlüssels der Registrierung verschlüsselt sein, wobei diese Schlüssel Kommunikationsschlüssel sein können, die von dem geheimen/öffentlichen Schlüsselpaar verschieden sind, die von der Organisation verwendet werden, um die ICONS zu unterzeichnen. Die Registrierung 40 entschlüsselt die Nachricht von der Organisation, indem zuerst der öffentliche Schlüssel der Organisation und dann der Geheimschlüssel der Registrierung verwendet wird, wonach ein immer noch verschlüsseltes ICON verbleibt, aber die Volltext-ID des Kunden. Außerdem werden einige Prüfbits, wie zum Beispiel ein zyklischer Redundanzprüfungs-Code (CRC) zu der Nachricht hinzugefügt, und zwar vor der Verschlüsselung durch den Sender, die nach der Entschlüsselung durch den Empfänger überprüft werden. Daher kann die Registrierung den CRC oder die Prüfbits verwenden, um zu verifizieren, ob eine entschlüsselte Nachricht korrekt entschlüsselt wurde, und zwar auch dann, wenn das ICON noch verschlüsselt ist und die ID des Kunden allein nicht zur Verifizierung führt. Nur eine Nachricht, die unter Verwendung des Geheimschlüssels der Organisation erzeugt wurde, wird unter Verwendung des öffentlichen Codes der Organisation korrekt entschlüsselt, um die korrekten Prüfbits zu offenbaren, wodurch für die Registrierung verifiziert wird, dass sie das ICON als Einlage akzeptieren kann. Die Registrierung ist nicht verantwortlich für die Verifizierung, dass ein identifizierter Kunde tatsächlich existiert oder dass das ICON irgendetwas Besonderes darstellt. Was das ICON darstellt, kann daher ein Geheimnis bleiben, das lediglich dem Kunden bekannt ist.
Bei den vorstehend beschriebenen Transaktionstechniken wird ein Verschlüsselungssystem mit einem öffentlichen Schlüssel verwendet, das auf einem zweiteiligen Schlüssel basiert, ein Teil für die Verschlüsselung und ein Teil für die Entschlüsselung. Ein herkömmlicher Verschlüsselungsalgorithmus mit einem öffentlichen Schlüssel, der für die Verwendung in der vorliegenden Erfindung geeignet ist, ist die RSA-Technik. Diese basiert auf der mathematischen Identität:
für jede mögliche Nachricht X, die als eine große Zahl behandelt wird, und wobei z das Produkt von Primzahlen ist: z = P1P2P3 ... P(n) (2) und y = 1 + (P1 – 1)(P2 – 1) ... (P(n) – 1 (3)
In dem herkömmlichen RSA-Algorithmus werden n = 2, d.h. nur zwei Primzahlen, verwendet, um z zu bilden, und "y", keine Primzahl, wird in zwei Teile faktorisiert, die als der öffentliche Schlüssel bzw. als der private oder der geheime Schlüssel bezeichnet werden.
Die beiden Schlüsselteile sind, wenn sie multipliziert werden, gleich dem Wert "y" in Gleichung (3), die, wenn sie in Gleichung (1) verwendet wird, jede Nachricht X auf sich selbst zurück transformiert, wodurch sie lesbar gemacht wird. Es ist jedoch möglich, den RSA-Algorithmus zu erweitern, indem "y" in Gleichung (3) in drei oder mehr Teile faktorisiert wird, und die Teile an verschiedene Parteien verteilt werden. Es kann dann für bestimmte Nachrichten möglich sein, dass sie nur für mehr als eine Partei in Zusammenarbeit konstruiert sind, oder um alternativ die Möglichkeit zu schaffen, dass mehr als eine Partei zusammenarbeiten, um eine Nachricht entschlüsselbar zu machen.
Bei der Verhinderung von zukünftigen Betrugsversuchen sollte die Anzahl der verwendeten Prüfbits und die Länge der Signatur und Kommunikationsschlüssel wesentlich sein, um für eine Person mit krimineller Absicht unproduktiv zu sein, die versucht, gefälschte ICONS zu erzeugen oder ihre Website als eine respektable finanzielle Organisation oder als eine vertrauenswürdige Registrierung falsch darzustellen. Bei Systemen gemäß Stand der Technik für die Verschlüsselung mit öffentlichen Schlüsseln hängt die Sicherheit in großem Ausmaß von den computertechnischen Anstrengungen ab, die erforderlich sind, um ein gegebenes Produkt aus zwei großen Primzahlen zu faktorisieren, um die Primzahlen herauszufinden. Auch noch größere Primzahlen sind gerechtfertigt, wenn dies zu einer finanziellen Sicherheit führt, als sie allein für sichere Kommunikationen gerechtfertigt wären, da die Sicherheit von Milliarden von verschlüsselten ICONs, die durch Millionen von Organisationen für Milliarden von Kunden weltweit garantiert wird, eventuell auf dem Spiel stehen könnte. Primzahlen in der Größenordnung von 1000 bis 2000 Bits Länge, wobei das Produkt von zwei solcher Primzahlen eine Länge von mehr als 2000 Bits hat, werden zum jetzigen Zeitpunkt für die vorhersehbare Zukunft als sicher erachtet, wobei bestimmte Beschränkungen bei der Wahl von Primzahlen beachtet werden müssen, so dass deren Produkt nicht einfach durch einen reversen Miller-Test für Faktoren faktorisiert werden kann.
Durch das obige Verfahren werden somit ICONs, die Bargeld oder andere Anlagen darstellen, in den "Namen" von verschiedenen Kunden erzeugt und in einer oder in mehreren Registrierungen 40 gespeichert. Eine vertrauenswürdige "Registrierung" ist eine solche, die gemäß den vorstehend beschriebenen Prinzipien als neue Einlagen nur ICONs akzeptiert, die von einer vertrauenswürdigen Organisation empfangen werden, die durch das Unterzeichnen von Kommunikationen mit der Registrierung unter Verwendung eines Geheimschlüssels identifiziert werden, der in einer Liste von vertrauenswürdigen Organisationen aufgelistet ist. Auf ähnliche Weise muss ein Kunde 31 oder 32 verifizieren, dass eine Registrierung, mit dem er handelt, eine vertrauenswürdiges Registrierung ist, die nur solche Einlagen akzeptiert, wobei der Kunde ähnliche Maßnahmen treffen kann, d.h. durch Verifizierung, dass die Kommunikationsschlüssel der vertrauenswürdigen Registrierung lediglich einer aus einer Liste von Schlüsseln ist, die zu den vertrauenswürdigen Registrierung gehören. Auf ähnliche Weise können vertrauenswürdige Organisationen verifizieren, dass ein Registrierung, in die sie ein neu erzeugtes ICON ablegt, eine vertrauenswürdige Registrierung ist, und zwar mit Hilfe der Kommunikationsschlüssel, die verwendet werden, um mit dem Registrierung zu kommunizieren, die in einer Liste von geprüften Registrierungen existieren.
Um die Wirksamkeit von Kommunikationstechniken gemäß der vorliegenden Erfindung darzustellen, wird das nachfolgende Beispiel betrachtet. Es sei angenommen, dass zwei Kunden 31 und 32, die beispielsweise über das Internet unter Verwendung von Links L14 und L13 kommunizieren, ein Übereinkommen treffen, um mit Anlagen zu handeln. Ein Kunde 31 kann beispielsweise einwilligen, eine Geldsumme an den anderen 32 zu zahlen, und zwar für einen Gegenstand oder eine Anlage, die kein Geld ist, die dem anderen Kunden gehört.
In dem einfachsten Fall besitzt die erste Partei 31 ein in der Registrierung 40 gespeichertes ICON, das genau der vereinbarten Zahlungssumme entspricht, und die andere Partei 32 besitzt ein einzelnes ICON, das in der gleichen Registrierung 40 gespeichert ist und einen Gegenstand, der kein Geld ist, darstellt, dessen Kauf die erste Partei zugestimmt hat, wobei jedes ICON von einer geeigneten Organisation garantiert wird, wie beispielsweise eine Organisation 20 oder eine Organisation 30.
Die zweite Partei 32 sendet eine Anfrage an die Registrierung 40, um ein ICON zeitweise zurückzuziehen, und zwar unter Verwendung der Kommunikations-Links L9 und L10. Diese Transaktion wird unter Verwendung der Kommunikationsschlüssel von sowohl der Registrierung 40 als auch dem Kunden 32 gesichert. Optional kann das ICON in der Registrierung als durch den Halter als temporär zurückgenommen identifiziert werden, aber das ICON ist zu diesem Zeitpunkt nicht zerstört, es ist lediglich gesichert und kann nicht zurückgezogen oder gehandelt werden, während der ursprüngliche Handel noch läuft. Dies in sich ist noch kein Schutz gegen einen Halter, der ein zurückgezogenes ICON klont, aber es wird später erläutert, weshalb ein solches Klonen eine unproduktive Methode für einen versuchten Betrug ist.
Der Kunde 32 entschlüsselt das zurückgezogene ICON unter Verwendung seines Geheimschlüssels. Der Kunde 32 verschlüsselt das ICON wieder unter Verwendung des öffentlichen Schlüssels der ersten Partei 31 und überträgt das Ergebnis an den Kunden 31 unter Verwendung der sicheren Kommunikations-Links L13 und L14, die durch Schlüssel gesichert sind, die verschieden sind von jenen, die für die Unterzeichnung der ICONS verwendet werden. Der Kunde 31 empfängt das verschlüsselte ICON und entschlüsselt dieses zuerst unter Verwendung seines eigenen Geheimschlüssels und dann unter Verwendung des öffentlichen Schlüssels der angegebenen garantierenden Organisation, beispielsweise die Organisation 30. An dieser Stelle wird ihn die Beschreibung des Gegenstandes offengelegt, der kein Geld darstellt, den er kaufen will, zusammen mit der Tatsache, dass dessen Existenz und Eigenschaft, wie beschrieben, von der vertrauenswürdigen Organisation 30 garantiert wird. Umgekehrt zieht der Kunde 31 temporär das ICON zurück, das die Bargeldzahlung darstellt, bezüglich derer es zugestimmt hat, sie an den Kunden 32 zu übertragen, und nach der Entschlüsselung unter Verwendung seines Geheimschlüssels und der erneuten Verschlüsselung unter Verwendung des öffentlichen Schlüssels des Kunden 32, überträgt er sie an den Kunden 32. Der Kunde 32 entschlüsselt dieses ICON unter Verwendung seines Geheimschlüssels und dann des öffentlichen Schlüssels beispielsweise der garantierenden Organisation 20, um zu verifizieren, dass es die zugestimmte Bargeldzahlung darstellt und diese Organisation 20 garantiert, dass sie eventuell gegen reales Geld eintauschbar ist, falls dies irgendwann erforderlich ist.
Wenn beide Parteien ihre jeweiligen Waren inspiziert und dem Handel zugestimmt haben, dann kommunizieren beide mit der Registrierung 40 unter Verwendung der sicheren Links L5 und L6 bzw. L9 und L10, und zwar mit Instruktionen bezüglich der Durchführung des Handels. Der Kunde 31 überträgt dann das Bitmuster des zeitweise zurückgezogenen ICONs, dessen Handel mit dem Kunden 32 er zugestimmt hat, zusammen mit dem wiederverschlüsselten ICON, das mit dem öffentlichen Schlüssel des Kunden 32 unterzeichnet ist, und das Bitmuster von dem er erwartet, dass er es im Gegenzug von dem Kunden 32 empfängt. Der Kunde 32 überträgt auf ähnliche Weise das Bitmuster seines temporär zurückgenommenen ICONs, das Bitmuster des ICONs, das mit dem öffentlichen Schlüssel des Kunden 31 wieder verschlüsselt wurde, und das Bitmuster des ICONs, von dem er erwartet, dass er es im Gegenzug von dem Kunden 31 empfängt. Die Registrierung bringt dann das Bitmuster, das der Kunde 31 erwartet, mit dem Bitmuster in Übereinstimmung, das von dem Kunden 32 geliefert wird, und umgekehrt das Bitmuster, das der Kunde 32 erwartet, mit dem Bitmuster, das von dem Kunden 31 empfangen wird. Bei Erfassung einer Übereinstimmung wird der Handel durchgeführt, indem die Bitmuster gefunden werden, die in dem blockierten Konto für temporär zurückgenommene ICONS enthalten sind, diese Bitmuster gelöscht und in der Datenbank durch die neuen ICONs ersetzt werden, die in den Namen der neuen Halter unterzeichnet sind.
Beim Entwickeln von Finanzsystemen ist die Sicherheit gegen Betrug von großer Bedeutung. Es wird nun angenommen, dass die Kunden 31 und 32 in folgender Weise betrügerisch zusammenarbeiten. Jeder hat ICONs im Wert von $ 1000 in der Registrierung 40 und ICONs im Wert von $ 10000 in einer zweiten nicht gezeigten Registrierung gespeichert. Sie arbeiten gleichzeitig, um ihre $ 1000-ICONs in der Registrierung 40 und ihre $ 10000-ICONs in der zweiten Registrierung zu handeln, und zwar durch den Prozess der temporären Zurücknahme, wie vorstehend beschrieben. Beim Informieren der Registrierung 40, mit den $1000-ICONs zu handeln, tauschen sie die wiederverschlüsselten $ 1000-Bitmuster gegen die $ 10000-Bitmuster aus, die von der zweiten Registrierung zurückgenommen wurden, wodurch bewirkt wird, dass die Registrierung 40 die $ 1000-ICONs löscht und die $ 10000-ICONs speichert, wobei die zweite Registrierung weiterhin die $ 10000-ICONS speichert. Sie können nun beide fortfahren, mit anderen Parteien zu handeln, und zwar unter Verwendung der in beiden Registrierungen gespeicherten $ 20000, und haben Erfolg beim betrügerischen Klonen von virtuellem Geld.
Obiges ist lediglich ein Beispiel von vielen möglichen Sicherheitsanfälligkeiten, die bei der Erschaffung eines automatischen, im wesentlichen unüberwachten, elektronischen Handelssystem betrachtet werden müssen. Das obige Beispiel kann gemäß der vorliegenden Erfindung durch die folgende Technik verhindert werden.
Zusätzlich zu der Bereitstellung von digitalen Anlagebeschreibungen, die mit dem Geheimschlüssel unterschrieben sind, stellt die herausgebende Organisation ein digitales Prüfmuster zur Verfügung, wie zum Beispiel ein zyklischer Redundanzprüfungs-Code, das heißt eine Funktion von dem Volltext-Inhalt der Anlagebeschreibung, die aber dann unter Verwendung eines symmetrischen Verschlüsselungsschlüssels verschlüsselt wird – beispielsweise durch Bitweise Modulo-2-Addition eines Codes oder transponierenden Bits in einer Weise, die lediglich der Organisation bekannt ist. Alternativ kann der Prüfungs-Code unter Verwendung des Geheimschlüssels der Organisation verschlüsselt werden. Dies garantiert, dass keine andere Partei auf einfache Weise einen Prüfungs-Code fälschen kann, so dass eine gefälschte Nachricht durchgelassen wird.
Gemäß einem bereits beschriebenen Sicherheitsaspekt können lediglich qualifizierte Organisationen neue Anlage-ICONs erzeugen und in die Datenbank der Registrierung einfügen. Wenn sie dies tun, dann werden auch die verschlüsselten Prüfmuster zur Verfügung gestellt und jedem ICON zugewiesen. Die verschlüsselten Prüfmuster sind jedoch nicht für andere Individuen einsehbar. Diese Muster können lediglich von der Registrierung in sicheren Kommunikationen an eine qualifizierte Organisation übermittelt werden.
Obwohl ein Individuum, das den Volltext-Inhalt von einem ICON inspiziert, das Volltext-CRC wiederherstellen kann, kann es daher nicht das Bitmuster des entsprechenden, durch die Organisation verschlüsselten CRC kennen, das in der Registrierung gespeichert ist.
Die verschlüsselten Prüfmuster hängen von dem Volltext in dem ICON ab, den lediglich eine autorisierte Organisation unter Verwendung ihres Geheimschlüssels erzeugen kann, und sind an die ICONs angehängt, und zwar auch während der Änderung der Halterschaft in Vorgängen außerhalb und innerhalb der Registrierung. In dem obigen Beispiel eines möglichen Betrugs, obwohl die Registrierung während eines Handels unbekannterweise ein betrügerisches ICON empfängt, um ein gültiges ICON zu ersetzen, bleibt daher der Prüfungs-Code des ursprünglichen ICONs an dem neuen ICON gekoppelt, und zwar unter der Annahme, dass das neue ICON den gleichen zugrundeliegenden Volltext hat und somit die gleiche Anlage beschreibt, lediglich wieder verschlüsselt für eine andere Halterschaft. Ein individueller Versuch, mit einem ICON zu betrügen, kann daher im schlechtesten Fall höchstens den Erfolg haben, es ungültig zu machen, indem eine fehlende Übereinstimmung zwischen dem ICON und seinem Prüfungs-Code erzeugt wird, für den es blind ist.
Wie vorstehend beschrieben, muss die zweite Partei an einem Handel an einem Betrugsversuch mitwirken, indem sie die Registrierung instruiert, ein ICON zu akzeptieren, von dem sie weiß, dass es das CRC von dem ICON nicht erfüllt, das es ersetzen soll. Daher wird keine unwissende Partei geschädigt, wenn ein ICON durch einen Betrugsversuch ungültig gemacht wird. Andererseits können ungültige ICONs in der Datenbank erzeugt werden, wobei dann versucht werden kann, dieses einer dritten Partei anzuhängen.
Eine weitere Sicherheitsmaßnahme verhindert auch Letzteres: Während eines Handels wird eine Partei, die ein angebotenes ICON inspiziert, um zu verifizieren, ob es ihren Erwartungen entspricht, dieses entschlüsseln, um den Volltext zu inspizieren, und außerdem wird das CRC über dem Volltext neu berechnet. Das angebotene ICON, das ihr von ihrem Handelspartner übertragen wird, wird zuerst einer notwendigen Link-Protokoll-Entzifferung unterzogen und dann unter Verwendung ihres Geheimschlüssels entschlüsselt. Dann wird es unter Verwendung des öffentlichen Schlüssels der garantierenden Organisation weiter entschlüsselt, um den Volltext offenzulegen, und zwar nur dann, wenn das ICON auch wirklich von dieser Organisation stammt. Der Empfang zur Berechnung des unverschlüsselten Prüfungs-Codes von dem Volltext wird veröffentlicht, und jede Partei mit Zugriff auf den Volltext kann somit den Prüfungs-Code des Volltextes berechnen. Dieser wird durch die Partei an die Registrierung geleitet, die ein zu handelndes ICON akzeptiert, so dass die Registrierung verifizieren kann, ob das CRC mit einem gespeicherten CRC von einem ICON übereinstimmt, durch das das angebotene ICON eventuell ersetzt wird. Die Registrierung entschlüsselt das CRC des vorhandenen ICONS unter Verwendung des Geheimschlüssels der garantierenden Organisation und vergleicht das Volltext-ICON mit dem erneut berechneten ICON, das von einer handelnden Partei empfangen wird. Wenn keine Übereinstimmung vorliegt, dann wird die handelnde Partei gewarnt, die das neu berechnete ICON liefert, und die Registrierung wird den Handel nicht durchführen.
Die Registrierung hat die Option anzufordern, dass die Organisation den Vergleich durchführt, wenn die Registrierung nicht in der Lage ist, einen verschlüsselten Prüfungs-Code zu entschlüsseln, z.B. wenn eine symmetrische Verschlüsselung verwendet wird, um den Prüfungs-Code zu schützen. Jede Organisation kann ein bestimmtes Verschlüsselungsverfahren für den Prüfungs-Code verwenden, und die Registrierungen können bestimmt werden, um jeden Typ von Prüfungs-Prozedur zu handhaben, und zwar abhängig davon, ob die Bestimmungen der Organisation eine autonome Prüfungs-Prozedur erlaubt, die nicht bei jeder Transaktion die Organisation einbezieht.
4(a) und 4(b) zeigen den Datenstrom in den vorstehend beschriebenen Sicherheitsoperationen. In 4(a) erzeugt eine Finanzorganisation 40 ein ICON nach Verhandlung mit einem Kunden, dass das ICON eine reale Anlage darstellen soll. Während dieser Verhandlung wurde das ICON mit dem öffentlichen Schlüssel des Kunden verschlüsselt werden, so dass lediglich der Kunde es unter Verwendung seines Geheimschlüssels entschlüsseln kann. Die Organisation hat außerdem einen CRC-Prüfungs-Code berechnet, der eine Anzahl von Bits beinhaltet, die ausreichend ist, um eine vernachlässigbare Wahrscheinlichkeit sicherzustellen, ihn durch Raten herauszufinden, wie zum Beispiel 64 Bits. Der Prüfungs-Code ist eine Funktion des Volltext-Inhalts des ICONS, und sowohl das vom Benutzer verschlüsselte ICON als auch der CRC-Code werden durch die Organisation unter Verwendung verschlüsselter Links an die Registrierung übertragen. Das benutzerspezifisch verschlüsselte ICON und das angehängte CRC werden dann in der Registrierungs-Datenbank zusammen mit einer Angabe des Kunden gespeichert, zu dem sie gehören (nicht gezeigt).
4(b) zeigt den Datenstrom in einer Richtung eines Handels, und die Schritte, die im Flussdiagramm aus 5 spezifiziert sind. Kunden 31 und 32 haben einer Transaktion zugestimmt, bei der der Kunde 31 ein wiederverschlüsseltes ICON liefert soll, das für den Kunden 32 spezifisch ist. Der Kunde 31 fordert zuerst in Schritt 100 das ICON von der Registrierung 40. Im Prinzip ist dies nicht notwendig, wenn der Kunde 31 eine Kopie hat. Die Registrierung sendet das von dem Kunden 31 angeforderte ICON über einen verschlüsselten Link, nachdem selbiges in Schritt 101 mit dem Geheimschlüssel der Registrierung und dem öffentlichen Schlüssel des Kunden 31 verschlüsselt wurde, sendet aber nicht das CRC. Der Kunde 31 entschlüsselt in Schritt 102 das empfangene ICON unter Verwendung seines Geheimschlüssels, des öffentlichen Schlüssels der Registrierung und wieder seines Geheimschlüssels. Der Kunde 31 verschlüsselt dann wieder das ICON unter Verwendung des öffentlichen Schlüssels des Benutzers 32, seines eigenen Geheimschlüssels und wieder des öffentlichen Schlüssels des Kunden 32, wie in Schritt 103 gezeigt, und überträgt das Ergebnis zu dem Kunden 32 über einen weiter verschlüsselten Kommunikationskanal. Der Kunde 32 empfängt die Nachricht und entschlüsselt das Kommunikationsschichtprotokoll und entschlüsselt dann das verschlüsselte ICON unter Verwendung seines Geheimschlüssels und des öffentlichen Schlüssels des Kunden 31, um in Schritt 104 den Volltext offenzulegen. Der Kunde 32 kann dann die Eigenschaft der Anlage inspizieren, die durch das ICON beschrieben wird. Der Kunde 32 berechnet (in Schritt 105) das CRC aus dem Volltext-ICON unter Verwendung einer Quittung, die von der garantierenden Organisation veröffentlicht wird. Der Kunde 32 überträgt dann die verschlüsselte Version des ICONs zusammen mit dem CRC unter Verwendung eines sicheren Kommunikationskanals zu der Registrierung, wie in Schritt 106 beschrieben.
Die Registrierung empfängt das vom Kunden 32 verschlüsselte ICON von dem Kunden 32 und ebenfalls von dem Kunden 31. Der Kunde 31 gibt der Registrierung an, dass bei Ausführung des Handels das vom Kunden 32 verschlüsselte ICON das ursprüngliche, vom Kunden 31 verschlüsselte ICON ersetzen soll. Der Kunde 32 gibt der Registrierung das Bitmuster des ICONs an, dessen Empfang er vom Handel erwartet. Das durch die Registrierung von dem Kunden 32 empfangene ICON wird entschlüsselt, wie in Block 107 gezeigt. Wenn die vom Kunden 32 verschlüsselten ICONs, die sowohl von dem Kunden 31 als auch von dem Kunden 32 empfangen werden, in der Registrierung übereinstimmen, ist ein Kriterium für die Ausführung des Handels erfüllt. Die Registrierung entschlüsselt außerdem das CRC des ICONs, von dem der Kunde 31 angibt, dass er damit handeln möchte, und zwar unter Verwendung des öffentlichen Schlüssels der garantierenden Organisation, und vergleicht es in Schritt 108 mit dem CRC, das von dem Kunden 32 empfangen wird. Wenn sie übereinstimmen, dann wird die vom Kunden 32 verschlüsselte Version des ICONs als gültig bestätigt, und der Kunde 32 wurde über dessen Eigenschaft nicht durch den Kunden 31 getäuscht. Andererseits, wenn keine Übereinstimmung angezeigt wird, dann warnt die Registrierung den Kunden 32, dass das ICON, das der Kunde 31 angeboten hat, ungültig ist, und verweigert die Ausführung eines Handels, wie in Schritt 109 gezeigt. Umgekehrt kann dem Kunde 31 die Gültigkeit des ICONs gewährleistet werden, das ihm durch den Kunden 32 angeboten wird, und ob bestimmte Kriterien erfüllt sind. Nämlich, dass (1) das ICON, dessen Empfang der Kunde 32 von dem Kunden 31 erwartet, mit dem vom Kunden 32 verschlüsselten ICON übereinstimmt, das von A an die Registrierung geliefert wurde; (2) das ICON, dessen Empfang der Kunde 31 von dem Kunden 32 erwartet, mit dem vom Kunden 31 verschlüsselten ICON übereinstimmt, das von dem Kunden 32 an die Registrierung geliefert wurde; (3) das von dem Kunden 32 gelieferte CRC mit dem gespeicherten CRC des von dem Kunden 31 verschlüsselten ICONS übereinstimmt, das durch das vom Kunden 32 verschlüsselte ICON überschrieben wird, dessen Empfang durch den Kunden 32 von dem Kunden 31 erwartet wird; (4) das von dem Kunden gelieferte CRC mit dem gespeicherten CRC des vom Kunden 32 verschlüsselten ICONS übereinstimmt, das durch das vom Kunden 31 verschlüsselte ICON überschrieben wird, dessen Empfang durch den Kunden 31 von dem Kunden 32 erwartet wird; (5) das ICON, das der Kunde 31 anbietet, um durch ein wiederverschlüsseltes ICON ersetzt zu werden, das die Halterschaft des Kunden 32 angibt, in der Registrierung vorhanden ist; (6) das ICON, das der Kunde 32 anbietet, um durch ein wiederverschlüsseltes ICON ersetzt zu werden, das die Halterschaft des Kunden 31 angibt, in der Registrierung vorhanden ist; und dass (7) bestätigt wird, dass alle Kommunikationen von den Kunden 31 und dem Kunden 32 zu der Registrierung die digitalen Signaturen des Kunden 31 und des Kunden 32 tragen, wobei die Registrierung dann den Handel der ICONs durchführt.
Die obige Prozedur verhindert somit das betrügerische Klonen von ICONs, wobei mehrere Kopien in die Registrierung eingesetzt werden können, die für den gleichen oder auf verschiedene Benutzer registriert sind, und verhindert außerdem, dass ein unwissender Kunde durch einen Betrüger betrogen wird, indem er ein wertloses ICON akzeptiert. Diese Prozedur basiert auf der Schwierigkeit des Erzeugens eines betrügerischen ICONs, das die gleiche CRC erzeugt wie ein gültiges ICON.
Obwohl das Letzteres durch die obigen Prozeduren verhindert wird, besteht eine weitere Sicherheit gegen Betrug darin, wenn ein Mechanismus gefunden werden kann, um die Modifizierung des Volltextes von einem ICON zu verhindern, so dass es ein existierendes CRC passiert, das zu einem anderen ICON gehört, das dem Betrüger bekannt ist. Beispielsweise werden ICONs während einer Verhandlung zwischen einem Kunden und einer Organisation erzeugt, während derer der Kunde in genauem Wortlaut eine Anlagebeschreibung abgeben muss. Zum Beispiel kann der Kunde damit Erfolg haben, so dass die Organisation überzeugt, unwichtig erscheinende Modifikationen der Anlagebeschreibung zu akzeptieren, so dass, für die Organisation unbekannt, der Volltext ein bestimmtes CRC erzeugt, wie es von dem Halter zum Zweck eines Betrugs gewünscht wird.
Unglücklicherweise haben übliche zyklische Redundanzprüfungs-Codes eine lineare Eigenschaft, die es möglich macht, modifizierte Bitmuster zu erzeugen, die ein gegebenes CRC erzeugen. Da das CRC von (Bitmuster A).XOR.(Bitmuster B) gleich (CRC von A).XOR.(CRC von B) ist, kann die folgende Prozedur bei einem betrügerischen Versuch verwendet werden, um einen gewünschten CRC-Wert zu erhalten:

– Konstruieren eines betrügerischen Bitmusters A mit acht, 8-Bit-Leerzeichen am Ende des Volltextes (oder irgendwo anders), die leer sind (unter der Annahme, dass ein 64-Bit-CRC verwendet wird).
– Berechnen des CRC über das betrügerische Bitmuster CRC (A).
– XOR CRC(A) mit CRC(B), um zu bestimmen, wie sie sich unterscheidet, wobei das 64-Bit-SYNDROM erhalten wird.
– Berechnen eines 8×8-Bit-Zeichenmusters, um die Leerstellen auszufüllen, die das Syndrom annullieren. Dies kann folgendermaßen geschehen:
– Konstruieren eines Bitmusters nur aus Nullen, mit Ausnahme einer "1" in der ersten leeren Bit-Position und Berechnen von dessen CRC(=B1).
– Wiederholen mit der "1" in jeder der Leerstellen, um aufeinanderfolgend B2, B3 ... B64 zu erhalten, alle 64-Bit-Vektoren.
– Anordnen der 64, 64-Bit-Vektoren B1 ... B64 in einer 64×64-Bit-Boolschen Matrix, und Invertieren der Boolschen Matrix durch bekannte Techniken, um eine neue 64×64-Bit inverse Matrix zu erhalten.
– Multiplizieren des SYNDROM mit der inversen Matrix, um ein geeignetes Leerstellen ausfüllendes Muster zu erhalten, wodurch bewirkt wird, dass das betrügerische Bitmuster zu dem gleichen CRC führt wie das gültige Bitmuster.

Diese Schwäche kann unter Verwendung einer nicht-linearen Prüfungs-Code-Berechnung überwunden werden, wie in 6 dargestellt. Das Volltext-Bitmuster 200 wird zuerst als eine Sequenz von Bitblocks 201, 202 ... 206 dargestellt, und jeder Bitblock wird einem Eingang, beispielsweise der Schlüsseleingang, von einem Block-Verschlüsseler 211 ... 216 zugeführt, wie zum Beispiel der DES-Algorithmus. In dem DES-Fall würden die Bitblocks daher jeweils 56 Bits enthalten, was der DES-Schlüssellänge entspricht, das heißt 7,8-Bit-ASCII-Zeichen, unter Verwendung eines ASCII-Paritätsbits gemäß einer zugestimmten Konvention, oder ansonsten 8,7-Bit-ASCII-Zeichen ohne Paritätsbit.
Das Volltext-Bitmuster durchläuft außerdem eine Bit-Transpositionsroutine 210, die die Bits gemäß einem festen Zeitplan aufzeichnet, um ein verschachteltes oder transponiertes Volltext-Bitmuster 220 zu erzeugen. Das transponierte Bitmuster wird außerdem in Bitblocks 241 ... 246 unterteilt, wobei die Anzahl der Bits pro Blocks der Größe der Volltext-Eingabe von Blockschlüsseln 211 ... 216 entspricht, d.h. 64 Bits in dem DES-Fall, das beispielsweise 8 × 8 Bit-ASCII-Zeichen einschließlich des ASCII-Paritätsbits enthält.
Jeder transponierte Bitblock mit Ausnahme des ersten 241 wird außerdem zu der Schlüsseltext(CT)-Ausgabe des vorhergehenden Blockschlüssels addiert, und zwar vor der Anwendung der Volltext(PT)-Eingabe des nachfolgenden Blockschlüssels. Die CT-Ausgabe von dem letzten Blockschlüssel bildet den erforderlichen Prüfungs-Code. Der nicht-lineare Prüfungs-Code, wie oben beschrieben, kann in irgendeinem nicht-linearen Block-Kombinationsalgorithmus berechnet werden, wie beispielsweise jene, die in den US-Patenten 5,148,480 oder 5,091,942 beschrieben sind, die hiermit durch Bezugnahme eingeführt werden.
Ein weiteres Verfahren zum Erzeugen eines nicht-linearen CRC besteht darin, das CRC über sowohl den Volltext-ICON-Inhalt als auch über die von der Organisation verschlüsselte Version des Volltextes zu erzeugen, die eventuell in einer Registrierung gespeichert ist. Der betrügerische Kunde kann dann nicht die Wirkung vorhersagen, die Veränderung in dem Volltext auf den CRC-Code haben, da er nicht vorhersagen kann, welche Wirkung die Volltext-Veränderungen auf das von der Organisation verschlüsselte Muster haben.
Unter Verwendung des nicht-linearen Prüfungs-Codes ist es unmöglich, außer durch unpraktische, arbeitsaufwendige Try-and-Error-Versuche, sich von einem gewünschten Prüfungs-Code zurückzuarbeiten, um eine Anlagebeschreibung zu erzeugen, die ihn erfüllt und der gleichzeitig Sinn macht. Eine gegebene Volltext-Nachricht muss in vielen gestreuten Bitpositionen modifiziert werden, um eine gegebene Veränderung des CRC durchzuführen. Die Länge des Prüfungs-Codes kann darüber hinaus erhöht werden, und zwar auf irgendeine Größe, die erforderlich ist, um Zufallsversuche, um diesen zu erzeugen, unproduktiv zu machen.
7 zeigt in größerem Detail eine beispielhafte Implementierung der symmetrischen Sicherheitsgarantien, die bereitgestellt werden, wenn die Erfindung ausgeführt wird.
Ein ICON 1000 wird so in der Registrierung gespeichert, dass es zu dem Kunden 31 gehört, und wird auf Anfrage durch den Kunden 31 zeitweise zurückgezogen. Die Registrierung sendet das ICON über einen sicheren Link, der mit einem Linkschlüssel bei 1004 verschlüsselt und bei Block 2004 entschlüsselt wird. Der Kunde 31 fährt mit dem Entschlüsseln des ICON-Bitmusters 'x' unter Verwendung seines Geheimschlüssels in Block 2000 fort und verschlüsselt es dann wieder unter Verwendung des öffentlichen Schlüssels des Kunden 32 bei 2001, um ein Bitmuster x' zu erhalten, das bezüglich des Eigentums des Kunden 32 modifiziert ist. Das modifizierte ICON x' wird an den Kunden 32 unter Verwendung eines sicheren Links übertragen, der den Linkschlüssel 2002 enthält, und entsprechend der Entschlüsselung beim Kunden 32 in Block 3003. Der Kunde 32, nach der Entschlüsselung in Block 3003, erhält x', das er unter Verwendung seines Geheimschlüssels in Block 3005 weiter entschlüsselt, um das ICON zu erhalten, das nun lediglich durch den Schlüssel der garantierenden Organisation geschützt ist. Das ICON wird bei 3007 unter Verwendung des öffentlichen Schlüssels der garantierenden Organisation weiter entschlüsselt, um den Volltext offenzulegen, der von dem Benutzerkunden 32 inspiziert, geprüft und genehmigt wird, oder auch nicht. Wenn der Kunde 32 mit der Anlagebeschreibung einverstanden ist, fährt er fort, indem das CRC des ICON unter Verwendung von sowohl dem Volltext- als auch dem durch die Organisation verschlüsselten Bitmuster zu berechnen, und zwar aus Gründen, die vorstehend beschrieben wurden. Das CRC 'a' wird dann zusammen mit dem Bitmuster x' an die Registrierung übertragen, von dem es abgeleitet wurde.
Umgekehrt zieht der Kunde 32 das ICON 1001 zeitweise aus der Registrierung zurück, das an ihn gesendet wurde, verschlüsselt ist durch das Link-Protokoll 1005 in der Registrierung, und entschlüsselt es dann unter Verwendung des Link-Entschlüsselungsblocks 2004. Der Kunde 32 entfernt dann seinen Geheimschlüssel in Block 3000, um den Volltext des ICONS offenzulegen, den er dann unter Verwendung des öffentlichen Schlüssels des Kunden 31 in Block 3001 verschlüsselt, um die Anlage dem Kunden 31 anzubieten. Das somit für die Halterschaft des Kunden 31 wieder verschlüsselte ICON wird an den Kunden 31 unter Verwendung eines sicheren Links übertragen, der eine Link-Verschlüsselung in Block 3002 beim Kunden 32 und eine Link-Entschlüsselung in Block 2003 beim Kunden 31 beinhaltet. Dadurch wird für den Kunden 31 das Bitmuster y' freigegeben, wobei der Kunde 32 anbietet, dieses in der Registrierung zu speichern. Der Kunde 31 entschlüsselt das Bitmuster y' unter Verwendung seines Geheimschlüssels weiter, um das ICON offenzulegen, das lediglich durch den Geheimschlüssel der garantierenden Organisation geschützt ist. Der Volltext wird dem Kunden 31 offengelegt, und zwar durch weitere Entschlüsselung in Block 2005 unter Verwendung des öffentlichen Schlüssels der garantierenden Organisation. Bei Inspektion, Prüfung und Genehmigung der Volltext-Anlagebeschreibung fährt der Kunde 31 fort, das CRC des angebotenen ICONs über sowohl den Volltext als auch das entsprechende, von der Organisation verschlüsselte Bitmuster zu berechnen, um CRC 'b' zu erzeugen. CRC 'b' wird dann unter Verwendung des Linkschlüssels 2010 zu der Registrierung übertragen, und zwar zusammen mit dem durch den Kunden 32 angebotenen Bitmuster y' und außerdem das Bitmuster x des Anlage-Kunden 31 und das wiederverschlüsselte Bitmuster x' der gleichen Anlage, wenn es zum Eigentum des Kunden 32 geworden ist. Auf ähnliche Weise hat der Kunde 32 das Bitmuster 'y' des ICON-Kunden 32 übertragen, wie aktuell auf ihn registriert wurde, sowie das entsprechende Bitmuster y', das auf das Eigentum des Kunden 31 modifiziert wurde. Die Registrierung entschlüsselt in Block 1010 die Bitmuster x' und y', die gemäß dem Kunden 31 genehmigt sind, und entschlüsselt in Block 1011 x' und y' gemäß dem Kunden 32. Ein Komparator 1012 verifiziert, dass x', wie es von dem Kunden 31 empfangen wurde, mit x' gemäß dem Kunden 32 genehmigt wurde, und verifiziert auf ähnliche Weise in dem Komparator 1013, dass die jeweiligen Ansichten des Kunden auf die Bitmuster y' genehmigt wurden. Der Komparator 1014 verifiziert, dass das Bitmuster x, das von dem Kunden 31 empfangen wurde, mit jenem des ICON A übereinstimmt, das auf ihn registriert ist, und der Komparator 1009 verifiziert, dass CRC 'a', das von dem Kunden 32 empfangen wurde, mit jenem des ICONs 1002 übereinstimmt, wobei zuerst in Block 1007 der Schlüssel der garantierenden Organisation entfernt werden muss. Daher ist verifiziert, dass der zugrundeliegende Volltext, der in den Bitmustern x und x' enthalten ist, der gleiche ist. Umgekehrt verifiziert der Komparator 1015, dass das Bitmuster y, das von dem Kunden 32 empfangen wurde, mit dem Bitmuster 1001 des auf ihn registrierten ICONs übereinstimmt, und der Komparator 1008 verifiziert, dass CRC 'b', das von dem Kunden 31 empfangen wurde, mit dem gespeicherten CRC 1003 des ICON-Kunden 32 übereinstimmt, nachdem es mit dem öffentlichen Schlüssel der garantierenden Organisation in Block 1006 entschlüsselt wurde. Nur wenn alle sechs Komparatoren eine Übereinstimmung erzeugen, führt die Registrierung den Handel durch, was ein Überschreiben des ursprünglichen Bitmusters x mit dem neuen Bitmuster x' beinhaltet, und vorzugsweise das gleichzeitige Überschreiben des anderen ursprünglichen Bitmusters y des ICONs mit dem modifizierten Bitmuster y'.
Die Präferenz des gleichzeitigen Überschreibens von ICONs impliziert, dass die Inhalte des ICON-Speichers der Registrierung auf halbem Wege ungültig sind, wo lediglich ein ICON überschrieben wurde, und nicht das andere. In einer zeitlich aufgeteilten Hardware-Implementierung, die viele Kommunikations-Links und Handelsaktionen handhaben kann, die mehr oder weniger gleichzeitig stattfinden, ist es wichtig, einen neuen Handel zu verhindern, der beinhalten kann, dass die gleichen ICONs durch einen Transaktions-Zeitplaner auf halbem Wege von einer vorhergehenden Transaktion überlagert werden. Dieses Problem kann beispielsweise umgangen werden, indem der Interrupt-Mechanismus des Registrierungs-Prozessors deaktiviert wird, bis alle ICONs, die zu einer Handelsaktion gehören, überschrieben wurden, wonach die Interrupts wieder aktiviert werden.
Die Sicherheit gemäß der vorliegenden Erfindung hängt teilweise von dem Konzept der "vertrauenswürdigen Registrierung" ab, die programmiert werden kann, um wahlweise Handelsaktionen durchzuführen, wenn die Sicherheit, wie gerade mit Hilfe von 7 beschrieben, erfüllt ist. Dieses "Vertrauen" wird durch kryptologische Techniken sichergestellt, zusammen mit einer korrekten Autorisierung von Registrierungen und der physikalischen Sicherheit und Integrität von deren Hardware. Danach können Transaktionen automatisch ohne menschliche Intervention ausgeführt werden. Die Sicherheit hängt außerdem teilweise von der Tatsache ab, dass die Gesamtzahl von ICONs in einer Registrierung nicht durch Transaktionen verändert werden kann, die allein von Kunden geordert werden. Wenn jedoch der Kunde 31 und der Kunde 32 ihre Anlagen in verschiedenen Registrierungen halten, dann können die Registrierungen durch automatische und verschlüsselte Kommunikations-Links untereinander zusammenarbeiten, um die obigen Sicherheitsprotokolle zu implementieren, wobei sie sich für den Zweck einer bestimmten Transaktion effektiv wie eine einzige Registrierung verhalten. Eine solche zusammenarbeitende Transaktion kann zur Sicherheit beitragen, dass ein ICON von einer Registrierung zu einer anderen übertragen wird, wobei in diesem Fall die Anzahl von ICONs in einer Registrierung abnehmen kann, während die Anzahl in der anderen zunehmen kann, wobei jedoch die Gesamtzahl während einer solchen Transaktion gleich bleibt.
Andere Transaktionen können eine Veränderung bezüglich der Anzahl von gespeicherten ICONs beinhalten. Wenn beispielsweise ein ICON, das einen Geldwert darstellt, der größer als der ist, der gehandelt wird, kann die Notwendigkeit bestehen, diesen aufzuteilen. Ein solches Aufteilen kann von dem Halter in Kommunikation mit der herausgebenden Bank erfolgen. Das Folgende ist eine beispielhafte Prozedur zum Organisieren des Aufteilens, wobei viele Variationen davon erfolgen können, ohne von den Prinzipien und dem Grundgedanken der Erfindung abzuweichen.
Es sei angenommen, dass der Halter zeitweise das aufzuspaltende ICON aus der Registrierung zurückzieht und nach der Entschlüsselung das CRC berechnet. Das unverschlüsselte ICON wird dann unter Verwendung eines sicheren Links zusammen mit dem CRC an seine Bank übertragen, und zwar zusammen mit den Details des Wertes von neuen ICONs, von denen er wünscht, dass er sie zurück empfängt, die natürlich insgesamt den Wert des zu ersetzenden ICONS haben. Die Bank kommuniziert dann mit der Registrierung unter Verwendung eines sicheren Kommunikationsprotokolls, um das alte ICON durch mehr als ein neues ICON zu ersetzen. Diese Erhöhung bezüglich der Anzahl von ICONs wird in diesem Fall durch die Registrierung akzeptiert, da es von einer qualifizierten Finanzorganisation angewiesen wird. Auf ähnliche Weise können zwei oder mehr ICONs, die den gleichen (oder sogar unterschiedlichen) Typ von Anlage darstellen, durch eine ähnliche Transaktion zu einem einzelnen ICON konsolidiert oder "gebündelt" werden. Auf diese Weise können kompliziertere Handelsvorgänge unter Verwendung der "Bündelung" von Anlagen organisiert werden. Beispielsweise kann ein erster Benutzer $ 10000 an einen zweiten Benutzer zahlen, um eine Menge an Teilen zu empfangen, die im Austausch einen Wert von $ 9000 und $ 1000 haben.
Als eine Alternative zur Erzeugung eines speziellen ICONs, um "gebündelte" Anlagen darzustellen, ist es möglich, die Nachrichten zu strukturieren, die handelnde Parteien zu vertrauenswürdigen Registrierungen senden oder von diesen empfangen, so dass mehr als zwei ICONs in der gleichen Transaktion gehandelt werden können. 8 stellt in tabellarischer Form die Struktur von einer beispielhaften Nachricht von einer handelnden Partei zu einer Registrierung dar, wodurch ein Multi-ICON-Handel dargestellt wird.
In Zeile (1) ist die ID von der ersten und der zweiten handelnden Partei angegeben. Diese kann, aber nicht beschränkt darauf, eines der folgenden beinhalten:

– den öffentlichen Schlüssel der jeweiligen handelnden Parteien;
– die Sozialversicherungsnummer oder Organisationsnummer der jeweiligen handelnden Parteien;
– die ID der Partei, die durch die Registrierung herausgegeben wird (möglicherweise nur gültig für diese Aktion); und
– die E-Mail-Adresse oder die Internet-Port-Adresse.

Die Anzahl von ICONs, die die erste Partei zu der zweiten Partei übertragen möchte, ist in diesem Beispiel als "3" angegeben, und die Anzahl von ICONs, die von der zweiten Partei empfangen werden soll, ist in diesem Beispiel als "2" angegeben.
Dann wird das Bitmuster von dem ersten zu übertragenden, zugestimmten ICON zur Verfügung gestellt, und zwar als zeitweise in der Registrierung (Zeile 2a) gespeichert, d.h. verschlüsselt mit dem öffentlichen Schlüssel der ersten Partei, zusammen mit einer neuen Version, verschlüsselt mit dem öffentlichen Schlüssel der zweiten Partei (Zeile 2b). Es folgt die gleiche Information für die übrigen zwei ICONs, z.B. in Zeilen 3a–4b.
Dann folgt das Bitmuster für das erste der beiden ICONs, die von der zweiten Partei empfangen werden sollen, verschlüsselt mit dem öffentlichen Schlüssel der ersten Partei in Zeile 5a. Die ID der garantierenden Organisation, die offengelegt ist, wenn der Volltext des ICONs inspiziert wird, ist ebenfalls angegeben.
Zusammen mit jedem erwarteten ICON-Bitmuster gibt es einen CRC-Code in Zeile 5a, der von der ersten Partei berechnet wird, und zwar über den Volltext-Inhalt des ICONs, das für ihn offengelegt wurde, wenn es von der zweiten Partei für die Inspektion gesendet wurde, d.h., wenn das ICON durch die zweite Partei der ersten Partei "angeboten" wurde. Eine ähnliche Information für das zweite ICON, das erwartet wird, komplettiert die Nachricht in Zeilen 6a und 6b. Die gesamte Nachricht wird unter Verwendung des öffentlichen Schlüssels der Registrierung und des Geheimschlüssels des Senders verschlüsselt und vorzugsweise unter Verwendung eines fehlertoleranten Paketprotokolls übermittelt, das eigene Prüfungen durchführen kann, wobei so viele Rückübertragungen von Paketen durchgeführt werden, die bei der Übertragung verstümmelt wurden, wie es notwendig ist, um eine fehlerfreie Lieferung an die Registrierung zu garantieren.
Die zweite Partei sendet in der Zwischenzeit eine entgegengerichtete Nachricht an die Registrierung. Die Registrierung bringt die beiden Nachrichten in Übereinstimmung und überprüft, ob:

– die IDs der handelnden Parteien in beiden Nachrichten übereinstimmen;
– die Nachrichten tatsächlich durch die Parteien erzeugt wurden, die durch die angegebenen IDs beansprucht sind, wie durch erfolgreiche Entschlüsselung unter Verwendung ihrer jeweiligen öffentlichen Schlüssel verifiziert;
– die Anzahl von ICONs, die von einer Partei empfangen werden sollen, mit der Anzahl übereinstimmt, die von der anderen Partei gehandelt werden, und umgekehrt;
– die Bitmuster von jedem ICON, die von einer Partei empfangen werden sollen, mit denen übereinstimmen, die von der anderen geliefert wurden;
– das CRC von dem ICON ersetzt wurde, wie es in der Registrierung gespeichert ist, nach der Entschlüsselung durch die Registrierung unter Verwendung des angegebenen öffentlichen Schlüssels der garantierenden Organisation, mit dem CRC übereinstimmt, das in der Nachricht für dieses ICON zur Verfügung gestellt wird.

Wenn die Registrierung irgendwelche Anomalien bezüglich der Übereinstimmung von Daten erfasst, die von den handelnden Parteien empfangen werden, wird der Handel nicht durchgeführt, und Warnmitteilungen werden an die handelnden Parteien gesendet, durch die das Problem angegeben wird. Wiederholte fehlgeschlagene Versuche zur Durchführung einer Transaktion können wahlweise bewirken, dass die Registrierung die Handelsaktion abbricht und die Verbindung als Schutz gegen zufällige, betrügerische Transaktionen durch Try and Error-Transaktionsversuche schließt.
Ein weiterer Typ von Transaktion kann die Übertragung der Garantie von virtuellem Geld oder anderen Anlagen von einer Organisation zur anderen beinhalten, während das modifizierte ICON in der gleichen Registrierung verbleibt. Eine solche Transaktion kann von dem Halter nach digitaler Verhandlung mit den jeweiligen Organisationen in Auftrag gegeben werden, und sie wird dann durch die Organisationen, private sichere Kommunikationen untereinander und der Registrierung durchgeführt. Auf ähnliche Weise kann der Benutzer den Transfer von ICONs zwischen Registrierungen bewirken, ohne die zu Grunde liegende garantierende Organisation zu verändern. All diese Transaktionen können automatisiert sein, so dass sie in wenigen Sekunden ohne menschliche Intervention durchgeführt werden, und zwar gemäß den hier angegebenen Lehren, um die Integrität und Sicherheit zu gewährleisten.
Mit Blick auf die beschriebenen beispielhaften Sicherheitstechniken für elektronische Transaktionen gemäß der vorliegenden Erfindung bezieht sich das Folgende darauf, wie tagtägliche finanzielle Transaktionen im Cyberspace übertragen werden können. Es wird beschrieben, wie beispielsweise eine Bank Zinsen auf einen Wert von einem ICON zahlen kann, dessen tatsächlicher Halter nicht bekannt ist, und die realen Einlagen auf einem anonymen Anderkonto liegen. Das Problem betrifft die Tatsache, dass der Erhalt von Zinsen auf Einlagen, und in ähnlicher Weise Dividenden auf Aktien, wahrscheinlich einer Besteuerung unterliegen – aber versteuerbar an wen?
Eine Lösung beinhaltet eine Angabe in der Beschreibung von einem ICON über die Zinsen, die auf eine Einlage gezahlt werden müssen, die durch dieses ICON dargestellt sind, und über den Tag, von dem an die Zinsen durch eine einfache Zinsformel berechnet werden. Die Bank kann entweder die Zinsen auf dem gleichen Anderkonto akkumulieren, und zwar netto unter Zurückbehaltung von Steuern, falls dies so geregelt ist, oder kann Vorkehrungen für die aufgelaufenen Zinsen treffen, die auf Anfrage gezahlt werden müssen.
Der tatsächliche Halter des ICONs kann eine digitale Anmeldung an die Bank richten, um aufgelaufene Zinsen zu konsolidieren oder um ein separates ICON für die Zinsen herausgeben. Auf diese Weise kann der Halter sicherstellen, wenn er bei der geregelten Anfrage zur Konsolidierung der Zinsen sorgfältig ist, dass die Zinsen wieder investiert werden, um in den Genuss des Zinseszinses zu kommen. Darüber hinaus kann ein möglicher Empfänger von einem ICON zur Inspektion der Volltext-Beschreibung von einer Einlage die Menge an aufgelaufenen Zinsen verifizieren, die an ihn übertragen werden, und zwar beim Akzeptieren des sich im Handel befindlichen ICONs, und muss einer möglichen Steuerfälligkeit zustimmen. Solche Berechnungen können automatisch durch ein geeignetes Handelsprogramm durchgeführt werden, das auf seinem Personalcomputer läuft, um das Erfordernis manueller Kalkulationen während des sonst schnellen automatischen Handelns zu vermeiden.
Wenn Nettozinsen auf zurückgehaltene Steuern angefallen sind, kann auch eine weitere Form von ICON durch die Bank herausgegeben werden, das die Menge an zurückgehaltenen Steuern angibt, die gezahlt werden müssen. Tatsächlich können ICONs für irgendeine Form von übertragbaren Steuern erzeugt werden (wie zum Beispiel zurückgehaltene, zu zahlenden Steuern), oder Steuerverbindlichkeiten (wie zum Beispiel unbezahlte Steuern auf eigene Immobilien).
Dividenden auf Obligationen oder Aktien, wie auch Steuern, werden vorzugsweise auf das Anderkonto gezahlt, um das Erfordernis zu vermeiden, die Identität des tatsächlichen Halters kennen zu müssen. Solche Zahlungen können netto auf zurückgehaltene Steuern erfolgen, oder werden alternativ von der Organisation empfangen, und eine Vorkehrung für einen entsprechenden Betrag kann durch die Organisation erfolgen.
Es ist Aufgabe des tatsächlichen Halters des ICONS, das in einem Registrierung abgelegt ist, um eine digitale Nachricht an die Organisation zu senden, die die realen, zugrundeliegenden Anlagen hält, und eine Zahlung bezüglich aufgelaufener Zinsen oder Dividenden durchzuführen. Die Zahlung kann wahlweise von dem Halter in Form eines weiteren elektronisch handelbaren ICONS empfangen werden und wird durch die zahlende Organisation in eine Registrierung bewirkt, die durch den Zahler in der vorstehend beschriebenen sicheren Weise spezifiziert wird.
Wenn die vorliegende Erfindung verwendet wird, ist es ebenfalls möglich, Anlagen zum Kauf oder Tausch anzubieten, wie zum Beispiel auf einem "schwarzen Brett". Auf einem solchen "schwarzen Brett" wird eine kurze Beschreibungen von zum Verkauf angebotenen Gütern oder Anlagen angezeigt, oder der erwünscht oder der angefragten oder angebotenen Preis, wodurch ein Internet-Austausch durchgeführt wird. Personen, die eine Anlage inspizieren wollen, können eine angegebene E-mail-Adresse kontaktieren und entweder mit der betroffenen Person korrespondieren, oder, wenn der angefragte oder angebotene Preis durch die Anlage akzeptiert wird, die in dem Austausch angeboten wird, der Handel kann im Prinzip automatisch durch einen geeignete Software auf einem Personalcomputer durchgeführt werden, der Anlagen inspiziert und deren Akzeptanz und die Gewährleistung der garantierenden Organisation bestätigt. Eine vertrauenswürdige Registrierung gemäß der Erfindung befindet sich physikalisch in einem sicheren Gebiet, führt garantiert nur Operationen innerhalb der Grenzen seiner Sicherheitsprozeduren durch und muss außerdem eine ausreichende Hardware-Redundanz aufweisen, um zuverlässig zu arbeiten und die Möglichkeit zu bieten, gegen Fehler und Ausfälle sicher zu sein, einschließlich vielleicht der Verwendung einer Notstromversorgung. Eine vertrauenswürdige Registrierung soll außerdem ein Abrechnungssystem zur Abrechnung von Kunden zur Speicherung von ICONS und Durchführung von Handelstätigkeiten beinhalten, die Verarbeitungsressourcen konsumieren.
Dies sind genau die Eigenschaften, die ein modernes digitales Telefonvermittlungssystem besitzt, wie zum Beispiel das Ericsson AXE. Dieses System existiert überall in der Welt und wird für lokale Vermittlungen, überregionale Vermittlungen und Mobiltelefon-Vermittlungscenter verwendet. Diese PSTN-Abrechnungen können mit Software-Aktualisierungen ausgestattet sein, die die Funktionen der sicheren, vertrauenswürdigen Registrierungen implementieren, mit dem sich diese Erfindung beschäftigt.
Moderne digitale Mobiltelefone, die zum Beispiel dem europäischen GSM oder dem amerikanischen PCS1900-Standard entsprechen, verwenden Smart-Cards, die geheime Teilnehmer-Kommunikationsschlüssel Teilnehmer enthalten, auf die von außerhalb des Telefons nicht zugegriffen werden können. Sie enthalten außerdem einen Lese/Schreib-Speicher zur Speicherung häufig verwendeter Telefonnummern und ähnlichem. Diese Smart-Cards können dazu ausgestaltet werden, um verschlüsseltes virtuelles Bargeld gemäß der Erfindung zu speichern und aufzunehmen. Die Smart-Cards sind aus den Telefonen herausnehmbar und können in anderen Telefonen oder Vorrichtungen installiert werden, wie zum Beispiel ein PC, der mit einer geeigneten Schnittstelle ausgestaltet ist. Die gleiche Smart-Card kann das öffentliche bzw. private Schlüsselpaar des Teilnehmers enthalten, das für die Absicherung von Transaktionen verwendet wird, die entweder drahtlos, beispielsweise über ein zellulares Telefonnetzwerk, oder über das Internet durchgeführt werden. Durch Entfernen einer Smart-Card macht der Teilnehmer den Anschluss "sicher", so dass keine andere Person sie benutzen kann, um sich als der Teilnehmer auszugeben. Die Smart-Card kann daher drahtlose Downloads von virtuellem Bargeld über einen digitalen zellularen Telefonanruf empfangen oder es downloaden, wenn sie in einen heimischen PC eingesteckt wird. Die Smart-Card kann über das tragbare zellulare Telefon außerdem virtuelles Bargeld an ein Ladenkassen-Terminal auszahlen, und zwar beispielsweise durch Aufleuchten einer LED an einem Laserscanner an dem Ladenkassen-Terminal, wobei das Licht mit Bits oder Barcodes mit einer Rate moduliert wird, die von dem Ladenkassen-Terminal erwartet wird. Das zellulare Telefon kann außerdem mit einem Barcode-Scanner ausgestattet sein, um Zeitungs-Rabatt-Coupons in den Speicher einzulesen, oder sein Mikrophon verwenden, um Fernsehwerbung zu hören, wobei akustische Modemsignale ausgestrahlt werden können, um digitale Rabatt-Coupons zu versenden, wobei das digitale Signal des Telefons dann solche Modemsignale verschlüsselt und die digitalen Coupons in dem Speicher der Smart-Card speichert, um sie eventuell in einem Ladengeschäft in elektronischer Kommunikation mit einem Ladenkassen-Terminal zu verwenden.
Es wurde somit vorstehend erläutert und beschrieben, wie ein neuer Typ von elektronischen Geschäften im Internet eingerichtet werden kann, der den Vorteil von Geschwindigkeit, reduzierten Ausführungskosten durch die Vermeidung manueller Intervention und der erfindungsgemäßen Verwendung von Verschlüsselungstechniken mit Hilfe eines öffentlichen Schlüssels, um Handelsaktionen in beiden Richtungen sicher zu machen, was ein Vorteil gegenüber Methoden gemäß Stand der Technik ist, die lediglich die Zahlung an den Verkäufer garantiert haben, d.h. lediglich eine Richtung des Handels. Die Erfindung garantiert umgekehrt eine Sicherheit, die durch die Erfindung zur Verfügung gestellt wird, wodurch ermöglicht wird, dass Waren oder Anlagen die verkauft werden, digital durch den Käufer inspiziert werden, und zwar vor dem Kauf, um zu verifizieren, dass eine Organisation, der er vertraut, hinter dem beanspruchten Wert steht, und außerdem ermöglicht wird, dass der Verkäufer auf digital Weise die Mittel inspiziert, die von dem Käufer im Austausch angeboten werden.
Viele Variationen und Anwendungen der Erfindung können von dem Fachmann auf dem Gebiet von Verschlüsselungs- und Finanzsystemen durchgeführt werden, wobei diese Variationen in den Schutzbereich der Erfindung fallen, der durch die nachfolgenden Ansprüche definiert ist.

Claims

Verfahren zum Registrieren eines Bitmusters, welches eine Anlage darstellt, mit den Schritten: Erzeugen einer Beschreibung der Anlage; Verschlüsseln der Beschreibung unter Verwendung eines Geheimschlüssels einer Organisation (20); Verschlüsseln der verschlüsselten Beschreibung unter Verwendung eines Halters (31) des öffentlichen Schlüssels der Anlage, um das Bitmuster zu erzeugen; Übertragen des Bitmusters an eine Registrierung (40), wobei die Registrierung das Bitmuster speichert, welches die Anlage darstellt; Entschlüsseln der Beschreibung unter Verwendung des öffentlichen Schlüssels der Organisation (20); und Authentifizieren der Herkunft von der Beschreibung.
Verfahren nach Anspruch 1, bei welchem der Schritt des Authentifizierens ferner den Schritt enthält: Durchführen einer zyklischen Redundanzprüfung der entschlüsselten Beschreibung.
Verfahren nach Anspruch 1 oder 2, bei welchem der Schritt des Übertragens ferner den Schritt enthält: Übertragen einer Identität von der Organisation (20) zusammen mit dem Bitmuster.
Verfahren nach Anspruch 1, 2 oder 3, bei welchem der Schritt des Entschlüsselns ferner den Schritt enthält: Abfragen des öffentlichen Schlüssels der Organisation (20) bei der Registrierung (40) unter Verwendung der übertragenen Identität.
Verfahren nach Anspruch 1, welches ferner die Schritte enthält: Erzeugen eines zyklischen Redundanzprüfungs-Kodes unter Verwendung der Beschreibung; Einbeziehen des zyklischen Redundanzprüfungs-Kodes als Teil des an die Registrierung (40) übertragenen Bitmusters.
Verfahren nach Anspruch 5, bei welchem der Schritt des Erzeugens ferner den Schritt enthält: Verwenden einer nicht linearen Kode-Berechnung um den zyklischen Redundanzprüfungs-Kode zu erzeugen.
Verfahren nach Anspruch 1, bei welchem sich die Registrierung (40) bei einer Telekommunikationsvermittlung befindet.
Verfahren zum Handeln elektronisch dargestellter Anlagen mit den Schritten: Senden durch eine erste Partei (31) von einer Anfrage an eine erste Registrierung (40), welche eine erste elektronisch dargestellte Anlage zurückzieht; Übertragen durch die erste Registrierung von einer Kopie der ersten elektronisch dargestellten Anlage an die erste Partei; Kennzeichnen durch die erste Registrierung (40) der ersten elektronisch dargestellten Anlage als nicht erhältlich; Entschlüsseln durch die erste Partei (31) der ersten elektronisch dargestellten Anlage unter Verwendung des Geheimschlüssels der ersten Partei; Wiederentschlüsseln durch die erste Partei (31) der ersten elektronisch dargestellten Anlage unter Verwendung eines öffentlichen Schlüssels der zweiten Partei (32); und Übertragen der ersten elektronisch dargestellten Anlage an die zweite Partei (32).
Verfahren nach Anspruch 8, welches ferner die Schritte enthält: Entschlüsseln durch die zweite Partei (32) der ersten elektronisch dargestellten Anlage unter Verwendung des Geheimschlüssels der zweiten Partei (32); Entschlüsseln durch die zweite Partei (32) der ersten elektronisch dargestellten Anlage unter Verwendung eines ersten garantieren öffentlichen Schlüssels der Organisation; und Bewerten einer Beschreibung der ersten elektronisch dargestellten Anlage.
Verfahren nach Anspruch 9, welches ferner die Schritte enthält: Senden durch die zweite Partei (32) von einer Anfrage an eine zweite Registrierung, welche eine zweite elektronisch dargestellte Anlage zurückzieht; Kennzeichnen durch die zweite Registrierung der zweiten elektronisch dargestellten Anlage als nicht erhältlich; Entschlüsseln durch die zweite Partei (32) der zweiten elektronisch dargestellten Anlage unter Verwendung des Geheimschlüssels der zweiten Partei; Wiederentschlüsseln durch die zweite Partei (32) der zweiten elektronisch dargestellten Anlage unter Verwendung des öffentlichen Schlüssels der ersten Partei; und Übertragen der zweiten elektronisch dargestellten Anlage an die erste Partei (31).
Verfahren nach Anspruch 10, welches ferner die Schritte enthält: Entschlüsseln durch die erste Partei (31) der zweiten elektronisch dargestellten Anlage unter Verwendung des Geheimschlüssels der ersten Partei; Entschlüsseln durch die erste Partei (31) der zweiten elektronisch dargestellten Anlage unter Verwendung eines zweiten garantierten öffentlichen Schlüssels der Organisation (30); und Bewerten einer Beschreibung der zweiten elektronisch dargestellten Anlagen.
Verfahren nach Anspruch 11, welches ferner die Schritte enthält: Übertragen der zurückgezogenen Version von der ersten elektronisch dargestellten Anlage, wobei die erste elektronisch dargestellte Anlage durch den öffentlichen Schlüssel der zweiten Partei wiederverschlüsselt ist, und eines Bitmusters, welches im Austausch von der zweiten Partei (32) erwartet wird, durch die erste Partei (31) an die erste oder zweite Registrierung; und Übertragen der zurückgezogenen Version von der zweiten elektronisch dargestellten Anlage, wobei die zweite elektronisch dargestellte Anlage durch den öffentlichen Schlüssel der ersten Partei wiederverschlüsselt ist, und eines Bitmusters, welches im Austausch von der ersten Partei (31) erwartet wird, durch die zweite Partei (32) an dieselbe Registrierung aus der ersten und zweiten Registrierung.
Verfahren nach Anspruch 12, welches ferner die Schritte enthält: Vergleichen des Bitmusters, welches im Austausch durch die zweite Partei (32) erwartet wird, mit der zurückgezogenen Version der zweiten elektronisch dargestellten Anlage; Vergleichen des Bitmusters, welches im Austausch durch die erste Partei (31) erwartet wird, mit der zurückgezogenen Version der ersten elektronisch dargestellten Anlage; und Ausführen des Handels, wenn beide der Vergleichsschritte zu einer Übereinstimmung durch Löschen der markierten ersten und zweiten elektronisch dargestellten Anlage jeweils in der ersten und zweiten Registrierung führen, und Ersetzten derselben jeweils durch die erste elektronisch dargestellte Anlage, welche durch den öffentlichen Schlüssel der zweiten Partei wiederverschlüsselt ist, und die zweite elektronisch dargestellte Anlage, wobei die zweite elektronisch dargestellte Anlage durch den öffentlichen Schlüssel der ersten Partei wiederverschlüsselt ist.
Verfahren nach Anspruch 8, bei welchem die erste und zweite Registrierung eine selbe Datenbank enthalten.
Verfahren nach Anspruch 11, bei welchem die erste und zweite garantierende Organisation (20, 30) eine selbe garantierende Organisation sind.
Verfahren zum Bereitstellen von sicheren elektronischen Handeln zwischen einer ersten Partei (31), welche einem Handel mit einer ersten Anlage zustimmt, und einer zweiten Partei (32), welche einem Handel mit einer zweiten Anlage zustimmt, und zwar als Gegenleistung für die erste Anlage, mit den Schritten: Kommunizieren durch die erste Partei (31) mit einer ersten Finanzorganisation (20) um ein erstes Datensymbolmuster zu erlangen, welches die erste Anlage beschreibt, wobei das erste Symbolmuster unter Verwendung eines ersten Kodeschlüssels verschlüsselt wird, welcher nur der ersten Organisation (20) bekannt ist, und ferner unter Verwendung eines zweiten Kodeschlüssels verschlüsselt wird, welcher durch die erste Partei (31) zugeführt wird; Kommunizieren durch die zweite Partei (32) mit einer zweiten Finanzorganisation (30) um ein zweites Datensymbolmuster zu erlangen, welches die zweite Anlage beschreibt, wobei das zweite Symbolmuster unter Verwendung eines dritten Kodeschlüssels verschlüsselt wird, welcher nur der zweiten Organisation (30) bekannt ist, und ferner unter Verwendung eines vierten Kodeschlüssels verschlüsselt wird, welcher durch die zweite Partei (32) zugeführt wird; Entschlüsseln des ersten Symbolmusters durch die erste Partei (31) unter Verwendung eines Kodeschlüssels, welcher invers zum zweiten Kodeschlüssel ist, welcher nur der ersten Partei (31) bekannt ist, und Wiederverschlüsseln des ersten Symbolmusters unter Verwendung des vierten Kodeschlüssels; Entschlüsseln des ersten Symbolmusters durch die zweite Partei (32) unter Verwendung eines Kodeschlüssels, welcher invers zum vierten Codeschlüssel ist, welcher nur der zweiten Partei (32) bekannt ist, und Wiederverschlüsseln des zweiten Symbolmusters unter Verwendung des zweiten Kodeschlüssels; Übertragen des wiederverschlüsselten ersten Symbolmusters durch die erste Partei (31) an eine Registrierung (40); Übertragen des wiederverschlüsselten zweiten Symbolmusters durch die zweite Partei (32) an die Registrierung (40); und Austauschen des wiederverschlüsselten ersten und zweiten Symbolmusters durch elektronische Übertragung jeweils zwischen der Registrierung und der ersten Partei (31) und zwischen der Registrierung und der zweiten Partei (32).
Verfahren nach Anspruch 16, bei welchem die erste und zweite Finanzorganisation (20, 30) die gleiche Finanzorganisation sind.
Verfahren nach Anspruch 16, bei welchem der erste und dritte Kodeschlüssel die gleichen sind und ihre jeweiligen inversen Schlüssel ebenfalls die gleichen sind.
Verfahren nach Anspruch 16, bei welchem mindestens einer der Kodeschlüssel eine erste und zweite Nummer enthält, wobei die erste Nummer ein Produkt aus "n" großen Primzahlen P1, P2 ... P(n) ist, und die zweite Nummer ein Faktor des Wertes 1 + (P1 – 1)(P2 – 1) ... (P(n) – 1) ist, wobei "n" mindestens gleich zwei ist.