[go: up one dir, main page]

DE69620460T2 - Sicherer anonymer informationsaustausch in einem netzwerk - Google Patents

Sicherer anonymer informationsaustausch in einem netzwerk

Info

Publication number
DE69620460T2
DE69620460T2 DE69620460T DE69620460T DE69620460T2 DE 69620460 T2 DE69620460 T2 DE 69620460T2 DE 69620460 T DE69620460 T DE 69620460T DE 69620460 T DE69620460 T DE 69620460T DE 69620460 T2 DE69620460 T2 DE 69620460T2
Authority
DE
Germany
Prior art keywords
sig
tmp
sender
public key
offer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE69620460T
Other languages
English (en)
Other versions
DE69620460D1 (de
Inventor
Christian Hauser
Gene Tsudik
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
International Business Machines Corp
Original Assignee
International Business Machines Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by International Business Machines Corp filed Critical International Business Machines Corp
Application granted granted Critical
Publication of DE69620460D1 publication Critical patent/DE69620460D1/de
Publication of DE69620460T2 publication Critical patent/DE69620460T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/388—Payment protocols; Details thereof using mutual authentication without cards, e.g. challenge-response
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/606—Protecting data by securing the transmission between two devices or processes
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/12—Payment architectures specially adapted for electronic shopping systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2103—Challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42—Anonymization, e.g. involving pseudonyms

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Accounting & Taxation (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Finance (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer And Data Communications (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

    TECHNISCHES GEBIET
  • Die vorliegende Erfindung liegt im Bereich der (Computernetzverwaltung, insbesondere betrifft sie die technische Realisierung eines Geschäftsprozesses in einer Computernetzumgebung. Die hier angesprochenen Prozesse sind von dem Typ, bei dem zwei oder mehr Teilnehmer legitim anonym kommunizieren möchten, oftmals bevor sie einen Handel besprechen oder abschließen. Die Erfindung betrifft nicht einen Geschäftsprozess an sich, sondern zugrundeliegende technische Verfahren, die zum Ausführen des einen oder anderen Geschäftsprozesses verwendet werden. Insbesondere kann das erfundene Verfahren für anonyme Gebote oder Versteigerungen im elektronischen Handel verwendet werden.
    • GRUNDLAGEN DER ERFINDUNG
  • Offensichtlich wachsen sowohl die Bedeutung als auch die Verbreitung des elektronischen Handels weiterhin; ein eindrucksvolles Beispiel ist das Internet. In einer solchen Umgebung - analog zum herkömmlichen "nichtelektronischen Handel" - wird der Verbraucherdatenschutz ein Hauptanliegen.
  • Die bloße Tatsache, dass der elektronische Handel über eine bestehende offene Netzwerkinfrastruktur wie das Internet durchgeführt wird, läuft dem Datenschutz des Verbrauchers zuwider. Oftmals gibt es rechtmäßige Gründe für einen Teilnehmer, zumindest während einer Anfangsphase einer sich entwickelnden (Geschäfts-) Beziehung mit einem anderen Teilnehmer anonym zu bleiben. Es wird für einen Teilnehmer jedoch sehr schwierig oder sogar unmöglich, seine Identität zu schützen, wenn er sich über ein offenes Netzwerk an einen anderen Teilnehmer wendet. Und diese Frage der Anonymität wird selbstverständlich noch komplexer, wenn beide kommunizierenden Teilnehmer anonym bleiben möchten.
  • Der Grund hierfür besteht im Wesentlichen in der Endpunkt-zu- Endpunkt-Beschaffenheit von Anwendungsprotokollen, die in erster Linie als Mittel für den elektronischen Handel verwendet werden: World-Wide Web (WWW), E-Mail, File Transfer (FTP) und andere.
    • Stand der Technik
  • Die oben erwähnte Frage der Anonymität wurde bereits früher angegangen: die US-Patentschrift 5 375 055 von Dunne et al. ist ein Beispiel, wenn auch in einer anderen Umgebung als die vorliegende Erfindung und folglich nur von begrenzter Bedeutung. Das Patent von Dunne beschreibt ein elektronisches Maklersystem (brokerage system) in einem Kommunikationsnetz, das Händler miteinander verbindet, die mit Finanzmarktinstrumenten (financial instruments) handeln. In diesem computerunterstützten System werden anonyme Preisangaben (price quotes) selektiv gemäß eingerichteten Kreditgrenzen verteilt. Dieses System enthält sozusagen eine zentrale Instanz, die alle Informationen verfügbar hat, jedoch nur einen Teil von diesen an die angeschlossenen Teilnehmer überträgt.
  • Bereits von Anfang an ist dies gänzlich verschieden vom Ziel der vorliegenden Erfindung, das darin besteht, ein sicheres Verfahren bereitzustellen, das es einem Teilnehmer, z. B. einem Benutzer, einem Verbraucher oder einem Bieter (bidder) ermöglicht, Angaben/Gebote/Angebote von einem anderen Teilnehmer, z. B. einem voraussichtlichen Händler, ohne Verlust von seinem Datenschutz, d. h. anonym, über ein offenes Netzwerk zu erhalten.
  • Ein anderer spezifischer Lösungsweg wird in der US- Patentschrift 5 420 926 von Low et al. beschrieben. Dieses Patent beschreibt Verfahren zum Ausführen von Kreditkartentransaktionen, ohne der die Kreditkarte bereitstellenden Institution den Gegenstand der Transaktion zu offenbaren. Die Verfahren beinhalten die Verwendung eines vermittelnden gerufenen Kommunikationsaustauschs (called communication exchange) zum Austausch von Informationen und Geld, ohne dass das Ziel für die Übertragung die Quelle der Informationen oder des Geldes kennt. Eine Verschlüsselung mit öffentlichem Schlüssel (public key encryption) wird verwendet, so dass jeder Teilnehmer an der Transaktion und am Kommunikationsaustausch nur die Informationen lesen kann, die er für seine Rolle bei der Transaktion benötigt.
  • Obwohl das Patent von Low ein Verfahren zum Verbergen von Transaktionseinzelheiten vor den betroffenen Teilnehmern beschreibt, konzentriert es sich auf das Ziel, jeden der entsprechenden Teilnehmer darauf zu beschränken, nur die Mindestmenge an Informationen zu erhalten, die zum Ausführen der Transaktion benötigt werden. Dies ist im Allgemeinen für die vorliegende Erfindung von Bedeutung, die im Patent von Low vorgeschlagenen Verfahren lösen jedoch nicht das Problem des anonymen Bietens (anonymous bidding), das den Austausch von genügend Detailinformationen zwischen zwei oder mehr Teilnehmern mit lediglich einem Minimum an Vermittlungstätigkeit zum Lösen der Anonymitätsfrage erforderlich macht.
  • Ein weiteres Beispiel für eine Technologie, die die Frage von Datenschutz und Anonymität von "elektronischen Verbrauchern" oder Teilnehmern angeht, wobei ein gewisser Grad an elektronischem Datenschutz bereitgestellt wird, ist das so genannte elektronische/digitale Bargeld (electronic/digital cash), wie z. B. von D. Chaum et al. in "Untraceable Electronic Cash" in Proceedings of CRYPTO'88, August 1988, Kalifornien, USA, beschrieben wird.
  • Hier unterscheidet sich die Situation wiederum von der vorliegenden Erfindung, da die zu übertragenden Informationen auf finanzielle Transaktionen begrenzt sind, die sicher ausgeführt werden müssen. Dies ermöglicht einen eng formalisierten Prozess mit einem Minimum an zu betrachtendem oder zu bearbeitendem "freiem Text". Andererseits muss die vorliegende Erfindung praktisch eine Kommunikation mit freiem Text ermöglichen, zumindest von der Benutzerseite aus. Dies bringt offensichtlich zusätzliche Probleme mit sich, die durch Realisierungen von digitalem Bargeld, wie die oben zitierte, nicht gelöst werden.
  • Einige Fragen der Angreifbarkeit von Verschlüsselungssystemen mit öffentlichem Schlüssel werden in einer Veröffentlichung von Dorothy E. Denning: "Digital Signatures with RSA and Other Public-Key Cryptosystems" in Communications of the ACM, April 1984, Band 27, Nr. 4, angesprochen. Protokolle und ihre Schwachstellen hinsichtlich möglicher Angriffe werden im Einzelnen und mit Bezugnahme auf andere Techniken erläutert.
  • Obwohl diese Veröffentlichung insofern mit der vorliegenden Erfindung in Zusammenhang steht, als eine Anzahl von Vorgehensweisen zum Verbergen von Nachrichten erläutert werden, konzentriert sie sich auf die Sicherheit von Systemen vor Angriffen durch Kennzeichnen von Eigenschaften, die von einem sicheren Signatursystem erfüllt werden müssen. Da Denning sich auf spezifische Eigenschaften von digitalen Signatursystemen konzentriert, spricht sie folglich weder ein vollständiges System an, das für spezifische Geschäftszwecke hilfreich ist, z. B. Bieten oder Versteigern, noch stellt sie ein solches System vor, wie es bei der vorliegenden Erfindung der Fall ist.
  • Ein Micropayment-System für Informationsgüter wird von B. Cox et al.: "NetBill Security and Transaction Protocol" in Proceedings of the First USENIX Workshop on Electronic Commerce - 11. bis 12. Juli 1995, New York, beschrieben. Diese Veröffentlichung wird als der neueste Stand der Technik angesehen. Dieses System konzentriert sich auf ein unterteilbares, zertifiziertes Lieferverfahren (an die Verbraucher) für die Informationsgüter, um die zugeordneten Zahlungen zu sichern, und beinhaltet unter anderen Merkmalen, einen Mechanismus zum Erstellen von Pseudonymen, um die Identität dieser Verbraucher zu schützen.
  • Bereits von Anfang an ist dies ein asymmetrisches System, das es nur einem angegeben Teilnehmer der Transaktion ermöglicht, anonym zu bleiben. Dies steht bereits im Gegensatz zum Konzept der vorliegenden Erfindung, die es jedem Teilnehmer ermöglichen muss, seine Identität zu verbergen, falls dies gewünscht wird. Diese "symmetrische" Vorgehensweise, wie sie weiter unten in dieser Beschreibung angesprochen wird, bleibt von diesem Stand der Technik unberührt und ungelöst. Außerdem muss darauf hingewiesen werden, dass in der vorliegenden Erfindung andere Geschäftsvorgänge als die Lieferung von Informationen und die dieser Lieferung zugeordnete Zahlung angesprochenen werden, z. B. anonymes Bieten oder Versteigern.
    • Aufgaben der Erfindung
  • Die Beschaffenheit der meisten gegenwärtigen Netzprotokolle und -anwendungen ist von Anfang an ungünstig für den Datenschutz. Die große Mehrheit von verwendeten Protokollen hat eines gemeinsam: sie übertragen zuverlässig Endpunkt- Kennzeichnungsinformationen. "Endpunkt" bedeutet in diesem Zusammenhang ein Benutzer (mit einer ID), eine Netzadresse oder ein Organisationsname. Beispielsweise überträgt die elektronische Post (E-Mail) üblicherweise die Adresse eines Senders in ihtem (ihren) Vorsatz (Vorsätzen). File Transfer (z. B. FTP), Fernanmeldung (remote login) (z. B. TELNET) und Hypertext-Browser (z. B. WWW) enthüllen Adressen, Hostnamen und IDs ihrer Benutzer. Dies ist bei den meisten Anwendungen kein Problem.
  • Wie oben erwähnt wurde, gibt es jedoch legitime Gründe, warum ein Benutzer seinen Datenschutz nicht verlieren möchte, z. B. beim Ausführen einer harmlosen Tätigkeit, wie "Durchblättern" (browsing) eines Katalogs über WWW oder Einziehen von Erkundigungen über Waren per E-Mail. Insbesondere in letzterem Fall gibt es oftmals vernünftige wirtschaftliche Gründe, warum ein potentieller Kunde seine Identität nicht preisgeben möchte.
  • Wird dies als Ausgangspunkt genommen, ist die Hauptaufgabe dieser Erfindung die Bereitstellung eines Verfahrens, das einen solchen anonymen Datenaustausch ermöglicht, z. B. ein Verfahren, wie ein voraussichtlicher Kunde Gebote oder Angebote von voraussichtlichen Händlern erhalten kann, ohne seine Identität preiszugeben. Ein anderes Beispiel ist das anonyme Bieten eines Benutzers in einer über ein Netzwerk durchgeführten Versteigerung.
  • Weiter in diese Richtung geht eine andere Aufgabe der Erfindung, ein Verfahren bereitzustellen, durch das der anbietende Händler ebenfalls selektiv auf seinen Wunsch seinen Datenschutz bis zu einem gewissen Punkt des üblichen Verkaufsprozesses - oder sogar während des gesamten Prozesses - wahren kann.
  • Eine besondere Aufgabe ist die Bereitstellung eines Systems, das widerstandsfähig gegenüber falschen Darstellungen sowohl vonseiten des Senders (Bieter oder Kunde) als auch vonseiten des Empfängers (Auktionator oder Händler) ist.
  • Noch eine weitere Aufgabe ist die Verwendung und Nutzung bekannter Dienste, die zu diesem Zweck bereits in vielen Netzwerken verfügbar sind, und folglich die Herabsetzung des zusätzlichen Aufwands und der Ausgaben zur Realisierung der Erfindung auf ein Minimum.
    • ZUSAMMENFASSUNG DER ERFINDUNG
  • In einem Netzwerk, das eine Möglichkeit zur anonymen Kommunikation und eine Infrastruktur mit öffentlichem Schlüssel und vielleicht sogar eine Zertifizierung für öffentliche Schlüssel (PKC) bereitstellt, stellt die Erfindung ein Verfahren für die gewünschte sichere, jedoch anonyme Kommunikation bereit. Mit kurzen Worten, ein Sender erstellt anfänglich eine verschlüsselte Anforderung, die eine "Frage zu einem Thema" (subject question) und seine digitale Signatur enthält. Diese Anforderung wird anonym zu einem oder mehreren Empfängern gesendet. Jeder Empfänger erstellt sodann eine verschlüsselte Antwort, die eine "Antwort zu einem Thema" (subject answer) und seine digitale Signatur enthält. "Frage zu einem Thema" und "Antwort zu einem Thema" bezeichnen entsprechende Paare von Informationssätzen, die in dem bestimmten Geschäftsvorgang verwendet werden, z. B. eine Beschreibung von bestimmten Waren und das entsprechende Angebot von einem Händler oder die Anforderung für einen bestimmten Dienst und das entsprechende Angebot von einem Dienstleister (service provider) oder das Gebot eines Bieters in einer Auktion und die Antwort des Auktionators.
  • Die Erfindung wird durch das Beispiel des anonymen Bietens (das üblicherweise einen Kauf vordatiert) ausführlicher erläutert.
  • Voraussetzungen hierfür sind die Möglichkeit einer anonymen Kommunikation und eine Infrastruktur für öffentliche Schlüssel, wie oben erwähnt wird. Der Prozess wird von einem Sender eingeleitet, normalerweise einem voraussichtlichen Kunden oder Verbraucher, der eine Angebotsanforderung mit einer unverschlüsselten Beschreibung des gewünschten Produktes oder Dienstes und seiner digitalen Signatur erstellt. Es muss klar sein, dass eine solche digitale Signatur allein die Identität des Senders nicht enthüllt. Diese Angebotsanforderung wird über das Netzwerk anonym zu einem oder mehreren ausgewählten Empfängern gesendet oder sogar rundgesendet. Empfänger sind Händler, Dienstleister oder dergleichen. Da die Angebotsanforderung selbst in unverschlüsselter Sprache erstellt wird, kann sie jeder Empfänger lesen und entscheiden, ob er ein Gebot macht. Falls sich ein Empfänger dazu entscheidet, erstellt er eine Antwort mit einer Angebotsbeschreibung und seiner digitalen Signatur, die die digitale Signatur des Senders "enthält", und sendet sie per E-Mail zum Sender. Der öffentliche Schlüssel des Empfängers muss möglicherweise ebenfalls gesendet werden, falls angenommen werden muss, dass der Sender keinen Zugriff darauf hat. Aus der empfangenen Nachricht und dem öffentlichen Schlüssel des Empfängers kann der Sender nun zwei Werte (einen ersten und einen zweiten) berechnen, deren Übereinstimmung die Echtheit des Angebots anzeigt. So viel zum Prozess des Bietens.
  • Für Fachleute muss klar sein, dass die Erfindung sogar noch vorteilhafter in einem Netzwerk realisiert werden kann, das eine Zertifizierung für öffentliche Schlüssel (PKC) bereitstellt.
  • Außerdem kann ein tatsächlicher Kauf, der auf den obigen Prozess des Bietens folgt, auf dieselbe Weise organisiert werden. In diesem Fall verwendet der Sender ebenfalls die vorhandene Infrastruktur für öffentliche Schlüssel. Der Sender, d. h. der voraussichtliche Kunde, sendet einen Nachweis zum Händler, der seinerseits den öffentlichen Schlüssel des Senders verwendet, um einen dritten Wert zu berechnen, und einen vierten Wert ermittelt, indem er eine Hash-Funktion auf bestimmte Teile der empfangenen Nachricht anwendet, und indem er diese beiden letzteren Werte vergleicht, stellt er die Echtheit des Angebots fest. Dies macht das erfundene Verfahren widerstandsfähig gegen Betrug durch Sender oder Empfänger.
    • KURZE BESCHREIBUNG DER ZEICHNUNGEN
  • In den begleitenden Zeichnungen zeigen
  • Fig. 1 die allgemeine Gestaltung eines Netzwerkes, in dem die Erfindung verwendet werden kann;
  • Fig. 2A den Datenaustausch gemäß einem ersten Teil der Erfindung;
  • Fig. 2B den Datenaustausch gemäß einem zweiten Teil der Erfindung;
  • Fig. 3 den Datenaustausch gemäß einer Änderung der Erfindung;
    • Bevorzugte Ausführungsformen
  • Das im Folgenden beschriebene Verfahren ist ein generischer Lösungsweg zum Erhalten von Geboten oder Angeboten von "elektronischen Händlern" ohne irgendeinen Verlust des Datenschutzes des Verbrauchers. Als Erweiterung bietet es Schutz für die Händler, indem es ihnen ermöglicht, für echte Gebote von Verbrauchern anzunehmen und bei Bedarf einen Verbraucher einem zuvor ausgegebenen blinden Gebot zuverlässig zuzuordnen. Außerdem können Händler Wiederholungen oder Duplikate von bereits bearbeiteten Geboten erkennen.
  • Das Verfahren zum anonymen Bieten gemäß dieser Realisierung der Erfindung benötigt gewisse grundlegende Sicherheitsdienste für seinen ordnungsgemäßen Betrieb: 1. eine Vorkehrung für eine anonyme nachrichtenorientierte (message-based) Kommunikation und 2. eine Infrastruktur für öffentliche Schlüssel mit Zertifizierung (PKC). Beides wird unten kurz angesprochen.
  • Als Erstes wird ein anonymer Kommunikationskanal benötigt. Zu Beginn ist der anonyme Kommunikationskanal notwendig, um die Anonymität des Senders, d. h. in diesem Zusammenhang des voraussichtlichen Verbrauchers, zu wahren. Außerdem wird er verwendet, um den Standort des Senders zu verbergen, da die Identität des Senders und sein Standort oftmals eng miteinander verbunden sind.
  • Unabhängig davon, ob eine synchrone oder asynchrone Kommunikation verwendet wird, gibt es eine einfache Möglichkeit, um eine Art von Anonymität zu erreichen. Falls der Sender, d. h. der Verbraucher, Kunde oder Bieter, von einer öffentlichen Datenstation aus arbeitet, ermöglicht die Adresse von letzterer nicht die Identifizierung des sie verwendenden Teilnehmers und gewährleistet folglich Anonymität.
  • Komplexer, aber sicherer sind Netzwerke, die ein spezielles Hilfsprogramm für eine solche anonyme nachrichtenorientierte Kommunikation bereitstellen. Sowohl bei synchronen (z. B. WWW) als auch bei asynchronen (z. B. herkömmliches E-Mail) Netzwerken sind geeignete Hilfsprogramme verfügbar und bekannt. Im Falle einer synchronen Kommunikation kann ein protokollspezifischer Anonymisierer (anonymizer) verwendet werden, der im Wesentlichen ein Programm ist, das als Kanal (conduit) zwischen dem realen Sender und dem Empfänger fungiert, wobei die Identität des Senders verborgen wird, indem z. B. ein zufälliger Alias-Name verwendet wird.
  • Ein Beispiel für einen synchronen Anonymisierer kann problemlos auf einem Netzwerk-Gateway/Firewall eingerichtet werden, beispielsweise dem IBM "NetSP Secured Gateway for AIX", kurz "SNG" in den folgenden Veröffentlichungen von IBM:
  • - SC31-8113 - NetSP SNG Installation, Configuration and Administration Guide, und
  • - GG24-2577 - Implementing an Internet Firewall with NetSP SNG.
  • Eine typische Firewall anonymisiert bereits ausgehenden Datenverkehr, indem Quellenadressen mit ihrer eigenen Adresse überschrieben werden. Es ist lediglich notwendig, dasselbe für eingehenden Datenverkehr zu ermöglichen, d. h., die Quellenadressen mit der Netzadresse der Firewall zu überschreiben, um daraus einen Anonymisierer zu machen.
  • Im Falle einer asynchronen Kommunikation kann ein anonymer Vermittlungsdienst (relay service) verwendet werden. Ein Beispiel ist der anonyme Pseudonymserver (remailer), eine anonyme Vermittlung für E-Mail. Während Anonymisierer für synchrone Kommunikation noch nicht weit verbreitet sind, sind anonyme Pseudonymserver im globalen Internet gut bekannt; es sind viele verfügbar, die unterschiedliche Grade an Anonymität und Interoperabilität bieten.
  • Ein Beispiel für einen funktionierenden anonymen Pseudonymserver ist der in Finnland von J. Helsingius betriebene PENET-Dienst. Ein anderer ist der von L. Cottrell vertriebene und von mehreren Standorten in den USA betriebene Pseudonymserver MIXMASTER.
  • Der Pseudonymserver PENET ist aus dem World-Wide Web, WWW, unter "http://www.penet.fi" erhältlich. Die Informationen unter dieser Adresse beinhalten eine Veröffentlichung von J. Helsingius über Pseudonymserver mit dem Titel "Penet Anonymous Remailer Service" und Adressen von Pseudonymservern. Der Pseudonymserver MIXMASTER ist über das WWW unter "http://obscura.com/loki/remailer-essay.html" erhältlich. Eine Veröffentlichung von L. Cottrell über Pseudonymserver mit dem Titel "Mixmaster and Remailer Attacks" und mehr Informationen über anonyme Pseudonymserver sind unter dieser WWW-Adresse zu finden.
  • Beim anonymen Bieten gibt es im Allgemeinen fast keine Begrenzungen hinsichtlich der Art der verwendeten Hilfsprogramme zum Anonymisieren. Die einzige Ausnahme ist das Erfordernis einer Zwei-Wege-Kommunikation; mit anderen Worten, es muss für einen voraussichtlichen Verbraucher, Kunden oder Bieter (Sender) möglich sein, eine anonyme Anforderung zu einem voraussichtlichen Händler oder Auktionator zu senden, und für den letzteren, dem Sender zu antworten. Hierfür gibt es mehrere Möglichkeiten. Ein von einfachen bestehenden Pseudonymservern verwendetes Verfahren ist die Einrichtung einer Tabelle, die reale E-Mail-Adressen auf Alias-Namen abbildet; auf diese Weise kann ein Empfänger (Händler) dem Alias-Namen antworten, der anschließend vom anonymen Pseudonymserver in eine reale E-Mail-Adresse übersetzt wird. Außerdem gibt es sicherere und aufwendigere Verfahren, beispielsweise muss der Sender zuvor einen geheimen Rückkehrpfad berechnen, der sodann vom Empfänger "blind" verwendet wird. Es genügt, darauf hinzuweisen, dass ein Fachmann problemlos ein Anonymitätssystem auswählen kann, das dem Bedarf gerecht wird, solange es verfügbar ist. Beispiele für Lösungen für den Bedarf an Anonymität sind in D. Chaum, "Untraceable Electronic Mail, Return Addresses and Digital Pseudonymes" in Communications of the ACM, Band 24, Nr. 2, Februar 1981, und C. Gulcu und G. Tsudik, "Mixing Email with Babel" in Proceedings of ISOC Symposium on Network and Distributed Systems Security, Februar 1996, San Diego, Kalifornien, USA, zu finden.
  • Das zweite Erfordernis ist eine Infrastruktur für öffentliche Schlüssel. Die meisten sind als Zertifizierungsverfahren für öffentliche Schlüssel (PKC) gestaltet. Solche PKCs sind heutzutage in Netzwerken verfügbar, wobei sie vielfältigen Zwecken dienen. Gegenwärtig liegt ihre bekannteste Verwendung im Bereich von sicherer elektronischer Post. Zwei weit verbreitete Beispiele sind Privacy-Enhanced Mail (PEM) und Pretty Good Privacy (PGP). PEM enthält eine PKC-Hierarchie und funktionen. PGP ist ziemlich "ad hoc", obwohl es informelle Zertifizierungshierarchien (informal certification hierarchies) ermöglicht. Es kann mit Sicherheit davon ausgegangen werden, dass PKC ein Grundstein für die meisten zukünftigen elektronischen Handelsprodukte sein wird. Solche PKC-Verfahren werden in Bruce Schneier in "Applied Cryptography", New York 1995 von John Wiley und Söhne, Inc., beschrieben.
  • In der folgenden ausführlichen Beschreibung wird vorausgesetzt, dass alle entsprechenden Teilnehmer, Sender/Verbraucher und Empfänger/Händler, mit individuellen Zertifizierungen für öffentliche Schlüssel ausgestattet sind. Bei einer Zertifizierung wird vorausgesetzt, dass sie zumindest den Namen des Teilnehmers, den öffentlichen Schlüssel, die Gültigkeitszeit und den Namen der ausgebenden Stelle enthält, wobei die letztere häufig als "Zertifizierungsstelle" bezeichnet wird.
    • Verwendete Schreibweise
  • Die folgende Tabelle gibt die in der gesamten Beschreibung, den Zeichnungen und den Ansprüchen verwendete Schreibweise an.
  • C, M - Verbraucher und Händler, die Protokollteilnehmer;
  • technisch sind sie "Sender" und "Empfänger";
  • MD - Warenbeschreibung;
  • OD - Angebotsbeschreibung;
  • REQ - Angebotsanforderung;
  • REP - Angebotsantwort;
  • ACC - Angebotsannahme;
  • TEMP-a - Zeitweiliger Wert a;
  • ID-x - Benutzer-ID von X;
  • PK-x - Öffentlicher Schlüssel von X (X = C oder X = M);
  • SK-x - Geheimer/privater Schlüssel von X;
  • R-x - Von X (für diesen Fall) erzeugte willkürliche Zahl
  • Cert-x - Zertifizierung des öffentlichen Schlüssels von X, enthält PK-x;
  • K(text) - Verschlüsselung von "text" unter dem Schlüssel K;
  • H(text) - Starke nicht umkehrbare Quersummenfunktion (strong one-way Hash function) von "text", z. B. SHA (Secure Hash Function) oder MDS, beide beschrieben in Bruce Schneier: Cryptography, oben;
  • SIG-x - Signatur von X;
  • (text) - Wahlweiser Text
    • Beschreibung des grundlegenden Prozesses (Übertragbarer Beleg (voucher))
  • Es folgt eine ausführliche Beschreibung des grundlegenden Prozesses gemäß der Erfindung, wie sie beansprucht wird.
    • 1. Verbraucheranforderung
  • Ein Verbraucher C, der ein Gebot/Angebot von einem Händler M für bestimmte Waren erhalten möchte, erstellt die folgende Nachricht:
  • OFFER-REQUEST = MERCHANDISE-DESCRIPTION, SIG-c, wobei:
  • - MERCHANDISE-DESCRIPTION, MD in den Zeichnungen, die Textbeschreibung der gewünschten Waren ist, die z. B. die Menge, die Farbe/Größe, das Lieferdatum usw. enthält;
  • - SIG-c = H (MERCHANDISE-DESCRIPTION, R-c)
  • SIG-c ist folglich die Quersummenfunktions-Übersicht (hash function digest) von MERCHANDISE-DESCRIPTION zusammen mit einem willkürlich für diesen Fall erzeugten, nur einmal verwendeten Größe R-c. Die bevorzugte empfohlene Mindestlänge für R-c beträgt 64 Bit.
  • Eine entscheidende Einzelheit ist, dass R-c nicht als Teil der Nachricht OFFER-REQUEST enthalten ist, obwohl R-c bei der Berechnung von SiG-c verwendet wird.
  • Wie in Fig. 1 gezeigt wird, verwendet der voraussichtliche Verbraucher (1) nach dem Erstellen von OFFER-REQUEST den anonymen Kommunikationsdienst (3, 4), z. B. anonyme Pseudonymserver (AR), um die Nachricht an den Händler (2) oder an eine Anzahl von Händlern zu senden. Jeder von ihnen kann die Beschreibung der gewünschten Waren lesen.
    • 2. Händlerantwort
  • Wie oben erwähnt wurde, muss der Händler M beim Empfang von OFFER-REQUEST keine Maßnahme hinsichtlich der Sicherheit (security-related activity) ausführen. Stattdessen überprüft er MERCHANDISE-DESCRIPTION und stellt fest, ob er ein entsprechendes Angebot/Gebot machen kann. Dieser Prozess hängt sowohl vom Händler M als auch von dem in der eingehenden Anforderung angegeben Warentyp ab. Falls der Händler ein Angebot machen kann, erstellt er die folgende Nachricht:
  • OFFER-REPLY = OFFER-DESCRIPTION, SIG-m,
  • (H(MERCHANDISE-DESCRIPTION, SIG-c)}, {Cert-m}, wobei
  • - OFFER-DESCRIPTION (OD in den Zeichnungen) die Beschreibung des Angebots in unverschlüsseltem Text ist, die z. B. das aktuelle Datum/die aktuelle Uhrzeit, den Preis, die Währung, die akzeptierten Zahlungsweise, das Lieferverzeichnis (delivery schedule) usw. enthält.
  • - SIG-m = SK-m[H(SIG-c, MERCHANDISE-DESCRIPTION, OFFER- DESCRIPTION)].
  • - MERCHANDISE-DESCRIPTION und SIG-c sind wie in der Nachricht OFFER-REQUEST beide wahlfrei.
  • - CERT-m ist die Zertifizierung des öffentlichen Schlüssels des Händlers M, falls verfügbar; sie ist wahlfrei. Unabhängig davon kann sie dem Verbraucher C bekannt sein.
  • Cert-m, die Zertifizierung des öffentlichen Schlüssels des Händlers, ist in einem Netzwerk möglicherweise nicht verfügbar, z. B. in einem Netzwerk, das keinen PKC-Service bereitstellt. Dann ist möglicherweise nur der Prozess des Bietens gemäß der Erfindung ausführbar. Das Senden von Cert-m ist selbstverständlich wahlfrei; auch wenn sie für den nachfolgenden Kaufprozess benötigt wird, ist es möglich, dass der Verbraucher sie bereits hat.
  • Die Quersummenfunktions-Übersicht von MERCHANDISE-DESCRIPTION und SIG-c sind ebenfalls wahlfrei, da ihr einziger Nutzen darin besteht, dem Kunden C dabei zu helfen, die ausstehende OFFER-REQUEST mit der eingehenden OFFER-REPLY in Übereinstimmung zu bringen. Dies ist im Grunde genommen nur notwendig, wann ein anonymer Kommunikationskanal verwendet wird.
    • 3. Nachfolgende Maßnahmen des Verbrauchers
  • Wenn der Verbraucher OFFER-REPLY empfängt, führt er die folgenden Maßnahmen aus:
  • a. Falls gültig, berechnet er H(MERCHANDISE-DESCRIPTION, SIG-c) neu und kennzeichnet die übereinstimmende OFFER-REQUEST.
  • b. Falls gültig, überprüft er die Gültigkeit, die Echtheit und die Datenintegrität der Zertifizierung Cert-m des Händlers. (Verfahren hierfür sind bekannt, siehe Bruce Schneier: Cryptography, oben zitiert)
  • c. Er überprüft OFFER-DESCRIPTION auf Übereinstimmung mit der entsprechenden MERCHANDISE-DESCRIPTION und stellt fest, ober das Angebot akzeptiert.
  • d. Falls das Angebot nicht akzeptiert wird, werden keine weiteren Maßnahmen getroffen.
  • e. Falls das Angebot von Interesse ist, berechnet der Verbraucher C Folgendes:
  • - einen zeitweiligen Wert TMP-1 TMP-1 = PK-m(SIG-m), wobei PK-m der aus Cert-m entnommene öffentliche Schlüssel des Händlers ist.
  • - einen zeitweiligen Wert TMP-2 TMP-2 = H(SIG-c, MERCHANDISE-DESCRIPTION, OFFER-DESCRIPTION)
  • f. Schließlich vergleicht er TMP-1 und TMP-2, und falls sie übereinstimmen, ist es gewährleistet, dass das Angebot echt ist.
  • Der obige Prozess wird in Fig. 2A in gekürzter Form gezeigt.
  • Unter der Voraussetzung, dass das Angebot annehmbar und echt ist, kann der Verbraucher - falls er dies wünscht - direkt an den Händler herantreten, d. h. ohne den Anonymisierungsprozess zu durchlaufen. Dies ist normalerweise der Fall, wenn Waren von physischer Beschaffenheit geliefert werden müssen. Der Verbraucher kann ohnehin entscheiden, einige Zeit nach dem ersten Austausch, z. B. am nächsten Tag, auf das Angebot des Händlers hin zu handeln.
  • Falls die Ware von elektronischer Beschaffenheit ist und online geliefert werden kann, z. B. Software oder Daten, ist es eventuell möglich und wünschenswett für den Verbraucher C, anonym zu bleiben. Dies kann ausgeführt werden, indem der Anonymisierungsprozess im Lieferstadium wieder durchlaufen wird. In vielen Fällen greift der Verbraucher C jedoch zu herkömmlichen Zahlungsverfahren (z. B. Kreditkarte), wobei seine Anonymität in diesem Fall wahrscheinlich verloren geht.
    • 4. Nachfolgende Maßnahmen
  • Der letzte Schritt im Verfahren des blinden Bietens gemäß einem weiteren Teil der Erfindung beinhaltet das Prüfen der Gültigkeit des Angebots durch den Händler, sobald der Verbraucher entscheidet, das Angebot anzunehmen. Unabhängig davon, wie der Verbraucher an die Sache herangeht, müssen die folgenden fünf Informationselemente an den Händler übertragen werden:
  • - MERCHANDISE-DESCRIPTION
  • - SIG-c
  • - OFFER-DESCRIPTION
  • - SIG-m
  • - R-c
  • Die ersten vier können direkt aus den zuvor erwähnten Nachrichten OFFER-REQUEST und OFFER-REPLY entnommen werden. Das fehlende R-c ist die bisher geheime Größe, die zum Berechnen von SIG-c verwendet wird, wie oben erläutert wird.
  • Um seine Annahme des Angebots zu zeigen, überträgt der Verbraucher R-c an den Händler, indem er eine Nachricht
  • OFFER-ACCEPT = R-c, OFFER-DESCRIPTION
  • sendet, wobei OFFER-DESCRIPTION enthalten ist, um dem Händler beim Identifizieren des entsprechenden ausstehenden Angebot zu helfen.
  • Um die Gültigkeit des Gebots einzurichten, führt der Händler nun die folgenden Schritte aus. Er
  • a. berechnet einen zeitweiligen Wert TMP-3 = H(MERCHANDISE- DESCRIPTION, R-c); und
  • b. falls TMP-3 = SIG-c, erkennt er, dass SIG-c echt und das Gebot gültig ist.
  • Die folgenden Schritte c und d sind wahlweise und werden nur ausgeführt, falls der Händler SIG-m nicht aufbewahrt. In diesem Fall muss SIG-m in der Kommunikation von OFFER-ACCEPT enthalten sein.
  • c. Der Händler M kann Folgendes berechnen TMP-5 = SK-m[H(SIG-c, MERCHANDISE-DESCRIPTION, OFFER- DESCRIPTION)]
  • d. Falls TMP-5 = SIG-m, erkennt der Händler an, dass SIG-m seine eigene Signatur und das Angebot folglich echt ist.
  • In diesem Fall kann der Verbraucher C seinen "Beleg" für den vorgesehenen Zweck an einen anderen möglichen Verbraucher übertragen. Der Händler M bemerkt eine solche Belegübertragung nicht. Der vollständige Prozess gemäß der obigen Beschreibung wird in Fig. 2B gezeigt.
    • Beschreibung des erweiterten Prozesses (Nicht-übertragbarer Beleg)
  • Es folgt eine ausführliche Beschreibung eines komplizierteren Prozesses. Die beschriebene Realisierung bietet zusätzliche Vorteile, wie unten beschrieben wird.
  • Der Hauptunterschied zum oben beschriebenen grundlegenden Prozess besteht darin, dass der Verbraucher C über eine Zertifizierung für öffentliche Schlüssel und das entsprechende Paar von öffentlichem/privatem Schlüssel verfügt. Da der Verbraucher folglich in der Lage ist, seine Anforderung für ein Gebot oder Angebot zu signieren, kann er - zu einem späteren Zeitpunkt - dem Händler M nachweisen, dass er der Einzige ist, der die ursprüngliche Anforderung erzeugen konnte und der das Angebot des Händlers empfing.
  • Außerdem kann der Händler M nun sicherstellen, dass das Angebot und die Waren an denselben Verbraucher gehen, d. h., der Verbraucher C kann das Angebot/Gebot nicht frei an einen anderen Verbraucher übertragen. Dies hat zur Folge, dass der Verbraucher C dem Händler M seine Identität enthüllt, jedoch nur, wenn der Verbraucher zum Kauf der Waren bereit ist, vorher nicht.
  • Aufgrund des Prozessaufbaus ist der Händler M, der mehrere Anforderungen für Angebote/Gebote vom selben Verbraucher C empfängt, gleichzeitig nicht in der Lage, diesen Verbraucher als ein und denselben zu erkennen.
    • 1. Verbraucheranforderung
  • Der Verbraucher C, der ein Gebot/Angebot vom Händler M für bestimmte Waren erhalten möchte, erstellt die folgende Nachricht, wie oben:
  • OFFER-REQUEST = (MERCHANDISE-DESCRIPTION, SIG-c)
  • wobei
  • MERCHANDISE-DESCRIPTION die Textbeschreibung der gewünschten Waren ist, die z. B. die Menge, die Farbe/Größe, die Liefertermine usw. enthält; und
  • SIG-c = SK-c[H(MERCHANDISE-DESCRTPTION, R-c)]
  • SIG-c ist folglich die Signatur der Quersummenfunktionsübersicht von MERCHANDISE-DESCRIPTION zusammen mit einer willkürlich für diesen Fall erzeugten, nur einmal verwendeten Größe R-c. Die bevorzugte empfohlene Mindestlänge für R-c beträgt 64 Bit.
  • Wie zuvor ist R-c nicht als Teil der Nachricht OFFER-REQUEST enthalten, selbst wenn R-c bei der Berechnung von SIG-c verwendet wird.
  • Nach dem Erstellen von OFFER-REQUEST verwendet der voraussichtliche Verbraucher (1) den anonymen Kommunikationsdienst (3, 4), um die Nachricht an den Händler (2) oder an eine Anzahl von Händlern zu senden. Jeder von ihnen kann die Beschreibung der gewünschten Waren lesen.
    • 2. Händlerantwort
  • Dieser Schritt ist identisch mit demjenigen im grundlegenden Prozess, wie er oben beschrieben wird, und wird daher hier nicht wiederholt.
    • 3. Nachfolgende Maßnahmen durch den Verbraucher
  • Dieser Schritt ist ebenfalls identisch mit demjenigen im grundlegenden Prozess, wie er oben beschrieben wird, und wird daher hier nicht wiederholt.
    • 4. Nachfolgende Maßnahmen
  • Der letzte Schritt im Verfahren des blinden Bietens gemäß diesem Teil der Erfindung beinhaltet das Überprüfen der Gültigkeit des Angebotes durch den Händler M, sobald der Verbraucher C entscheidet, dieses anzunehmen. Unabhängig davon, wie der Verbraucher an die Sache herangeht, müssen die folgenden sechs Informationselemente an den Händler übertragen werden; Cert-c kommt im Vergleich zum obigen grundlegenden Prozess hinzu.
  • - MERCHANDISE-DESCRIPTION
  • - SIG-c
  • - OFFER-DESCRIPTION
  • - SIG-m
  • - Cert-c
  • - R-c
  • Die ersten vier können direkt aus den zuvor erwähnten Nachrichten OFFER-REQUEST und OFFER-REPLY entnommen werden. Cert-c ist die Zertifizierung des öffentlichen Schlüssels des Verbrauchers C, und R-c ist die bisher geheime Größe, die zum Berechnen von SIG-c verwendet wird, wie oben erläutert wird.
  • Der Verbraucher überträgt R-c an den Händler, indem er eine Nachricht
  • OFFER = ACCEPT = R-c, OFFER-DESCRIPTION, {Cert-c}
  • sendet, wobei OFFER-DESCRIPTION enthalten ist, um dem Händler beim Identifizieren des entsprechenden ausstehenden Angebot zu helfen. Die Zertifizierung Cert-c des öffentlichen Schlüssels des Kunden ist wahlfrei.
  • Um die Gültigkeit des Gebots einzurichten, führt der Händler nun die folgenden Schritte aus. Er
  • a. überprüft die Gültigkeit, die Echtheit und die Datenintegrität der Zertifizierung Cert-c des öffentlichen Schlüssels des Verbrauchers,
  • b. entnimmt den öffentlichen Schlüssel PK-c des Verbrauchers aus Cert-c,
  • c. berechnet einen Wert TMP-3 = H(MERCHANDISE-DESCRIPTION, R-c) und
  • d. berechnet einen zeitweiligen Wert TMP-4 = PK-c(SIG-c).
  • e. Falls TMP-3 = TMP-4, erkennt der Händler M an, dass SIG-c die echte Signatur des Verbrauchers C und das Gebot gültig ist.
  • Die Schritte f und g sind wahlweise und werden nur ausgeführt, falls der Händler SIG-m nicht aufbewahrt.
  • f. Schließlich kann der Händler M TMP-5 = SK-m[H(SIG-c, MERCHANDISE-DESCRIPTION, OFFER- DESCRIPTION)] berechnen.
  • g. Falls TMP-5 = SIG-m, erkennt er an, dass SIG-m seine eigene Signatur und das Angebot folglich echt ist.
    • Änderungen
  • Das in den vorhergehenden Abschnitten beschriebene Verfahren kann auf folgende Weise verbessert/ergänzt werden:
  • Falls der Verbraucher von vornherein die Zertifizierung (Cert- m) des Händlers kennt, kann die Nachricht OFFER-REQUEST unter dem öffentlichen Schlüssel PK-m des Händlers verschlüsselt werden. Dies wird in den Fig. 2A, 2B und 3 gezeigt. Die sich ergebende Geheimhaltung der Nachrichten bietet Schutz vor Abhörern und Horchern.
  • Außerdem kann die Geheimhaltung/der Datenschutz der Händlerantwort erhalten werden, falls der Verbraucher einen geheimen Schlüssel in die verschlüsselte OFFER-REQUEST aufnimmt, wobei es dem Händler ermöglicht wird, diesen Schlüssel zur Verschlüsselung von OFFER-REPLY zu verwenden.
    • Zusammenfassung von Sicherheitseigenschaften
  • Das Verfahren des blinden Bietens hat die folgenden Sicherheitseigenschaften - mit Ausnahme der letzten sind alle von diesen sowohl für den grundlegenden als auch für den erweiterten Prozess gültig.
  • - Die Anonymität des Verbrauchers C wird gewahrt, z. B. während der Recherche vor dem Kauf.
  • - Die Echtheit, die Datenintegrität und die Anerkennung des Angebots durch den Händler M werden garantiert.
  • - Mehrere Anforderungen vom selben Verbraucher können nicht verbunden werden. Dies ist ein besonders wichtiges Merkmal, das den Händler M im Wesentlichen daran hindert, einen recherchierenden Kunden als jemanden zu "erkennen", der zuvor Käufe getätigt hat, auch wenn der Händler die Zertifizierung dieses Kunden besitzt.
  • - Die Echtheit und Anerkennung der Angebotsanforderung durch den Händler M sind gegeben.
  • - Wahlweise wird der Datenschutz (vor Horchern) bei einer sich ergebenden Kommunikation gewahrt.
    • Verwendung in Produkten
  • Wie oben erwähnt wurde, kann das Verfahren des blinden Bietens gemäß der Erfindung sowohl im asynchronen, z. B. auf E-Mail beruhenden, als auch im synchronen (z. B. auf http oder WWW beruhenden) elektronischen Handel verwendet werden.
  • In den meisten asynchronen Umgebungen ist die nötige Infrastruktur bereits vorhanden, d. h., es gibt eine Anzahl von funktionierenden anonymen Pseudonymservern und mehrere Schemas für Zertifizierungen für öffentliche Schlüssel. Der elektronische Handel über eine synchrone Kommunikation kommt gegenwärtig in Schwung und wird als zukunftsweisend angesehen. Die Popularität des Handels über das World-Wide Web ist ein eindrucksvolles Beispiel. Der einzige fehlende Bestandteil ist ein synchroner Protokoll-Anonymisierer. Wenn vom WWW ausgegangen wird, ist ein Anonymisierer eine Vermittlung (relay), die eingehende http-Anforderungen entgegennimmt und sie mit gewünschten Punkten von Interesse verbindet, indem sie als Proxy fungiert, während die Anonymität der tatsächlichen eingehenden Endpunkte gewahrt bleibt. Selbstverständlich müssen die Antworten auf ähnliche Weise rückadressiert werden.
  • Ein wesentlicher Teil dieser Funktionalität wird bereits durch sogenannte "Protokoll-Firewalls" bereitgestellt. Der NetSP Secure Network Gateway von IBM ist ein Beispiel; wie oben beschrieben wird, kann er problemlos verbessert werden, um in beide Richtungen als Anonymisierer zu dienen.
    • Pseudocode für die beiden Prozesse
  • Es folgt eine Pseudocode-Auflistung für den grundlegenden Prozess (übertragbarer Beleg), wie er oben beschrieben wird. Ein Fachmann muss in der Lage sein, diesen Code an eine gegebene Netzwerkumgebung anzupassen oder in einer solchen zu realisieren. VERBRAUCHEREINHEIT: HÄNDLEREINHEIT:
  • Dies ist das Ende der Codeauflistung für den "grundlegenden Prozess". Es folgt der Pseudocode für den "erweiterten Prozess" (nicht-übertragbarer Beleg), wie oben beschrieben wird. VERBRAUCHEREINHEIT: HÄNDLEREINHEIT:
  • Dies ist das Ende der Auflistung für den "erweiterten Prozess".
  • Obwohl die Modi, die als die besten zum Ausführen dieser Erfindung angesehen werden, hierin gezeigt und beschrieben wurden, ist es klar, dass Änderungen vorgenommen werden können, ohne vom Gegenstand dieser Erfindung abzuweichen, wie er durch die angehängten Ansprüche beschrieben wird.

Claims (13)

1. Verfahren zum anonymen nachweisbaren Informationsaustausch zwischen einem Sender (1) und einem Empfänger (2) in einem Computernetz, wobei das Letztere Folgendes bereitstellt:
eine Infrastruktur für öffentliche Schlüssel, vorzugsweise mit Zertifizierung, und
einen anonymen Kommunikationskanal, der zwischen Netzbenutzern zur Verfügung steht,
wobei das Verfahren die folgenden Schritte umfasst:
der Sender C (1) erstellt eine Angebotsanforderung REQ mit einer Gegenstands- oder Warenbeschreibung MD und einer digitalen Signatur SIG-c von C,
REQ = (MD, SIG-c),
die REQ wird über den anonymen Kommunikationskanal an mindestens einen Empfänger M (2) gesendet,
der Empfänger M (2) erstellt eine Antwort REP mit einer Angebotsbeschreibung OD und seiner digitalen Signatur SIG- m, wobei die Signatur SIG-m über die Größe MD oder OD oder SIG-c oder über eine Kombination von zwei oder drei dieser Größen berechnet wird,
REP = (OD, SIG-m),
wobei außerdem der öffentliche Schlüssel PK-m oder die Zertifizierung Cert-m des öffentlichen Schlüssels von M enthalten ist,
beim Empfang der Antwort REP verwendet der Sender C (1) den öffentlichen Schlüssel PK-m von M, der bekannt ist, gesendet wird oder aus der Zertifizierung Cert-m des öffentlichen Schlüssels entnommen wird, um die empfangene SIG-m zu verschlüsseln, wodurch ein erster zeitweiliger Wert TMP-1 bestimmt wird,
TMP-1 = PK-m(SIG-m),
und berechnet eine Verkettung der Auswahl von. Größen, auf denen die Signatur SIG-m beruht, wodurch ein zweiter zeitweiliger Wert TMP-2 bestimmt wird
TMP-2 = H(SIG-c/MD/OD),
wobei die Übereinstimmung der zeitweiligen Werte TMP-1 und TMP-2 die Echtheit des Angebots anzeigt.
2. Verfahren nach Anspruch 1, wobei
die digitale Signatur SIG-c des Senders C (1) eine Hash- Funktion der MD und/oder ein für diesen Fall willkürlich erzeugtes R-c ist,
SIG-c = H(MD/R-c).
3. Verfähren nach Anspruch 1, wobei
die digitale Signatur SIG-c des Senders C (1) eine Verschlüsselung der MD unter einem für diesen Fall willkürlich erzeugten R-c als Schlüssel ist,
SIG-c = R-c (MD).
4. Verfahren nach Anspruch 1, wobei
die digitale Signatur SIG-c des Senders C (1) eine Hash- Funktion der MD und/oder eines für diesen Fall willkürlich erzeugten R-c ist, die unter dem geheimem Schlüssel SK-c von C verschlüsselt werden,
SIG-c = SK-c[H(MD/R-c)].
5. Verfahren nach irgendeinem der Ansprüche 2 bis 4, wobei
das für diesen Fall erzeugte R-c des Senders C (1) an den Empfänger M (2) gesendet wird,
der Empfänger M (2) eine Hash-Funktion von MD und R-c berechnet, wodurch ein dritter zeitweiliger Wert TMP-3 bestimmt wird.
TMP-3 = H(MD, R-c),
wobei die Übereinstimmung des zeitweiligen Wertes TMP-3 und SIG-c die Echtheit der SIG-c anzeigt.
6. Verfahren nach Anspruch 5, wobei
der Empfänger (2) PK-c verwendet, das bekannt ist, empfangen wird oder aus Cert-c entnommen wird, um die empfangene SIG-c zu verschlüsseln, wodurch ein vierter zeitweiliger Wert TMP-4 bestimmt wird,
TMP-4 = PK-c(SIG-c),
wobei die Übereinstimmung der zeitweiligen Werte TMP-3 und TMP-4 die Echtheit der SIG-c anzeigt.
7. Verfahren nach irgendeinem vorhergehenden Anspruch, wobei
die digitale Signatur SIG-m des Empfängers M (2) eine Hash-Funktion der gewählten Auswahl von Größen von MD, OD, SIG-c ist,
STG-m = H(SIG-c/MD/OD), und
die Verkettung zum Ableiten von TMP-2 eine Hash-Funktion derselben Auswahl von Größen ist, die zum Berechnen der SIG-m verwendet werden,
TMP-2 = H(SIG-c/MD/OD).
8. Verfahren nach irgendeinem der Ansprüche 2 bis 4, wobei
die digitale Signatur SIG-m des Empfängers M (2) eine Hash-Funktion der gewählten Auswahl von Größen von MD, OD, SIG-c ist, die unter dem geheimem Schlüssel SK-m von M verschlüsselt werden,
SIG-m = SK-m(H(SIG-c/MD/OD)).
9. Verfahren nach irgendeinem vorhergehenden Anspruch, wobei
insbesondere wenn der Sender (1) von vornherein den öffentlichen Schlüssel PK-m des Empfängers kennt, der Empfänger M (2) die Angebotsbeschreibung OD mit seinem geheimen Schlüssel SK-m verschlüsselt und eine Antwort
REP = (SK-m(OD), SIG-m) sendet.
10. Verfahren nach irgendeinem vorhergehenden Anspruch, wobei
der Sender C (1) außerdem seine Benutzerkennung ID-c als Identitätsnachweis an den Empfänger M (2) sendet.
11. Verfahren nach irgendeinem der Ansprüche 2 bis 4, wobei
der Sender C (1) außerdem das für diesen Falle erzeugte Rc an den Empfänger M (2) sendet, was eine Identifikation des Senders C (1) durch Überprüfung seiner Signatur SIG-c ermöglicht.
12. Verfahren nach irgendeinem vorhergehenden Anspruch,
wobei der Sender C (1) und/oder der Empfänger M (2) den Status insofern laufend verfolgen, als mindestens einer von ihnen eingehende Anforderungen REQ und/oder Antworten REP speichert.
13. System zum anonymen nachweisbaren Informationsaustausch zwischen einem Sender (1) und einem Empfänger (2) in einem Computernetz, wobei das Letztere Folgendes bereitstellt:
eine Infrastruktur für öffentliche Schlüssel, vorzugsweise mit Zertifizierung, und
ein anonymes Kommunikationsmittel (3, 4, 5, 6) zwischen Netzbenutzern (1, 2)
wobei das System Folgendes umfasst:
Mittel im Sender C (1) zum Erstellen einer Angebotsanforderung REQ = (MD, SIG-c) mit einer Gegenstands- oder Warenbeschreibung MD und einer digitalen Signatur SIG-c von C,
Mittel zum Anonymisieren der Angebotsanforderung REQ,
Mittel zum Senden der anonymisierten Angebotsanforderung an mindestens einen Empfänger M (2),
Mittel im Empfänger M (2) zum Erstellen einer Antwort REP = (OD, SIG-m) mit einer Angebotsbeschreibung OD und einer digitalen Signatur SIG-m von M, wobei die Signatur SIG-m über Größe MD oder OD oder SIG-c oder über eine Kombination von zwei oder drei dieser Größen MD, OD, SIG-c berechnet wird, die außerdem den öffentlichen Schlüssel PK-m von M oder die Zertifizierung Cert-m des öffentlichen Schlüssels enthält,
Mittel im Sender C (1), um beim Empfang der Antwort REP die empfangene SIG-m zu verschlüsseln und einen ersten zeitweiligen Wert TMP-1 = PK-m(SIG-m) zu bestimmen, wobei der öffentliche Schlüssel PK-m von verwendet wird, der bekannt ist, gesendet wird oder aus der Zertifizierung Cert-m des öffentlichen Schlüssels entnommen wird,
Mittel zum Berechnen einer Verkettung der Auswahl von Größen, auf denen die Signatur SIG-m beruht, und zum Bestimmen eines zweiten zeitweiligen Wertes TMP-2 = H(SIG- c/MD/OD),
Mittel zum Vergleichen des ersten und zweiten zeitweiligen Wertes TMP-1 und TMP-2, wobei ihre Übereinstimmung die Echtheit des Angebots anzeigt.
DE69620460T 1996-01-12 1996-01-12 Sicherer anonymer informationsaustausch in einem netzwerk Expired - Lifetime DE69620460T2 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/IB1996/000025 WO1997025801A1 (en) 1996-01-12 1996-01-12 Secure anonymous information exchange in a network

Publications (2)

Publication Number Publication Date
DE69620460D1 DE69620460D1 (de) 2002-05-08
DE69620460T2 true DE69620460T2 (de) 2003-12-04

Family

ID=11004401

Family Applications (1)

Application Number Title Priority Date Filing Date
DE69620460T Expired - Lifetime DE69620460T2 (de) 1996-01-12 1996-01-12 Sicherer anonymer informationsaustausch in einem netzwerk

Country Status (6)

Country Link
US (1) US6061789A (de)
EP (1) EP0876722B1 (de)
JP (1) JP3346772B2 (de)
DE (1) DE69620460T2 (de)
ES (1) ES2174050T3 (de)
WO (1) WO1997025801A1 (de)

Families Citing this family (144)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10361802B1 (en) 1999-02-01 2019-07-23 Blanding Hovenweep, Llc Adaptive pattern recognition based control system and method
WO1999010815A1 (en) * 1997-08-22 1999-03-04 Grenex Corporation Exchange method and apparatus
US6161129A (en) * 1997-09-30 2000-12-12 At&T Corp. Unlisted address messaging system
EP0917119A3 (de) * 1997-11-12 2001-01-10 Citicorp Development Center, Inc. Verteilte netzwerkbasierte elektronische Geldbörse
US6240400B1 (en) * 1998-02-17 2001-05-29 International Business Machines Corporation Method and system for accommodating electronic commerce in the semiconductor manufacturing industry
EP0946022B1 (de) * 1998-03-26 2013-12-18 Nippon Telegraph And Telephone Corporation Zugriffssteuerungsschema für elektronische Post in einem Kommunikationsnetzwerk unter Verwendung einer Vorrichtung zum Verdecken von Identifizierung
US7051004B2 (en) * 1998-04-03 2006-05-23 Macrovision Corporation System and methods providing secure delivery of licenses and content
WO2000001108A2 (en) * 1998-06-30 2000-01-06 Privada, Inc. Bi-directional, anonymous electronic transactions
US6807530B1 (en) * 1998-08-05 2004-10-19 International Business Machines Corporation Method and apparatus for remote commerce with customer anonymity
JP3204317B2 (ja) * 1998-12-28 2001-09-04 日本電気株式会社 電子入札システム
JP3451396B2 (ja) * 1999-01-07 2003-09-29 ミネベア株式会社 ステッピングモータ
US6389533B1 (en) * 1999-02-05 2002-05-14 Intel Corporation Anonymity server
WO2000052552A2 (en) 1999-03-02 2000-09-08 Quixtar Investments, Inc. Electronic commerce transactions within a marketing system that may contain a membership buying opportunity
US7359871B1 (en) 1999-03-02 2008-04-15 Alticor Investments Inc. System and method for managing recurring orders in a computer network
EP1244968A1 (de) * 1999-06-12 2002-10-02 Tara Chand Singhai Methode und vorrichtung zur ermöglichung von anonymen informationssystemen und anonymen service-transaktionen
US6938022B1 (en) 1999-06-12 2005-08-30 Tara C. Singhal Method and apparatus for facilitating an anonymous information system and anonymous service transactions
US7330826B1 (en) 1999-07-09 2008-02-12 Perfect.Com, Inc. Method, system and business model for a buyer's auction with near perfect information using the internet
US6584452B1 (en) * 1999-07-12 2003-06-24 Northrop Grumman Corporation Communication satellite resource trading techniques
AU7056800A (en) * 1999-08-13 2001-03-13 Fleetboston Financial Corporation Proxy system for customer confidentiality
US7889052B2 (en) * 2001-07-10 2011-02-15 Xatra Fund Mx, Llc Authorizing payment subsequent to RF transactions
US6714944B1 (en) * 1999-11-30 2004-03-30 Verivita Llc System and method for authenticating and registering personal background data
US20010032189A1 (en) * 1999-12-27 2001-10-18 Powell Michael D. Method and apparatus for a cryptographically assisted commercial network system designed to facilitate idea submission, purchase and licensing and innovation transfer
US8429041B2 (en) 2003-05-09 2013-04-23 American Express Travel Related Services Company, Inc. Systems and methods for managing account information lifecycles
US8543423B2 (en) 2002-07-16 2013-09-24 American Express Travel Related Services Company, Inc. Method and apparatus for enrolling with multiple transaction environments
US6965874B2 (en) * 2000-02-04 2005-11-15 Joseph Ronald G Jr. Method, apparatus and program product for facilitating transfer of vehicle leases
AU2001241777A1 (en) * 2000-02-29 2001-09-12 Iprivacy Llc Anonymous and private browsing of web-sites through private portals
US7627531B2 (en) 2000-03-07 2009-12-01 American Express Travel Related Services Company, Inc. System for facilitating a transaction
US8121941B2 (en) 2000-03-07 2012-02-21 American Express Travel Related Services Company, Inc. System and method for automatic reconciliation of transaction account spend
KR20030017485A (ko) * 2000-03-29 2003-03-03 리스쿠몬스타 가부시키가이샤 여신 기능을 구비한 익명 전자상거래 시스템 및 방법
US7111176B1 (en) 2000-03-31 2006-09-19 Intel Corporation Generating isolated bus cycles for isolated execution
US6741989B1 (en) 2000-06-07 2004-05-25 Ge Capital Services Structured Finance Group, Inc. Web-based method and system for exchanging information among partners
US7587368B2 (en) 2000-07-06 2009-09-08 David Paul Felsher Information record infrastructure, system and method
US7516097B2 (en) * 2000-08-04 2009-04-07 Bgc Partners, Inc. Systems and methods for anonymous electronic trading
US7278159B2 (en) * 2000-09-07 2007-10-02 Mazu Networks, Inc. Coordinated thwarting of denial of service attacks
US7743134B2 (en) * 2000-09-07 2010-06-22 Riverbed Technology, Inc. Thwarting source address spoofing-based denial of service attacks
US7398317B2 (en) * 2000-09-07 2008-07-08 Mazu Networks, Inc. Thwarting connection-based denial of service attacks
US7702806B2 (en) * 2000-09-07 2010-04-20 Riverbed Technology, Inc. Statistics collection for network traffic
US7124440B2 (en) * 2000-09-07 2006-10-17 Mazu Networks, Inc. Monitoring network traffic denial of service attacks
US7043759B2 (en) * 2000-09-07 2006-05-09 Mazu Networks, Inc. Architecture to thwart denial of service attacks
US7185065B1 (en) * 2000-10-11 2007-02-27 Buzzmetrics Ltd System and method for scoring electronic messages
US7043760B2 (en) * 2000-10-11 2006-05-09 David H. Holtzman System and method for establishing and managing relationships between pseudonymous identifications and memberships in organizations
US7197470B1 (en) * 2000-10-11 2007-03-27 Buzzmetrics, Ltd. System and method for collection analysis of electronic discussion methods
US7277961B1 (en) 2000-10-31 2007-10-02 Iprivacy, Llc Method and system for obscuring user access patterns using a buffer memory
US6807635B1 (en) * 2000-11-13 2004-10-19 Currenex, Inc. Using digital signatures to validate trading and streamline settlement of financial transaction workflow
US7996288B1 (en) 2000-11-15 2011-08-09 Iprivacy, Llc Method and system for processing recurrent consumer transactions
US20040019552A1 (en) * 2000-12-07 2004-01-29 Tobin Christopher M. Limited inventory offered for sale at iteratively adjusted pricing
US7242921B2 (en) * 2000-12-29 2007-07-10 Intel Corporation Anonymous electronic transactions
US20020103689A1 (en) * 2001-01-27 2002-08-01 Hornick Randall F. Methods and systems for identifying prospective customers and managing deals
US7430535B2 (en) * 2001-01-27 2008-09-30 General Electric Capital Corporation Methods and systems for identifying prospective customers and managing deals
US7051006B2 (en) * 2001-02-09 2006-05-23 International Business Machines Corporation System and method for maintaining customer privacy
US7181017B1 (en) 2001-03-23 2007-02-20 David Felsher System and method for secure three-party communications
US20020147766A1 (en) * 2001-04-04 2002-10-10 Marko Vanska Operating user profiles with distributed profile model using a hybrid terminal
WO2002087148A1 (en) * 2001-04-23 2002-10-31 International Business Machines Corporation Non-transferable anonymous digital receipts
US7340438B2 (en) * 2001-05-21 2008-03-04 Nokia Corporation Method and apparatus for managing and enforcing user privacy
US7542942B2 (en) * 2001-07-10 2009-06-02 American Express Travel Related Services Company, Inc. System and method for securing sensitive information during completion of a transaction
US7725427B2 (en) 2001-05-25 2010-05-25 Fred Bishop Recurrent billing maintenance with radio frequency payment devices
US8494949B2 (en) 2001-06-01 2013-07-23 Bgc Partners, Inc. Electronic trading for principal/broker trading
US7103912B2 (en) * 2001-06-29 2006-09-05 International Business Machines Corporation User authorization management system using a meta-password and method for same
US7463133B2 (en) 2001-07-10 2008-12-09 American Express Travel Related Services Company, Inc. Systems and methods for providing a RF transaction device operable to store multiple distinct calling card accounts
US7668750B2 (en) 2001-07-10 2010-02-23 David S Bonalle Securing RF transactions using a transactions counter
US7925535B2 (en) 2001-07-10 2011-04-12 American Express Travel Related Services Company, Inc. System and method for securing RF transactions using a radio frequency identification device including a random number generator
US7303120B2 (en) 2001-07-10 2007-12-04 American Express Travel Related Services Company, Inc. System for biometric security using a FOB
US7503480B2 (en) 2001-07-10 2009-03-17 American Express Travel Related Services Company, Inc. Method and system for tracking user performance
US9024719B1 (en) 2001-07-10 2015-05-05 Xatra Fund Mx, Llc RF transaction system and method for storing user personal data
US9031880B2 (en) 2001-07-10 2015-05-12 Iii Holdings 1, Llc Systems and methods for non-traditional payment using biometric data
US20040236699A1 (en) 2001-07-10 2004-11-25 American Express Travel Related Services Company, Inc. Method and system for hand geometry recognition biometrics on a fob
US8635131B1 (en) 2001-07-10 2014-01-21 American Express Travel Related Services Company, Inc. System and method for managing a transaction protocol
US8548927B2 (en) 2001-07-10 2013-10-01 Xatra Fund Mx, Llc Biometric registration for facilitating an RF transaction
US7762457B2 (en) 2001-07-10 2010-07-27 American Express Travel Related Services Company, Inc. System and method for dynamic fob synchronization and personalization
US9454752B2 (en) 2001-07-10 2016-09-27 Chartoleaux Kg Limited Liability Company Reload protocol at a transaction processing entity
US7805378B2 (en) 2001-07-10 2010-09-28 American Express Travel Related Servicex Company, Inc. System and method for encoding information in magnetic stripe format for use in radio frequency identification transactions
US7735725B1 (en) 2001-07-10 2010-06-15 Fred Bishop Processing an RF transaction using a routing number
US7996324B2 (en) 2001-07-10 2011-08-09 American Express Travel Related Services Company, Inc. Systems and methods for managing multiple accounts on a RF transaction device using secondary identification indicia
US7705732B2 (en) 2001-07-10 2010-04-27 Fred Bishop Authenticating an RF transaction using a transaction counter
US8960535B2 (en) * 2001-07-10 2015-02-24 Iii Holdings 1, Llc Method and system for resource management and evaluation
US7543738B1 (en) 2001-07-10 2009-06-09 American Express Travel Related Services Company, Inc. System and method for secure transactions manageable by a transaction account provider
US8001054B1 (en) 2001-07-10 2011-08-16 American Express Travel Related Services Company, Inc. System and method for generating an unpredictable number using a seeded algorithm
US7249112B2 (en) 2002-07-09 2007-07-24 American Express Travel Related Services Company, Inc. System and method for assigning a funding source for a radio frequency identification device
US8279042B2 (en) 2001-07-10 2012-10-02 Xatra Fund Mx, Llc Iris scan biometrics on a payment device
EP1276062A1 (de) * 2001-07-12 2003-01-15 Hewlett-Packard Company, A Delaware Corporation Verfahren für die Bereitstellung von benutzerspezifischen Daten an eine Informationsquelle, Informationsträger und Verfahren für die Anpassung eines Internet-Erlebnisses an die Person des Benutzers
US8239531B1 (en) 2001-07-23 2012-08-07 At&T Intellectual Property Ii, L.P. Method and apparatus for connection to virtual private networks for secure transactions
US7827278B2 (en) * 2001-07-23 2010-11-02 At&T Intellectual Property Ii, L.P. System for automated connection to virtual private networks related applications
US7827292B2 (en) * 2001-07-23 2010-11-02 At&T Intellectual Property Ii, L.P. Flexible automated connection to virtual private networks
FI20011680L (fi) * 2001-08-21 2003-02-22 Bookit Oy Ajanvarausmenetelmä ja -järjestelmä
US20030046144A1 (en) * 2001-08-28 2003-03-06 International Business Machines Corporation System and method for anonymous message forwarding and anonymous voting
US8250025B2 (en) * 2001-11-06 2012-08-21 Business Controls, Inc. Anonymous reporting system
US7213264B2 (en) 2002-01-31 2007-05-01 Mazu Networks, Inc. Architecture to thwart denial of service attacks
US7743415B2 (en) * 2002-01-31 2010-06-22 Riverbed Technology, Inc. Denial of service attacks characterization
US20030177277A1 (en) * 2002-03-15 2003-09-18 Ziv Dascalu System and method for personal referrals
DE10230442B3 (de) * 2002-07-06 2004-02-19 Daimlerchrysler Ag Kraftübertragungselement
US7587756B2 (en) 2002-07-09 2009-09-08 American Express Travel Related Services Company, Inc. Methods and apparatus for a secure proximity integrated circuit card transactions
US6805287B2 (en) 2002-09-12 2004-10-19 American Express Travel Related Services Company, Inc. System and method for converting a stored value card to a credit card
US20040078587A1 (en) * 2002-10-22 2004-04-22 Cameron Brackett Method, system, computer product and encoding format for creating anonymity in collecting patient data
JP2006505070A (ja) * 2002-10-30 2006-02-09 ボストン オプションズ エックスチェンジ グループ，エルエルシー 金融証券の電子売買用の価格訂正プロセッサ
US8479057B2 (en) * 2002-11-04 2013-07-02 Riverbed Technology, Inc. Aggregator for connection based anomaly detection
US8504879B2 (en) * 2002-11-04 2013-08-06 Riverbed Technology, Inc. Connection based anomaly detection
US7103676B2 (en) * 2002-11-04 2006-09-05 Nokia Corporation User-identifier translator and linking apparatus for XML-based services and corresponding method
US7363656B2 (en) * 2002-11-04 2008-04-22 Mazu Networks, Inc. Event detection/anomaly correlation heuristics
US20040128259A1 (en) * 2002-12-31 2004-07-01 Blakeley Douglas Burnette Method for ensuring privacy in electronic transactions with session key blocks
US9818136B1 (en) * 2003-02-05 2017-11-14 Steven M. Hoffberg System and method for determining contingent relevance
US20040193685A1 (en) * 2003-03-31 2004-09-30 Sony Corporation/Sony Electronics, Inc. Method and apparatus for managing and sharing personal identities in a peer-to-peer environment
US7107447B2 (en) * 2003-04-17 2006-09-12 America Online, Inc. Use of pseudonyms vs. real names
US7543149B2 (en) * 2003-04-22 2009-06-02 Ge Medical Systems Information Technologies Inc. Method, system and computer product for securing patient identity
US7290278B2 (en) 2003-10-02 2007-10-30 Aol Llc, A Delaware Limited Liability Company Identity based service system
US7472827B2 (en) 2004-05-17 2009-01-06 American Express Travel Related Services Company, Inc. Limited use PIN system and method
US20080294559A1 (en) * 2004-06-28 2008-11-27 Gary Wield Transmission of Anonymous Information Through a Communication Network
US7929534B2 (en) * 2004-06-28 2011-04-19 Riverbed Technology, Inc. Flow logging for connection-based anomaly detection
US7314165B2 (en) 2004-07-01 2008-01-01 American Express Travel Related Services Company, Inc. Method and system for smellprint recognition biometrics on a smartcard
US7318550B2 (en) 2004-07-01 2008-01-15 American Express Travel Related Services Company, Inc. Biometric safeguard method for use with a smartcard
US7760653B2 (en) * 2004-10-26 2010-07-20 Riverbed Technology, Inc. Stackable aggregation for connection based anomaly detection
US7979492B2 (en) * 2004-11-16 2011-07-12 International Business Machines Corporation Time decayed dynamic e-mail address
US20060277092A1 (en) * 2005-06-03 2006-12-07 Credigy Technologies, Inc. System and method for a peer to peer exchange of consumer information
US9158855B2 (en) 2005-06-16 2015-10-13 Buzzmetrics, Ltd Extracting structured data from weblogs
US20070016493A1 (en) * 2005-07-13 2007-01-18 Peter Kelly Real Time Bidding Interface Systems and Methods
US20070100779A1 (en) * 2005-08-05 2007-05-03 Ori Levy Method and system for extracting web data
US8874477B2 (en) 2005-10-04 2014-10-28 Steven Mark Hoffberg Multifactorial optimization system and method
JP4734089B2 (ja) * 2005-10-27 2011-07-27 日立オートモティブシステムズ株式会社 車載端末
US8560456B2 (en) * 2005-12-02 2013-10-15 Credigy Technologies, Inc. System and method for an anonymous exchange of private data
US20070162377A1 (en) * 2005-12-23 2007-07-12 Credigy Technologies, Inc. System and method for an online exchange of private data
US7835978B2 (en) * 2005-12-23 2010-11-16 International Business Machines Corporation Method and system for linking an anonymous electronic trade order to an identity of a trader
US20070180039A1 (en) * 2006-02-01 2007-08-02 David Sutidze Anonymous disposable email addressing system and method of use thereo
US8315921B2 (en) * 2006-03-03 2012-11-20 Openlane, Inc. Vehicle co-listing systems and methods
US8738472B2 (en) * 2006-03-10 2014-05-27 Openlane, Inc. Systems and methods for vehicle lifecycle management
US8095422B2 (en) * 2006-03-10 2012-01-10 Openlane, Inc. Systems and methods for vehicle information management
WO2007127881A2 (en) 2006-04-26 2007-11-08 Business Controls, Inc. Anonymous reporting system
US8831973B2 (en) * 2007-04-30 2014-09-09 The Invention Science Fund I, Llc Systems for rewarding influencers
US20090177527A1 (en) * 2007-04-30 2009-07-09 Flake Gary W Rewarding influencers
US20110113006A1 (en) * 2008-05-08 2011-05-12 Motohiko Sakaguchi Business process control apparatus, businesses process control method and business process control program
US20090327042A1 (en) * 2008-06-30 2009-12-31 Flake Gary W Facilitating compensation arrangements having privacy preservation aspects
US8473388B2 (en) * 2008-06-30 2013-06-25 The Invention Science Fund I, Llc Facilitating compensation arrangements providing for data tracking components
US20110066519A1 (en) * 2008-08-21 2011-03-17 Flake Gary W Facilitating data brokering arrangements having auctioning aspects
US8429040B2 (en) * 2008-06-30 2013-04-23 The Invention Science Fund I, Llc Facilitating compensation arrangements for data brokering
US8473387B2 (en) * 2008-06-30 2013-06-25 The Invention Science Fund I, Llc Facilitating compensation arrangements between data providers and data consumers
US8468073B2 (en) * 2008-06-30 2013-06-18 The Invention Science Fund I, Llc Facilitating compensation arrangements providing for data tracking components
CA2753889C (en) 2009-02-27 2021-11-16 Openlane, Inc. Wholesale virtual inventory and retail lead generation
US20110022489A1 (en) * 2009-06-08 2011-01-27 Hallowell Zachary E Third-Party Inspection of Vehicles in an Electronic Marketplace System
US20110106643A1 (en) * 2009-09-28 2011-05-05 Berkowitz Ed Systems and Methods for Electronic Summary and Detail Performance Data of Equipment Sellers
US20110173086A1 (en) * 2009-12-14 2011-07-14 Berkowitz Ed Systems and Methods for Dynamic Pricing and Auction Adjudication During Online Auctions
US9189615B2 (en) 2010-04-28 2015-11-17 Openlane, Inc. Systems and methods for system login and single sign-on
US20130254830A1 (en) 2012-03-22 2013-09-26 Madhav Moganti Apparatus and method for assuring communications of corporate users
JP6563812B2 (ja) * 2012-12-10 2019-08-21 コーニンクレッカ フィリップス エヌ ヴェＫｏｎｉｎｋｌｉｊｋｅ Ｐｈｉｌｉｐｓ Ｎ．Ｖ． マルチサイトパフォーマンス測定を匿名にし、匿名データの処理及び再識別を制御する方法及びシステム
US10270689B2 (en) * 2014-12-19 2019-04-23 Futurewei Technologies, Inc. Multi-nonce enabled interest packet design for named-data networking
US10050925B1 (en) * 2015-01-28 2018-08-14 Intuit Inc. Method and system for notifying users of misdirected response messages associated with messages sent on the users' behalf by an intermediary service
SG11201908666VA (en) * 2017-03-21 2019-10-30 Tora Holdings Inc Secure order matching by distributing data and processing across multiple segregated computation nodes

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4870591A (en) * 1987-08-24 1989-09-26 International Business Machines Corp. System for ensuring device compatibility
US4962532A (en) * 1988-12-22 1990-10-09 Ibm Corporation Method for providing notification of classified electronic message delivery restriction
US4961224A (en) * 1989-03-06 1990-10-02 Darby Yung Controlling access to network resources
US5884270A (en) * 1996-09-06 1999-03-16 Walker Asset Management Limited Partnership Method and system for facilitating an employment search incorporating user-controlled anonymous communications

Also Published As

Publication number Publication date
JPH11509354A (ja) 1999-08-17
JP3346772B2 (ja) 2002-11-18
DE69620460D1 (de) 2002-05-08
WO1997025801A1 (en) 1997-07-17
US6061789A (en) 2000-05-09
ES2174050T3 (es) 2002-11-01
EP0876722B1 (de) 2002-04-03
EP0876722A1 (de) 1998-11-11

Similar Documents

Publication Publication Date Title
DE69620460T2 (de) Sicherer anonymer informationsaustausch in einem netzwerk
DE60315726T2 (de) Verfahren zum sicherstellen von anonymität in einer elektronischen transaktion mittels sitzungsschlüsselblöcken
DE60133312T2 (de) System und verfahren zur sicheren verteilung eines digitalen inhaltes in einem geteilten netzwerk
DE69423454T2 (de) Anonyme Kreditkartentransaktionen
Rose et al. Current technological impediments to business-to-consumer electronic commerce
DE69620994T2 (de) Verfahren und vorrichtung zum durchführen von elektronischem handel
DE60126096T2 (de) Digitale transaktionsquittung
DE602004007254T2 (de) System und verfahren zum authentifizieren von dokumenten
DE112018002942T5 (de) Verfahren und System zur datenschutzwahrenden Social-Media-Werbung
Schunter et al. A status report on the SEMPER framework for secure electronic commerce
WO2005015514A1 (de) Verfahren zum übermitteln von geschützten informationen an mehrere empfänger
JP2000029973A (ja) ロック・ボックス機構、電子入札方法およびセキュリティ提供方法
Abe et al. Receipt-free sealed-bid auction
US20040236698A1 (en) System and method of clearing services for risk management trading
DE60202149T2 (de) Verfahren zur kryptographischen authentifizierung
Trevathan Security, anonymity and trust in electronic auctions
Shih et al. A secure reverse Vickrey auction scheme with bid privacy
DE69636612T2 (de) Zahlungsverfahren in einer Datenübertragungsanordnung und Anordnung zu dessen Implementierung
CA2343805C (en) Method of improving security in electronic transactions
DE102005008610A1 (de) Verfahren zum Bezahlen in Rechnernetzen
DE10114188A1 (de) Ein sicherer Auktionsmarkt unter Benutzung eines sicheren Coprozessors
US20100114795A1 (en) Stock broker social-professional website system
JP2002215935A (ja) 電子商取引システム
DE19940267C2 (de) Verfahren zur mißbrauchssicheren Übermittlung von Daten zwischen Teilnehmern eines bezüglich Mißbrauch ungesicherten Datenübertragungsnetzes
Magkos et al. An equitably fair on-line auction scheme

Legal Events

Date Code Title Description
8332 No legal effect for de
8370 Indication related to discontinuation of the patent is to be deleted
8364 No opposition during term of opposition
8320 Willingness to grant licences declared (paragraph 23)
8328 Change in the person/name/address of the agent

Representative=s name: DUSCHER, R., DIPL.-PHYS. DR.RER.NAT., PAT.-ANW., 7

R082 Change of representative

Ref document number: 876722

Country of ref document: EP

Representative=s name: PFENNING MEINIG & PARTNER GBR, DE