DE60126096T2

DE60126096T2 - Digitale transaktionsquittung

Info

Publication number: DE60126096T2
Application number: DE60126096T
Authority: DE
Inventors: Xinhong San Jose YUAN; J. Stan Mountain View SIMON; W. Robert Woodside PRATT; R. Gregory Menlo Park WHITEHEAD; Atul San Jose TULSHIBAGWALE
Original assignee: Verisign Inc
Current assignee: Verisign Inc
Priority date: 2000-07-28
Filing date: 2001-07-19
Publication date: 2007-10-18
Anticipated expiration: 2021-07-20
Also published as: EP1307863A1; US8370916B2; US20020161721A1; AU2001277943B2; AU7794301A; US20100154048A1; WO2002011091A1; CA2417406C; EP1307863B1; US7694332B2; DE60126096D1; ES2275702T3; ATE352082T1; CA2417406A1

Description

HINTERGRUND DER ERFINDUNG
1. Technisches Gebiet
Die Erfindung betrifft die Public-Key-Kryptografie (Kryptografie mit öffentlichen Schlüsseln), digitale Signaturen und die Public-Key-Infrastruktur (PKI) (Infrastruktur mit öffentlichen Schlüsseln). Insbesondere betrifft sie die Erzeugung und Verwendung von Belegen und digitalen Quittungen für Transaktionen.
2. Hintergrund der Technik
Als Ergebnis der steigenden Verbreitung und Akzeptanz des Computers und des Internets sowie anderer Formen vernetzter Kommunikation nehmen elektronische Transaktionen und Dokumente in Anzahl und Bedeutung zu. Beispielsweise steigt ständig das Volumen bei Verbraucherkäufen, Business-to-Business-Handel (Handel zwischen Unternehmen) und Aktienhandel sowie anderen Investitionsformen, die über das Internet und/oder drahtlose Netzwerke vollzogen werden, was auch für andere Formen des Online-Handels gilt. Zudem erhöht sich auch ständig die Anzahl von Dokumenten, die elektronisch erzeugt werden oder verfügbar sind, sowie die Anzahl von Dokumenten, die nur in elektronischer Form vorliegen (z. B. das papierlose Büro).
Die zunehmende Anzahl elektronischer Transaktionen und Dokumente führt zu einem entsprechenden Bedarf an zuverlässigen Verfahren zur Erstellung von Belegen für diese Transaktionen und Dokumente. Kauft z. B. ein Verbraucher einen Artikel im Internet mit seiner Kreditkarte, ist erwünscht, einen zuverlässigen, nicht abstreitbaren Beleg für den Einkauf zu erstellen. "Unterzeichnen" zwei Firmen einen Vertrag elektronisch, ist erwünscht, sowohl den Unterzeichnungsakt als auch den Inhalt des Vertrags zu belegen. Im papierlosen Büro ist erwünscht, bestimmte Dokumente "digital zu beglaubigen", was gewährleistet, daß ihre Existenz zu einer spezifischen Zeit später nachgewiesen werden kann.
Eine Herangehensweise an das Belegproblem nutzt die Kryptografie. Insbesondere können die Eigenschaften der Public-Key-Kryptografie auf verschiedene Weise verwendet werden, um beweiskräftige Transaktionsbelege zu erstellen. So könnte im Beispiel des Verbrauchers im Internet z. B. ein Verbraucher mit einem digitalen Zertifikat eine digitale Signatur seines Auftrags mit der Kreditkartennummer erstellen, wodurch er einen Kaufbeleg erstellt. Im Vertragsbeispiel könnten die beiden Firmen ähnlich eine digitale Zwei-Parteien-Signatur des Vertrags erzeugen, wobei jede Firma ihr digitales Zertifikat verwendet. Im Beispiel der digitalen Beglaubigung könnte ein Dritter (d. h. der Notar) das Dokument bezeugen, indem er das Dokument mit einem Zeitstempel und einer digitalen Signatur versieht (siehe z. B. die US-A-5497422).
Um aber weitverbreitete Akzeptanz zu finden, sollten diese Wege intuitiv und leicht zu verwenden sein. Ein Problem mit bisherigen Versuchen zur Schaffung einer Infrastruktur von Transaktionsbelegen ist, daß sie zu umständlich und schwierig zu verwenden waren. Beispielsweise wird bei vielen Ansätzen eine digitale Signatur erzeugt, um eine Transaktion zu bezeugen, und diese digitalen Signaturen werden für den Fall gespeichert, daß sie künftig benötigt werden. Gleichwohl sind digitale Signaturen für den Menschen unverständlich. Um also die richtige digitale Signatur für einen spezifischen Fall zu finden, müssen die digitalen Signaturen mit einer Beschreibung der Transaktion sicher gespeichert werden. Sobald die richtige digitale Signatur lokalisiert ist, muß eine wei tere Bearbeitung erfolgen, um den Inhalt der digitalen Signatur für den Menschen nutzbar zu machen.
Oft werden diese Funktionen durch separate Teilstücke von Software durchgeführt. Zum Beispiel kann Datenbanksoftware zum Einsatz kommen, um die digitalen Signaturen und ihre entsprechende Software in einer großen zentralen Datenbank zu speichern. Plug-in-(Erweiterungs-) Software für Browser kann verwendet werden, um die richtige digitale Signatur zu verarbeiten, sobald sie lokalisiert ist. Jedoch kann dieser Weg sowohl umständlich als auch nicht intuitiv sein. Die zentrale Datenbank erfordert Zugriff auf die Datenbank, um die richtigen Belege zu lokalisieren. Somit ist es für jemanden bzw. eine "Entität" schwierig, eine Kopie des Transaktionsbelegs zu einer anderen Entität zu senden, besonders wenn nicht jede Entität hierbei Zugriff auf die Datenbank hat. Zu einem ähnlichen Problem kommt es, wenn eine Entität nicht das richtige Plug-in für den Browser besitzt oder nicht weiß, wie das Plug-in zu verwenden ist.
Somit besteht Bedarf an einfachen und intuitiven Herangehensweisen an die Erstellung und Verwendung von Belegen für Transaktionen und Dokumente. Weiterhin besteht Bedarf an Herangehensweisen, die es erlauben, diese Belege leicht zu verschicken, ohne ihre Integrität zu beeinträchtigen.
OFFENBARUNG DER ERFINDUNG
Die oben genannten Probleme werden durch die Merkmale der Ansprüche 1, 10, 18, 21 und 24 gelöst.
Erfindungsgemäß dient ein computerlesbares Medium als Beleg für einen Vollzug einer Transaktion. Das computerlesbare Medium speichert eine digitale Quittung (300, 700, 900) der Transaktion, die zur Anzeige für den Menschen geeignet ist. Die digitale Quittung (300, 700, 900) verfügt über eine Beschreibung (310, 710, 720, 910, 1020) der Transaktion in einem für den Menschen verständlichen Format, einen gewissen fälschungssicheren Nachweis (320) über den Vollzug der Trans aktion und eine Verifizierungsaufforderung (330, 740, 940, 1030). Vorzugsweise ist der fälschungssichere Nachweis (320) in der Anzeige verborgen. Durch Aktivieren der Verifizierungsaufforderung (330, 740, 940, 1030) wird der fälschungssichere Nachweis (320) verifiziert, ohne daß es weiterer menschlicher Interaktion zur Identifizierung des Nachweises bedarf.
In einer Ausführungsform dient das computerlesbare Medium als Beleg für die Existenz eines Dokuments zu einer spezifischen Zeit. Die digitale Quittung (700) weist ein Formular in einer Standard-Auszeichnungssprache wie HTML oder XML auf und enthält einen Namen (710), der das Dokument identifiziert, eine Zeit (730), die die spezifische Zeit identifiziert, ein digital signiertes Zeitstempel-Token bzw. Zeitstempelfolge (Time Stamp Token), das als verborgener Text im Formular codiert ist, und eine Verifizierungsschaltfläche bzw. -button (740). Das Zeitstempel-Token weist einen Fingerabdruck des Dokuments (z. B. einen Hash des Dokuments) und einen Zeitstempel für das Dokument auf. Durch Aktivieren der Verifizierungsschaltfläche (740) wird der verborgene Text zu einem Dienstanbieter (130) zur Verifizierung übertragen. In einer weiteren Ausführungsform weist das Formular auch das Dokument (910) selbst auf, das als verborgener Text codiert ist. Durch Aktivieren der Verifizierungsschaltfläche (940) wird auch der verborgene Text des Dokuments zum Dienstanbieter (130) zur Verifizierung übertragen.
In einem weiteren Aspekt der Erfindung weist ein Verfahren (200, 400) zum Erstellen eines Belegs für einen Vollzug einer Transaktion die nachfolgend dargestellten Schritte auf. Eine Anforderung zur Erstellung einer digitalen Quittung (300, 700) für die Transaktion wird empfangen (210, 410). Ein fälschungssicherer Nachweis (320) des Vollzugs der Transaktion wird erzeugt (220, 420). Eine digitale Quittung (300, 700, 900) für die Transaktion wird erstellt (230, 430). Die digitale Quittung (300, 700, 900) ist zur Anzeige für den Menschen geeignet und weist eine Beschreibung (310, 710, 720, 910, 1020) der Transaktion, den erzeugten fälschungssicheren Nachweis (320) und eine Verifizierungsaufforderung (330, 740, 940, 1030) auf. Bei Aktivieren der Verifizierungsaufforderung wird der Nachweis (320) verifiziert, ohne daß es weiterer menschlicher Interaktion zur Identifizierung des Nachweises bedarf.
In einem weiteren Aspekt der Erfindung weist ein Verfahren (250, 450) zum Verifizieren des zurückliegenden Vollzugs der Transaktion die nachfolgend dargestellten Schritte auf. Die zuvor beschriebene digitale Quittung (300, 700, 900) wird angezeigt (265, 465), und die Verifizierungsaufforderung (330, 740, 940, 1030) wird aktiviert (270, 470), was die Verifizierung des fälschungssicheren Nachweises (320) initiiert. In einer Ausführungsform wird die Verifizierung des Nachweises empfangen (295, 495), und bei ihrem Empfang wird eine zweite Verifizierungsaufforderung angezeigt. Durch Aktivieren (202, 402) der zweiten Aufforderung wird dann die zugrundeliegende Transaktion verifiziert (202, 404, 406).
Vorzugsweise werden die Verfahren (200, 250, 400, 450) in den beiden vorherigen Absätzen durch Software implementiert, die auf einem Prozessor ausgeführt wird.
Von besonderem Vorteil ist die Erfindung, da die digitale Quittung (300, 700, 900) sowohl eine Verifizierungsaufforderung (330, 740, 940, 1030) als auch den zu verifizierenden fälschungssicheren Nachweis (320) aufweist. Dadurch ist die digitale Quittung (300, 700, 900) leichter und intuitiver zu verwenden. Wiese z. B. die digitale Quittung (300, 700, 900) nicht die Verifizierungsaufforderung (330, 740, 940, 1030) auf, so wären gesonderte Software oder Anweisungen erforderlich, um den Nachweis (320) zu verifizieren. Wiese die digitale Quittung (300, 700, 900) alternativ nicht den Nachweis (320) auf, so müßte der Nachweis (320) erst aus einer gesonderten Quelle erhalten werden. Jeder dieser Fälle stellt ein Problem dar, wenn der Benutzer (120) keinen zweckmäßigen Zugriff auf den fehlenden Teil hat. Indem sie sowohl die Verifizierungsaufforderung (330, 740, 940) als auch den zu verifizierenden Nachweis (320) aufweist, ist die digitale Quittung (300, 700, 900) in sich geschlossen und vermeidet dieses Problem. So kann z. B. die digitale Quittung (300, 700, 900) einem anderen (120) zugesandt werden, der sie durch Aktivieren (270, 470) der Verifizierungsaufforderung (330, 740, 940, 1030) verifizieren könnte.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
Die Erfindung hat weitere Vorteile und Merkmale, die aus der nachfolgenden näheren Beschreibung der Erfindung und den beigefügten Ansprüchen im Zusammenhang mit den beigefügten Zeichnungen deutlicher hervorgehen. Es zeigen:
1 ein Blockdiagramm eines erfindungsgemäßen Systems;
2A und 2B Ereignisverfolgungen, die ein Verfahren zum Betreiben des Systems von 1 veranschaulichen;
3 eine Darstellung einer bevorzugten Ausführungsform einer erfindungsgemäßen digitalen Quittung für eine Transaktion;
4A und 4B Ereignisverfolgungen, die ein bevorzugtes Verfahren zum Betreiben des Systems von 1 zeigen;
5–8 verschiedene Formulare und Dialogfelder, die das Verfahren von 4 veranschaulichen; und
10 einen Screenshot, der noch eine weitere erfindungsgemäße Ausführungsform veranschaulicht.
NÄHERE BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
Die Erfindung betrifft allgemein die Public-Key-Kryptografie, digitale Signaturen und durch eine Zertifizierungsstelle (Certification Authority CA) ausgestellte digitale Zertifikate, die zusammen Bestandteil einer Public-Key-Infrastruktur (PKI) zur Sicherung von Online-Transaktionen bilden. Vor der Diskussion der Darstellungen ist es nützlich, zunächst die zugrundeliegenden Konzepte zu beschreiben.
Die Public-Key-Kryptografie ist ein Weg, Kommunikationsabläufe mit Hilfe von Schlüsselpaaren zu sichern. Zu jedem Schlüsselpaar gehört ein öffentlicher Schlüssel und ein privater Schlüssel, die jeweils normalerweise eine große Zahl sind. Der private Schlüssel wird von der Entität sicher aufbewahrt; während der öffentliche Schlüssel weithin verfügbar gemacht wird. Der öffentliche Schlüssel und private Schlüssel stehen in einer mathematischen Beziehung, so daß eine mit einem Schlüssel verschlüsselte Nachricht mit dem anderen entschlüsselt werden kann, aber die Beziehung ist so, daß es rechnerisch undurchführbar ist, einen Schlüssel anhand des anderen zu berechnen. Kennt anders ausgedrückt ein Dritter den öffentlichen Schlüssel einer Entität (was normalerweise der Fall ist), ist es rechnerisch unmöglich, auf den entsprechenden privaten Schlüssel (der normalerweise von der Entität sicher verwahrt wird) zu schließen. Zu bekannten Public-Key-Verschlüsselungsalgorithmen zählen RSA, DSA und ElGamal.
Die Schlüsselpaare können verwendet werden, Dokumente "digital zu signieren". Eine Entität "signiert" ein Dokument "digital", indem sie das Dokument oder eine verarbeitete Version des Dokuments mit Hilfe des privaten Schlüssels der Entität verschlüsselt. Damit kann ein Dritter das Dokument authentifizieren, indem verifiziert wird, daß (i) es sich um den privaten Schlüssel der Entität (und nicht um einen anderen Schlüssel) handelt, der zum digitalen Signieren des Dokuments verwendet wurde; (ii) der Inhalt des Dokuments nicht geändert wurde, seit das Dokument digital signiert wurde; und (iii) die Entität später nicht leugnen kann, daß sie das Dokument digital signiert hat. Häufig bezeichnet man die erste Eigenschaft als "Urheberschaft", die zweite als "Integrität" und die dritte als "Unleugbarkeit".
Vorzugsweise wird ein Dokument digital signiert, indem zunächst ein One-Way-(Einweg-) Hash (siehe unten) des Dokuments erzeugt wird, wodurch man etwas erstellt, was gemeinhin als Dokument-Digest (Konzentrat) bezeichnet wird. Danach wird der Dokument-Digest mit Hilfe des privaten Schlüssels der Entität verschlüsselt, um die digitale Signatur für das Dokument zu erzeugen. Ein Dritter empfängt normalerweise sowohl das Dokument als auch die entsprechende digitale Signatur und authentifiziert das Dokument dann wie folgt: Der Dritte entschlüsselt die empfangene digitale Signatur mit Hilfe des öffentlichen Schlüssels der Entität, was einen entschlüsselten Dokument-Digest ergibt, der mit dem ursprünglichen Dokument-Digest identisch sein sollte. Außerdem erzeugt der Dritte einen One-Way-Hash des empfangenen Dokuments, wobei er dieselbe Hashfunktion verwendet, die von der Entität gebraucht wurde, was einen neu erzeugten Dokument-Digest ergibt. Danach vergleicht der Dritte den entschlüsselten Dokument-Digest und den neu erzeugten Dokument-Digest. Sind sie identisch, hat der Dritte das Dokument authentifiziert.
Eine Hashfunktion ist eine Transformation, die eine Eingabe mit variabler Größe aufnimmt und eine Ausgabe mit fester Größe abgibt, die normalerweise kleiner als die Eingabe ist und als Hash der Eingabe bezeichnet wird. Eine One-Way- (Einweg-) Funktion ist eine Transformation, die in einer Richtung erheblich leichter als in der Gegenrichtung durchzuführen ist. Somit ist eine One-Way-Hashfunktion eine Transformation mit beiden diesen Eigenschaften. One-Way-Hashfunktionen, die zur Erzeugung digitaler Signaturen zum Einsatz kommen, erzeugen vorzugsweise auch Ausgaben, deren Größe allgemein kleiner als die Eingabe ist, können Eingaben jeder Größe handhaben und sind in gewissem Grad kollisionsfrei. Aufgrund ihres Wesens sind Hashfunktionen Many-to-one-(mehreindeutige) Funktionen, was bedeutet, daß viele Eingaben mit der gleichen Ausgabe abgebildet werden. Ist aber die Hashfunktion kollisi onsfrei, entfällt dieses potentielle Problem in der Praxis. Eine Hashfunktion ist schwach kollisionsfrei, wenn es angesichts einer Eingabe rechnerisch undurchführbar ist, eine weitere Eingabe zu ermitteln, die mit der gleichen Ausgabe abgebildet wird. Eine Hashfunktion ist stark kollisionsfrei, wenn es rechnerisch undurchführbar ist, beliebige zwei Eingaben zu ermitteln, die mit der gleichen Ausgabe abgebildet werden. Zu bekannten One-Way-Hashfunktionen zählen MD2, MD5 und SHA-1.
Mit dem Einsatz der Public-Key-Kryptografie widmet man sich vielen der inhärenten Sicherheitsprobleme in einem solchen offenen Netzwerk wie dem Internet. Gleichwohl bleiben ohne weitere Maßnahmen zwei erhebliche Probleme offen. Erstens müssen Parteien in der Lage sein, auf öffentliche Schlüssel vieler Entitäten effizient zuzugreifen. Da Kommunikationen und Transaktionen durch die Schlüsselpaare und Entitäten gesichert werden, die ihren öffentlichen Schlüsseln zugeordnet sind und in gewissem Sinn durch sie identifiziert werden, muß es zweitens ein sicheres Verfahren für Dritte geben, um zu verifizieren, daß ein bestimmter öffentlicher Schlüssel wirklich einer bestimmten Entität gehört.
Digitale Zertifikate sind ein Verfahren, diese beiden Probleme zu lösen. Ein "digitales Zertifikat" ist ein Dokument, das einen bestimmten öffentlichen Schlüssel an eine bestimmte Entität, z. B. Einzelpersonen, juristische Personen, Webserver u. ä., auf vertrauenswürdige Weise bindet. Insbesondere wird ein digitales Zertifikat vorzugsweise durch einen vertrauenswürdigen Dritten ausgestellt, der gemeinhin als Zertifizierungsstelle (CA) bezeichnet wird. Das digitale Zertifikat enthält Informationen über die Identität der Entität (auch als Subscriber (Zertifikatserwerber) des digitalen Zertifikats bekannt) und den öffentlichen Schlüssel der Entität, und das digitale Zertifikat ist durch die CA digital signiert.
Das digitale Zertifikat dokumentiert vertrauenswürdig, daß der öffentliche Schlüssel im digitalen Zertifikat an den Subscriber des Zertifikats gebunden ist. Dritte, die diese Informationen verifizieren wollen, können die Authentizität der digitalen Signatur der CA und die Integrität des Inhalts des digitalen Zertifikats auf die zuvor beschriebene Weise verifizieren. Vertraut der Dritte der CA, dann kann er auch darauf vertrauen, daß der öffentliche Schlüssel im digitalen Zertifikat an den Zertifikat-Subscriber gebunden ist. Kommuniziert also eine unbekannte Partei mit dem Dritten unter Verwendung des privaten Schlüssels in Entsprechung zum öffentlichen Schlüssel im digitalen Zertifikat, kann der Dritte ferner darauf vertrauen, daß die unbekannte Partei der im digitalen Zertifikat benannte Subscriber ist. Hat der Dritte keine Grundlage, der CA zu vertrauen, beginnt der Dritte, eine solche Grundlage. aufzubauen, indem das digitale Zertifikat der CA authentifiziert wird. Der Dritte fährt fort, digitale Zertifikate zu authentifizieren, wobei er eine Folge digitaler Zertifikate durchläuft, die CAs ausgestellt wurden, bis er eine CA erreicht, der er vertraut, wobei an diesem Punkt der Dritte darauf vertrauen kann, daß der öffentliche Schlüssel im digitalen Zertifikat an den Zertifikat-Subscriber gebunden ist.
Vorzugsweise stimmen digitale Zertifikate mit dem Format überein, das durch die ITU-Empfehlung X.509 (1997 E): Information Technology – Open Systems Interconnection – The Directory: Authentication Framework, Juni 1997 definiert ist. Das digitale Zertifikat kann auf oder in jeder Art computerlesbarer Medien gespeichert sein, u. a. Festplatten, Smartcards, Flash Memory, Magnetstreifen, z. B. auf der Rückseite von Kreditkarten, oder als aufgedruckte Barcodes.
Aus Sicherheits- und anderen Gründen sind digitale Zertifikate normalerweise nur für eine begrenzte Zeitdauer gültig. Bei der Ausstellung digitaler Zertifikate können sie z. B. ein Datum des Inkrafttretens und ein Ablaufdatum haben, wobei das digitale Zertifikat nur zwischen diesen Daten gültig ist. Wird ein digitales Zertifikat vor seinem Ablaufdatum kompromittiert, kann es ferner gesperrt werden, wobei das digitale Zertifikat auf eine Zertifikatsperrliste gesetzt wird.
Bei einer PKI handelt es sich um ein System zur Implementierung der Sicherheit mit Hilfe von Public-Key-Kryptografie und digitalen Zertifikaten. Bestimmte Dienste kommen zum Einsatz, um die öffentlichen Schlüssel und die zugehörigen digitalen Zertifikate, die in einer PKI verwendet werden, zu erstellen, zu verbreiten, zu warten und zu pflegen. Diese Dienste werden durch Entitäten bereitgestellt, die als Dienstanbieter bezeichnet werden. Aus Sicherheits-, Effizienz- und anderen Gründen sind Dienstanbieter oft auch CAs und müssen sogar CAs sein, um einige Leistungen bereitzustellen. Zu Beispielen für solche Leistungen zählen die Ausstellung neuer digitaler Zertifikate, die Prüfung der Gültigkeit digitaler Zertifikate, die Erzeugung digitaler Signaturen und/oder die Aufbewahrung von Belegen für Transaktionen unter Nutzung der PKI.
1 ist ein Blockdiagramm eines erfindungsgemäßen Beispielsystems 100. Das System 100 weist einen anfordernden Benutzer (Requesting User) 110, einen Zertifikatsnutzer bzw. "vertrauenden" Benutzer (Relying User) 120 und einen Dienstanbieter (Service Provider) 130 für die Public-Key-Infrastruktur (PKI) auf, die miteinander kommunizieren. Optional weist das System 100 eine Datenbank 140 von Transaktionsbelegen auf, die für den Dienstanbieter 130 zugänglich ist.
Die Benutzer 110 und 120 können Einzelpersonen, Gruppen von Einzelpersonen, juristische Personen, z. B. Unternehmen, Computer o. ä. sein. Der Dienstanbieter 130 ist eine Entität, die Dienste im Zusammenhang mit dem Betrieb einer PKI bereitstellt. In diesem speziellen Beispiel stellt der Dienstanbieter 130 digitale Notardienste bereit, um Transaktionsbelege zu erzeugen und anschließend zu verifizieren. Die Belege des Dienstanbieters 130 sind in der Datenbank 140 gespeichert, die normalerweise mit hoher Sicherheit und Zuverlässigkeit gepflegt wird, um die Vertrauenswürdigkeit der Belege in der Datenbank 140 und der durch den Dienstanbieter 130 bereitgestellten Dienste zu erhöhen.
Die Benutzer 110 und 120 kommunizieren mit dem Dienstanbieter 130 und können auch miteinander kommunizieren. Die Kommunikationsverbindungen können durch eine beliebige Anzahl von Einrichtungen hergestellt sein, u. a. über Computernetzwerke, z. B. das Internet, und/oder durch drahtlose Verbindungen. Die Verbindungen brauchen nicht permanent oder anhaltend zu sein. In einer bevorzugten Ausführungsform verwenden die Benutzer 110 und 120 Standard-Webbrowser zur Kommunikation mit dem Webserver des Dienstanbieters 130 über das Internet mit Hilfe des HTTP-Protokolls.
Der anfordernde Benutzer 110 möchte einen Beleg für eine Transaktion erstellen und beauftragt den Dienstanbieter 130 damit. Der vertrauende Benutzer 120 will später den Vollzug der Transaktion verifizieren und tut dies, indem er sich auf den durch den Dienstanbieter 130 erzeugten Beleg verläßt. Der Dienstanbieter 130 kann für weitere Sicherheit sorgen, indem er den Beleg verarbeitet, um die Authentizität des Belegs oder der zugrundeliegenden Transaktion zu verifizieren. Als ein Beispiel kann die Transaktion der Online-Kauf eines Artikels sein, wobei der Dienstanbieter 130 einen Beleg erstellt, um den Kauf zu bezeugen. Alternativ kann die Transaktion das Vorhandensein eines Dokuments sein, wobei der Dienstanbieter 130 einen Beleg erstellt, um den Inhalt des Dokuments zu einer spezifischen Zeit zu bezeugen. In diesem Fall spielt der Dienstanbieter 130 im wesentlichen die Rolle eines digitalen Notars.
Der Begriff "Transaktion" wird breit verwendet. Dazu gehören Ereignisse, z. B. ein Online-Kauf von Waren oder das elektronische Signieren eines Vertrags, sowie von Dokumenten. Das Beispiel von 2 ist im Kontext der Erstellung eines Belegs für eine "Transaktion" im allgemeinen Sinn des Begriffs veranschaulicht. Die bevorzugte Ausführungsform von 4–8 verwendet ein Notarbeispiel, wobei das Bezeugen der "Transaktion" bedeutet, die Existenz eines spezifischen Dokuments zu einer spezifischen Zeit zu bezeugen. Die bevorzugte Ausführungsform von 9 verwendet ein Beispiel, in dem die Transaktion ein Online-Kauf ist. Allerdings sollte klar sein, daß die in diesen beiden letzteren Beispielen dargestellten Grundsätze auch auf andere Transaktionsarten anwendbar sind. Auch der Begriff "Dokument" wird breit verwendet. Dazu gehören jede Art von elektronischem Inhalt, u. a. beispielsweise Audio- oder Videodateien, Softwarecode, Animationen und Datendateien, zusätzlich zu elektronischen Versionen traditioneller Papierdokumente.
2A und 2B sind Ereignisverfolgungen, die den Betrieb des Systems 100 veranschaulichen. 2A zeigt eine Belegerstellung 200, in deren Verlauf der Dienstanbieter 130 einen digitalen Beleg für die Transaktion für den anfordernden Benutzer 110 erstellt. 2B zeigt eine Belegverifizierung 250, in deren Verlauf der Dienstanbieter 130 (der ein anderer Dienstanbieter sein könnte) den digitalen Beleg und/oder die zugrundeliegende Transaktion für den vertrauenden Benutzer 120 (der mit dem anfordernden Benutzer 110 identisch sein könnte) verifiziert. Nicht alle Implementierungen nutzen beide Stufen 200 und 250 oder alle dargestellten Einzelschritte, aber sie sind alle aufgeführt, um verschiedene Aspekte der Erfindung zu veranschaulichen.
In 2A und 2B repräsentiert jeder der gestrichelten. Kästen 110, 120 und 130 eine der Komponenten im System 100. Die durchgezogenen Kästen stellen verschiedene Schritte in den Verfahren dar. Die Lage eines durchgezogenen Kastens innerhalb eines gestrichelten Kastens verweist darauf, daß der Schritt allgemein durch diese Komponente durchgeführt wird. Beispielsweise liegt der Schritt 210 im gestrichelten Kasten für den anfordernden Benutzer 110. Damit wird angezeigt, daß der anfordernde Benutzer 110 allgemein den Schritt 210 des Übertragens einer Anforderung zum Dienstanbieter 130 durchführt. Wie aus den späteren Beispielen aber hervorgeht, soll dies nicht bedeuten, daß der Dienstanbieter 130 keine Rolle spielt. Zum Beispiel kann das Komplettieren der Anforderung eine interaktive Aufgabe sein, an der sowohl der Benutzer 110 als auch der Dienstanbieter 130 beteiligt sind und der Dienstanbieter zumindest die durch den Benutzer 110 gesendete Anforderung empfängt. Vorzugsweise sind die Schritte durch Software implementiert, die auf den verschiedenen Komponenten im System 100 läuft, möglicherweise mit Unterstützung durch spezialisierte Hardwaremodule. Außerdem können sie in Hardware und/oder Firmware implementiert sein.
Gemäß 2A beginnt der anfordernde Benutzer 110; indem er dem Dienstanbieter 130 eine Anforderung sendet 210, einen digitalen Beleg für eine Transaktion zu erstellen. Zur Anforderung gehört normalerweise eine Beschreibung der Transaktion in einem für den Menschen verständlichen Format. Beispielsweise könnte der anfordernde Benutzer 110 eine kurze Textbeschreibung der Transaktion erstellen oder ein Symbol als Darstellung der Transaktion senden, oder eine kurze Zusammenfassung der Transaktion kann automatisch erzeugt werden, wenn die Transaktion vollzogen wird. Zur Anforderung gehören auch Informationen, die durch den Dienstanbieter 130 beim Erstellen des digitalen Belegs zu verarbeiten sind. Diese Informationen können in genormten Formaten bereitgestellt werden, um die Verarbeitung zu erleichtern, und können für den Menschen unverständlich sein. Im Szenario des Online-Kaufs könnten diese Informationen Einzelheiten zur Transaktion und/oder eine Bestätigung der vollzogenen Transaktion aufweisen, z. B. Kreditkartennummer, Kaufbetrag, Kreditkartenau torisierungscode usw. Im Szenario der Online-Vertragsunterzeichnung könnten die digitalen Zertifikate o. ä. Informationen über die signierenden Parteien aufgenommen sein. Im Notarszenario für Dokumente könnte das Dokument selbst aufgenommen sein.
Der Dienstanbieter 130 empfängt 210 sowohl die für den Menschen verständliche Beschreibung als auch die Zusatzinformationen. Er verarbeitet die Zusatzinformationen, um einen fälschungssicheren Nachweis für den Vollzug der Transaktion (z. B. eine digitale Signatur) zu erzeugen 220. Vorzugsweise läßt sich der fälschungssichere Nachweis zu einem späteren Zeitpunkt nicht ändern, ohne daß die Änderung erkannt wird. Beispielsweise könnte der Dienstanbieter für Zeitstempel-, Hash- und/oder digitale Signaturfunktionen als Teil dieser Verarbeitung sorgen. Er könnte auch weitere Informationen aus anderen Quellen zufügen. Die genaue Art der Verarbeitung und des erzeugten Nachweises hängt von der spezifischen Anwendung ab. Der Dienstanbieter speichert 240 einen Beleg für die Transaktion, vorzugsweise in seiner Datenbank 140. In einer bevorzugten Ausführungsform verfügt dieser Beleg über die für den Menschen verständliche Beschreibung, die durch den anfordernden Benutzer 110 bereitgestellt wird 210, den fälschungssicheren Nachweis, der durch den Dienstanbieter 130 erzeugt wird 220, und auch Informationen über die Anforderung des Benutzers 110, um einen digitalen Beleg und die Identität des Benutzers 110 zu erstellen.
Außerdem erstellt 230 der Dienstanbieter 130 einen zweiten digitalen Beleg für die Transaktion, wofür ein Beispiel in 3 gezeigt ist. Der Zweckmäßigkeit halber wird dieser digitale Beleg als digitale Quittung bezeichnet. Normalerweise weist die digitale Quittung 300 eine Beschreibung 310 der Transaktion auf. Zum Beispiel könnte sie die gesamte oder einen teil der für den Menschen verständlichen Beschreibung aufweisen, die vom anfordernden Benutzer 110 empfangen wurde. Zudem weist die digitale Quittung den fälschungssicheren Nachweis 320 auf, der durch den Dienstanbieter 130 erzeugt wurde. In einer Ausführungsform ist der fälschungssichere Nachweis 320 selbst als Teil der digitalen Quittung aufgenommen. In einer alternativen Herangehensweise ist der fälschungssichere Nachweis 320 durch Verweis aufgenommen, indem z. B. ein Zeiger (Pointer) auf den Nachweis als Teil der digitalen Quittung aufgenommen ist. In einer bevorzugten Ausführungsform ist der Nachweis 320 in die digitale Quittung aufgenommen, ist aber für den Menschen verborgen, da der Nachweis für den Menschen oft unverständlich ist. Außerdem weist die digitale Quittung 300 eine Verifizierungsaufforderung 330 auf. Bei Aktivierung der Verifizierungsaufforderung 330 wird der Verifizierungsvorgang des fälschungssicheren Nachweises 320 initiiert. Zu beachten ist, daß in diesem Vorgang keine Notwendigkeit besteht, daß ein Mensch positiv identifiziert, welcher Nachweis zu verifizieren ist, da die digitale Quittung 300 selbst den Nachweis 320 identifiziert. In einer Ausführungsform wird durch Aktivieren der Verifizierungsaufforderung 330 der Nachweis 320 zum Dienstanbieter 130 zur Verifizierung anhand der Datenbank 140 des Dienstanbieters gesendet. In einer alternativen Ausführungsform führt dies zu lokalen Berechnungen, um den Nachweis 320 zu verifizieren. Mit erneutem Bezug auf 2A wird nach Erstellung 230 der digitalen Quittung durch den Dienstanbieter 130 die digitale Quittung zum anfordernden Benutzer 110 übertragen 235, der sie normalerweise zum späteren Gebrauch speichert 237. In einer Ausführungsform speichert 237 die Software des anfordernden Benutzers automatisch die digitale Quittung auf eine für den anfordernden Benutzer 110 transparente Weise.
2B zeigt ein Beispiel dafür, wie ein vertrauender Benutzer 120 die digitale Quittung 300 verwenden würde, um die den zurückliegenden Vollzug der Transaktion zu verifizieren. Der vertrauende Benutzer 120 greift auf die digitale Quittung 300 zu 260. Beispielsweise könnte der anfordernde Benutzer 110 eine Kopie der Quittung 300 dem vertrauenden Benutzer 120 per E-Mail oder anderweitig zusenden, oder der vertrauende Benutzer 120 könnte die Quittung 300 vom Dienstanbieter 130 anfordern oder die Quittung 300 aus einer zentralen Datenbank oder einem zentralen Verzeichnis abrufen. Bei Anzeige 265 der Quittung 300 sieht der vertrauende Benutzer 120 die Beschreibung 310 der Transaktion und die Verifizierungsaufforderung 330. Der Benutzer 120 kann auch den fälschungssicheren Nachweis 320 sehen, was aber nicht unbedingt der Fall ist, da der Nachweis 320 vorzugsweise verborgen ist. Der vertrauende Benutzer aktiviert 270 die Verifizierungsaufforderung 330, was den Verifizierungsvorgang initiiert. In diesem speziellen Beispiel wird der fälschungssichere Nachweis 320 aus der digitalen Quittung extrahiert und zum Dienstanbieter 130 gesendet 280, der den empfangenen Nachweis 320 mit dem entsprechenden Beleg in der Datenbank 140 vergleicht 290. Bei einer Übereinstimmung ist der Nachweis 320 verifiziert. Ansonsten liegt keine Verifizierung vor (unter der Annahme, daß der Nachweis nicht auf anderem Weg verifiziert wurde). In jedem Fall wird das Ergebnis zum vertrauenden Benutzer 120 gesendet 295. Wird in einer bevorzugten Ausführungsform der Nachweis 320 verifiziert, wird eine zweite Verifizierungsaufforderung angezeigt. Durch Aktivieren 202 dieser Aufforderung kann der vertrauende Benutzer 120 einen weiteren Schritt vollführen und die zugrundeliegende Transaktion verifizieren 204 (z. B. die Integrität des zugrundeliegenden Dokuments im digitalen Notarszenario verifizieren).
Zu beachten ist, daß die digitale Quittung 300 sowohl eine Verifizierungsaufforderung 330 als auch den zu verifizierenden fälschungssicheren Nachweis 320 aufweist. Somit ist sie ziemlich in sich geschlossen und in gewissem Sinn "selbstverifizierend". Dies ist ein erheblicher Vorteil, da dadurch die digitale Quittung 300 viel einfacher und intuitiver zu verwenden ist. Beispielsweise braucht der anfordernde Benutzer 120 nicht unabhängig zu identifizieren, welcher Teil des Nachweises zu verifizieren ist. Wiese als weiteres Beispiel die digitale Quittung nicht die Verifizierungsaufforderung 330 auf, wären separate Software oder Anweisungen erforderlich, um den Nachweis 320 zu verifizieren. Dies fügt zusätzliche Komplexität zu, da der vertrauende Benutzer 120 möglicherweise nicht die erforderliche Software und die Anweisungen kennt oder keinen Zugriff darauf hat, besonders weil der vertrauende Benutzer 120 und der anfordernde Benutzer 110 vermutlich unterschiedliche Entitäten sind und unterschiedliche Dienstanbieter mit inkompatiblen Systemen verwenden können. Aber auch wenn der vertrauende Benutzer 120 die gleiche Software verwenden würde, könnte sie in diesem Moment einfach nicht verfügbar sein. Beispielsweise könnte die Software auf einem Computer laufen und die digitale Quittung 300 auf einem anderen. Indem sowohl der fälschungssichere Nachweis 320 als auch die Verifizierungsaufforderung 330 an derselben Stelle aufgenommen sind, umgeht man diese Probleme. Indem ferner die für den Menschen verständliche Beschreibung 310 aufgenommen ist, wird auch der Gebrauch der digitalen Quittung 300 vereinfacht, da sie für Aussagekraft der digitalen Quittung sorgt.
4–8 zeigen eine bevorzugte Ausführungsform des Systems 100 und Verfahrens 200, die über ein HTTP-basiertes System, insbesondere das Internet, abläuft. Die Benutzer 110 und 120 greifen auf das Internet mit Hilfe eines herkömmlichen Webbrowsers zu. Der Dienstanbieter 130 ist mit dem Internet über einen Webserver gekoppelt. Der anfordernde Benutzer 110 möchte einen Beleg dafür erstellen, daß ein spezifisches Dokument zu einer spezifischen Zeit existierte. Im Grunde sucht der anfordernde Benutzer 110 einen digitalen Notar, und diese Funktion wird durch den Dienstanbieter 130 bereitgestellt. Später will der vertrauende Benutzer 120 die vom anfordernden Benutzer 110 behauptete "Beglaubigung" verifizieren und vielleicht auch den Inhalt des spezifischen Dokuments verifizieren. Wie beim Verfahren 200 kann das Verfahren 400 grob in zwei Stufen unterteilt werden: Belegerstellung 400 und Belegverifizierung 450, was in 4A bzw. 4B dargestellt ist.
Gemäß 4A beginnt der anfordernde Benutzer 110, indem er dem Dienstanbieter 130 eine Anforderung zur Erzeugung eines digitalen Belegs für eine Transaktion zusendet 410. In dieser Ausführungsform geschieht dies, indem der anfordernde Benutzer 110 die Website des Dienstanbieters 130 mit einer SSL-URL aufsucht 412, die den Notardienst anbietet. Der Benutzer 110 authentifiziert 414 sich gegenüber dem Dienstanbieter 130 über ein digitales Zertifikat und ein entsprechendes Schlüsselpaar. Für die Zwecke des Notardiensts ist die Identität des anfordernden Benutzers 110 durch das digitale Zertifikat definiert. Der Benutzer 110 navigiert 416 durch die Website des Dienstanbieters 130, um den digitalen Notardienst auszuwählen und fordert den Dienst an, indem er das HTML-Formular 500 gemäß 5 ausfüllt und absendet 418. In dieser Ausführungsform ist das Formular 500 von der Website des Dienstanbieters 130 erhältlich. In alternativen Ausführungsformen kann die gleiche Funktionalität durch andere Formulare aus anderen Quellen oder als eingebettete Funktion in einer Anwendung implementiert sein (z. B. als Schaltfläche "Beglaubigung", die einer Werkzeugleiste in einer Textverarbeitungsanwendung oder dem Druckertreiber zugefügt ist). Im Formular 500 identifiziert der Benutzer 110 das zu beglaubigende Dokument im Feld 510 und fügt auch eine Beschreibung des Dokuments im Feld 520 zu. Beim Absenden 418 werden diese Informationen vom Benutzer 110 digital signiert und zum Dienstanbieter 130 gesendet. Zusätzlich zum Dokumentname 510 und zur Beschreibung 520 wird auch das Dokument selbst zum Dienstanbieter 130 gesendet.
Aus den vom Benutzer 110 empfangenen Informationen erzeugt 420 der Dienstanbieter 130 einen fälschungssicheren Nachweis für das Dokument, der in diesem Beispiel ein Zeitstempel-Token ist, das wie folgt erzeugt wird: Der Dienstanbieter 130 berechnet 422 einen Hash des empfangenen Dokuments (z. B. mit dem Hashalgorithmus SHA-1) und erzeugt 424 dann ein Zeitstempel-Token des Hash. In einer bevorzugten Ausführungsform erzeugt 424 der Dienstanbieter das Zeitstempel-Token, indem er eine von einer vertrauenswürdigen Zeitstempelstelle anfordert. Zum Zeitstempel-Token gehören der Hash des Dokuments, der Zeitstempel, Informationen zur Identifizierung der Zeitstempelstelle und die digitale Signatur der Zeitstempelstelle für alle vorstehenden Details. In einer bevorzugten Ausführungsform folgt das Zeitstempel-Token dem Protokoll gemäß der Beschreibung im Arbeitsentwurf der Internet Engineering Task Force mit dem Titel "Internet X.509 Public Key Infrastructure, Time Stamp Protocol (TSP), draftietf-pkix-time-stamp". In alternativen Ausführungsformen kann der Nachweis andere Formen annehmen. Zum Beispiel kann der Zeitstempelaspekt entfallen, oder ein anderer Fingerabdruck des Dokuments als ein Hash kann verwendet werden. Der Fingerabdruck des Dokuments identifiziert das Dokument vorzugsweise eindeutig.
Der Dienstanbieter 130 speichert 440 einen Beleg für die Beglaubigung in seiner Datenbank 140. Zu diesem Beleg gehören die Anforderung der Beglaubigung durch den Benutzer 110 (die vom Benutzer 110 digital signiert wurde), die Identität des Benutzers 110, der Hash des Dokuments und das Zeitstempel-Token.
Außerdem erzeugt 430 der Dienstanbieter 130 eine digitale Quittung für die Transaktion zur Übertragung zum anfordernden Benutzer 110. 7 zeigt ein Beispiel für diese digitale Quittung 700. Hierbei handelt es sich um ein HTML-Dokument, das die folgenden Elemente sichtbar aufweist: den Na men 710 und die Beschreibung 720 des Dokuments, die vom anfordernden Benutzer 110 empfangen werden, sowie die Zeit 730 für den Zeitstempel. Die digitale Quittung 700 weist auch ein Formular auf. Das Zeitstempel-Token ist im BASE64-Textformat codiert und in das Formular als verborgenes Formularfeld eingebettet, weshalb es nicht in der Anzeige der digitalen Quittung 700 erscheint. Ferner weist das Formular in der digitalen Quittung 700 eine Schaltfläche 740 "Verify Receipt" (Quittung verifizieren) auf (als Schaltfläche in dieser Ausführungsform gezeigt, aber auch als andere Arten benutzeraktivierter Elemente implementierbar). In einer bevorzugten Ausführungsform hat das Formular in der digitalen Quittung 700 die folgende Struktur:
<form method = post action = "https://serviceprovider.com/">
<input type = "hidden" value = "V1">
<input type = submit value = "Verify">
</form>
"https://serviceprovider.com/" ist die SSL-URL des Dienstanbieters 130. Der Wert "V1" ist die BASE64-codierte Version des Zeitstempel-Tokens. Andere Felder können verwendet werden, um zusätzliche Funktionalität zu unterstützen oder zusätzliche Informationen bereitzustellen. Beispielsweise kann auch der anfordernde Benutzer 110 in der digitalen Quittung 700 identifiziert sein.
In einer bevorzugten. Ausführungsform wird die digitale Quittung 700 nicht automatisch erzeugt und zum anfordernden Benutzer 110 gesendet. Statt dessen sendet 432 der Dienstanbieter 130 die Ergebnisse der Beglaubigung zum Benutzer 110, was 6 zeigt. War die Beglaubigung erfolgreich, fragt der Ergebnisbildschirm 600 den Benutzer 110 auch, ob er eine Kopie der digitalen Quittung 700 haben möchte. Fordert der Benutzer 110 eine Kopie an 434 (z. B. durch Klicken auf die Schaltfläche 610 in diesem Beispiel), erzeugt 436 der Dienstanbieter die digitale Quittung 700 und sendet 435 sie zum Be nutzer 110. Der anfordernde Benutzer 110 speichert 437 die digitale Quittung 700, z. B. auf seiner lokalen Festplatte.
4B zeigt ein Beispiel dafür, wie ein vertrauender Benutzer 120 die digitale Quittung 700 verwenden würde, um die Beglaubigung zu verifizieren. Der vertrauende Benutzer 120 greift auf die digitale Quittung 700 zu 460. Der Benutzer 120 könnte Zugriff auf die Kopie der Quittung 700 haben, die durch den anfordernden Benutzer 110 gespeichert ist. Alternativ könnte der Benutzer 120 eine Kopie vom anfordernden Benutzer 110 oder vom Dienstanbieter 130 empfangen. In einem alternativen Szenario postet (veröffentlicht) der anfordernde Benutzer 110 sowohl die digitale Quittung als auch das zugrundeliegende Dokument im Internet. Zum Beispiel könnte der anfordernde Benutzer 110 eine Firma sein, die Pressemitteilungen ausgibt, und würde sowohl die Pressemitteilung als auch die digitale Quittung auf seiner Website posten, so daß interessierte Parteien die Authentizität der Pressemitteilung verifizieren können.
Der vertrauende Benutzer 120 öffnet 465 die digitale Quittung 700 mit dem HTML-Formular mit Hilfe seines Webbrowsers. Wie zuvor erwähnt, gehören zur Anzeige der digitalen Quittung der Name 710 und die Beschreibung 720 des Dokuments, die Zeit 730 für den Zeitstempel und eine Schaltfläche "Verify Receipt" (Quittung verifizieren) 740.
Durch Klicken 470 auf die Schaltfläche 740 wird das Zeitstempel-Token, das im HTML-Formular als verborgener Text eingebettet ist, zum Dienstanbieter 130 übertragen 480. In dieser Ausführungsform wird der verborgene Text zum Dienstanbieter 130 gePOSTet (gesendet) 480. Der Dienstanbieter 130 decodiert 484 die BASE64-Textcodierung, um das ursprüngliche Zeitstempel-Token zurückzugewinnen. Er verifiziert 482 die Vertrauenswürdigkeit des Zeitstempel-Tokens durch Prüfen der digitalen Signatur und vergleicht 490 dann das zurückgewonnene Zeitstempel-Token mit denen in seiner eigenen Datenbank 140. Das Zeitstempel-Token ist verifiziert, wenn es genau mit dem einen in der Datenbank des Dienstanbieters 130 übereinstimmt. Der Dienstanbieter 130 sendet 495 die Ergebnisse des Vergleichs zum vertrauenden Benutzer 120, was die Vertrauenswürdigkeit der digitalen Quittung 700 verifiziert oder nicht verifiziert.
Ist die digitale Quittung 700 verifiziert, sendet der Dienstanbieter 130 auch die Identität des anfordernden Benutzers 110, den Originalnamen 810 des Dokuments, die Beschreibung 820 des Dokuments und die Zeit 830 für den Zeitstempel, die aus der Datenbank 140 des Dienstanbieters 130 abgerufen wurden, was 8 zeigt. Die Antwort 800 weist auch ein Formular mit einer zweiten Verifizierungsaufforderung 840 auf, durch die der vertrauende Benutzer 120 in einem weiteren Schritt das zugrundeliegende Dokument zusätzlich zur Verifizierung der Beglaubigung verifizieren kann.
Zu beachten ist, daß bisher nur die digitale Quittung 700 verifiziert wurde, wogegen das zugrundeliegende Dokument selbst nicht verifiziert wurde. Weiterhin stellt der Dienstanbieter 130 keine Kopie des Dokuments bereit und speichert auch keine Kopie des Dokuments in dieser Ausführungsform, wenngleich er dies in alternativen Ausführungsformen tun könnte. Will sich der vertrauende Benutzer 120 auf den Inhalt des Dokuments verlassen, könnte er zunächst die Integrität dieses Inhalts verifizieren wollen. Dies kann er mit der Schaltfläche "Verify Document" (Dokument verifizieren) 840 tun. Wird z. B. behauptet, daß das Dokument D:\documents\doc-schedules\SalePricelist.doc mit dem beglaubigten Dokument identisch ist, identifiziert der vertrauende Benutzer 120 das Dokument über das Feld "Browse" (Durchsuchen) 850 und klickt 402 dann auf die Schaltfläche "Verify Document" 840. Damit wird das Dokument D:\documents\doc-schedules\SalePricelist. doc zum Dienstanbieter 130 gePOSTet. Informationen, die zum Identifizieren des Zeitstempel-Tokens dienen, werden eben falls zum Dienstanbieter 130 gePOSTet. Beispielsweise werden in einer bevorzugten Ausführungsform die laufende Nummer des Zeitstempel-Tokens und der Hash des Dokuments (wie aus der Datenbank des Dienstanbieters abgerufen) in der Antwort 800 als verborgene Formularfelder eingebettet und dann zum Dienstanbieter 130 gePOSTet, wenn die Schaltfläche "Verify Document" 840 aktiviert wird. Der Dienstanbieter 130 erzeugt 406 einen Hash des empfangenen Dokuments. Der neu erzeugte Hash wird mit dem Hash in dem Zeitstempel-Token verglichen 408, wobei das Ergebnis zum vertrauenden Benutzer 120 zurückgesendet wird 409. Stimmen die beiden Hashwerte überein, liegt eine gute Grundlage für die Annahme vor, daß das empfangene Dokument mit dem Original identisch ist: Stimmen die Hashwerte nicht überein, ist die Annahme begründet, daß das Dokument abgeändert wurde.
In einer alternativen Ausführungsform kann das Dokument selbst Teil der digitalen Quittung sein und kann so gleichzeitig mit der digitalen Quittung verifiziert werden. 9 ist ein Beispiel für eine digitale Quittung 900, die diesen Weg veranschaulicht. In diesem Beispiel hat Greg Whitehead die (Fußballschuhe) Accelerator Cup für $59,95 gekauft. Als Nachweis dieser Transaktion wird das Dokument 910 erzeugt, und auch ein Zeitstempel dieses Dokuments wird erzeugt. Die digitale Quittung 900 für diese Transaktion weist das Dokument 910 als sichtbares Element auf. Genauer gesagt kann das Dokument 910 ursprünglich als gesondertes unabhängiges HTML-Dokument existieren. Normalerweise gehört nicht dieses gesamte Originaldokument zur digitalen Quittung 900. Zum Beispiel sind zumindest die Tags für Anfang und Ende des Dokuments für das ursprüngliche HTML-Dokument nicht erforderlich. Somit findet normalerweise eine gewisse Neuformatierung und möglicherweise auch Bearbeitung beim Einbetten des ursprünglichen HTML-Dokuments 910 in die digitale Quittung 900 statt. Deut lich sollte sein, daß dies allgemein der Fall ist, wenngleich der Unterschied nicht nochmals explizit erwähnt wird.
In einer Implementierung weist die digitale Quittung auch ein HTML-Formular auf, und das Dokument 910 ist im BASE64-Textformat codiert und in das Formular als verborgenes Formularfeld eingebettet. Die digitale Quittung 900 weist auch Javascript-Code auf, der den verborgenen BASE64-Text decodiert und anzeigt, weshalb das Dokument 910 in der digitalen Quittung 900 sichtbar ist. In diesem Beispiel dient das Dokument 910 auch als Beschreibung der Transaktion. Das Formular in der digitalen Quittung 900 weist auch das Zeitstempel-Token auf, aber das Zeitstempel-Token ist im BASE64-Textformat codiert und in das Formular als verborgenes Formularfeld eingebettet, weshalb es nicht in der Anzeige der digitalen Quittung 900 erscheint. Das Formular weist auch eine Schaltfläche "Verify Receipt" (Quittung verifizieren) 940 auf. In einer bevorzugten Ausführungsform ist das Formular wie folgt implementiert:
<form method = post action = "https://serviceprovider.com/">
<input type = "hidden" value = "V1">
<input type = "hidden" value = "V2">
<input type = submit value = "Verify">
</form>
"https://serviceprovider.com/" ist die SSL-URL des Dienstanbieters 130. Der Wert "V1" ist die BASE64-codierte Version des Zeitstempel-Tokens, und der Wert "V2" ist die BASE64-codierte Version des Dokuments 910. In einer alternativen Ausführungsform sind die Werte "V1" und "V2" Zeiger auf das Zeitstempel-Token bzw. das Dokument statt die tatsächliche Folge und das tatsächliche Dokument.
Durch Klicken auf die Schaltfläche 940 werden die Werte V1 und V2 (d. h. die BASE64-codierten Versionen des Zeitstempel-Tokens und des Dokuments 910) zum Dienstanbieter 130 gePOSTet. Der Dienstanbieter 130 decodiert die BASE64-Textco dierung, um die ursprüngliche Zeitstempel-Token und das Dokument 910 zurückzugewinnen. Er verifiziert die Vertrauenswürdigkeit des Zeitstempel-Tokens durch Prüfen der digitalen Signatur und vergleicht das zurückgewonnene Zeitstempel-Token mit denen in seiner eigenen Datenbank 140. Außerdem verifiziert der Dienstanbieter 130 die Authentizität des Dokuments 910. Der Dienstanbieter 130 sendet die Ergebnisse dieser Vergleiche zum vertrauenden Benutzer 120, wodurch die Vertrauenswürdigkeit der digitalen Quittung 900 mit dem Dokument 910 verifiziert oder nicht verifiziert wird. In einer alternativen Ausführungsform können einige oder alle Berechnungen (z. B. Verifizieren der Authentizität des Dokuments 910) beim Client des vertrauenden Benutzers 120 lokal erfolgen.
Statt daß die digitale Quittung das Zeitstempel-Token, das zugrundeliegende Dokument und die Schaltfläche "Verify" enthält, werden in einer Abwandlung dieser Herangehensweise diese drei Elemente separat im Internet gePOSTet, was 10 zeigt. In 10 wird das zugrundeliegende Dokument 1010, eine Pressemitteilung, an einer Stelle präsentiert. Eine "Notarquittung" 1020, die das Zeitstempel-Token enthält, wird separat präsentiert; gleiches gilt für ein "Siegel" 1030, das ein Formular ist, das die Schaltfläche "Verify" 1040 und Zeiger auf, das Dokument und das Zeitstempel-Token enthält. In diesem Beispiel dient die physische Plazierung als Hinweis darauf, daß die Notarquittung 1020 und das Siegel 1030 der Pressemitteilung 1010 entsprechen. Obwohl die physische Plazierung anders aussieht, hat das Aktivieren der Schaltfläche "Verify" 1040 den gleichen Effekt wie das Aktivieren der Schaltfläche "Verify" in den vorherigen Beispielen. Insbesondere werden sowohl das Zeitstempel-Token als auch das zugrundeliegende Dokument zum Dienstanbieter 130 zur Verifizierung gePOSTet. Anders gesagt spielt das Siegel 1030 in diesem Szenario eine ähnliche Rolle wie die digitalen Quittungen 700 und 900 im Hinblick auf die Initiierung des Verifizierungsvorgangs.
Obwohl die Erfindung anhand bestimmter bevorzugter Ausführungsformen recht detailliert beschrieben wurde, sind andere Ausführungsformen deutlich. Zum Beispiel wurden die Beispiele von 4–10 im Kontext von HTML-Dokumenten beschrieben, aber XML und andere Standard-Auszeichnungssprachen sind gleichermaßen zum Einsatz geeignet. In einer XML verwendenden Ausführungsform wird ein Dokumenttyp für die digitale Quittung definiert, und Elementtypen, Attribute, Entitäten und Notationen für den Inhalt in der digitalen Quittung werden deklariert. In einer alternativen Ausführungsform können auch Binärdateien verwendet werden, wobei Felder innerhalb der Dateien definiert sind, um für ähnliche Funktionalität zu sorgen. Als weiteres Beispiel wurden die meisten der Beispiele im Kontext von Dokumenten und Zeitstempel-Token selbst diskutiert (oder allgemeiner im Kontext von Transaktionen und dem entsprechenden Nachweis). Wie aber in einigen der Beispiele veranschaulicht ist, können alternative Implementierungen statt dessen Verweise oder Zeiger verwenden. Zudem kann die Funktionalität offline implementiert sein oder im Stapelbetrieb verarbeitet werden. Daher sollte der Schutzumfang der beigefügten Ansprüche nicht auf die Beschreibung der hierin enthaltenen bevorzugten Ausführungsformen beschränkt werden.

Claims

Computerlesbares Medium zum Dienen als Beleg für einen Vollzug einer Transaktion, wobei das computerlesbare Medium folgendes speichert: eine digitale Quittung für die Transaktion, die zur Anzeige für Menschen geeignet ist, wobei die digitale Quittung aufweist: eine Beschreibung der Transaktion in einem für Menschen verständlichen Format; einen fälschungssicheren Nachweis für den Vollzug der Transaktion; und eine Verifizierungsaufforderung zum Verifizieren des fälschungssicheren Nachweises, ohne weiterer menschlicher Interaktion zu bedürfen, um den fälschungssicheren Nachweis zu identifizieren, wobei: die Transaktion eine Existenz eines Dokuments zu einer spezifischen Zeit ist; die digitale Quittung ein Formular in einer Standard-Auszeichnungssprache aufweist, wobei das Formular das als verborgenen Text codierte Dokument aufweist; die Beschreibung der Transaktion aufweist: einen Namen, der das Dokument identifiziert, und eine Zeit, die die spezifische Zeit identifiziert; der fälschungssichere Nachweis ein digital signiertes Zeitstempel-Token aufweist, das als verborgener Text im Formular codiert ist, wobei das Zeitstempel-Token aufweist: einen Fingerabdruck des Dokuments, und einen Zeitstempel für das Dokument; und die Verifizierungsaufforderung ein benutzeraktiviertes Element im Formular aufweist, wobei durch Aktivierung des benutzeraktivierten Elements der verborgene Text des fälschungssicheren Nachweises und der verborgene Text des Dokuments zu einem Dienstanbieter zur Verifizierung übertragen werden.
Computerlesbares Medium nach Anspruch 1, wobei bei Anzeige der digitalen Quittung die Beschreibung der Transaktion und die Verifizierungsaufforderung angezeigt werden, aber der fälschungssichere Nachweis nicht angezeigt wird.
Computerlesbares Medium nach Anspruch 1, wobei der fälschungssichere Nachweis einen Fingerabdruck der Transaktion aufweist.
Computerlesbares Medium nach Anspruch 1, wobei der fälschungssichere Nachweis eine digitale Signatur aufweist.
Computerlesbares Medium nach Anspruch 1, wobei der fälschungssichere Nachweis einen Zeitstempel für die Transaktion aufweist.
Computerlesbares Medium nach Anspruch 1, wobei der fälschungssichere Nachweis durch Verweis in die digitale Quittung aufgenommen ist.
Computerlesbares Medium nach Anspruch 1, wobei die digitale Quittung in einer Standard-Auszeichnungssprache vorliegt.
Computerlesbares Medium nach einem der Ansprüche 1 bis 7, wobei: bei Anzeige der digitalen Quittung ein Script das Dokument decodiert und anzeigt.
Computerlesbares Medium nach einem der Ansprüche 1 bis 7, wobei das Dokument durch Verweis in die digitale Quittung aufgenommen ist.
Verfahren zum Erstellen eines Belegs für einen Vollzug einer Transaktion mit den folgenden Schritten: Empfangen einer Anforderung von einem anfordernden Benutzer, eine digitale Quittung für die Transaktion zu erstellen; Erzeugen eines fälschungssicheren Nachweises für den Vollzug der Transaktion; und Erstellen einer digitalen Quittung für die Transaktion, die zur Anzeige für Menschen geeignet ist, wobei die digitale Quittung aufweist: eine Beschreibung der Transaktion in einem für Menschen verständlichen Format; den fälschungssicheren Nachweis für den Vollzug der Transaktion; und eine Verifizierungsaufforderung zum Verifizieren des fälschungssicheren Nachweises, ohne weiterer menschlicher Interaktion zu bedürfen, um den fälschungssicheren Nachweis zu identifizieren, wobei: die Transaktion eine Existenz eines Dokuments zu einer spezifischen Zeit ist; die digitale Quittung ein Formular in einer Standard-Auszeichnungssprache aufweist; und der Schritt des Erstellens der digitalen Quittung die folgenden Schritte aufweist: Aufnehmen eines das Dokument identifizierenden Namens und einer die spezifische Zeit identifizierenden Zeit als Teil der Beschreibung der Transaktion; Codieren eines digital signierten Zeitstempel-Tokens als verborgenen Text im Formular, wobei das Zeitstempel-Token einen Fingerabdruck des Dokuments und einen Zeitstempel für das Dokument aufweist; und Implementieren der Verifizierungsaufforderung als benutzeraktiviertes Element in das Formular, wobei durch Aktivierung des benutzeraktivierten Elements der verborgene Text zu einem Dienstanbieter zur Verifizierung übertragen wird.
Verfahren nach Anspruch 10, wobei bei Anzeige der digitalen Quittung die Beschreibung der Transaktion und die Verifizierungsaufforderung angezeigt werden, aber der fälschungssichere Nachweis nicht angezeigt wird.
Verfahren nach Anspruch 10, wobei der fälschungssichere Nachweis durch Verweis in die digitale Quittung aufgenommen wird.
Verfahren nach Anspruch 10, wobei der Schritt des Erzeugens eines fälschungssicheren Nachweises für den Vollzug der Transaktion den folgenden Schritt aufweist: Empfangen des fälschungssicheren Nachweises von einem Dritten.
Verfahren nach Anspruch 10, wobei der Schritt des Erstellens einer digitalen Quittung den Schritt des Erstellens der digitalen Quittung in einer Standard-Auszeichnungssprache aufweist.
Verfahren nach einem der Ansprüche 10 bis 14, wobei: der Schritt des Erstellens einer digitalen Quittung die folgenden Schritte aufweist: Codieren des Dokuments als verborgenen Text in der digitalen Quittung; und Aufnehmen eines Scripts in die digitale Quittung; und bei Anzeige der digitalen Quittung das Script das Dokument decodiert und anzeigt.
Verfahren nach einem der Ansprüche 10 bis 15, wobei das Dokument durch Verweis in die digitale Quittung aufgenommen wird.
Verfahren nach Anspruch 10, ferner mit dem folgenden Schritt: Übertragen der digitalen Quittung zum anfordernden Benutzer.
Vorrichtung zum Erstellen eines Belegs für einen Vollzug einer Transaktion, wobei die Vorrichtung aufweist: eine Einrichtung zum Empfangen einer Anforderung, eine digitale Quittung für die Transaktion zu erstellen; eine Einrichtung zum Erzeugen eines fälschungssicheren Nachweises für den Vollzug der Transaktion; und eine Einrichtung zum Erstellen einer digitalen Quittung für die Transaktion, die zur Anzeige für Menschen geeignet ist, wobei die digitale Quittung aufweist: eine Beschreibung der Transaktion in einem für Menschen verständlichen Format; den fälschungssicheren Nachweis für den Vollzug der Transaktion; und eine Verifizierungsaufforderung zum Verifizieren des fälschungssicheren Nachweises, ohne weiterer menschlicher Interaktion zu bedürfen, um den fälschungssicheren Nachweis zu identifizieren, wobei: die Transaktion eine Existenz eines Dokuments zu einer spezifischen Zeit ist; die digitale Quittung ein Formular in einer Standard-Auszeichnungssprache aufweist; die Beschreibung der Transaktion aufweist: einen Namen, der das Dokument identifiziert, und eine Zeit, die die spezifische Zeit identifiziert; der fälschungssichere Nachweis ein digital signiertes Zeitstempel-Token aufweist, das als verborgener Text im Formular codiert ist, wobei das Zeitstempel-Token aufweist: einen Fingerabdruck des Dokuments, und einen Zeitstempel für das Dokument; und die Verifizierungsaufforderung ein benutzeraktiviertes Element im Formular aufweist, wobei durch Aktivierung des benutzeraktivierten Elements der verborgene Text zu einem Dienstanbieter zur Verifizierung übertragen wird.
Vorrichtung nach Anspruch 18, wobei: die digitale Quittung in einer Standard-Auszeichnungssprache vorliegt.
Vorrichtung nach Anspruch 18 oder 19, wobei: das Dokument als verborgener Text codiert ist; und bei Anzeige der digitalen Quittung ein Script das Dokument decodiert und anzeigt.
Softwareprogrammprodukt zum Erstellen eines Belegs für einen Vollzug einer Transaktion, wobei das Softwarepro grammprodukt den Betrieb eines Prozessors durch Ausführung der Software durch den Prozessor steuert, wobei die Software die folgenden Schritte ausführt: Empfangen einer Anforderung, eine digitale Quittung für eine Transaktion zu erstellen; Erzeugen eines fälschungssicheren Nachweises für den Vollzug der Transaktion; und Erstellen einer digitalen Quittung für die Transaktion, die zur Anzeige für Menschen geeignet ist, wobei die digitale Quittung aufweist: eine Beschreibung der Transaktion in einem für Menschen verständlichen Format; den fälschungssicheren Nachweis für den Vollzug der Transaktion; und eine Verifizierungsaufforderung zum Verifizieren des fälschungssicheren Nachweises, ohne weiterer menschlicher Interaktion zu bedürfen, um den fälschungssicheren Nachweis zu identifizieren, wobei: die Transaktion eine Existenz eines Dokuments zu einer spezifischen Zeit ist; die digitale Quittung ein Formular in einer Standard-Auszeichnungssprache aufweist; der Schritt des Erstellens der digitalen Quittung die folgenden Schritte aufweist: Aufnehmen eines das Dokument identifizierenden Namens und einer die spezifische Zeit identifizierenden Zeit als Teil der Beschreibung der Transaktion; und Codieren eines digital signierten Zeitstempel-Tokens als verborgenen Text im Formular, wobei das Zeitstempel-Token einen Fingerabdruck des Dokuments und einen Zeitstempel für das Dokument aufweist; und die Verifizierungsaufforderung als benutzeraktiviertes Element im Formular implementiert ist, wobei durch Aktivierung des benutzeraktivierten Elements der verborgene Text zu einem Dienstanbieter zur Verifizierung übertragen wird.
Softwareprogrammprodukt nach Anspruch 21, wobei: die digitale Quittung in einer Standard-Auszeichnungssprache vorliegt.
Softwareprogrammprodukt nach Anspruch 21, wobei: die digitale Quittung ferner ein Script aufweist; der Schritt des Erstellens einer digitalen Quittung den folgenden Schritt aufweist: Codieren des Dokuments als verborgenen Text in der digitalen Quittung, wobei bei Anzeige der digitalen Quittung das Script den verborgenen Text decodiert und das Dokument anzeigt.
Verfahren zum Verifizieren des zurückliegenden Vollzugs einer Transaktion, wobei das Verfahren die folgenden Schritte aufweist: Anzeigen einer digitalen Quittung für die Transaktion, wobei die digitale Quittung aufweist: eine Beschreibung der Transaktion in einem für Menschen verständlichen Format; einen fälschungssicheren Nachweis für den Vollzug der Transaktion; und eine Verifizierungsaufforderung; und Aktivieren der Verifizierungsaufforderung, wodurch der fälschungssichere Nachweis verifiziert wird, ohne weiterer menschlicher Interaktion zu bedürfen, um den fälschungssicheren Nachweis zu identifizieren, wobei: die Transaktion eine Existenz eines Dokuments zu einer spezifischen Zeit ist; und der fälschungssichere Nachweis ein digital signiertes Zeitstempel-Token aufweist, das aufweist: einen Fingerabdruck des Dokuments; und einen Zeitstempel für das Dokument, wobei: die digitale Quittung ein Formular in einer Standard-Auszeichnungssprache aufweist; der fälschungssichere Nachweis als verborgener Text im Formular codiert ist; und die Verifizierungsaufforderung ein benutzeraktiviertes Element im Formular aufweist, wobei durch Aktivierung des benutzeraktivierten Elements der verborgene Text zu einem Dienstanbieter zur Verifizierung übertragen wird.
Verfahren nach Anspruch 24, wobei der Schritt des Anzeigens der digitalen Quittung die folgenden Schritte aufweist: Anzeigen der Beschreibung der Transaktion und der Verifizierungsaufforderung; und Nichtanzeigen des fälschungssicheren Nachweises.
Verfahren nach Anspruch 24, wobei: die digitale Quittung ferner das Dokument aufweist; und wodurch bei Aktivierung der Verifizierungsaufforderung das. Dokument verifiziert wird, ohne weiterer menschlicher Interaktion zu bedürfen, um das Dokument zu identifizieren.
Verfahren nach Anspruch 26, wobei: die digitale Quittung ferner ein Script aufweist; das Dokument als verborgener Text in der digitalen Quittung codiert ist; und der Schritt des Anzeigens der digitalen Quittung den folgenden Schritt aufweist: bei Anzeige der digitalen Quittung erfolgendes Ausführen des Scripts, um den verborgenen Text zu decodieren und das Dokument anzuzeigen.
Verfahren nach Anspruch 24, ferner mit den folgenden Schritten: Empfangen einer Verifizierung des fälschungssicheren Nachweises; und bei Empfang der Verifizierung des fälschungssicheren Nachweises erfolgendes Anzeigen einer zweiten Verifizierungsaufforderung zum Verifizieren der Transaktion.
Verfahren nach Anspruch 28, wobei: die Transaktion eine Existenz eines Dokuments zu einer spezifischen Zeit ist; die digitale Quittung in einer Standard-Auszeichnungssprache vorliegt; der Schritt des Anzeigens der digitalen Quittung die folgenden Schritte aufweist: Anzeigen der digitalen Quittung als ein Formular; Anzeigen eines das Dokument identifizierenden Namens und einer die spezifische Zeit identifizierenden Zeit; Nichtanzeigen eines digital signierten Zeitstempel-Tokens, das als verborgener Text im Formular codiert ist, wobei das Zeitstempel-Token einen Fingerabdruck des Dokuments und einen Zeitstempel für das Dokument aufweist; und Anzeigen der Verifizierungsaufforderung als benutzeraktiviertes Element im Formular, wobei durch Ak tivierung des benutzeraktivierten Elements der verborgene Text zu einem Dienstanbieter zur Verifizierung übertragen wird; der Schritt des Empfangens einer Verifizierung des fälschungssicheren Nachweises den Schritt des Empfangens einer Verifizierung vom Dienstanbieter aufweist, ob der Fingerabdruck und der Zeitstempel in dem zum Dienstanbieter übertragenen verborgenen Text mit einem unabhängig aufbewahrten Beleg für die Transaktion übereinstimmen; und der Schritt des Anzeigens einer zweiten Verifizierungsaufforderung den Schritt des Anzeigens einer Aufforderung aufweist, um zu verifizieren, ob der Fingerabdruck im verborgenen Text mit einem Fingerabdruck eines zweiten Dokuments übereinstimmt, von dem behauptet wird, daß es mit dem Dokument identisch ist, das zu der spezifischen Zeit existierte.