-
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.