DE19960977A1 - System für ein elektronisches Datenarchiv mit Erzwingung einer Zugriffskontrolle beim Datenabruf - Google Patents

Abstract

In einem sicheren Datenarchiv- und -austauschsystem haben sowohl der Dokumenturheber als auch der Archivverwalter Tresorumgebungen. Der Tresor des Dokumenturhebers chiffriert ein Dokument, bevor er es an den Tresor des Archivs sendet. Danach signiert der Tresor des Archivs das chiffrierte Dokument selber, bevor er das Dokument im elektronischen Archiv speichert, und sendet an den Tresor des Urhebers einen Beweis für die Deponierung. Wenn eine Einsicht in das Dokument angefordert wird, erfolgt diese Anforderung vom Tresor der anfordernden Partei an den Tresor des Archivs. Der Tresor des Archivs ruft eine Kopie des chiffrierten Dokuments ab, die er zusammen mit der Identität des Anfordernden an den Tresor des Urhebers sendet. Der Tresor des Urhebers verifiziert die Authorisierung des Anfordernden, dechiffriert dann das Dokument und sendet das dechiffrierte Dokument direkt an den Tresor des Anfordernden.

Description

Gegenstand der Erfindung

Die vorliegende Erfindung betrifft das Gebiet der elektronischen Datenspeicherung und liefert speziell ein sicheres Datenarchiv- und -austauschsystem, das von einer dritten Partei, die die Funktion eines Verwalters ausübt, verwaltet wird, und in dem eine Zugriffskontrolle beim Abruf der Daten erzwungen wird.

Hintergrund der Erfindung

Neuere parallele Fortschritte in der Netzwerkkommunikation und der PKI-Technologie (public key infrastructure - Infrastruktur öffentlicher Schlüssel) haben bewirkt, daß Unternehmen und Institutionen beginnen, elektronische Dokumentation zur Aufzeichnung und für Transaktionen jeglicher Art einzusetzen. Mit Verbesserungen bei der Integrität und Sicherheit der Übertragung kann zuversichtlich davon ausgegangen werden, daß Dokumente, die elektronisch über das Internet und andere offene Netzwerke gesendet werden, intakt und unverfälscht ankommen.

Datenbankverwaltungssysteme, die mit modernen Computerspeichern mit einer Kapazität von mehreren Gigabyte gekoppelt sind, haben es Unternehmen und Institutionen ermöglicht, auf die Aufbewahrung von Dokumenten in Papierform zu verzichten, deren Masse Immobilienkosten verursacht.

Typischerweise müssen Daten, die von einer Stelle stammen, aus verschiedenen Gründen an eine andere übertragen werden, z. B. zur Aufbewahrung, zur Prüfung usw. Die Datenelemente könnten in Form unstrukturierter Dokumentdateien oder strukturierter Datensätze vorliegen wie z. B. Konto- und andere Finanzinformationen. Im Beispiel unstrukturierter Daten kann es notwendig sein, ein Dokument zum Zweck der Prüfung vom Ursprungssystem an andere Computer im gleichen System oder an Computer auf anderen Systemen zu schicken. Dies könnte gleichermaßen in einer Geschäftssituation (z. B. einem Vorschlag für ein Joint Venture oder einer komplexen Angebotsausschreibung) wie auch in einer Institution (z. B. wenn eine Dissertation von akademischen Beratern überprüft wird, bevor sie einer Prüfungskommission vorgelegt wird) vorkommen. Das Dokument ist elektronisch erstellt worden, da auf diese Weise Überarbeitungen und Einfügungen (speziell wenn sie umfangreich sind) leicht eingearbeitet werden können, ohne daß jedesmal das gesamte Dokument neu getippt werden muß.

Wenn das Dokument in elektronischer Form vorliegt, kann es auch leichter überprüft werden, weil es in dieser Form leichter zu übertragen ist. Anstatt das Dokument zu versenden, kann der Ersteller des Dokuments auch die vorgesehenen Prüfer wissen lassen, daß das Dokument zur Verfügung steht, und ihnen den Zugriff darauf ermöglichen. Um das Dokument zu überprüfen, muß den autorisierten Prüfern der Zugriff auf den Speicherort des Dokuments gewährt werden.

Es gibt mehrere Gründe, warum der Ersteller des Dokuments das Dokument nicht lokal speichern möchte. Wenn die lokale Speicherung des Dokuments bedeutet, daß hinter der Firewall anderen Stellen offener Zugriff gewährt wird, besteht ein Sicherheitsrisiko (die Gefahr von Hackerangriffen). Der Zugriff auf den lokalen Speicher stellt auch eine Gefahr für die Datenverwaltung dar, da eine einzige unbedachte Aktion von einem Prüfer die Dokumentdatei löscht. Auch kann mangelnde Verfügbarkeit des Systems und/oder des Netzwerks mögliche Vorteile, die ein Prüfer darin sieht, daß ihm direkter Zugriff auf das Dokument im Speicher gewährt wird, zunichte machen. Die Systemverfügbarkeit gibt an, ob der lokale Computer oder das LAN des Urhebers des Dokuments jederzeit für Prüfer zugänglich ist, und die Netzwerkverfügbarkeit bezeichnet die Einschränkung, daß es für das Netzwerk schwierig sein kann, mehrere Punkte dem lokalen Speicherort zur Verfügung zu stellen, wenn mehrere Prüfer gleichzeitig zugreifen wollen.

In einer Geschäfts- oder Institutionssituation könnte es auch Gründe dafür geben, daß eine unabhängige Verifizierung notwendig ist, um nachzuweisen, daß ein Urheber eines Dokuments dieses an einem bestimmten Datum vorgelegt hat (z. B. ein kommerzielles Angebot).

Eine Lösung besteht darin, das Archiv einer dritten Partei zu nutzen, und zwar speziell einer Partei, deren Zweck es ist, den Dienst einer sicheren Datenarchivierung anzubieten, und die bei Bedarf einen Deponierungsbeweis erbringen kann.

In den US-Patentschriften Nr. 5,615,268 und 5,748,738, beide mit dem Titel "System and Method for Electronic Transmission Storage and Retrieval of Authenticated Documents" und beide der Document Authentication Systems, Inc. übertragen, wird ein System beschrieben, das Datenintegrität und Deponierungsbeweis mit Hilfe eines Windows-Client zur Kommunikation mit den Datenspeicherdateien anbietet.

Eine wichtige Überlegung, die in diesen Patentschriften nicht angesprochen wird, ist, daß die Integrität der im Archiv gespeicherten Daten und der Zugriff auf diese Daten nicht von den Aktionen der dritten Partei, die das Dokumentarchiv verwaltet, abhängig sein darf. Anders ausgedrückt, der Datenverwalter darf nicht in der Lage sein, unabsichtlich oder böswillig den Inhalt der Daten zu verändern, ohne daß dies von den Systembenutzern bemerkt wird. Außerdem darf es dem Datenverwalter nicht möglich sein, das Zugriffsrecht oder die Verweigerung des Zugriffsrechts eines Benutzers auf ein Datenelement zu ändern.

In dem genannten System der US-Patentschriften 5, 615,268 und 5,748,738 wird darauf vertraut, daß der Datenarchivservice die Daten nicht für andere Benutzer einsehbar macht. In diesem System gibt es keine Vorkehrungen, die die Vertraulichkeit der Daten mit Hilfe der Verschlüsselungstechnologie gewährleistet.

Kurzbeschreibung der Erfindung

Es ist deshalb eine Aufgabe der vorliegenden Erfindung, ein System zur elektronischen Speicherung und zum elektronischen Austausch von Dokumenten zur Verfügung zu stellen, in dem die Dokumente physisch in einem von einer dritten Partei verwalteten Archiv gespeichert werden, in dem die Benutzer aber auf ihre Dokumente zugreifen und sie mit anderen gemeinsam benutzen können.

Eine weitere Aufgabe der Erfindung besteht darin, ein System zur Verfügung zu stellen, in dem die Integrität der im Archiv gespeicherten Daten und der Zugriff darauf nicht von den Aktionen der dritten Partei, die das Archiv verwaltet, abhängig ist.

In einem Aspekt hat die vorliegende Erfindung also ein sicheres elektronisches Datenspeicherungs- und -abrufsystem zum Ziel, das aus einem Datenarchiv, einem Datenarchiv- Verwalter, der Speicherung und Abruf verschlüsselter elektronischer Daten eines das Dokument deponierenden Computers in das und aus dem Archiv verwaltet, und einem Agentenprogramm des zur Speicherung verwendeten Computers besteht. Das Agentenprogramm ist für den Archiv-Verwalter immer zugänglich, unabhängig davon, ob der Computer online oder offline arbeitet. Das Agentenprogramm besitzt auch Mittel, um nach Authentifizierung eines anfordernden Computers die verschlüsselten elektronischen Daten des deponierenden Computers, die auf Anfrage des anfordernden Computers aus dem Datenarchiv abgerufen werden, zu dechiffrieren. Vorzugsweise kann der Archivverwalter die chiffrierten elektronischen Daten mit einer digitalen Signatur versehen, bevor sie im Datenarchiv gespeichert werden, und dann eine Kopie der mit der Signatur versehenen chiffrierten Daten an das Agentenprogramm senden, so daß das Agentenprogramm nach der Dechiffrierung anhand der signierten chiffrierten Daten die abgerufenen chiffrierten elektronischen Daten überprüfen kann.

In einem anderen Aspekt liefert die vorliegende Erfindung ein System und ein Verfahren zur sicheren Authentifizierung des Benutzerzugriffs auf elektronische Daten, die in einem Datenarchiv gespeichert sind, das von einem Archiv-Verwalter verwaltet wird, der mit der Quelle der Daten nichts zu tun hat, wobei den elektronischen Daten bei der Speicherung im Datenarchiv eine Zugriffskontroll-Liste der Benutzerzugriffsberechtigungen zugeordnet wird. Die Quelle ist für die Aktualisierung der Zugriffskontroll-Liste zuständig und erbringt Nachweis der aktuellen Zugriffskontroll-Liste. Der Nachweis der aktuellen Zugriffskontroll-Liste wird auch jedem Benutzercomputer, der die Aktualisierung vorgenommen hat, zur Verfügung gestellt.

Die Quelle überprüft, bevor sie die Daten für den anfordernden Computer freigibt, ob die aktualisierte Zugriffskontroll-Liste, die mit den elektronischen Daten im Datenarchiv gespeichert ist, korrekt ist.

Die Verwendung der Erfindung ist besonders vorteilhaft in einem System mit einer großen Anzahl von Dokumenten, die von einer großen Anzahl von Benutzern benutzt werden können und benutzt werden. Die Zentralisierung der Benutzerzugriffsdaten verbessert die Systemeffizienz, da auf diese Weise eine Duplikation der Information vermieden wird. Außerdem ermöglicht die Verwendung einer mächtigen, zentralisierten Suchautorität eine umfangreichere Suche - Parameter müssen nicht auf die Dokumentidentität beschränkt sein, sondern können möglicherweise andere Identifikationsdaten enthalten, z. B. die Erstellungszeit, die Identität des Dokumenturhebers usw.

Die Erfindung kann in Form von Datenträgern, die mit Programmcode codiert sind, realisiert werden, um das oben beschriebene System oder die beschriebenen Verfahren zu realisieren.

Kurzbeschreibung der Zeichnungen

Im folgenden werden Ausführungsbeispiele der Erfindung ausführlich in Verbindung mit den beigefügten Zeichnungen beschrieben. Die Zeichnungen haben folgenden Inhalt:

Fig. 1 ist eine Schemazeichnung von einem Dokumentarchivsystem, das von einer dritten Partei verwaltet wird.

Fig. 2 ist eine Schemazeichnung, ähnlich wie Fig. 1, in der ein Tresor-Dokumentarchivsystem dargestellt ist, das in der bevorzugten Ausführungsform der vorliegenden Erfindung verwendet wird.

Fig. 3 ist ein Flußdiagramm des Dokumenterstellungsverfahrens gemäß der Erfindung.

Fig. 4, bestehend aus Fig. 4A und Fig. 4B ist ein Flußdiagramm des Dokumentabrufverfahrens gemäß der Erfindung.

Fig. 5 ist ein Flußdiagramm eines Verfahrens, gemäß der bevorzugten Ausführungsfarm der Erfindung, das für die Unveränderlichkeit der Zugriffskontrolle für den Dokumentabruf sorgt.

Fig. 6 schließlich ist ein Flußdiagramm eines erfindungsgemäßen Verfahrens zur Zuordnung von Eignerzurgriffsrechten auf gespeicherte Dokumente.

Ausführliche Beschreibung der bevorzugten Ausführungsformen

Eine konventionelle Anordnung für ein Dokumentarchivsystem, bei dem eine dritte Partei als Verwalter agiert, ist in Fig. 1 dargestellt. Ein Dokumenturheber 100 kann Dokumente über seine Verbindung 102 mit einem fernen Dokumentarchivdienst 104, z. B. einer von einer dritten Partei verwalteten Datenbank, deponieren. Als Eigner der deponierten Dokumente kann der Urheber 100 Zugriffsrechte auf die Dokumente zuweisen. Der Urheber eines Dokuments kann beispielsweise festlegen, daß ein Geschäftspartner 106 die "Lese"-Berechtigung hat, d. h. daß er das Dokument über seine Verbindung 108 mit dem Dokumentarchivdienst 104 abrufen, aber nicht ändern darf.

In solchen konventionellen Systemen ist das vom Urheber 100 deponierte Dokument normalerweise nicht verschlüsselt, so daß der Geschäftspartner 106 das Dokument auf Verlangen prüfen kann. Der Grund dafür ist, daß es nach dem Stand der Technik Probleme mit der Dechiffrierung von Dokumenten gibt. Für die Dechiffrierung eines Dokuments ist der Zugriff auf den privaten Schlüssel des Dokumenturhebers 100 erforderlich. Um den Zugriff auf seinen privaten Schlüssel zu ermöglichen, muß der Dokumenturheber 100 entweder selber zu allen Zeiten, zu denen möglicherweise eine Dechiffrierung angefordert werden könnte, online erreichbar sein, um die Dechiffrierung selber vorzunehmen (die Frage der Systemverfügbarkeit), oder er muß im voraus einen Plan entwickeln, um seinen privaten Schlüssel dem Geschäftspartner 106 direkt oder über einen vertrauenswürdigen Proxy-Server (nicht dargestellt) zukommen zu lassen.

In der US-Patentschrift Nr. 5,491,750 der International Business Machines Corporation, mit dem Titel "Method and Apparatus for Three-Party Entity Authentication and Key Distribution Using Message Authentication Codes", wird ein System beschrieben, das die Verteilung geheimer Sitzungsverwaltungsschlüssel ermöglicht, die von zwei oder mehr Kommunikationspartern gemeinsam benutzt werden können, nachdem die Kommunikationspartner durch einen vertrauenswürdigen Vermittler authentifiziert worden sind. Die so erzeugten Schlüssel und andere ähnliche sind aber kurzlebig und ihre Verwendung sollte auf das absolut Notwendige beschränkt werden. Es ist nicht klar, daß ein solches Konzept geeignet wäre, Dechiffrierschlüssel in einem Dokumentrevisionssystem mit einem dauerhaften Dokumentarchiv sicher zwischen Kommunikationspartnern zu übertragen.

In konventionellen Systemen, in denen Dokumente für einige Zeit deponiert werden und nicht chiffriert sind (Fig. 1), muß darauf vertraut werden, daß die dritte Partei, die den Archivdienst 104 verwaltet, die Integrität des Dokuments bewahrt.

Das Dokumentarchivsystem in der bevorzugten Ausführungsform der vorliegenden Erfindung ist mit dem Produkt IBM Vault Registry erstellt, das Gegenstand der US-Patentanmeldung Nr. 980,022 mit dem Titel "Secure Server and Method of Operation for a Distributed Information System", eingereicht am 26. November 1977 und der IBM Corporation übertragen, ist. Die US-Patentschrift Nr. 980,022 ist hiermit durch Bezugnahme Teil des vorliegenden Dokuments. Das Produkt IBM Vault Registry bietet eine erweiterte Webserver-Umgebung, die eine sichere Erweiterung, einen sogenannten Tresor, der Klientenumgebung implementiert. Dieses System vertraut auf die im Hintergrund der Erfindung beschriebene moderne Übertragungstechnologie, daß die elektronische Übertragung von Dokumenten und anderen Daten intakt und fehlerfrei ankommt. Ressourcen in einem Client-Tresor sind nur verfügbar, wenn der Zugriff vom Client mit einer starken Authentifizierung mit Hilfe von zertifizierten öffentlichen Schlüsseln erfolgt. Abhängig von der Umgebung kann der Zugriff über den Web-Browser des Client erfolgen.

Der Informationsgehalt des Tresors ist aus Gründen der Vertraulichkeit chiffriert. Jeder Tresor auf einem Server besitzt einen eindeutigen Chiffrierschlüssel und Mechanismen, die den Zugriff auf die Schlüssel verhindern, sofern er nicht über den vom Eigner des Tresors genehmigten vertrauenswürdigen Pfad, z. B. einen Browser, erfolgt. Programme, die in einem Tresor laufen, sind durch Betriebssystemdienste isoliert, um folgendes zu gewährleisten:

• a) daß sie in einem Prozeß mit einer Systemidentität (einem virtuellen Logon) laufen, so daß die Identität abhängigen Prozessen zur Verfügung steht, ohne daß eine Änderung durch ein im Tresor laufendes Programm möglich ist;
• b) daß sie auf den Dateninhalt des Tresors, in dem sie laufen, zugreifen können - aber auf keinen anderen;
• c) daß sie vom Eigner des Tresors für die Ausführung im Tresor genehmigt werden; und
• d) daß sie signiert sind, um Manipulationen und Angriffe durch sog. "Trojanische Pferde" zu verhindern.

Programme, die in einem Tresor laufen, können Informationen in dem gleichen Tresor oder in anderen Tresoren, die gegenseitig sicheren Zugriff ihrer öffentlichen Schlüssel haben, deponiert werden. Normalerweise befinden sich diese Tresore auf dem gleichen Tresorserver, sie können aber auch auf verschiedenen Tresorservern mit Zugriff auf eine gemeinsame Zertifizierungsstelle liegen, die die Information zum öffentlichen Schlüssel. liefert. Im Zusammenhang mit einem Tresorarchiv kann "deponieren" verschiedenes bedeuten. In einer Implementierung kann "deponieren" die Chiffrierung der Daten im Chiffrierschlüssel des Zieltresors und die Signierung der Daten im Signierschlüssel des deponierenden Tresors bedeuten. Tresorprogramme können nicht direkt auf Chiffrier- oder Signierschlüssel zugreifen. Dies geschieht über eine API. Optional kann die "Deponierungs"-Funktion Informationen in eine Warteschlange im Zieltresor schreiben. Eine andere Option bietet einen "Deponierungsbeweis", der bestätigt, daß die Information deponiert wurde, und daß ein Programm im Zieltresor die Daten geöffnet hat. All diese "Deponierungs"-Funktionen bieten ein Mittel, um Informationen so zwischen Tresoren auszutauschen, daß:

• a) ihr Ursprungsprozeß nicht geleugnet werden kann;
• b) ihr Inhalt nicht von denen, die die Interprozeßkommunikationspuffer inspizieren, eingesehen werden kann; und
• c) die Zustellung gewährleistet ist.

Wenn eine Anwendung keine Daten in die Warteschlange des Zieltresors stellen will, kann sie sich dafür entscheiden, die Information in einer Datei oder Datenbank zu speichern oder andere Systemdienste zu benutzen, die die Daten als "undurchsichtiges" Element behandeln können (z. B. Serialisierung für die Fortdauer des Objekts). Diese undurchsichtige Information kann mit Standardverfahren zum Zweck der Sicherung und Wiederherstellung verwaltet werden. Ihr Inhalt kann jedoch nur von einem im Kontext des Eignertresors laufenden Programm mit Hilfe der Sicherverwahrungs-Anwendungsprogrammschnittstelle dechiffriert werden.

Mit dem Produkt IBM Vault Registry wurde die bevorzugte Ausführungsform der Erfindung entwickelt wie in Fig. 2 schematisch dargestellt.

Wie in dem System aus Fig. 1 kann auch in dem in Fig. 2 dargestellten Konzept ein Dokumenturheber 200 Dokumente über seine Verbindung 202 zu einem Dokumentarchivdienst 204 Dokumente deponieren und als Eigner der deponierten Dokumente dritten Parteien 206, z. B. Geschäftspartnern, die über ihre eigenen Netzwerkverbindungen 208 auf die Dokumente im Dokumentarchivdienst 204 zugreifen können, Zugriffsrechte auf die Dokumente zuordnen. Anders als bei dem oben beschriebenen System sind die Benutzer des Dokumentarchivsystems aber nicht gezwungen, darauf zu vertrauen, daß die dritte Partei die Integrität der im Archiv hinterlegten Dokumente bewahrt.

Das Dokumentarchivsystem 204 in der bevorzugten Ausführungsform besteht aus zwei Komponenten, einem Anwendungsserver 210 und einem Tresor-Controller 214. Der Anwendungsserver (AS) ist ein Programm zur Verwaltung des Datenbankarchivs 212, das sich auf dem gleichen System oder auf einem fernen System in einem abgeschlossenen Netzwerk befindet. Der Tresor-Controller 214 enthält mehrere Komponenten: Benutzertresore 216, 218, die individuell den Dokumenturhebern 200 und Geschäftspartnern 206 zugeteilt sind, einen AS-Tresor 220, der dem Anwendungsserver 210 zugeteilt ist, und ein Tresor-Überwachungsprogramm 222.

Ein Benutzertresor 216 oder 218 ist nur für den Benutzer (Dokumenturheber 200 oder Geschäftspartner 206) zugänglich, dem der Tresor zugeordnet ist, und nur nach ordnungsgemäßer Authentifikation. Die einzelnen Tresore haben keinen direkten Zugriff auf die Dokumentdatenbank 212; der Zugriff erfolgt über den AS-Tresor 220 und den Anwendungsserver 210.

Die Anwendungsserver-Komponente 210 läuft nicht auf einer vertrauenswürdigen Computerbasis, sondern kann auf jeder beliebigen Plattform ausgeführt werden. Der Anwendungsserver besitzt eine Gegenkomponente, die im AS-Tresor 220, der ihm im Tresorserver 214 zugeteilt ist, läuft. Der AS-Tresor 220 kann mit dem Anwendungsserver 210 kommunizieren und hat über den Anwendungsserver Zugriff auf die Dokumentdatenbank 212.

Fig. 3 ist ein Flußdiagramm des Dokumenterstellungsprozesses gemäß der bevorzugten Ausführungsform der Erfindung. In der Umgebung von IBM Vault Registry ist ein persönlicher Tresor im Prinzip eine sichere Erweiterung der Umgebung des Tresoreigners. Die Interaktion zwischen den Prozeßschritten in Fig. 3 ist deshalb zwischen den Tresoren des Dokumenturhebers und des Anwendungsservers dargestellt.

Wenn ein Dokument in dem Datenarchiv erstellt wird, wird es zuerst vom Arbeitsplatz des Benutzers, der es erstellt hat oder sein Urheber ist, in den persönlichen Tresor des Benutzers (Dokumenturhebers) gesendet (Block 300), wo das Dokument mit dem privaten Signierschlüssel des Benutzertresors "signiert" wird (Block 302).

Mit einer elektronischen Signatur eines Datenelementes garantiert der Signierende die Integrität des Datenelementes. Eine Signatur kann berechnet werden, indem zuerst ein Digest des Datenelementes berechnet wird. Das Digest ist eine relativ kleine Struktur (z. B. 128 Bit für eine MD2- oder MD5-Zusammenfassung) mit bestimmten Eigenschaften, um die Sicherheit zu gewährleisten. Erstens ist sie eine Einwegfunktion, d. h. aus einem Digest kann das Originaldokument, aus dem es hervorgegangen ist, nicht reproduziert werden. Außerdem ist es unmöglich (oder computertechnisch nicht machbar), zu einem Digest ein zweites Vor-Bild zu finden, das das gleiche Digest hat. Ferner ist das Digest auch kollisionsresistent. Das heißt, es ist äußerst unwahrscheinlich, daß zwei verschiedene Vor- Bilder das gleiche Digest erzeugen.

Das Digest des Datenelementes wird dann mit dem privaten Signierschlüssel der Benutzertresoranwendung chiffriert (Block 304). In der bevorzugten Ausführungsform wird sowohl ein symmetrisches als auch ein asymmetrisches Kryptographieverfahren mit öffentlichem Schlüssel benutzt.

Bei der Kryptographie mit öffentlichem Schlüssel besitzt eine Anwendung zwei Schlüssel, einen öffentlichen und einen privaten, die als Schlüsselpaar bezeichnet werden. Der private Schlüssel wird von der Anwendung lokal gespeichert und wird weiter unten ausführlicher beschrieben. Der öffentliche Schlüssel ist für alle Benutzer zugänglich, in der Regel über einen Verzeichnisdienst, z. B. X500. Die Verteilung öffentlicher Schlüssel ist in Fachkreisen bekannt und wird in der vorliegenden Spezifikation nicht weiter erläutert.

Wenn eine Kryptographie mit öffentlichem Schlüssel verwendet wird, kann ein mit dem öffentlichen Schlüssel chiffriertes Datenelement nur mit dem zugehörigen privaten Schlüssel dechiffriert werden. Entsprechend kann ein mit dem privaten Schlüssel chiffriertes Datenelement nur mit dem öffentlichen Schlüssel dechiffriert werden.

In einer Technologie mit symmetrischem Schlüssel wird für Chiffrierung und Dechiffrierung derselbe Schlüssel verwendet. In der derzeitigen Praxis erfolgen Chiffrierung/Dechiffrierung und Schlüsselgenerierung bei der Technologie mit symmetrischem Schlüssel wesentlich schneller als bei der asymmetrischen Technologie mit öffentlichem Schlüssel.

Daten werden normalerweise mit einem nach dem Zufallsprinzip generierten symmetrischen Schlüssel chiffriert. Dann wird der symmetrische Schlüssel selber mit dem öffentlichen Chiffrierschlüssel des Benutzers chiffriert und mit dem Dokument gespeichert, so daß er Teil des Dokuments wird.

In Fig. 3 wird das chiffrierte Dokument und die elektronische Signatur zum Zweck der Aufbewahrung an den Tresor des Anwendungsservers gesendet (Block 306). Nach Empfang des chiffrierten Dokuments (Block 308) beglaubigt die im Tresor des Anwendungsservers laufende Anwendung die Signatur (Block 310), indem sie sie mit ihrem eigenen privaten Signierschlüssel noch einmal signiert.

Die Beglaubigung einer Signatur in einem elektronischen Kontext bedeutet, daß eine dritte Partei, die als "Notar" fungiert, den Inhalt einer Signatur zertifiziert. (Die Begriffe "Notar" und "beglaubigen" haben in dieser Spezifikation nicht den vollen Bedeutungsumfang aller Pflichten, die einem Notariat von einer Regierungsbehörde übertragen werden.) Allgemein erfolgt eine elektronische Beglaubigung einer Signatur als zusätzliche Vorsichtsmaßnahme, um eine spätere unberechtigte Änderung der Signatur zu verhindern. Im Fall der vorliegenden Erfindung verhindert die Beglaubigung einer digitalen Signatur des Benutzers, daß dieser das Originaldokument im Dokumentarchiv ersetzt oder ändert. Eine Prüfung der beglaubigten Signatur des Dokuments würde jegliche Inkonsistenz ans Tageslicht bringen.

Eine beglaubigte elektronische Signatur enthält zwei Informationen, nämlich die Signatur des betreffenden Datenelements durch den Urheber und die Signatur der Urhebersignatur durch den. Notar. Die Signatur des Notars sollte über die Urhebersignatur und den aktuellen Zeitstempel berechnet werden.

Die Anwendung, die im Tresor des Anwendungsservers läuft, signiert dann das von ihr empfangene Dokument (Block 312). Da die Daten, die er vom Dokumenturheber empfängt, chiffriert sind, kennt der Anwendungsserver faktisch den Inhalt des Dokuments nicht. Deshalb wird gemäß der Erfindung diese zweite Signatur über das chiffrierte Dokument und die beglaubigte Urhebersignatur berechnet. Die Signatur des Anwendungsservers stellt einen Empfangsbeweis dar, der dem Dokumenturheber (demjenigen, der das Dokument deponiert), beweist, daß der Archivdienst das Dokument empfangen hat. Die Erstellung des Dokuments im Archiv kann dann später nicht mehr vom Archivdienst geleugnet werden.

Das chiffrierte Dokument, die beglaubigte Urhebersignatur und der Empfangsbeweis werden im Archiv des Anwendungsservers oder in der Anwendungsdatenbank gespeichert (Block 314). Der Empfangsbeweis wird an den Tresor des Dokumenturhebers gesendet (Block 316). Der Tresor des Dokumenturhebers prüft die Richtigkeit des Empfangsbeweises (Block 318), indem die Signatur des chiffrierten Dokuments überprüft wird. Der Tresor des Dokumenturhebers prüft auch die Aktualität des Zeitstempels in der beglaubigten Signatur (Block 320). Die Toleranz für den Zeitstempel hängt von der Anwendung ab. Wenn bei einer dieser Prüfungen ein Fehler erkannt wird, wird eine Fehlermeldung an den AS-Tresor gesendet (Block 322) und im System protokolliert. Wenn der Empfang korrekt und aktuell ist, sendet die Anwendung, die im Tresor des Benutzers läuft, den Empfangsbeweis an den verursachenden Benutzer zurück (Block 324), damit sie für eine spätere Referenz in einem lokalen Cache gespeichert wird, falls bewiesen werden muß, daß das Dokument im Archiv gespeichert worden ist.

Es ist möglich, daß der Dokumenturheber das Dokument mit einem eigenen Verfahren signieren und/oder chiffrieren kann, bevor er es zur Speicherung in seinen Tresor sendet. Das Dokumentarchiv beachtet dsen Inhalt des zu speichernden Dckuments aber nicht. Ein chiffriertes Dokument wird deshalb vom Tresor des Benutzers erneut signiert und chiffriert, wie jedes andere Dokument.

Fig. 4 ist ein Flußdiagramm, in dem dargestellt ist, welche Schritte gemäß der bevorzugten Ausführungsform der Erfindung ausgeführt werden müssen, damit das Dokument von einem anfordernden Benutzer abgerufen werden kann, der unter der Zugriffskontroll-Liste (ACL) des Dokumenturhebers autorisiert worden ist. Die Erstellung und Verwaltung von Zugriffskontroll-Listen wird weiter unten ausführlich beschrieben.

Wie in Fig. 3 sind die Prozeßschritte in Fig. 4 die Aktionen und Interaktionen zwischen den Tresoren des Dokumenturhebers, des Anwendungsservers und des anfordernden Benutzers, auf der Basis, daß deren persönlichen Tresore im Prinzip sichere Erweiterungen ihrer betreffenden Arbeitsbereiche, die in IBM Vault Registry oder einer Umgebung mit ähnlichen Eigenschaften zur Verfügung gestellt werden, sind.

In Fig. 4A stellt der Benutzer an seine Tresoranwendung eine Anforderung, ein Dokument aus dem Anwendungsserverarchiv abzurufen (Block 400), und seine Tresoranwendung sendet dann ihrerseits die Dokumentabrufanforderung an den Anwendungsserver-Tresor (Block 402).

Die Tresoranwendung des Anwendungsservers empfängt die Zugriffsanforderung (Block 404) und ruft das chiffrierte Dokument, die beglaubigte Signatur des Urhebers und die ACL aus der Anwendungsdatenbank ab.

Die Tresoranwendung des Anwendungsservers sendet das chiffrierte Dokument, die beglaubigte Signatur und die signierte ACL an den Tresor des Dokumenturhebers. Der Tresor des Anwendungsservers sendet auch den Identitätstresor des anfordernden Benutzers an den Tresor des Urhebers (Block 408).

Der Tresor des Urhebers prüft, ob der anfordernde Benutzer die Berechtigung zum Abrufen des Dokuments besitzt (Block 412). Die Dokumentzugriffskontrolle wird in der bevorzugten Ausführungsform durch Zugriffskontroll-Listen aktiviert, mit denen der Zugriff auf das Dokument auf autorisierte Stellen beschränkt wird. Eine Zugriffskontroll-Liste ist einem Dokument zugeordnet und muß geprüft werden, wenn ein Benutzer eine Dokumentabrufanforderung sendet. Ein anfordernder Benutzer erhält nur eine Kopie des Dokuments, wenn er das Zugriffsrecht besitzt. Wenn Fähigkeitslisten benutzt werden, kann anfordernde Benutzer sein Zugriffsrecht im voraus überprüfen, bevor er eine Anforderung stellt. Wenn der anfordernde Benutzer keine Zugriffsberechtigung auf das Dokument besitzt, wird eine Fehlermeldung an den Urheber gesendet und im System protokolliert (Block 414).

In Fig. 4B wird, wenn der anfordernde Benutzer die Zugriffsberechtigung für das Dokument besitzt, das Dokument von der Tresoranwendung des Urhebers dechiffriert (Block 416) und die beglaubigte Signatur überprüft (Block 418).

Da die Originalsignatur des Urhebers über den unchiffrierten Dokumentinhalt berechnet wurde, können nur diejenigen Benutzer, die auf den Dokumentinhalt zugreifen können, die Signatur prüfen. Wenn die empfangene Signatur nicht dem dechiffrierten Dokument entspricht, ist klar, daß es sich nicht um dieselbe Version des Dokuments handelt, die deponiert wurde, und der Urheber sendet eine Fehlernachricht an den Anwendungsserver (Block 420).

Wenn die Signatur geprüft worden ist, sendet der Urheber das dechiffrierte Dokument und die beglaubigte Signatur an den Tresor des anfordernden Benutzers (Block 422).

Nach Empfang des dechiffrierten Dokuments versucht die Tresoranwendung des anfordernden Benutzers, die beglaubigte Signatur des Urhebers mit Hilfe des öffentlichen Signaturschlüssels des Notars zu prüfen (Block 424). Wenn der anfordernde Benutzer sie nicht verifizieren kann, wird eine Fehlermeldung an den Urheber gesendet und im System protokolliert (Block 426).

Wenn die beglaubigte Signatur des Urhebers verifiziert werden kann, signiert der Tresor des Anfordernden die mit dem Dokument empfangene beglaubigte Signatur. Diese Signatur wird über die beglaubigte Signatur und über den aktuellen Zeitstempel berechnet und stellt einen Empfangsbeweis dar (Block 428), der belegt, daß das Dokument aus dem Archiv abgerufen wurde. Der Tresor des Anfordernden sendet das dechiffrierte Dokument zusammen mit dem von ihm generierten Empfangsbeweis an den Arbeitsplatz des Anfordernden (Block 430). Der Tresor des Anfordernden sendet auch den Empfangsbeweis an den Anwendungsserver-Tresor (Block 432). Der Anwendungsserver verifiziert die Signatur des Anforderertresors auf dem Empfangsbeweis (Block 434). Wenn die Signatur nicht dem Dokument entspricht, wird der Empfangsbeweis als falsch oder als "fehlend" markiert und in den Cache geschrieben, falls die Anwendung über eine solche Speicherfunktion verfügt (Block 436). Wenn die Signatur verifiziert werden kann, speichert der Anwendungsservertresor den Empfangsbeweis in der Anwendungsdatenbank, als Beweis dafür, daß der Anfordernde das Dokument tatsächlich abgerufen hat (Block 438).

Unveränderlichkeit der Zugriffskontrolle für den Dokumentabruf

Wie bereits erwähnt besteht in einem Datenarchiv die Notwendigkeit eine Dokumentzugriffskontrolle. Dies bedeutet, daß nur die vom Dokumenteigner autorisierten Benutzer Einsicht in die Dokumente haben, und daß Dokumentzugriffsberechtigungen nur vom Dokumenteigner (d. h. vom Urheber) selber und von den Personen, die vom Dokumenteigner die Berechtigung zum Ändern der Zugriffskontroll-Liste für das Dokument erhalten haben, geändert werden können. Es ist wichtig, daß sichergestellt ist, daß selbst der Archivverwalter nicht in der Lage ist, ohne Autorisierung durch den Dokumenteigner die Zugriffsberechtigungen für ein Dokument zu ändern.

Es gibt zwei verschiedene Arten von Anwendungsanforderungen für die Realisierung der Unveränderlichkeit der Dokumentzugriffskontrolle. Der Dokumentzugriff sollte in folgenden Fällen geprüft werden:

• 1. wenn ein Benutzer eine Suche durchführt, um alle Dokumente zu finden, für die er die Berechtigung zum Betrachten hat; und
• 2. wenn ein Benutzer tatsächlich ein Dokument abruft.

Alle Anwendungen müssen die Zugriffskontrolle beim Dokumentabruf (Zugriffsart: 2) erzwingen. Für diese Zugriffsart muß das Archiv garantieren, daß die Zugriffskontrolle eines Dokuments nicht von einem nicht autorisierten Benutzer, z. B. einem Konkurrenten, geändert werden kann.

Manche Anwendungen müssen auch eine Zugriffskontrolle bei der Dokumentsuche erzwingen, insbesondere in Situationen, in denen Benutzer kein anderes Mittel als den Anwendungsserver des Archivs besitzen, um festzustellen, auf welche Dokumente sie zugreifen dürfen. Ein System, daß die Unveränderlichkeit der Zugriffskontrolle sowohl bei der Dokumentsuche als auch beim Abruf erzwingt, ist Gegenstand unserer gleichzeitigen Anmeldung mit dem Titel "System for Electronic Repository of Data Enforcing Access Control on Data Search and Retrieval" (IBM Docket No. CA998-040).

In einigen Anwendungen muß ein Benutzer nicht das Dokument abfragen können, um festzustellen, welche Dokumente er betrachten darf. Dieses Wissen kann z. B. offline in geschäftlichen Besprechungen, durch E-Mail oder telefonisch übermittelt werden. In einem solchen Fall weiß der Benutzer bereits, auf welche Dokumente er zugreifen kann, und seine Kenntnis seines eigenen Dokumentzugriffs kann nicht von Aktionen des Archivs beeinflußt werden.

In der vorliegenden Ausführungsform ist jedem Dokument eine Zugriffskontroll-Liste (A CL) zugeordnet, die die Dokumentzugriffsberechtigung verschiedener Benutzer festlegt. Um die Unveränderlichkeit zu garantieren, wird jede ACL im Tresor des Dokumenturhebers verarbeitet wie in Fig. 5 zu sehen ist.

Jeder ACL ist eine Versionsnummer und ein Zeitstempel der letzten Änderung zugeordnet. Wenn eine ACL aktualisiert wird (Block 500), wird ihre Versionsnummer inkrementell erhöht (Block 502), und der Zeitstempel der ACL wird durch den aktuellsten Zeitstempel ersetzt (Block 504). Aus der aktuellen Versionsnummer und Zeitstempel, die der ACL jetzt zugeordnet sind, wird ein Token erstellt, das die Unveränderlichkeit der ACL garantieren soll. Das Token wird vom Tresor des Dokumenturhebers signiert (Block 506). Eine Datenstruktur, z. B. eine Textkette oder eine Binärstruktur, wird erzeugt, indem das Token an die ACL angehängt wird (Block 508). Die Datenstruktur wird vom Tresor des Eigners signiert, um auszuschließen, daß sie ersetzt wird (Block 510), und zusammen mit der ACL und dem Token zur Speicherung im Dokumentarchiv an den AS-Tresor gesendet (Block 512).

Das ACL-Token wird auch an den Tresor jedes zum Zugriff auf das Dokument berechtigten Benutzers gesendet, wo es zur Speicherung mit der Zugriffsanwendung des Benutzers auf dessen Arbeitsplatz gespeichert wird (Block 514), damit eine spätere Verifizierung der ACL möglich ist. Das signierte Token wird zur Speicherung an den Arbeitsplatz des Dokumenturhebers gesendet (Block 516). Da der Dokumenturheber eine Kopie des signierten Tokens besitzt, wird er letztlich zum Arbeiter darüber, ob die Dokument-ACL aktuell ist oder nicht.

Wenn ein Geschäftspartner ein Dokument abrufen möchte, sendet die AS-Tresoranwendung das chiffrierte Dokument wie oben beschrieben an den Tresor des Urhebers (Block 408 in Fig. 4A). Zusammen mit dem Dokument, der beglaubigten Signatur und der ID des Anfordernden sendet der AS-Tresor auch die signierte ACL an den Tresor des Urhebers. Um die Berechtigung des Anfordernden zu verifizieren (Block 412 in Fig. 4A), prüft der Tresor des Urhebers dann folgendes:

• 1. ob die ACL-Signatur korrekt ist;
• 2. ob die Versionsnummer und der Zeitstempel mit den im Tresor des Urhebers gespeicherten übereinstimmen; und
• 3. prüft er in der verifizierten ACL, ob der Anfordernde eine Zugriffsberechtigung für das angegebene Dokument besitzt.

Mit diesem Verfahren kann niemand die in der Anwendungsdatenbank gespeicherte ACL ändern, ohne daß dies vom Tresor des Urhebers bemerkt wird.

Wie oben beschrieben besitzt jeder Benutzer, der Eigner von Dokumenten im Archiv ist, auf seinem Arbeitsplatz die signierten Tokens der korrekten Version jeder ACL. Die ACL- Versionen im Benutzertresor werden verifiziert, indem das auf dem Arbeitsplatz des Benutzers gespeicherte Token mit dem im Benutzertresor gespeicherten verglichen wird. Dieser Vergleich kann zu verschiedenen Zeiten ausgeführt werden; eine gute Gelegenheit zur Verifizierung der in einem Benutzertresor gespeicherten ACLs ist das Logon, so daß jedesmal, wenn sich ein Benutzer beim System anmeldet, die ACLs verifiziert werden.

Wenn die Verifizierung der ACL nicht gelingt, kann die Benutzertresoranwendung automatisch die Verarbeitung jeglicher Anforderung, ein von der ACL geschütztes Dokument abzurufen, einstellen. Dieser Zustand der Unveränderlichkeit des Dokuments würde weiterbestehen, bis der Benutzer entweder eine neue ACL erstellt oder die vorhandene ACL neu zertifiziert. Der Prozeß der Rezertifizierung der vorhandenen ACL würde die Synchronisierung des im Benutzertresor gespeicherten ACL-Tokens mit dem auf dem Arbeitsplatz des Benutzers gespeicherten Token einschließen.

In dieser Ausführungsform wird die eigentliche ACL in der Anwendungsdatenbank gespeichert. Wenn ein Benutzer eine Suche der Dokumente, für die er eine Berechtigung besitzt, ausführen will, kann dies nur über die Tresoranwendung des Anwendungsservers, das einzige Programm, das direkt auf die Anwendungsdatenbank zugreifen kann, geschehen. Wenn ein "böswilliger" Anwendungsserver Fehlinformationen über die Zugriffsrechte eines Benutzers auf ein Dokument unterbreitet, kann dies aber festgestellt werden. Der Anwendungsserver hat keinen Zugriff auf das signierte ACL- Token auf der Datenstation oder im Tresor des Benutzers. Wenn der Benutzer das nächste Mal das Token verifiziert, stellt er fest, daß das Token nicht mit der vom Anwendungsserver empfangenen Information übereinstimmt (siehe unten im Abschnitt über Sicherung und Wiederherstellung). Dies ist besonders nützlich in einem System, das so aufgebaut ist, daß Zugriffe auf ein Dokument nur gewährt, aber nicht nachträglich aufgehoben werden können.

Zuordnung von Eignerzugriffsrechten

In manchen Umgebungen muß der Dokumenturheber die Möglichkeit haben, einer anderen Person die Erlaubnis zum Ändern der Zugriffsliste des Dokuments zu erteilen. Zum Beispiel wenn der Eigner nicht da ist, kann ein anderer autorisierter Benutzer in der Lage sein, die Zugriffskontrolle für das bestimmte Dokument zu aktualisieren.

In einer bevorzugten Ausführungsform der Erfindung kann diese Funktion implementiert werden wie in Fig. 6 dargestellt. Wenn eine Aktualisierung der ACL versucht wird, muß der Benutzer, der die Aktualisierung vornimmt, in der Lage sein, das aktuelle signierte Token für die ACL vorzulegen (Block 600). Das signierte Token wird zum Tresor des aktualisierenden Benutzers gesendet (Block 602), der das signierte Token an den Tresor des Urhebers übergibt (Block 604). Der Tresor des Urhebers prüft die Gültigkeit des Tokens (Block 606), indem er es mit dem signierten Token in seinem eigenen Speicher vergleicht. Der Tresors prüft auch die Berechtigung des aktualisierenden Benutzers (Block 610).

Wenn das Token ungültig ist oder dem aktualisierenden Benutzer in der ACL dieses Dokuments keine Eignerzugriffsrechte zugewiesen worden sind, dann erkennt der Tresor des Dokumenturhebers dies, und er verweigert die Aktualisierung und sendet eine Fehlermeldung an den Tresor des Benutzers (Blöcke 608).

Wenn der Tresor des Urhebers das Zugriffsrecht des signierenden Benutzers auf das Dokument verifizieren kann, und wenn festgestellt wird, daß die Versionsnummer und der Zeitstempel des ACL-Tokens aktuell sind (Block 706), wird die ACL aktualisiert (Block 710), und ein neues Token wird generiert und signiert (Block 712) und im Tresor des Urhebers gespeichert (Block 714). Das neu signierte Token wird an den Tresor des Dokumenturhebers gesendet (Block 716). Der Tresor des Aktualisierenden sendet das neue Token zur Speicherung an dessen Arbeitsplatz zurück (Block 718). Das neu signierte Token kann optional auch zur Speicherung im Archiv an den Tresor des Anwendungsservers gesendet werden (Block 720).

Dieses Verfahren verlangt, daß zu jedem Zeitpunkt nur eine einzige Person eine ACL-Aktualisierung durchführt. Wenn zum Beispiel ein Dokumenturheber John Urlaub nimmt, kann er einer Mitarbeiterin Mary erlauben, die ACL seines Dokuments in seiner Abwesenheit zu aktualisieren, indem er Mary sein aktuelles Token für die ACL des Dokuments gibt. Mary führt dann eine ACL-Aktualisierung durch, indem sie das Token durch ihren Tresor John's Tresor vorlegt. Mary empfängt das neu signierte Token für die ACL und gibt es John bei seiner Rückkehr wieder zurück. Nach der Installation des neuen Tokens kann John selber eine ACL-Aktualisierung vornehmen.

Datensicherung und -wiederherstellung

Gelegentlich kann es notwendig sein, daß der Verwalter des Dokumentarchivs die Dokumentdatenbank aus einem vorherigen Backup wiederherstellt. Dies kann beispielsweise bei einem katastrophalen Datenbankfehler, z. B. bei einem Festplattendefekt, der Fall sein. Die zu sichernden Daten sind die Dokumente selber, die ACLs (entweder in der Anwenderdatenbank oder in den Eignertresoren gespeichert), die Fähigkeitslisten (für die Systeme, in denen sie implementiert sind, wie oben beschrieben), und die Verifikationstokens von ACLs und Fähigkeitslisten.

Nach einer Rückspeicherung der Daten können Aktualisierungen, die nach der letzten Sicherung vorgenommen wurden, verloren gegangen sein. Für die Zwecke der vorliegenden Erfindung kcinnte es sich dabei auch um ACL- und Fähigkeitslisten- Aktualisierungen handeln. Wenn dies geschieht, stimmen die auf den Benutzerarbeitsplätzen gespeicherten Verifizierungstokens möglicherweise nicht mehr mit den Tokens in den entsprechenden Tresoren überein, so daß die Benutzer keinen Zugriff mehr haben.

Deshalb wurde als Standard für die Datenwiederherstellung in verschiedenen Situationen das folgende System implementiert. Es wird angenommen, daß die Sicherung zum Zeitpunkt ZEIT1 erfolgte, während die Rückspeicherung zu einem späteren Zeitpunkt ZEIT2 mit dem Stand der Daten zum Zeitpunkt ZEIT1 stattfand, an dem der Anfordernde das Dokument abgerufen hat.

Wenn eine vollständige Rückspeicherung der Dokumentdatenbank, der ACLs, der Fähigkeitslisten und der entsprechenden in den Tre oren gespeicherten Tokens durchgeführt wird, können die Benutzer, die vor ZEIT1 auf ein Dokument zugreifen konnten, dies auch nach ZEIT2 tun. Dies bedeutet, daß wenn ein Benutzer vor ZEIT1 berechtigt war, die Berechtigung aber zwischen ZEIT1 und ZEIT2 widerrufen wurde, dieser Benutzer dennoch auf das Dokument zugreifen kann, bis der Urheber des Dokuments das ACL-Token prüft. Nach einer vollständigen Datenrückspeicherung sollten deshalb alle Benutzer eine Prüfung der ACL und der Fähigkeitsliste durchführen.

Wenn nur die Dokumentdatenbank zurückgespeichert wurde und die ACLs, die Fähigkeitslisten und die in den Tresoren gespeicherten Tokens unberührt geblieben sind, können Benutzer feststellen, daß sie das Zugriffsrecht für ein Dokument besitzen, das gar nicht in der Datenbank gespeichert ist, da das Dokument nach ZEIT1 hinzugefügt wurde, aber nachher bei der Rückspeicherung der Datenbank verloren gegangen ist. Da alle Tokens aktuell sind, gibt es keine weiteren Anomalien.

Ein anderer Fall liegt vor, wenn in einem System keine Fähigkeitslisten benutzt werden, die ACLs aber in der Anwendungsdatenbank gespeichert werden. Wenn die Dokumentdatenbank und die ACL zurückgespeichert worden sind, während die in den Tresoren gespeicherten Tokens nicht zurückgespeichert wurden, stellen die Benutzer fest, daß alle Dokumente, deren ACL nach ZEIT1 geändert wurden, nicht mehr zugänglich sind. Dies kommt daher, daß die ACL-Tokens in der Anwendungsdatenbank nicht mit den in den Tresoren der einzelnen Eigner gespeicherten Tokens übereinstimmen. Um dieses Problem zu lösen, müssen alle Dokumenturheber die ACLs aktualisieren. Eine Möglichkeit dazu ist, daß der Verwalter die alten ACLs (die zu ZEIT1 in Kraft waren), den Dokumenturhebern sendet und sie bittet, die entsprechenden Tokens in ihren Tresoren neu zu installieren. Diese Aktualisierung wird manuell, nicht automatisch, vorgenommen, und die Dokumente eines Eigners sind unzugänglich, bis er die Aktualisierung durchgeführt hat.

In Situationen, in denen Datenbankinkonsistenzen vermieden werden müssen, kann der Archivverwalter nach einer Rückspeicherung den Zugriff auf alle Dokumente sperren, bis der Urheber Fehlerbehebungsmaßnahmen ergriffen hat. Diese Sperre kann für alle Dokumente im Archiv gelten oder nur für einen Teil der Dokumente, bei denen die Konsistenz am kritischsten ist. In diesem Fall muß man sich auf den Archivverwalter verlassen, um die Konsistenz des Systems zu wahren. Wie bereits erwähnt hat der Verwalter aber in keinem Fall die Möglichkeit, Benutzerzugriffsrechte auf ein Dokument zu erteilen oder zu widerrufen.

Um die Möglichkeit einer konzertierten Attacke auf das System zu minimieren, ist es wichtig, daß die Rollen zwischen dem Verwalter des Tresorservers und des betreffenden lokalen Tresorspeichers einerseits und dem Datenbankverwalter andererseits getrennt sind.

In der obigen Beschreibung wurden bevorzugte Ausführungsformen der vorliegenden Erfindung mittels des Produkts IBM Vault Registry beschrieben. Dem Fachmann ist aber klar, daß die vorliegende Erfindung auch mit anderen Produkten, die über ähnliche Funktionen verfügen, implementiert werden könnte, z. B. mit sicheren tresorähnlichen Umgebungen, die sich lokal auf dem Arbeitsplatz der einzelnen Benutzer befinden. Solche und andere Abwandlungen, die für den Fachmann offensichtlich sind, sollen ebenfalls unter den Schutzumfang der beigefügten Ansprüche fallen.

Claims (17)

1. Ein sicheres elektronisches Datenspeicherungs- und -ab­ rufsystem, umfassend:
ein Datenarchiv;
einen Archivverwalter zur Verwaltung der Speicherung und des Abrufs von chiffrierten elektronischen Daten eines deponierenden Computers in dem und aus dem Datenarchiv;
ein Agentenprogramm des deponierenden Computers, auf das der Archivverwalter zugreifen kann, unabhängig davon, ob der deponierende Computer online oder offline arbeitet, und das Mittel besitzt, um nach Authentifizierung des anfordernden Computers die chiffrierten elektronischen Daten des deponierenden Computers, die auf Anforderung des anfordernden Computers aus dem Datenarchiv abgerufen werden, zu dechiffrieren.

2. Das System nach Anspruch 1, wobei der Archivverwalter außerdem daran angepaßt ist, die chiffrierten elektronischen Daten vor der Speicherung im Datenarchiv mit einer digitalen Signatur zu versehen und eine Kopie der signierten chiffrierten Daten an das Agentenprogramm des deponierenden Computers zu senden, und wobei das Agentenprogramm des deponierenden Computers daran angepaßt ist, anhand der signierten chiffrierten Daten die abgerufenen chiffrierten Daten nach der Dechiffrierung zu verifizieren.

3. Das System nach Anspruch 1 oder 2, wobei das Agentenprogramm außerdem daran angepaßt ist, die dechiffrierten elektronischen Daten an den anfordernden Computer zu senden.

4. Das System nach Anspruch 3, wobei das Agentenprogramm eine sichere Erweiterung des deponierenden Computers ist und daran angepaßt ist, die Kommunikation zwischen dem deponierenden Computer und dem Archivverwalter zu verwalten.

5. Das System nach Anspruch 4, das außerdem einen Server umfaßt, der Kommunikationsverbindungen mit dem Archivverwalter, den deponierenden Computer und dem anfordernden Computer besitzt, und der folgendes enthält:
das Agentenprogramm des deponierenden Computers;
eine zweite Umgebung, die eine sichere Erweiterung des Archivverwalters umfaßt, und die daran angepaßt ist, Übertragungen von und zu anderen Umgebungen auf dem Server mit dem Archivverwalter zu verwalten; und
mindestens eine dritte Umgebung, die eine sichere Erweiterung des anfordernden Computers umfaßt, und die daran angepaßt ist, Übertragungen von und zu anderen Umgebungen auf dem Server mit dem anfordernden Computer zu verwalten.

6. Das System nach Anspruch 4 oder 5, wobei das Agentenprogramm des deponierenden Computers Mittel zum Chiffrieren und digitalen Signieren der vom deponierenden Computer empfangenen elektronischen Daten und zum senden der chiffrierten elektronischen Daten und der Signatur an den Archivverwalter zur Speicherung im Datenarchiv umfaßt.

7. Ein Prozeß zur sicheren Authentifizierung des Benutzerzugriffs auf elektronische Daten, die in einem von einem Archivverwalter, der nichts mit einer Quelle der elektronischen Daten zu tun hat, verwalteten Archiv gespeichert sind, umfassend:
Zuordnen einer Zugriffskontroll-Liste der Benutzerberechtigungen für die elektronischen Daten bei Speicherung im Datenarchiv;
Durchführung von Aktualisierungen der Zugriffskontroll- Liste von der Quelle der elektronischen Daten aus;
Speichern der aktualisierten Zugriffskontroll-Liste mit den im Datenarchiv gespeicherten elektronischen Daten;
Speichern eines Beweises der aktualisierten Zugriffskontroll-Liste an der Quelle der elektronischen Daten und auf jedem Benutzercomputer, der die Aktualisierung durchgeführt hat; und
Verifizieren der Richtigkeit der mit den elektronischen Daten im Datenarchiv gespeicherten Zugriffskontroll- Liste mit einem an der Quelle gespeicherten Beweis, bevor die elektronischen Daten für einen anfordernden autorisierten Benutzer freigegeben werden.

8. Der Prozeß nach Anspruch 7, wobei der Schritt der Durchführung von Aktualisierungen an der Zugriffskontroll-Liste folgendes umfaßt:
Identifizieren einer Revisionsstufe der aktualisierten Zugriffskontroll-Liste; und
Zuordnen eines aktuellen Zeitstempels zu der aktualisierten Zugriffskontroll-Liste,
und wobei der Schritt der Beweisspeicherung folgendes umfaßt:
Erstellen eines Tokens der Revisionsstufe und des aktuellen Zeitstempels; und
Speichern des Tokens bei jedem Benutzer mit Zugriffsrecht auf die elektronischen Daten im Datenarchiv.

9. Der Prozeß nach Anspruch 8, außerdem umfassend:
Anhängen des Tokens an die aktualisierte Zugriffskontroll-Liste, um eine Datenstruktur zu bilden;
digitale Signierung der Datenstruktur; und
Speichern der signierten Datenstruktur mit der aktuellen Zugriffskontroll-Liste im Datenarchiv und an der Quelle, und wobei der Schritt der Verifizierung der Richtigkeit der aktualisierte Zugriffskontroll-Liste folgendes umfaßt:
Verifizieren der Dechiffrierung der Datenstruktursignatur an der Quelle; und
Vergleichen der verifizierten Datenstruktur mit der aus dem Datenarchiv abgerufenen aktualisierten Zugriffskontroll-Liste.

10. Der Prozeß nach Anspruch 8, wobei der Schritt der Beweisspeicherung außerdem folgendes umfaßt:
digitale Signierung des Tokens; und
Speichern des signierten Tokens an der Quelle.

11. Der Prozeß nach Anspruch 10, außerdem umfassend:
Senden des digital signierten Tokens an einen von der Quelle zur Aktualisierung der Zugriffskontroll-Liste autorisierten Benutzers; und
bei Vorlegen des digital signierten Tokens durch den zur Aktualisierung der Zugriffskontroll-Liste berechtigten Benutzer,
Verifizierung der Tokensignatur an der Quelle; und
Vergleichen des verifizierten Tokens mit der Revisionsstufe und dem aktuellen Zeitstempel, die der aus dem Datenarchiv abgerufenen aktualisierten Zugriffskontroll-Liste zugeordnet sind.

12. Ein Verfahren zum sicheren Speichern und Abrufen elektronischer Daten in einem fernen Datenarchiv, umfassend:
digitales Signieren der elektronischen Daten an der Quelle;
Chiffrieren der elektronischen Daten an der Quelle;
Senden der chiffrierten elektronischen Daten an das Datenarchiv;
digitales Signieren der chiffrierten elektronischen Daten im Datenarchiv, um einen Deponierungsbeweis zu erzeugen;
Speichern der chiffrierten elektronischen Daten und des Deponierungsbeweises im Datenarchiv; und
Zurücksenden einer Kopie des Deponierungsbeweises an die Quelle.

13. Das Verfahren nach Anspruch 12, außerdem umfassend:
Empfangen einer Zugriffanforderung auf die gespeicherten elektronischen Daten von einem anfordernden Benutzer;
Abrufen der chiffrierten elektronischen Daten und Senden der abgerufenen Daten an die Quelle;
Verifizieren des anfordernden Benutzers als zum Zugriff auf die elektronischen Daten Berechtigen; und
falls verifiziert, Dechiffrieren der abgerufenen Daten.

14. Das Verfahren nach Anspruch 13, außerdem umfassend:
Zuordnen einer Zugriffskontroll-Liste der Benutzerberechtigungen für die elektronischen Daten bei Speicherung im Datenarchiv;
Durchführung von Aktualisierungen der Zugriffskontroll- Liste von der Quelle der elektronischen Daten aus;
Speichern der aktualisierten Zugriffskontroll-Liste mit den im Datenarchiv gespeicherten elektronischen Daten; und
Speichern eines Beweises der aktualisierten Zugriffskontroll-Liste an der Quelle und bei jedem Benutzer, der zum Zugriff auf die elektronischen Daten im Archiv berechtigt ist.

15. Das Verfahren nach Anspruch 14, wobei der Schritt der Verifizierung des anfordernden Benutzers als Berechtigten das Auffinden des anfordernden Benutzers in der aktualisiertem Zugriffskontroll-Liste umfaßt.

16. Der Prozeß nach Anspruch 15, wobei dieser außerdem einen Schritt umfaßt, in dem die Richtigkeit der mit den elektronischen Daten im Datenarchiv gespeicherten aktualisierten Zugriffskontroll-Liste anhand des an der Quelle gespeicherten Beweises verifiziert wird, bevor die elektronischen Daten für den anfordernden Benutzer freigegeben werden.

17. Ein computerlesbarer Speicher zum Speichern der Instruktionen zur Verwendung bei der Ausführung eines der Verfahren nach Anspruch 7 bis 16 auf einem Computer.