DE10084964B3

DE10084964B3 - Verfahren zum sicheren Speichern, Übertragen und Wiedergewinnen inhaltsadresssierbarer Informationen

Info

Publication number: DE10084964B3
Application number: DE10084964.4A
Authority: DE
Inventors: Paul R. Carpentier; Tom Teugels; Jan F. Van Riel
Original assignee: EMC Corp
Current assignee: EMC Corp
Priority date: 1999-09-07
Filing date: 2000-09-01
Publication date: 2015-06-18
Anticipated expiration: 2020-09-02
Also published as: US6976165B1; GB2382179B; AU7035300A; JP2003508995A; US20050223224A1; US8261066B2; GB2382179A; HK1056621A1; DE10084964B8; GB0204624D0; US9497062B1; US20050172124A1; US20050172123A1; DE10084964T1; WO2001018633A1

Abstract

Ein Algorithmus (wie z. B. die MD5-Hash-Funktion) (104) wird an eine Datei (102) angelegt, um einen eindeutigen Eigenidentifizierer (IUI) (106) für die Datei (oder den Nachrichtenüberblick) zu erzeugen. Die Datei wird unter Verwendung ihres IUI als Schlüssel (106) für den Verschlüsselungsalgorithmus verschlüsselt. Ein Algorithmus (112) wird dann an die verschlüsselte Datei (110) angelegt, um einen IUI (114) für die verschlüsselte Datei zu erzeugen. Die verschlüsselte Datei wird sicher gespeichert oder innerhalb eines Netzwerks übertragen und ist eindeutig durch ihren IUI identifizierbar. Die verschlüsselte Datei wird unter Verwendung des IUI der Klartextdatei als Schlüssel entschlüsselt. Der IUI dient sowohl als Schlüssel zum Entschlüsseln der Datei als auch als Bestätigung, daß die Integrität der Klartextdatei nicht beeinträchtigt wurde. IUIs für jegliche Anzahl derartiger verschlüsselter Dateien können in einer Beschreiberdatei (130) zusammengestellt sein, die Metadaten (134) für jede Datei, den IUI (106) der Klartextdatei und den IUI (114) der verschlüsselten Datei umfaßt. Ein Algorithmus (136) wird an die Beschreiberdatei angelegt, um einen IUI (138) für die Beschreiberdatei zu erzeugen. Die Klartextbeschreiberdatei wird dann unter Verwendung des Beschreiberdatei-IUI als Schlüssel für den Verschlüsselungsalgorithmus verschlüsselt. Ein Algorithmus (144) wird an die verschlüsselte Beschreiberdatei (142) angelegt, um einen IUI (146) für die verschlüsselte Beschreiberdatei zu erzeugen. Der IUI der verschlüsselten Beschreiberdatei ist ein positionsunabhängiger Identifizierer zum Lokalisieren der verschlüsselten Beschreiberdatei. Eine abgeflachte Beschreiberdatei (460) umfaßt die IUIs (416, 422, 432) der verschlüsselten Datendateien und den IUI (456) der verschlüsselten Beschreiberdatei. Ein Algorithmus (462) wird an die abgeflachte Beschreiberdatei angelegt, um einen eigenen IUI (464) derselben zu erzeugen.

Description

Gebiet der Erfindung
Die vorliegende Erfindung betrifft im allgemeinen das sichere Speichern, Übertragen und Wiedergewinnen von Informationen unter Verwendung eines Computers. Insbesondere betrifft die vorliegende Erfindung eine Technik zum Identifizieren von Informationen unter Verwendung eines eindeutigen Eigenidentifizierers und zum sicheren Speichern, Übertragen und Wiedergewinnen dieser Informationen unter Verwendung verwandter Techniken.
Hintergrund der Erfindung
Digitale Informationen (wie z. B. eine Computerdatei) müssen oft identifiziert werden, um in einem bestimmten Zustand zu sein, der durch den Zustand der Informationen als ein bestimmtes Ereignis oder eine bestimmte Zeit bezeichnet wird. Digitale Informationen unterliegen Änderungen zu einem großen Ausmaß; normale Versuche, den Inhalt, unabsichtliche Befehle oder Aktionen, die den Inhalt ändern oder ein unbefugtes Einmischen durch andere zu verbessern sind schwierig zu erfassen.
Eine andere, problematische Eigenschaft digitaler Informationen ist, daß Kopien existieren können, die im Inhalt identisch sind, sich aber in den Metadaten unterscheiden, die das Computersystem verwendet, um die digitalen Informationen zu beschreiben. Solche Metadaten umfassen Datum/Zeit, die für die Erzeugung oder die letzte Modifikation der Datei und des Dateinamens verwendet wurden. Die Metadaten können implizieren, daß anderweitig identische Kopien digitaler Informationen unterschiedlich sind, wenn dieselben dies tatsachlich nicht sind. Eine derartige Verwechslung macht es schwierig, eine unnötige Vervielfaltigung des Inhalts auf einen einzelnen Computer oder auf einer Mehrzahl von Computer auf einem Netzwerk zu verhindern. Die Unfähigkeit von Systemen, unterschiedliche Versionen von Dateien mit dem gleichen Identifizierer zuverlässig zu unterscheiden oder identische Dateien mit unterschiedlichen Identifizierern zu erkennen verschwendet Netzwerkressourcen und erzeugt eine Verwechslung, wenn Dateien zwischen Benutzern eines Netzwerks übertragen werden.
Ferner kann auf Daten auf Computersystemen im allgemeinen nur durch Identifizierer zugegriffen werden, die zu einem größeren oder geringeren Ausmaß Informationen über die Position der Datei in der Speicherung des Computers umfaßt. Dateien innerhalb eines Teilverzeichnisses sind z. B. in Gefahr, wenn jemand den Teilverzeichnisnamen ändert. Wenn derselbe geändert ist, wird der Weg zu einer Datei ungültig, und alle der gespeicherten oder unvergessenen Dateinamen werden ebenfalls ungültig.
Letztendlich ist es unbequem für Computerbenutzer Sammlungen spezifischer Versionen digitaler Datei zu identifizieren. Es wäre wünschenswert für Benutzer, sich auf Sammlungen spezifischer Kopien oder Versionen digitaler Dateien zu beziehen, ohne eine neue Entität zu erzeugen, die Kopien der Dateien in eine neue Form integriert. Es wurden viele Mechanismen erzeugt, um solche Kopien in Dateien zu kombinieren, die üblicherweise Archivdateien genannt werden. Derartige Lösungen erzeugen zusätzliche Kopien, die oft auf viele Systeme verbreitet werden. Die Schwierigkeit ist, daß digitale Kopien von vielen der Dateien in einem Archiv bereits auf den Systemen vorhanden sind, auf sie kopiert werden, was verschwenderisch und potentiell verwirrend ist.
Ein Ergebnis ist, daß vervielfältigte Kopien digitaler Dateien häufig auf Computerspeichervorrichtungen gespeichert werden (auf Kosten des Eigentümers des Systems) oder über Telekommunikationsvorrichtungen übertragen werden (wiederum auf Kosten des Systemeigentümers und des Telekommunikationsanbieters). Diese Vervielfaltigung belastet begrenzte Ressourcen und verursacht eine unnötige Verwechslung auf lokalen Netzwerken und auf Systemsammlungen, die durch Telekommunikationsnetzwerke verbunden sind.
Um verschiedenen dieser Probleme zu begegnen, wurden eindeutige Lösungen in den Anmeldungen US 6,807,632 B1 und WO 99/38092 A1 , eingereicht am 21. Januar 1999 in Namen von Carpentier u. a. vorgelegt. Bei einem Ausführungsbeispiel dieser Erfindungen wird eine Technik verwendet, wie in 1 gezeigt ist. 1 stellt eine Technik dar, durch die jegliche Anzahl von Dateien eindeutig durch einen Identifizierer für eine spätere Wiedergewinnung dargestellt werden. Wie in 1 gezeigt ist wird die Verschlüsselungs-Hash-Funktion, die bekannt ist als der MD5-Algorithmus (als ein Beispiel) an den Inhalt der Datei A angelegt, um einen eindeutigen Identifizierer 20 für diese Datei zu erzeugen, der als MD5 A bezeichnet wird. Der Algorithmus wird ferner an die Dateien B und C angelegt, um die eindeutigen Identifizierer 22 und 24 zu erzeugen. Als nächstes wird eine Beschreiberdatei 30 erzeugt, die die Metadaten 32 umfaßt, die höhere Informationen betreffend die Dateien (wie z. B. die Ordner, in denen dieselben eingeschlossen sind, Zeitstempel, Größe, etc.) und Informationen für jede Datei beschreiben. Bei einem Ausführungsbeispiel umfassen die Informationen für jede Datei den Dateinamen 34, Dateimetadaten 36 (wie z. B. Zeitstempel, Größe, etc.) und den kürzlich berechneten MD5 20 für die Datei. Wie gezeigt ist, können solche Informationen für jede der anderen Dateien umfaßt sein. Als nächstes kann der MD5-Algorithmus an die Beschreiberdatei 30 angelegt werden, um einen eindeutigen Identifizierer 40 für die Beschreiberdatei 30 zu erzeugen.
Wie in den obigen Patentanmeldungen beschrieben wird, kann der eindeutige Identifizierer 40 für die Beschreiberdatei 30 verwendet werden, um viele Vorteile zu schaffen. Der Identifizierer 40 kann z. B. verwendet werden, um die Beschreiberdatei 30 eindeutig zu identifizieren, und dann wiederum können die Identifizierer 20–24 verwendet werden, um die Dateien A, B und C eindeutig zu identifizieren. Dementsprechend können Dateien A, B und C gespeichert werden, sobald sie sich irgendwo auf einem Netzwerk befinden, und können schließlich unter Verwendung des Identifizierers 40 und der Beschreiberdatei 30 lokalisiert, wiedergewonnen und identifiziert werden.
Obwohl die obigen Techniken viele Vorteile aufweisen und bei gewissen Anwendungen äußerst nützlich sind, besteht trotzdem Raum für Verbesserungen in dem Bereich der Informationsverwaltung. Wie oben angedeutet wurde, ist das Verwalten von Front-Office-Dateien (Büro-Eingangs-Dateien) und webbasierten Informationen ein großes Problem bei den heutigen Angestellten. Da auf Daten durch zugreifbare URLs und Pfadnamen Bezug genommen werden kann, sind die Nachteile groß: Daten können modifiziert, verfälscht, verschoben und unerreichbar werden. Folglich gehen wertvolle Informationen für ein Unternehmen verloren oder dessen Integrität wird zweifelhaft.
Genauer gesagt verläßt sich der Datenschutz auf eine ausgedehnte Organisation und teuere Spezialisten, um digitale Informationen zu verwalten, zu sichern und zu archivieren. Das Lokalisieren und Wiedergewinnen der richtigen Informationen von deren exakter Position kann zeitaufwendig sein, wenn nicht unmöglich, da die Informationen auf verschiedene Festplatten, Dateiserver und dem Internet in vervielfältigten Formen und mit einer Vielzahl von hartcodierten Dateinamen verteilt sein können. Ferner kann das gemeinschaftliche Verwenden derartiger Informationen das Netzwerkverhalten intern und extern ernsthaft verschlechtern, um nicht zu erwähnen die empfindlichen Informationen einem Risiko aussetzen. Elektronische Postanhange können zu groß sein oder zu lange zum Übertragen brauchen. Ein Herunterladen von einem FTP-Server oder einer Web-Site muß vielleicht völlig neu gestartet werden, wenn dasselbe unterbrochen wurde. Das gleiche, exakte Herunterladen, das durch eine große Anzahl von Benutzern auf einer Stelle durchgeführt von Benutzern auf einer Stelle durchgeführt wird, kann das gesamte Netzwerk verlangsamen. Zusätzlich werden Dateien kontinuierlich modifiziert, gelöscht, verschoben oder falsch plaziert, was bedeutet, daß keine Gewißheit über die Position einer Datei oder lieber deren Datenintegrität besteht. Somit ist es keine Überraschung, daß Angestellte selbst für das Verwalten ihrer eigenen Daten und das Speichern von Versionen von Dokumenten verantwortlich werden. Solche Versuche sind äußerst zeitaufwendig und funktionieren vielleicht nicht immer.
Obwohl die in den obigen Anmeldungen beschriebenen Ausführungsbeispiele einigen dieser Probleme begegnen, bestehen weitere Probleme, denen man begegnen muß. Wenn z. B. der eindeutige Identifizierer 40 entweder abgehört oder anderweitig durch eine skrupellose Einzelperson erhalten wird, kann diese Einzelperson dann in der Lage sein, die Beschreiberdatei 30 wiederzugewinnen, was es der Einzelperson dann ermöglichen würde, die Dateien A, B und C zu lokalisieren und wiederzugewinnen. Wenn diese Dateien empfindliche oder geheime Firmeninformationen enthalten, würde dann ein Problem entstehen. Anders ausgedrückt kann der Vorteil, der durch den Identifizierer 40 dadurch geschaffen wird, daß derselbe verwendet werden kann, um eine Gruppe von Dateien eindeutig zu lokalisieren, kann ebenfalls in einen Nachteil umgewandelt werden, wenn die falsche Partei den Identifizierer 40 erhalt und Zugriff auf empfindliche Informationen erhalt, die in den Dateien enthalten sind. Ferner kann eine geheime Datei gestohlen, betrachtet und/oder ausgedruckt werden, wenn dieselbe nicht angemessen gesichert ist, obwohl die Dateien A, B und C überall auf einem Netzwerk auf eine positionsunabhängige Weise gespeichert sein können.
Somit werden die Angestellten aufgerufen, ihre eigenen Datendateien zu sichern. Eine Datei kann z. B. in einem Computer in einer physisch sicheren Position gespeichert sein (wie z. B. in einem geschlossenen Raum mit ausschließlich elektronischem Zugriff), die Datei kann elektronisch unter Verwendung eines Paßworts oder einer anderen Betriebssystemfunktion verschlossen werden, die Datei kann codiert werden, oder eine gewisse andere Sicherheitstechnik kann verwendet werden. Es ist somit keine Überraschung, daß Angestellte selbst verantwortlich werden für die Verwaltung der Sicherheit ihrer eigenen Daten, das Verschlüsseln von Dateien, das Schützen von Dateien durch Paßwörter, das Verstecken von Dateien und letztendlich das Speichern von Versionen von Dateien an einem Ort, von dem sie glauben daß dieselben sicher sind und später lokalisiert werden können. Das Ablegen der Last auf die Angestellten, um die Sicherheit für eine bestimmte Datei zu implementieren und dann diese Sicherheit über die Lebensdauer der Datei hinweg beizubehalten ist äußerst beschwerlich, teuer und ist vielleicht nicht betriebssicher.
Die WO 99/38092 A1 beschreibt ein Verfahren zum Speichern eines digitalen Objekts in einem Datendepot zum Zweck eines Bereitstellens eines wirksamen Zugriffs auf die Daten über ein Netz. Das Verfahren umfasst folgende Schritte: Empfangen eines rundgesendeten kryptographischen Hash-Digitales-Objekt-Identifizierers; Bestimmen, ob der rundgesendete kryptographische Hash-Digitales-Objekt-Identifizierer ein bekannter kryptographischer Hash-Digitales-Objekt-Identifizierer ist; wenn bestimmt wird, daß der rundgesendete kryptographische Hash-Digitales-Objekt-Identifizierer kein bekannter kryptographischer Hash-Digitales-Objekt-Identifizierer ist, Hinzufügen des rundgesendeten kryptographischen Hash-Digitales-Objekt-Identifizierers zu einer Liste erwünschter rundgesendeter kryptographischer Hash-Digitales-Objekt-Identifizierer; Empfangen eines digitalen Objekts, das durch den rundgesendeten kryptographischen Hash-Digitales-Objekt-Identifizierer identifiziert wird; Erzeugen eines erzeugten kryptographischen Hash-Digitales-Objekt-Identifizierers aus dem empfangenen digitalen Objekt; und Verifizieren, daß der erzeugte kryptographische Hash-Digitales-Objekt-Identifizierer mit dem rundgesendeten kryptographischen Hash-Digitales-Objekt-Identifizierer übereinstimmt.
Die WO 99/38093 A1 beschreibt ein Verfahren zum Identifizieren einer Mehrzahl digitaler Objekte zur späteren Wiedergewinnung. Das Verfahren umfasst folgende Schritte: Auswählen einer Mehrzahl digitaler Objekte; Erzeugen eines kryptographischen Hash-Objekt-Identifizierers für jedes der digitalen Objekte; Erzeugen einer Beschreiberdatei, die die kryptographischen Hash-Objekt-Identifizierer umfaßt; Erzeugen eines kryptographischen Hash-Objekt-Liste-Identifizierers für die Beschreiberdatei; und Speichern der digitalen Objekte, der Beschreiberdatei und des kryptographischen Hash-Objekt-Liste-Identifizierers an sicheren Orten, wodurch der kryptographische Hash-Objekt-Liste-Identifizierer zu einem späteren Zeitpunkt verwendet werden kann, um die Objekte wiederzugewinnen.
Aus der US 57 57 915 A1 ist parametriebare Hash-Funktion zur Zugangskontrolle. Ein computer-implementiertes Verfahren zum Erzeugen eines codierten ausführbaren Abbilds eines ausführbaren Programms umfasst dabei ein Durchführen einer kryptografischen schlüsselabhängigen Hash-Funktion an dem ausführbaren Programm, so daß eine Signaturkomponente erzeugt wird, unter Verwendung eines ersten Schlüssels, der einen zugehörigen Satz von Zugriffsrechten aufweist, die dem ausführbaren Programm zugewiesen sind; und ein Durchführen eines Verschlüsselungsalgorithmus an dem ausführbaren Programm unter Verwendung der Signaturkomponente als einem zweiten Schlüssel.
Dementsprechend ist eine Technik erwünscht, die eine effiziente und annähernd betriebssichere Sicherheit für digitale Informationen und/oder deren entsprechende, eindeutige Identifizierer schaffen würde. Insbesondere ist es die Aufgabe der vorliegenden Erfindung, eine solche Technik zu schaffen, die gut mit dem in den oben beschriebenen Patentanmeldungen erwähnten Ausführungsbeispiel funktioniert; eine derartige Technik würde einem Benutzer die Sicherheit liefern, daß eine Datei nicht nur eindeutig identifiziert werden kann, sondern daß die Datei vor neugierigen Augen geschützt werden kann und die Integrität derselben garantiert werden kann.
Zusammenfassung der Erfindung
Bei einem ersten Ausführungsbeispiel der Erfindung wird ein Algorithmus an eine Datei angelegt, um einen eindeutigen Eigenidentifizierer (IUI = intrinsic unique identifier) für die Datei zu erzeugen. Erfindungsgemäß wird der IUI aus mindestens einem Abschnitt des Inhalts des Binärwertes berechnet, ohne Informationen betreffend eine Zugriffserlaubnis auf den Binärwert zu verwenden. Um eine Sicherheit für die Datei bereitzustellen, wird die Datei dann unter Verwendung des soeben hergestellten IUI als ein Schlüssel für den Verschlüsselungsalgorithmus verschlüsselt. Die Datei kann ferner komprimiert werden, zusätzlich zu dem Verschlüsseln. Ein Algorithmus wird dann an die verschlüsselte Datei angelegt, um einen IUI für die verschlüsselte Datei zu erzeugen. Somit kann die verschlüsselte Datei innerhalb eines Netzwerks sicher gespeichert oder übertragen werden und ist durch ihren IUI eindeutig identifizierbar. Eine autorisierte Partei, die die verschlüsselte Datei erhalt, kann die verschlüsselte Datei dann unter Verwendung des IUI der Klartextdatei entschlüsseln, wenn er oder sie Zugriff auf diesen Schlüssel hat. Unter Verwendung des IUI der Datei, der ferner als Schlüssel zum Verschlüsseln dient, liefert die Datei viele Vorteile. Ein einzelner Identifizierer (in diesem Fall der IUI) dient z. B. sowohl als ein Schlüssel zum Entschlüsseln der Datei als auch als Bestätigung, daß die Integrität der Klartextdatei nicht beeinträchtigt wurde. Weitere Vorteile und spezifische Anwendungen dieser Technik werden nachfolgend vorgelegt. Bei einem spezifischen Ausführungsbeispiel wird der MD5-Algorithmus verwendet, um den IUI für die Klartextdatei zu erzeugen. Der resultierende MD5 (das Ergebnis der Hash-Funktion) kann dann verwendet werden, um zu verifizieren, daß die Klartextdatei sich nicht geändert hat.
Bei einem weiteren Zusatz zu diesem ersten Ausführungsbeispiel können IUIs für jegliche Anzahl derartiger verschlüsselter Dateien in eine Beschreiberdatei eingebaut werden. Bei einer spezifischen Implementierung umfaßt die Beschreiberdatei Metadaten für jede Datei (wie z. B. den Dateinamen), den IUI der Klartextdatei und den IUI der verschlüsselten Datei. Ein Algorithmus wird an die Beschreiberdatei angelegt, um einen IUI für die Beschreiberdatei zu erzeugen. Die Klartextbeschreiberdatei wird dann unter Verwendung des Beschreiberdatei-IUI als ein Schlüssel für den verschlüsselten Algorithmus verwendet. Das Ergebnis erzeugt eine verschlüsselte Beschreiberdatei. Ein Algorithmus wird dann an die verschlüsselte Beschreiberdatei angelegt, um einen IUI für die verschlüsselte Beschreiberdatei zu erzeugen. Die verschlüsselten Dateien und die verschlüsselte Beschreiberdatei können dann sicher innerhalb eines Netzwerks gespeichert oder übertragen werden. Der IUI der verschlüsselten Beschreiberdatei wird als ein positionsunabhängiger Identifizierer verwendet, um die verschlüsselte Beschreiberdatei zu lokalisieren.
Somit ist eine interessierte Partei in der Lage, die verschlüsselte Beschreiberdatei unter Verwendung des IUI derselben zu lokalisieren und wiederzugewinnen. Die Partei wäre jedoch nicht in der Lage, die verschlüsselte Beschreiberdatei zu entschlüsseln, außer dieselbe wird ferner mit dem IUI der Beschreiberdatei geliefert, der als ein Verschlüsselungsschlüssel verwendet wurde. Somit kann dieser Schlüssel einer Partei vorenthalten werden, bis eine solche Partei autorisiert ist, Zugriff zu den Informationen zu erhalten, die innerhalb der Dateien umfaßt sind. Sobald die Partei den IUI der Beschreiberdatei erhält, kann sie dann die verschlüsselte Beschreiberdatei entschlüsseln, um die Klartextbeschreiberdatei zu erhalten. Unter Verwendung der IUIs der verschlüsselten und Klartext-Dateien, die in der Beschreiberdatei umfaßt sind, kann die Partei dann die verschlüsselten Datendateien lokalisieren und dieselben entschlüsseln. Bei einer alternativen Implementierung können die IUIs der verschlüsselten Datendateien außerhalb der Beschreiberdatei lokalisiert sein und können an die interessierte Partei geliefert werden, so daß die Partei die verschlüsselten Datendateien wiedergewinnen kann. Bei diesem Szenario können die IUIs der verschlüsselten Datendateien innerhalb der Beschreiberdatei vorhanden sein oder nicht.
Bei einem zweiten Ausführungsbeispiel der Erfindung kann ferner eine abgeflachte Beschreiberdatei erzeugt werden. Eine Beschreiberdatei, deren IUI, eine verschlüsselte Beschreiberdatei und deren IUI können erzeugt werden, wie bei dem ersten Ausführungsbeispiel beschrieben wird. Zusätzlich wird eine abgeflachte Beschreiberdatei basierend auf der Beschreiberdatei erzeugt. Die abgeflachte Beschreiberdatei umfaßt die IUIs der verschlüsselten Datendateien und den IUI der verschlüsselten Beschreiberdatei.
Ein Algorithmus wird dann an die abgeflachte Beschreiberdatei angelegt, um deren eigenen IUI zu erzeugen. Der IUI der abgeflachten Beschreiberdatei kann dann als ein eindeutiger Identifizierer verwendet werden, um indirekt auf alle Datendateien Bezug zu nehmen, die innerhalb der Beschreiberdatei aufgelistet sind. Unter Verwendung des IUI der abgeflachten Beschreiberdatei kann eine interessierte Partei die abgeflachte Beschreiberdatei (in Klartext) wiedergewinnen. Unter Verwendung der IUIs, die dieselbe enthält, kann die Partei dann nicht nur die verschlüsselten Datendateien sondern auch die verschlüsselte Beschreiberdatei erhalten.
An diesem Punkt hat die Partei jedoch keinen Zugriff auf diese Dateien, obwohl die Partei die verschlüsselten Datendateien hat. Zu einer geeigneten Zeit kann die Partei dann mit dem IUI der Beschreiberdatei beliefert werden, der als ein Schlüssel zum Entschlüsseln der verschlüsselten Beschreiberdatei dient. Sobald dieselbe entschlüsselt ist, kann die Partei dann die Beschreiberdatei verwenden, wie bei dem ersten Ausführungsbeispiel beschrieben wird, um die Datendateien wiederzugewinnen und zu entschlüsseln. Vorteilhafterweise sind zwei Artikel zum Wiedergewinnen und zur Entschlüsselung der Datendateien notwendig: der IUI der abgeflachten Beschreiberdatei, der die Wiedergewinnung der verschlüsselten Datendateien ermöglicht; und der IUI der Klartextbeschreiberdatei, der eine Entschlüsselung der verschlüsselten Beschreiberdatei ermöglicht. Somit können einer oder beide von einer Datei zurückgehalten werden, um deren Zugriff auf die Datendateien zu verhindern, während es der Partei ermöglicht wird, die verschlüsselten Dateien physisch zu erhalten. Ferner wird einer Partei, die in der Lage ist, die verschlüsselten Datendateien wiederzugewinnen, garantiert, daß die Dateien ab der Zeit zu der ihrerorts berechnet wurden nicht verändert wurden, doch dieselbe ist nicht in der Lage, diese Dateien zu entschlüsseln, außer dieselbe erhält den zweiten Artikel.
Durch die Verwendung der vorliegenden Erfindung muß jede zu speichernde oder zu übertragende Datei nur einmal unter Verwendung eines Schlüssels verschlüsselt werden, und nur die verschlüsselte Version der Datei darf gehandhabt werden. Es besteht kein Bedarf, unterschiedliche Schlüssel für unterschiedliche Benutzer zu verwenden. Sollte dieselbe Datei ferner an zwei unterschiedlichen Positionen auf einem Computer oder innerhalb eines Netzwerks vorhanden sein, erzeugt die Verwendung der vorliegenden Erfindung eine verschlüsselte Datei für jede derselben, die automatisch gleich ist. Somit muß nur diese einzelne, verschlüsselte Datei gespeichert und/oder übertragen werden. Derartige Vorteile entstehen automatisch aufgrund der Eigenschaft der vorliegenden Erfindung. Die verschlüsselte Form jeder Datei kann überall innerhalb eines Computernetzwerks gespeichert oder übertragen werden, ohne den Bedarf nach Brandmauern, Zugriffssteuerung, virtuellen, privaten Netzwerken oder sicheren Kommunikationssteuerungsprotokollen. Ferner dient dieser einzelne Identifizierer nicht nur, um die Datei zu authentifizieren, sondern ferner um die Integritat der Datei zu bestätigen, durch Verwendung des eindeutigen Eigenidentifizierers, um als Verschlüsselungsschlüssel für die Datei zu dienen.
Die vorliegende Erfindung in ihren zahlreichen Ausführungsbeispielen liefert eine Vielzahl von Vorteilen bei zahlreichen Anwendungen, die nachfolgend beschrieben werden.
Kurzbeschreibung der Zeichnungen
Die Erfindung, zusammen mit weiteren Beispielen derselben, ist am besten verständlich durch Bezugnahme auf die nachfolgende Beschreibung in Verbindung mit den beiliegenden Zeichnungen. Es zeigen:
1 eine bekannte Technik, durch die jegliche Anzahl von Dateien eindeutig durch einen Identifizierer für ein späteres Wiedergewinnen repräsentiert werden.
2 eine Technik, durch die eine Datei gemäß einem Ausführungsbeispiel der Erfindung verschlüsselt werden kann.
3 eine Technik, durch die eine Beschreiberdatei gemäß einem Ausführungsbeispiel der Erfindung erzeugt und verschlüsselt wird.
4 ein Flußdiagramm, das beschreibt, wie ein eindeutiger Eigenidentifizierer (IUI) für eine Gruppe von Dateien erzeugt werden kann.
5 ein Beispiel einer Beschreiberdatei symbolisch.
6A ein Beispiel einer Implementierung einer Beschreiberdatei, die unter Verwendung einer modifizierten Version von XML geschrieben wurde.
6B eine modifizierte oder „abgeflachte” Beschreiberdatei, die für eine Verwendung bei dem zweiten Ausführungsbeispiel geeignet ist.
7 eine Technik zum Erzeugen eindeutiger Eigenidentifizierer (IUIs) gemäß einem zweiten Ausführungsbeispiel der Erfindung.
8 ein Flußdiagramm, das eine Technik zum Erzeugen einer Anzahl eindeutiger Eigenidentifizierer beschreibt, die eine Dateisammlung gemäß einem zweiten Ausführungsbeispiel der Erfindung darstellen.
9 ein Flußdiagramm, das beschreibt, wie Dateien wiedergewonnen werden können, die in 2 und 3 identifiziert sind.
10 ein Flußdiagramm, das die Wiedergewinnung von Dateien beschreibt, die unter Verwendung des Ausführungsbeispiels von 7 eindeutig identifiziert werden.
11 ein Fludiagramm, das beschreibt, wie eine Datei gemäß einem Ausführungsbeispiel der vorliegenden Erfindung gesucht und erhalten werden kann.
12 ein Blockdiagramm, das eine Verwendung der Erfindung in dem Bereich der sicheren Speicherung zeigt.
13 ein Blockdiagramm, das die Verwendung eines Ausführungsbeispiels der Erfindung in dem Bereich der Zugriffssteuerung zeigt.
14 ein Blockdiagramm, das die Verwendung eines Ausführungsbeispiels der Erfindung für Treuhandzwecke zeigt.
15 ein Blockdiagramm, das eine Computernetzwerkumgebung zeigt, die für eine Verwendung mit einem Ausführungsbeispiel der Erfindung geeignet ist.
16 und 17 eine mögliche Form eines Computersystems.
Detaillierte Beschreibung der Erfindung
Die vorliegende Erfindung ist auf eine breite Vielzahl von digitalen Informationen anwendbar. Wie hierin verwendet beziehen sich digitale Informationen auf eine Computerdatei, eine Gruppe von Dateien, eine Gruppe von Dateiidentifizierern oder andere Sammlungen von Daten- oder Datenbank-Informationen. Derartige andere Sammlungen von Daten umfassen Dokumente, ausgewählte Rahmen oder Clips von digitalen Audio- oder Video-Datenreihen, Datenreihen von Nachrichtenaufzeichnungen oder Dateien von Protokolleinträgen aus Prüfungen oder Statusprotokolle von Systemen. Datenbankinformationen könnten ausgewählte Datenbankaufzeichnungen von einer relationalen, hierarchischen, Netzwerk- oder anderen Format-Datenbank umfassen. In der Tat können digitale Informationen jegliche Reihe von Binärziffern umfassen, die ganz oder teilweise durch eine Anwendung oder Vorrichtung verwendet werden. Bei einem Ausführungsbeispiel handhabt die vorliegende Erfindung digitale Informationen als große, binäre Objekte oder BLOBs (eine Bitsequenz).
Die folgende Erörterung stellt Ausführungsbeispiele der Erfindung unter Verwendung des Beispiels üblicher Computerdateien für ein leichteres Verständnis dar. Es sollte darauf hingewiesen werden, daß Ausführungsbeispiele der Erfindung für eine Verwendung mit jeglichen der zuvor genannten digitalen Informationen gut geeignet sind.
Wie oben erörtert wurde, wäre es wünschenswert, Sicherheitsfragen im Hinblick auf Computerdateien und die eindeutigen Eigenidentifizierer (IUIs) der Datendateien einer Beschreiberdatei zu begegnen. Wie erwähnt wurden ist es für eine Datendatei möglich, durch unautorisierte Parteien erhalten zu werden oder für einen IUI einer Beschreiberdatei, abgefangen zu werden. Obwohl es derart erscheinen kann, daß Standardverschlüsselungstechniken diesen Problemen begegnen können, sind herkömmlichen Verwendungen dieser Standardtechniken Nachteile zugeordnet.
Es kann sich z. B. als Nachteil erweisen, eine Datei unter Verwendung öffentlicher Schlüsselkryptographie zu speichern oder an zahlreiche Personen zu senden. Um eine einzelne Datei an fünfzig Personen unter Verwendung einer öffentlichen Schlüsselkryptographie zu senden, müßte man zuerst den öffentlichen Schlüssel von jeder der fünfzig Personen erhalten. Dann müßten fünfzig Kopien der Datei hergestellt werden und jede Datei müßte mit einem unterschiedlichen der fünfzig Schlüssel verschlüsselt werden. Fünfzig unterschiedliche, verschlüsselte Dateien würden dann erzeugt, die für ein späteres Wiedergewinnen hinausgesendet oder gespeichert werden. Das Problem ist, daß die einzelne Datei, mit der begonnen wurde, nun zu fünfzig unterschiedlichen Dateien wurde, von welchen jede separat verwaltet und transportiert werden muß. Eine Berechnung eines Identifizierers für jede der fünfzig verschlüsselten Dateien würde dann fünfzig unterschiedliche Identifizierer erzeugen, von denen jeder verwaltet und transportiert werden muß. Es wäre äußerst wünschenswert, eine einzelne Kopie der Klartextdatei und eine einzelne Kopie der verschlüsselten Datei zur Verwendung durch eine autorisierte Entität zu haben, um die Vervielfältigung von Dateikopien zu verringern.
Die Verwendung herkömmlicher, symmetrischer Kryptographie hat ebenfalls Nachteile. Unter Verwendung des obigen Beispiels einer einzelnen Datei, die an fünfzig Personen verteilt werden soll, könnte man auswählen, einen unterschiedlichen Zufallsschlüssel zu verwenden, um die Datei fünfzigmal zu verschlüsseln. Die fünfzig unterschiedlichen, verschlüsselten Dateien müssen wiederum erzeugt werden, und jeder der Zufallsschlüssel muß ferner irgendwie an jede Person übertragen werden. Ferner muß die Situation berücksichtigt werden, unter der fünfzig unterschiedliche Dateien an eine Person gesendet werden müssen. Wenn nur ein einzelner Schlüssel verwendet wird, um alle der Dateien zu verschlüsseln, dann würde es viel leichter werden, den Schlüssel herauszufinden und dessen Wert durch eine skrupellose, dritte Partei zu bestimmen. Wenn jede Datei ferner mit einem unterschiedlichen Schlüssel verschlüsselt ist, dann muß jeder dieser Schlüssel irgendwie an die Person übermittelt werden und auf eine sichere Weise verwaltet werden.
Ferner könnte eine typische, bekannte Verwendung von entweder einer asymmetrischen oder einer symmetrischen Kryptographie, um eine Datei zu verschlüsseln, eine Datei liefern, die verschlüsselt ist, doch die verwendeten Schlüssel liefern keine Sicherheit, daß die Datei nicht entweder in ihrer Klartext- oder verschlüsselten Form irgendwie abgefälscht wurde. Ferner ist es vielleicht nicht möglich, eine Datei zu entschlüsseln, die abgefälscht wurde. Es wäre äußerst wünschenswert, wenn ein einzelner Schlüssel verwendet werden könnte, nicht nur um eine Datei zu verschlüsseln, sondern auch um die Integrität ihrer Inhalte zu sichern. Ferner wäre es wünschenswert, den Schlüssel oder die Schlüssel für einen gegebenen Dateisatz auf eine sichere Weise zu speichern und/oder zu übertragen. Dementsprechend realisiert die vorliegende Erfindung eine Technik zum Adressieren der oben genannten Probleme.
Erstes Ausführungsbeispiel
2 stellt eine Technik dar, durch die eine Datei gemäß einem Ausführungsbeispiel der Erfindung verschlüsselt werden kann. 3 stellt eine Technik dar, durch die eine Beschreiberdatei gemäß einem Ausführungsbeispiel der Erfindung erzeugt und verschlüsselt wird. 4 ist ein Flußdiagramm, das beschreibt, wie ein eindeutiger Eigenidentifizierer (IUI) für eine Gruppe von Dateien erzeugt werden kann. 4 wird Bezug nehmend auf 2 und 3 erklärt. Bei Schritt 202 wird eine Gruppe von Dateien (oder eine Datei) ausgewählt und ihre entsprechenden Dateidaten und jegliche Metadaten werden gesammelt. Wie oben erwähnt wurde, können die ausgewählten Dateien Computerdateien oder jegliche vorangehend beschriebene digitale Informationen sein. Die ausgewählten Dateien können eine Beschreiberdatei, jeglichen Typ einer verschlüsselten oder komprimierten Datei oder Dateien, die selbst eindeutige Eigenidentifizierer enthalten, umfassen. Eine Datei 102 ist ein Beispiel einer der Dateien, die ausgewählt wurden, und wird verwendet, um dieses Ausführungsbeispiel darzustellen. Andere ausgewählte Dateien oder Informationen werden vorzugsweise auf eine ähnliche Weise behandelt wie die Datei 102.
Bei Schritt 206 wird ein eindeutiger Eigenidentifizierer (IUI) für jede Datei erzeugt. Ein Algorithmus 14 wird an die Datei 102 angelegt, um einen IUI 106 zu erzeugen. Der Algorithmus kann an die komplette Datei oder an jeglichen Abschnitt der Datei angelegt sein. Der Algorithmus 104 ist vorzugsweise jeglicher Algorithmus, der einen zuverlässig eindeutigen Identifizierer für die Datei basierend auf den Dateiinhalten erzeugen kann. Als solches ist der erzeugte IUI insofern wiederholbar, daß das erneute Anlegen des Algorithmus an die Datei denselben IUI erzeugt. Der Begriff „eigen” wird verwendet, um anzudeuten, daß der IUI zumindest zum Teil (oder ganz) auf den Inhalten der Datei basiert. Der Algorithmus 104 kann jeglicher aus einer breiten Vielzahl von Algorithmen sein. Beispielsweise kann der Algorithmus 104 eine Hash-Funktion sein, wie z. B. der MD5-Algorithmus oder der SHA-1, die einen Nachrichtenüberblick erzeugen, oder er kann ein Fehlererfassungsalgorithmus sein, wie er bei einer zyklischen Blockprüfung (CRC = cyclic redundancy checking) verwendet wird.
Vorzugsweise sollte ein Algorithmus konsistent die gleiche Binärzahl für jeglichen spezifischen Fall von digitalen Informationen erzeugen, und eine solche Binärzahl sollte praktisch überprüft werden, um mit einer angemessen hohen Wahrscheinlichkeit für die Klasse von digitalen Informationen eindeutig zu sein, die identifiziert wird. Die Verwendung eines solchen Algorithmus über zwei Binärsequenzen, die zu der gleichen Binärzahl führen, kann belegen, daß die zwei Binärsequenzen gleich sind. Umgekehrt kann die Verwendung des Algorithmus über zwei Binärsequenzen, die zu unterschiedlichen Binärzahlen führen, belegen, daß die Binärsequenzen unterschiedlich sind. Ein solcher Algorithmus erleichtert die Identifikation von Kopien eines bestimmten Abschnitts von digitalen Informationen (wie z. B. einer Computerdatei). Das Ergebnis eines solchen Algorithmus wird hierin als ein eindeutiger Eigenidentifizierer (IUI) bezeichnet. Es können andere Algorithmen verwendet werden, um einen eindeutigen Eigenidentifizierer zu erzeugen, solange die Wahrscheinlichkeit des Erzeugens identische Identifizierer von unterschiedlichen Dateien unter einer Schwelle liegt, die als annehmbar definiert ist.
Bei einem bevorzugten Ausführungsbeispiel der Erfindung ist der verwendete Algorithmus der MD5-Algorithmus und erzeugt einen 128-Bit-Nachrichtenüberblick, der hierin einfach als der „MD5” bezeichnet wird. In diesem Fall erzeugt der Algorithmus 104 einen Klartext-MD5 106. Der Klartext-MD5 106 ist ein eindeutiger Eigenidentifizierer für die Datei 102 und identifiziert die Datei 102 eindeutig basierend auf deren Inhalten. Sollte die Datei 102 geändert werden, würde ein neu berechneter MD5 mit dem für die vorangehende Version der Datei berechneten MD5 nicht übereinstimmen.
Bei Schritt 210 kann ein optionaler Kompressionsschritt durchgeführt werden. Bei einem bevorzugten Ausführungsbeispiel wird ferner jede Datei komprimiert. Jeglicher aus einer breiten Vielzahl von Komprimierungsalgorithmen kann verwendet werden; der LZW-Algorithmus wird bevorzugt, obwohl andere Algorithmen, die Formaten wie z. B. GZIP und CAB zugeordnet sind, ebenfalls verwendet werden können. Die Komprimierung kann ferner nach der Verschlüsselung durchgeführt werden, obwohl bevorzugt wird, die Komprimierung zuerst durchzuführen oder beides zusammen durchzuführen. Alternativ ist es möglich, den Komprimierungsschritt und nicht den Verschlüsselungsschritt durchzuführen.
Bei Schritt 214 wird jede Datei unter Verwendung von deren kürzlich erzeugtem MD5 als der Schlüssel für den Verschlüsselungsalgorithmus verschlüsselt. Die Datei 102 wird z. B. unter Verwendung des Verschlüsselungsalgorithmus 108 verschlüsselt, wobei der Schlüssel der Klartext-MD5 106 ist, um eine verschlüsselte Datei 110 zu erzeugen. Es kann jegliches Kennwort aus einer breiten Vielzahl als der Verschlüsselungsalgorithmus verwendet werden. Als Beispiel funktioniert der „Two Fish”-Algorithmus gut, obwohl andere Algorithmen, wie z. B. Block- und Datenreihen-Kennwort ebenfalls verwendet werden kennen.
Die Verwendung des Klartext-MD5 106, um die Datei 102 zu verschlüsseln, liefert Vorteile. Der einzelne Schlüssel, der verwendet wird, um die Datei 102 zu verschlüsseln und zu entschlüsseln kann ferner verwendet werden, um die Integrität der Datei zu verifizieren, da der Schlüssel ein Klartext-MD5 106 ist, der unter Verwendung des MD5-Algorithmus erzeugt wurde. Da derselbe ein eindeutiger Eigenidentifizierer ist, kann er ferner verwendet werden, um zu verifizieren, daß die Inhalte der Datei 102 sich nicht geändert haben.
Jetzt, wo die verschlüsselte Datei 110 erzeugt wurde, kann dieselbe innerhalb eines Computernetzwerkes auf eine sichere Weise gespeichert und/oder übertragen werden. Bei Schritt 218 wird ein eindeutiger Eigenidentifizierer unter Verwendung des Algorithmus 112 für die Datei 110 erzeugt. Bei diesem Beispiel ist der Algorithmus 112 der MD5-Algorithmus, und das Ergebnis ist ein verschlüsselter MD5 114. Vorzugsweise ist der Algorithmus 112 gleich dem Algorithmus 104. Es ist jedoch möglich, daß die zwei Algorithmen unterschiedlich sind; es kann z. B. vertraglich geregelt sein, daß Klartextdateien einen bestimmten Algorithmus verwenden, während verschlüsselte Dateien einen unterschiedlichen Algorithmus verwenden, um ihre eindeutigen Eigenidentifizierer zu erzeugen.
An diesem Punkt wurde eine sichere und ausreichende Technik zum Speichern, Positionieren und Wiedergewinnen der Datei 102 beschrieben. Die verschlüsselte Datei 110 kann jetzt innerhalb eines Computernetzwerks gespeichert werden, anstatt eines Speicherns der Klartextdatei 102. Durch Beliefern eines Benutzers mit einem verschlüsselten MD5 114 ist der Benutzer in der Lage, die Datei 110 zu lokalisieren und wiederzugewinnen. Die Integrität der Datei 110 kann durch ein Neuberechnen des MD5 der Datei und durch Vergleichen derselben mit dem MD4 114 garantiert werden. Der Schlüssel 106 zu dem Verschlüsselungsalgorithmus 108 kann durch die Ursprungspartei zurückgehalten werden und nur an einen Benutzer freigegeben werden, wenn erwünscht ist, daß der Benutzer Zugriff zu der Datei 110 hat. Sobald der Schlüssel 106 an jemanden gegeben wird, der die Datei 110 wiedergewonnen hat, kann die Datei verschlüsselt werden, um die Klartextdatei 102 zu erzeugen. Somit sind zwei Informationen für einen Benutzer notwendig, um Zugriff zu der Datei 102 zu haben: Der verschlüsselte MD5 114 und der Klartext-MD5 106. Einem Benutzer, dem die verschlüsselte Datei 110 bereitgestellt wird, wird ferner garantiert, daß die Original-Klartextdatei nicht geändert wurde.
Bei Schritt 222 wird eine Beschreiberdatei erzeugt, die alle Dateien darstellt, die ausgewählt wurden. 5 und 6 liefern genauere Details darüber, wie eine Beschreiberdatei erscheinen kann. Eine Beschreiberdatei 130 kann eine Vielzahl von Informationen umfassen und kann viele Formen annehmen. Bei diesem Beispiel umfaßt dieselbe einen Dateinamen 132, Datei-Metadaten 134, dem Klartext-MD5 106 und den verschlüsselten MD5 114 für jede dieser Dateien, die ausgewählt und vorangehend verschlüsselt wurden. Bei anderen Ausführungsbeispielen kann der verschlüsselte MD5 für jede Datei ferner anderswo positioniert werden, um bei einem Lokalisieren der verschlüsselten Dateien zu assistieren und kann ferner in der Datei 130 erscheinen oder nicht. Eine Beschreiberdatei 130 umfaßt den Klartext-MD5 für jede Datei, sobald die Beschreiberdatei 130 erhalten wurde kann dieselbe verwendet werden, um die verschlüsselten Dateien zu decodieren, um die Original-Klartextdateien zu erhalten.
Bei Schritt 226 wird ein eindeutiger Eigenidentifizierer für die Beschreiberdatei 130 erzeugt. Bei einem bevorzugten Ausführungsbeispiel ist der Algorithmus 136 der MD5-Algorithmus, der verwendet wird, um einen MD5 138 zu erzeugen, der als der „Schlüssel-MD5” bezeichnet wird. Bei Schritt 230 wird die Beschreiberdatei 130 unter Verwendung des Schlüssel-MD5 138 als Schlüssel zu dem Verschlüsselungsalgorithmus 140 verschlüsselt, um die verschlüsselte Beschreiberdatei 142 zu erzeugen. Vorzugsweise ist der Verschlüsselungsalgorithmus 140 der Two-Fish-Algorithmus. Die Datei 130 kann ferner auf ähnliche Weise komprimiert werden, wie bei Schritt 210 erörtert wurde. Der MD5 138 wird als der „Schlüssel-MD5” bezeichnet, da derselbe den Schlüssel zum entschlüsseln der Datei 142 liefert.
Bei Schritt 234 wird ein eindeutiger Eigenidentifizierer für die Datei 142 unter Verwendung des Algorithmus 144 erzeugt. Vorzugsweise wird der MD5-Algorithmus verwendet, um den Haupt- bzw. Master-MD5 146 zu erzeugen. Vorzugsweise sind die Algorithmen 136 und 144 die gleichen Algorithmen, obwohl dieselben unterschiedlich sein können und sich von den Algorithmen 104 und 122 unterscheiden können. Durch einen Vertrag kann vorangehend vereinbart werden, unterschiedliche Algorithmen an unterschiedlichen Stellen zu verwenden. Metadaten 134 können ferner anzeigen, welche Algorithmen mit den Klartext- und den verschlüsselten Dateien verwendet werden sollen. Durch denselben Token können Metadaten für die Datei 130 in dieselbe aufgenommen sein, um den Algorithmus 136 anzuzeigen. An diesem Punkt wurden die ausgewählten Dateien unter Verwendung von entweder dem Hautp-MD5 146 oder dem Schlüssel-MD5 138 eindeutig identifiziert.
Ein Schritt 238 ist ein optionaler Schritt, bei dem der Haupt-MD5 und der Schlüssel-MD5 codiert werden. Da ein resultierender MD5 eine 128-Bit-Zahl ist kann es Wünschenswert sein, diese Zahl in eine besser verwaltbare Form für eine Verwendung durch Personen zu codieren. Die resultierende Zahl kann in jegliche einer Vielzahl von Formen codiert werden, einschließlich Dezimal, Hexadezimal oder Binär. Vorzugsweise wird die Zahl in eine Basis-36-Zahl umgewandelt, die auf den Satz von sechsundzwanzig alphabetischen und numerischen Zeichen in dem Basis-ASCII-Zeichensatz abgebildet wird. Dieses Abbilden wird als „ASCII-Armierung” bezeichnet und wird üblicherweise verwendet, um binäre Informationen in einen begrenzten Zeichensatz für eine Ubertragung über Protokolle zu übersetzen, die erfordern, daß ein Inhalt auf alphanumerische Codierung beschränkt wird. Bei einem bevorzugten Ausführungsbeispiel wird ein Flag-Zeichen an einer vorbestimmten Position innerhalb der resultierenden Zeichenkette aufgenommen, was die Gesamtlänge der Zeichenkette auf 27 Zeichen bringt. Dieses Flag-Zeichen könnte ferner Informationen liefern, wie den zu verwendeten Algorithmus, Dateityp, etc.
Das Ergebnis ist eine 27-Zeichen-ASCII-Zeichenkette aus Ziffern und Großbuchstaben. Ein solches Format liefert eine kompakte Form, die durch eine Person leichter notiert werden kann und/oder durch einen Computer leichter gehandhabt werden kann, und ist ferner in einer Form, die durch viele Softwareprogramme einfach untergebracht werden kann. Zusätzlich dazu weist diese spezielle Darstellung eines eindeutigen Eigenidentifizierers den Vorteil auf, daß derselbe durch eine Datenabfrage einfacher wiedergewonnen werden kann, in Softwareanwendungs-Dateianforderungen leichter codiert werden kann, durch ein Inhalt- oder Wert-Verwaltungssystem leichter auf denselben Bezug genommen werden kann, leichter in einem Objektbrowser angefordert, elektronisch kopiert und von einem Dokument zu einem anderen eingefügt werden kann, einfacher über elektronische Post gesendet werden kann, etc.
Der Haupt-MD5 146 kann ferner einem Dateilokalisierer zugeordnet sein, um bei dem Finden der Datei 142 zu helfen. Obwohl die Erfindung ohne einen zusätzlichen Dateilokalisierer funktioniert, kann ein solcher verwendet werden. Ein Beispiel eines Dateilokalisierers ist ein URL, eine IP-Adresse oder ein Wegname.
Bei Schritt 242 können die verschlüsselten Dateien gespeichert werden, die erzeugt wurden. Die erzeugten Dateien können an jeglicher geeigneten Position gespeichert werden, wie z. B. auf dem Computer des Benutzers, an einem entfernten Server, in einem Archiv, an dem Ort eines zukünftigen Benutzers oder anderswo. In der Tat müssen die erzeugten Dateien nicht zusammen gespeichert werden, sondern können an unterschiedlichen Positionen gespeichert werden.
Vorzugsweise umfassen die Dateien, die für zukünftige Bezugnahme durch einen Benutzer gespeichert werden, die verschlüsselten Dateien (wie z. B. Datei 110) und die verschlüsselte. Beschreiberdatei 142. Vorzugsweise müssen die Klartextdateien (wie z. B Datei 102) und die Klartext-Beschreiberdatei 130 nicht aufgrund der Sicherheit an einer zugänglichen Position gespeichert werden. Die Dateien können zerstört oder durch den Urheber an einer sicheren Position behalten werden. Da die Klartextdateien unter Verwendung des entsprechenden Schlüssels aus den verschlüsselten Dateien erzeugt werden können, ist es nicht notwendig, die Klartextdateien leicht verfügbar zu haben.
Bei Schritt 246 werden der Haupt-MD5 146 und der Schlüssel-MD5 138 für zukünftige Bezugnahme an den Urheber zurückgegeben. An diesem Punkt würden sowohl der Haupt-MD5 als auch der Schlüssel-MD5 durch eine Partei gebraucht, die auf die verschlüsselten Dateien zugreifen möchte. Sollte der Urheber z. B. wünschen, daß eine interessierte Partei an dem gleichen Punkt Zugriff zu den verschlüsselten Dateien hat, kann er dieser Datei den Haupt-MD5 liefern. Unter Verwendung des Haupt-MD5 könnte diese Partei die verschlüsselte Beschreiberdatei 142 erhalten, hätte jedoch keine Möglichkeit, dieselbe zu entschlüsseln. Nur wenn der Partei der Schlüssel-MD5 von dem Urheber geliefert wird, kann diese Partei die Datei 142 entschlüsseln und nicht nur die entschlüsselten MD5s erhalten (um jede verschlüsselte Datei zu lokalisieren) sondern auch den Klartext-MD5 für jede Datei (der es dieser Partei ermöglichen würde, die verschlüsselte Datei zu entschlüsseln, und zu bestätigen, daß die Originaldatei nicht geändert wurde). Alternativ können einer interessierten Partei die verschlüsselten MD5s zusätzlich zu der Haupt-MD5 geliefert werden, was es der Partei ermöglichen würde, die verschlüsselten Dateien wiederzugewinnen, jedoch nicht dieselben zu entschlüsseln. Sobald der Schlüssel-MD5 bereitgestellt wurde, könnte die Partei die Beschreiberdatei entschlüsseln, die Schlüssel für die Datendateien erhalten und dieselben entschlüsseln. Bei einem alternativen Ausführungsbeispiel können dem Benutzer MD5s für die verschlüsselten Datendateien geliefert werden, ihm wird jedoch bis zu einem späteren Zeitpunkt nicht der Haupt-MD5 oder der Schlüssel-MD5 geliefert. Alternativ kann dem Benutzer anfänglich der Schlüssel-MD5 und später der Haupt-MD5 geliefert werden. Solche Ausführungsbeispiele weisen eine Vielzahl von Anwendungen auf, die nachfolgend erörtert werden.
Beschreiberdatei-Beispiele
5 stellt symbolisch ein Beispiel einer Beschreiberdatei bzw. Deskriptordatei 300 dar. Im allgemeinen umfaßt eine Beschreiberdatei den Klartext-MD5 für jede der verschlüsselten Datendateien. Somit kann der Benutzer dann die verschlüsselten Datendateien unter Verwendung des Klartext-MD5 für jede Datei als ein Schlüssel bei dem Entschlüsselungsalgorithmus entschlüsseln, sobald die Beschreiberdatei erhalten und entschlüsselt ist. Andere Informationen können optional innerhalb der Beschreiberdatei umfaßt sein, um dem Lokalisieren einer verschlüsselten Datendatei, dem Rekonstruieren der Verzeichnisumgebung derselben und/oder dem Verwalten eines Schemas zum Erzeugen von Einnahmen für die Verwendung einer derartigen Technik zu assistieren. Ferner kann eine Beschreiberdatei in jeglicher aus einer breiten Vielzahl von Modelliersprachen implementiert sein; Beispiele sind in 6A gegeben.
Bei einem spezifischen Ausführungsbeispiel umfaßt die Beschreiberdatei 300 Metadaten 302, die Optionen betreffend die Beschreiberdatei und Informationen betreffend deren Verwendung und Inhalte beschreibt. Beispielsweise umfassen die Metadaten 302 den Typ der Beschreiberdatei, einen Namen für die Beschreiberdatei, ein Erstellungsdatum, Anmerkungen, die Anzahl von Datendateien, die dieselbe repräsentiert, die Anzahl von Verzeichnisordnern, die dieselbe repräsentiert, die Gesamtgroße von allen Dateien kombiniert, die dieselbe repräsentiert Und andere Informationen, wie z. B. Autor, Paßwörter, etc.
Ein vom Benutzer gelieferter Name kann zugeordnet werden, wenn die Beschreiberdatei erzeugt wird und wird durch den Benutzer als eine mnemonische Hilfe verwendet, um einen Ordner zu identifizieren, (zum Beispiel) aus den Dateien entstanden sind, die durch die Beschreiberdatei repräsentiert werden. Bei einem anderen Ausführungsbeispiel der Erfindung wird der Name der Ordners selbst automatisch als eine mnemonische Hilfe vorgeschlagen. Dieser Name kann dem Haupt-MD5 zugeordnet werden, der für die Beschreiberdatei erzeugt wurde, um einem Benutzer zu ermöglichen, die allgemeinen Inhalte einer Beschreiberdatei leichter zu identifizieren. Beim Wiedergewinnen von Daten unter Verwendung eines bestimmten Haupt-MD5 kann dieser Name z. B. umfaßt sein, um dem Benutzer zu assistieren. Das Erstellungsdatum zeigt an, wann die Beschreiberdatei erzeugt wurde, und ist hilfreich, um die Versionen nachzuverfolgen. Anmerkungen können zu jeglichem Zweck durch den Benutzer in die Beschreiberdatei eingefügt werden. Die Anzahl dargestellter Dateien, die Anzahl von Ordnern und die Gesamtgröße ist für den Verarbeitungsstatus während des Herunterladens nützlich.
Eine Beschreiberdatei kann jegliche Anzahl dargestellter Dateien umfassen, und kann optional die Ordner umfassen, in denen sich die Dateien ursprünglich befanden. Jegliche Anzahl von Ordnern und jegliche Hierarchie kann in der Beschreiberdatei dargestellt sein. Als Beispiel ist ein Ordnername 310, dessen Zeitstempel 312 und Betriebssystemeigenschaften 314 umfaßt. Der Zeitstempel 312 zeigt an, wann der Ordner als letztes modifiziert wurde. Die Eigenschaften 314 zeigen betriebsspezifische Eigenschaften für den Ordner an, wie z. B. ob der Ordner ein Nur-Lese-Ordner ist, ob derselbe verdeckt werden sollte, und dessen Typ, wie z. B. System, Archiv oder temporär.
Jegliche Anzahl von Dateien kann derart angezeigt sein, daß sie ursprünglich innerhalb des Ordners 310 gefunden werden kann, wie z. B. die Dateien, die durch den Dateinamen 320 und den Dateinamen 340 identifiziert werden. Eine breite Vielzahl von Metadaten kann vorhanden sein, die Informationen betreffend die Datei liefert, die durch den Dateinamen 320 identifiziert wird. Es ist ein erster Zeitstempel 322 umfaßt, der anzeigt, wann die Datei das letztemal geändert wurde, eine Größe 324, den Kurtext-MD5 326, den verschlüsselten MD5 328, ein Erstellungsdatum für die Datei 330 und jegliche Anzahl von betriebsspezifischen Eigenschaften 322. Diese Eigenschaften können den Lese- oder Schreib-Status der Datei umfassen, den Dateityp, ihren Urheber, etc. Durch Aufnehmen des verschlüsselten MD5 328 für die Datei wird die Datei unter Verwendung des verschlüsselten MD5 als ein positionsunabhängiger Dateiname inhaltsadressierbar. Der Kartext-MD5 326 kann dann verwendet werden, um die wiedergewonnene, verschlüsselte Datei zu entschlüsseln. Andere Dateinamen und zugeordnete Metadaten können ferner derart angezeigt sein, daß sie in dem Ordner 310 umfaßt sind. Jegliche Anzahl von Ordnern und ihre aufgenommenen Dateien (angezeigt durch 324 und 344) können ferner umfaßt sein. Eine Ordnerhierarchie kann existieren, bei der ein Ordner und dessen Dateien innerhalb eines anderen Ordners vorhanden sind.
Verwaltungsdaten 346 können ferner innerhalb der Beschreiberdatei 300 umfaßt sein, um bei dem Erzeugen von Einnahmen aus der Verwendung der Technik zu assistieren, die Software zu überwachen, die die Technik verkörpert, etc. Beispielsweise umfassen die Daten 346 einen Identifizierer, der anzeigt, auf welcher Maschine die Software ursprünglich installiert war. Bei einem Ausführungsbeispiel der Erfindung wird Software, die die Erfindung verkörpert, entweder verkauft, lizenziert oder kostenfrei an Benutzer geliefert.
Eine sogenannte „Token-Box” ist zusammen mit der Software umfaßt, der die Anzahl von Malen darstellt, die ein Benutzer eine Beschreiberdatei erzeugen und einen Haupt-MD5 für eine Sammlung von Dateien erzeugen kann. Innerhalb der Daten 346 wäre dann ein Token-Box-Identifizierer und ein Token-Box-Zählwert umfaßt. Der Boxidentifizierer identifiziert die bestimmte Box eindeutig, die zusammen mit der Software an einen Benutzer geliefert wurde. Der Boxzählwert zeigt die Anzahl von Malen an, die ein Benutzer eine Beschreiberdatei und deren entsprechenden Haupt-MD5 erzeugen kann. Ein Benutzer kann z. B. für die Software zahlen (oder dieselbe kostenlos erhalten), die die Erfindung verkörpert, die einen Boxzählwert von 1000 aufweist. Die Software überwacht diese Boxzählwertvariable und verringert dieselbe jedesmal, wenn der Benutzer eine verschlüsselte Beschreiberdatei und deren zugeordneten Haupt-MD5 erzeugt. Der Boxidentifizierer und der aktuelle Boxzählwert sind dann innerhalb der Daten 346 umfaßt. Der Boxidentifizierer kann nützlich sein, um anzuzeigen, daß nur gewisse Typen von Beschreiberdateien erzeugt werden können. Vorzugsweise ist dies eindeutig für eine gegebene Softwarekopie, die an einen Kunden geliefert wird, und ist ähnlich einer Seriennummer. Der Boxzählwert, die innerhalb der Beschreiberdatei umfaßt ist, ist nützlich zum Überwachen von Token-Boxen, in die „gehackt” wurde, um eine Zahlung zu umgehen.
Ferner kann ein Überblick über die komplette Beschreiberdatei innerhalb der Daten 346 umfaßt sein. Der Überblick kann z. B. durch Durchführen einer Hash-Funktion auf die Beschreiberdatei hin und durch nachfolgendes Verschlüsseln des Hashs erzeugt werden, der mit einem geheimen Schlüssel erzeugt wird, der nur dem Hersteller der Software bekannt ist. Asymmetrische oder symmetrische Kryptographie kann verwendet werden. Durch Aufnehmen dieses Überblicks innerhalb (oder am Ende) der Beschreiberdatei kann der Hersteller der Software beweisen, ob die Beschreiberdatei und/oder deren zugeordneter Haupt-MD5 durch den Hersteller erzeugt wurden oder nicht, da nur der Hersteller diesen eindeutigen Überblick berechnen kann. Somit kann der Hersteller bestimmen, ob eine andere Entität die Beschreiberdatei und/oder deren Haupt-MD5 erzeugt hat. Diese Informationen könnten beim Bestimmen nützlich sein, ob eine Anforderung zum Wiedergewinnen von Dateien, zum Anfordern einer Zahlung von einer Entität oder zum rechtlichen Schutz einer bestimmten Implementierung verarbeitet werden soll.
Der Typ einer Beschreiberdatei zeigt einen aus einer Vielzahl von Typen der Datei und deren zugeordneten Haupt-MD5 an. Im allgemeinen liefert ein bestimmter Typ unterschiedliche Metadaten und ein unterschiedliches Verhalten für unterschiedliche Klassen von Beschreiberdateien. Gewisse Typen von Beschreiberdateien können z. B. gewisse Metadaten umfassen, die nicht innerhalb anderer Typen vorhanden sind und können verursachen, daß ein Softwareagent oder ein Betriebssystem verschiedene Aktionen einleitet, die sich von anderen Typen unterscheiden. Es kann eine breite Vielzahl von Typen für Beschreiberdateien definiert werden. Beispielsweise können diese Typen folgende umfassen. Ein Standard-Typ kann wiedergewonnene Dateien automatisch zurück in einen Vorgabeordner auf dem Desktop des Computers des Benutzers plazieren, wenn die Dateien unter Verwendung von Ausführungsbeispielen der vorliegenden Erfindung wiedergewonnen werden. Bei anderen Szenarios kann es jedoch wünschenswert sein, eine Datei wiederzugewinnen und dieselbe an eine bestimmte Position innerhalb eines Computers oder anderswo zu plazieren. Ein erweiterter Typ einer Beschreiberdatei ermöglicht es der Beschreiberdatei, Metadaten für jeden Dateinamen oder Ordner zu umfassen, die anzeigen, nach wo innerhalb eines Computers und/oder dessen Betriebssystem die Datei plaziert werden soll, wenn dieselbe wiedergewonnen wird. Zum Durchführen von Software-Ersetzung oder -Aktualisierungen können Metadaten, die innerhalb der Beschreiberdatei für jede Datei enthalten sind z. B. anzeigen, daß eine bestimmte Datei eine Datei innerhalb des Betriebssystems des Computers ersetzen sollte. Wenn die vorliegende Erfindung somit zum Wiedergewinnen einer Datei verwendet wird, kann der Softwareagent die wiedergewonnene Datei automatisch an der Position plazieren, die durch die Metadaten angezeigt wird.
Da ein automatisches Ersetzen oder Plazieren von Betriebssystem- oder Anwendungssoftware-Dateien empfindlich sein kann und eine Erlaubnis erfordern kann, kann ein Zertifikat zusammen mit der Beschreiberdatei für diesen Typ umfaßt sein. Bei diesem Szenario bestätigt ein Benutzer einer Beschreiberdatei zuerst einen gegebenen Urheber der Dateien, die wiedergewonnen werden sollen. Der Softwareagent, der die vorliegende Erfindung implementiert, überwacht dann eine Liste von Urhebern, die durch den Benutzer genehmigt werden. Der Benutzer und der Urheber einigen sich dann auf ein digitales Zertifikat, das den Urheber an den Benutzer authentifiziert. Die Erzeugung und Verwendung digitaler Zertifikate ist in der Technik bekannt und jegliches aus einer Vielzahl derselben kann verwendet werden. In dieser Situation ist innerhalb der Metadaten 302 ein Zertifikat von dem Urheber umfaßt, daß die Authentizität der Dateien garantiert, die innerhalb der Beschreiberdatei angezeigt sind. Sobald der Softwareagent die Beschreiberdatei entschlüsselt hat, gewinnt er das Zertifikat des Urhebers wieder und verifiziert, daß dasselbe in der Tat diesen bestimmten Urheber authentifiziert. Der Softwareagent vergleicht dann den Urheber mit der Liste genehmigter Urheber, und wenn eine Übereinstimmung vorhanden ist, werden die angezeigten Dateien in der Beschreiberdatei wiedergewonnen, entschlüsselt und auf dem Computer des Benutzers installiert, wo dies angedeutet ist.
Ein anderer Typ einer Beschreiberdatei ist ein Versuchs-Typ. Bei dem Verwenden dieses Typs einer Beschreiberdatei erscheint eine Anzeige auf dem Benutzerbildschirm, jedesmal wenn eine Beschreiberdatei erzeugt und ein Haupt-MD5 geschaffen wird. Im Gegenzug zu dem Betrachten der Anzeige wird der Boxzählwert für diesen bestimmten Benutzer nicht verringert. Die Daten, die die Anzeige darstellen, können innerhalb des Softwareagenten gespeichert sein, der die vorliegende Erfindung verkörpert, oder können ferner innerhalb der Beschreiberdatei umfaßt sein.
Ein anderer Typ einer Beschreiberdatei ist ein Dienst-Typ. Diese Beschreiberdatei umfaßt Metadaten, die eine Softwareprogrammerweiterung auf jegliche geeignete Weise identifizieren. Die Programmerweiterung kann z. B. zur Verwendung eines eindeutigen Eigenidentifizierers (IUI) gemäß jeglichem Ausführungsbeispiel der vorliegenden Erfindung identifiziert werden, oder kann unter Verwendung eines Dateinamen, einer Position, etc. identifiziert werden. Wenn Dateien durch den Softwareagenten unter Verwendung der Beschreiberdatei wiedergewonnen werden, wird die Softwareprogrammerweiterung identifiziert, lokalisiert und automatisch auf dem Computer des Benutzers installiert. Die Programmerweiterung kann z. B. eine Java-Datei zum Laden sein oder XML-Konfigurationsdateien.
Beschreiberdateien können ferner durch einen Benutzer kundenspezifisch ausgelegt werden. Ein Benutzer kann z. B. einen kundenspezifischen Typ einer Beschreiberdatei erzeugen, der automatisch bestimmte Metadaten und Verhaltensweisen zu der Datei hinzufügt, wenn dieselbe erzeugt wird. Kundenspezifische Beschreiberdateien können ferner für jedes Unternehmen erzeugt werden, für das Software geliefert werden soll, die die vorliegende Erfindung verkörpert. Relevante Informationen können der Beschreiberdatei z. B. automatisch hinzugefügt werden, wenn dieselbe erzeugt wird, oder der Benutzer kann aufgefordert werden, Informationen hinzuzufügen, die für den Typ der Beschreiberdatei und deren Inhalte relevant sind. Automatische Verhaltensweisen können einer kundenspezifischen Beschreiberdatei hinzugefügt werden, die gewisse Aktionen durchführt, wenn eine Beschreiberdatei verwendet wird, um Dateien wiederzugewinnen. Zum Beispiel können Codes innerhalb der Beschreiberdatei automatisch elektronische Post senden. Andere Aktionen, die auftreten können, umfassen eine Publikation auf Web-Sites.
6A stellt ein Beispiel einer Implementierung einer Beschreiberdatei dar, die unter Verwendung einer Anwendung von XML geschrieben wurde. Die erweiterbare Markierungssprache (XML) wird bevorzugt, obwohl andere Mechanismen, die z. B. Initialisierung („.ini”-Dateien) verwendet werden können. Die bestimmte, gezeigte Beschreiberdatei verwendet eine sogenannte „Hyperdatei”-Modellierungssprache (HFML = hyperfile modeling language) basierend auf XML, um die Struktur der Verzeichnisse zu beschreiben, die Dateien enthalten, sowie die Dateien selbst. Eine HFML wird in der U.S.-Provisional-Patentanmeldung Nr. 60/072,316, eingereicht am 23. Januar 1998 beschrieben. Im allgemeinen sollte darauf hingewiesen werden, daß die Implementierung der Erfindung nicht auf eine Beschreiberdatei beschränkt ist, die in jeglicher bestimmten Syntax geschrieben ist. Die HFML bei dem bevorzugten Ausführungsbeispiel wird verwendet, da dieselbe leicht analysiert und verwendet werden kann, um ein Baumstrukturverzeichnis der Dateien und Schlüssel zu schaffen.
Die Beschreiberdatei von 6A umfaßt zwei MD5s für jede Datei. Der MD5, bezeichnet als „decoded.md5” entspricht dem Klartext-MD5 106 von 2 (zum Beispiel), und stellt einen eindeutigen Eigenidentifizierer für eine Klartextdatei dar. Der MD5, der einfach als „md5” bezeichnet ist, entspricht dem verschlüsselten MD5 114 von 2 und stellt einen eindeutigen Eigenidentifizierer für die verschlüsselte Klartextdatei dar. Die Beschreiberdatei von 6A umfaßt keine Verwaltungsdaten, obwohl dies möglich wäre.
6B stellt eine modifizierte oder „abgeflachte” Beschreiberdatei dar, die für eine Verwendung bei dem zweiten Ausführungsbeispiel geeignet ist. Bei dem zweiten Ausführungsbeispiel (beschrieben in 7 und 8) kann die Beschreiberdatei 402 wie in 6A implementiert sein, und eine abgeflachte Beschreiberdatei 460 kann wie in 63 implementiert sein. Es wird darauf hingewiesen, daß die Datei von 6B den MD5 der verschlüsselten Beschreiberdatei von 6A (bezeichnet als „keyfile md5”) umfaßt, und die MD5s für die verschlüsselten Klartextdateien umfaßt, jedoch nicht die MD5s für die Klartextdateien. 6B umfaßt ferner Verwaltungsdaten („eclipcontents”), wie z. B. einen Boxidentifizierer, einen Boxzählwert, einen Sitzidentifizierer und einen Überblick.
Zweites Ausführungsbeispiel
Das erste Ausführungsbeispiel hat die Technik beschrieben, durch die ein Haupt-MD5 und ein Schlüssel-MD5 an einen Benutzer geliefert werden, der eine Sammlung verschlüsselter Dateien lokalisieren und auf dieselben zugreifen möchte. Da der Haupt-MD5 ausschließlich Zugriff auf die verschlüsselte Beschreiberdatei 142 ermöglicht, wäre es für einen Benutzer schwierig, die verschlüsselten Datendateien zu lokalisieren und wiederzugewinnen, da die Beschreiberdatei verschlüsselt ist. Erst wenn dem Benutzer ferner der Schlüssel-MD5 geliefert wird, ist dieser Benutzer in der Lage, die Beschreiberdatei zu entschlüsseln und die MD5s zu erhalten, die es ihm ermöglichen, die verschlüsselten Datendateien zu lokalisieren. In verschiedenen Situationen kann es wünschenswert sein, einem Benutzer nicht nur zu ermöglichen, zuerst die verschlüsselte Beschreiberdatei zu erhalten, sondern ferner dem Benutzer zu ermöglichen, die verschlüsselten Datendateien zu lokalisieren und zu erhalten, ohne zu ermöglichen, daß diese Dateien verschlüsselt werden. Dies ist z. B. nützlich beim Verwalten von Sammelservern, beim Lastausgleichen, bei der Cashspeicherung, bei der Spiegelung und bei anderen Anwendungen wie z. B. treuhänderischem Verwalten.
7 und 8 beschreiben ein Ausführungsbeispiel, durch das dem Benutzer nicht nur ermöglicht wird, auf die verschlüsselte Beschreiberdatei zuzugreifen, sondern wobei er ferner die Einrichtung zum Lokalisieren der verschlüsselten Datendateien erhält. 7 stellt eine Technik zum Erzeugen eines eindeutigen Eigenidentifizierers (IUI) gemäß einem zweiten Ausführungsbeispiel der Erfindung dar. 8 ist ein Flußdiagramm, das eine Technik zum Erzeugen einer Anzahl eindeutiger Eigenidentifizierer beschreibt, die eine Sammlung von Dateien gemäß einem zweiten Ausführungsbeispiel der Erfindung darstellen.
Bei den Schritten 502–518 wird eine Sammlung von Dateien ausgewählt, MD5s werden erzeugt und die Dateien werden auf eine ähnliche Weise verschlüsselt, wie bei den Schritten 203–218 beschrieben wurde (in 7 nicht gezeigt). Bei Schritt 522 wird die Beschreiberdatei 402 erzeugt. Die Beschreiberdatei 402 umfaßt repräsentative Metadaten für jegliche Anzahl von Dateien, und kann ferner andere Informationen umfassen, wie z. B. in den 5 und 6A gezeigt ist. Es ist ein Dateiname 410, der eine erste Datei repräsentiert, deren zugeordnete Datei-Metadaten 412, deren Klartext-MD5 414, der aus der Klartextdatei erzeugt wurde und ein verschlüsselter MD5 416 umfaßt, der aus der verschlüsselten Datei erzeugt wird. Der Dateiname 420 und der Dateiname 430 stellen eine zweite bzw. dritte Datei dar, und jede weist ihre zugeordneten Metadaten, den Klartext-MD5 und den verschlüsselten MD5 auf.
Bei Schritt 526 wird der Algorithmus 404 verwendet, um den Schlüssel-MD5 406 für die Beschreiberdatei 402 zu erzeugen. Bei Schritt 530 wird die Beschreiberdatei 402 unter Verwendung des Schlüssel-MD5 406 als Schlüssel zu dem Verschlüsselungsalgorithmus 440 verwendet, um eine verschlüsselte Beschreiberdatei 452 zu erzeugen. Der MD5 406 wird als „key MD5 = Schlüssel-MD5” bezeichnet, da derselbe den Schlüssel zum Entschlüsseln der Datei 452 liefert. Bei Schritt 534 wird der Haupt-MD5 456 für die Datei 452 unter Verwendung des Algorithmus 454 erzeugt. Vorzugsweise sind die Algorithmen 404 und 454 die gleichen Algorithmen, obwohl dieselben unterschiedlich sein können und sich von den Algorithmen unterscheiden können, die mit den Datendateien verwendet werden.
An diesem Punkt kann der Haupt-MD5 456 an einen Benutzer geliefert werden, um dem Benutzer zu ermöglichen, die verschlüsselte Beschreiberdatei 452 zu lokalisieren und zu erhalten. Der Benutzer wäre jedoch nicht in der Lage, die verschlüsselten Datendateien zu lokalisieren. Es ist denkbar, daß der Urheber die verschlüsselten Datendateien einfach an den Benutzer liefern kann, oder die Dateilokalisierer für dieselben liefern kann, oder sogar deren verschlüsselte MD5s auf jegliche Weise liefern kann. Bei einem bevorzugten Ausführungsbeispiel werden die verschlüsselten MD5s jedoch für die verschlüsselten Datendateien in einer anderen, modifizierten Beschreiberdatei geliefert.
Bei Schritt 538 wird die abgeflachte Beschreiberdatei 460 zum Teil basierend auf den Informationen in der Beschreiberdatei 402 erzeugt. Innerhalb der abgeflachten Beschreiberdatei 406 sind die verschlüsselten MD5s 416, 422 und 432 umfaßt, die eindeutige Eigenidentifizierer bereitstellen, um die verschlüsselten Dateien zu lokalisieren, die durch die Dateinamen 410, 420 und 430 in der Beschreiberdatei dargestellt sind. Die Datei 460 kann durch Vervielfältigen der Datei 402 erzeugt werden, wobei gewisse Informationen entfernt und andere Informationen hinzugefügt werden. Der Haupt-MD5 456 wird z. B. ferner der Datei 460 hinzugefügt, um einem Benutzer zu ermöglichen, auf die Datei 452 zuzugreifen. Die Metadaten 470, die der Datei 460 zugeordnet sind können ebenfalls hinzugefügt werden. Diese Metadaten können die gleichen Beschreiberdatei-Metadaten sein, die in der Datei 402 gefunden werden, sie können ein Teilsatz dieser Daten sein oder können unterschiedliche Metadaten sein oder überhaupt nicht erscheinen. Die Metadaten 470 umfassen z. B. öffentlich suchbare Artikel, liefern jedoch keine Daten.
Die abgeflachte Beschreiberdatei kann eine breite Vielzahl anderer Formen annehmen. Es können z. B. andere Typen von Dateilokalisierern anstelle des MD5 umfaßt sein, um auf die verschlüsselten Dateien oder die Klartext-Datendateien zuzugreifen. Der Haupt-MD5 456 ist ferner optional, und Datei-Metadaten können ebenfalls für jede Datei umfaßt sein.
Bei Schritt 542 wird der Algorithmus 162 an die Datei 460 angelegt, um einen Benutzer-MD5 464 zu erzeugen, der ein eindeutiger Eigenidentifizierer für die Datei 460 ist. Vorzugsweise ist der Algorithmus 462 der MD5-Algorithmus. Bei Schritt 544 werden der Benutzer-MD5 464 und der Schlüssel-MD5 406 vorzugsweise in ein ASCII-Format auf ähnliche Weise umgewandelt, wie bei Schritt 238 beschrieben ist, um Identifizierer zu liefern, die durch einen Benutzer besser verwaltbar sind. Da der Haupt-MD5 456 bei diesem Ausführungsbeispiel nicht direkt durch einen Benutzer gehandhabt wird ist es optional, ob dieser Identifizierer in der Datei 460 codiert wird.
Bei Schritt 548 werden die relevanten Dateien für späteren Zugriff durch einen Benutzer gespeichert. Die zu speichernden Dateien umfassen die verschlüsselten Datendateien, die verschlüsselte Beschreiberdatei 452 und die nicht verschlüsselte, abgeflachte Beschreiberdatei 460. Diese Dateien können in jeglicher geeigneten Rechenvorrichtung oder einem Computernetzwerk gespeichert werden, und können zu verschiedenen Positionen verteilt werden. Bei einem Ausführungsbeispiel werden die Dateien in einem sogenannten Datei-„Vorrat” gespeichert. Im allgemeinen bezieht sich ein Dateivorrat auf eine Sammlung verteilter Speichervorrichtungen, die Dateien speichern, die nur durch ihre MD5s (oder durch andere IUIs) identifiziert werden.
Bei Schritt 552 werden der Benutzer-MD5 464 und der Schlüssel-MD5 406 zu dem Urheber für eine mögliche Verteilung an einen anfordernden Benutzer zurückgegeben. Auf diese Weise wird Zugriff zu den verschlüsselten Datendateien und eventuell zu den Klartextdateien einfach über zwei Identifizierer, nämlich den Benutzer-MD5 464 und den Schlüssel-MD5 460, geliefert. Unter Verwendung des Benutzers-MD5 464 kann der Benutzer z. B. auf die Datei 460 zugreifen und dieselbe lesen, was Zugriff zu den verschlüsselten Datendateien und zu der verschlüsselten Beschreiberdatei (über den Haupt-MD5) liefert. Sobald dem Benutzer ferner der Schlüssel-MD5 406 geliefert wird, kann der Benutzer die verschlüsselte Beschreiberdatei entschlüsseln, die Klartext-MD5s erhalten und jede der verschlüsselten Datendateien entschlüsseln.
Dateiwiedergewinnungsausführungsbeispiele
Zu diesem Zeitpunkt hat der Urheber der Datendateien den Schlüssel-MD5 138 und den Haupt-MD5 146 erzeugt, und hat die verschlüsselten Dateien sicher auf einem Computer oder auf einen verteilten Computernetzwerk gespeichert. Eine interessierte Partei, wie z. B. ein Benutzer oder ein Softwareprogramm, kann die folgenden Schritte durchführen, um die Datei wiederzugewinnen.
Bei Schritt 602 empfängt der Benutzer den Haupt-IUI (in diesem Beispiel den Haupt-MD5), der der Identifizierer ist, der die wiederzugewinnenden Dateien eindeutig darstellt. Bei Schritt 606 sucht der Benutzer nach der Datei, die durch den Haupt-MD5 146 identifiziert wird. Die Datei kann auf eine breite Vielzahl von Wegen gesucht und erhalten werden. Als Beispiel sucht der Benutzer auf einem lokalen Computer oder durch ein verteiltes Computernetzwerk nach der Datei. Vorzugsweise wird die Datei anfänglich durch Anpassen des Haupt-MD5 146 an den MD5 einer bestimmten, gefundenen Datei identifiziert. Bei einem bevorzugten Ausführungsbeispiel der Erfindung kann ein Schritt 606 implementiert werden, wie in 11 beschrieben ist. Bei Schritt 610 wird eine verschlüsselte Beschreiberdatei 142 empfangen, die angeblich dem Haupt-MD5 146 entspricht. Sobald sie empfangen wurde, kann der Benutzer annehmen, daß die Beschreiberdatei aufgrund der Suche authentisch ist, die bei Schritt 606 durchgeführt wurde. Es wird jedoch vielleicht bevorzugt, zu bestätigen, daß die empfangene Datei die richtige Datei ist, zuerst durch Berechnen des MD5 der empfangenen verschlüsselten Beschreiberdatei bei Schritt 614.
Bei Schritt 618 wird verifiziert, daß die empfangene Datei authentisch ist, durch Vergleichen des Haupt-MD5 146 mit dem soeben berechneten MD5 von der empfangenen Datei. Wenn die MD5s nicht übereinstimmen, kehrt die Steuerung zu Schritt 606 zurück, um nach einer anderen Datei zu suchen. Wenn die MD5s übereinstimmen, ist die Datei authentisch, und der Prozeß kann fortfahren. Die Schritte 614 und 618 sind optionale Schritte.
Aufgrund des Besitzes der verschlüsselten Beschreiberdatei 142 wird dem Benutzer an diesem Punkt effektiv garantiert, daß alle Dateidaten, die in der Klartext-Beschreiberdatei verschlüsselt und identifiziert wurden, effektiv versiegelt sind und nicht geändert wurden. Sollte eine skrupellose Partei z. B. versuchen, eine der Datendateien zu ändern, so würden die MD5s der Klartextdatei und der verschlüsselten Datei nicht mit der MD5 106 und 114 in der Klartext-Beschreiberdatei übereinstimmen. Auf diese Weise kann dem Besitzer der verschlüsselten Beschreiberdatei versichert werden, daß die Beschreiberdatei in der Lage sein wird, die Originaldatendateien, die in der Beschreiberdatei identifiziert wurden, verifizierbar zu identifizieren, sobald die Beschreiberdatei entschlüsselt ist. Auf diese Weise dient die verschlüsselte Beschreiberdatei 142 als ein Treuhanddokumenttyp der Originaldatendateien. Als solches kann der Schlüssel-MD5 138 gleichzeitig mit der Haupt-MD5 146 an den Benutzer geliefert werden, manchmal kurz danach oder eine gewisse Zeit später, wenn der Urheber wünscht, daß der Benutzer Zugriff auf die Originaldatendateien hat.
Daher erhält der Benutzer bei Schritt 622 zu einer angemessenen Zeit den Schlüssel-IUI (in diesem Fall den Schlüssel-MD5 138) und kann beginnen, die Originaldateien zu erhalten. Bei Schritt 626 verwendet der Benutzer den Schlüssel 138, um die Beschreiberdatei 142 zu entschlüsseln und die Klartext-Beschreiberdatei 130 zu erhalten. Obwohl dies an diesem Punkt optional ist, kann der Benutzer bei Schritt 630 wünschen, zu verifizieren, daß die Klartext-Beschreiberdatei 130 ebenfalls authentisch ist. Der Benutzer kann z. B. den MD5 für die Datei 130 neu berechnen und denselben mit dem Schlüssel 138 vergleichen. Eine derartige Prüfung verifiziert, daß die richtige Beschreiberdatei nicht durch eine falsche Beschreiberdatei 130 ersetzt wurde und dann unter Verwendung des Schlüssels 138 verschlüsselt wurde. Zusätzlich kann ein Überblick für die Datei 130 neu berechnet und mit einem vorangehend berechneten Überblick verglichen werden, der bereits in der Datei 130 vorhanden ist. Wie in 5 hervorgehoben wird, können Verwaltungsdaten 346 einen eindeutigen Überblick umfassen, der durch den echten Erzeuger der Beschreiberdatei 130 berechnet wurde. Wenn die MD5s aus irgendeinem Grund nicht übereinstimmen oder der Überblick inkorrekt ist, wird bei Schritt 634 ein Fehlerhandhaber angerufen, um eine geeignete Fehlermeldung und eine geeignete Aktion zu erzeugen.
Bei Schritt 638 wird die Verzeichnisstruktur (falls vorhanden), die in der Beschreiberdatei 130 beschrieben ist unter Verwendung der Informationen, die in der Beschreiberdatei enthalten sind, neu aufgebaut. Eine Verzeichnisstruktur, wie z. B. in 5 oder 6A gezeigt ist, oder eine andere Struktur kann aufgebaut werden. Eine Ordnerhierarchie kann erzeugt werden, Ordner- und Verzeichnis-Eigenschaften können zugeordnet werden und individuelle Dateieigenschaften können identifiziert werden, um bestimmten Dateien zugeordnet zu werden, sobald diese Dateien wiedergewonnen wurden.
Da die Beschreiberdatei 130 den verschlüsselten MD5 114 jeder identifizierten Datei auflistet, kann der Benutzer nun nach jeder der verschlüsselten Dateien unter Verwendung dieser MD5s suchen. Ein Schritt 642 kann auf jegliche geeignete Weise durchgeführt werden, z. B. kann er wie bei Schritt 606 und in 11 beschrieben ist durchgeführt werden, durch die eine Datei identifiziert wird, die einen bestimmten IUI aufweist.
Bei Schritt 646 wird eine Datei empfangen, die angeblich dem verschlüsselten MD5 114 entspricht. Obwohl der Benutzer vielleicht annimmt, daß diese wiedergewonnene Datei authentisch ist, wird bei Schritt 650 bevorzugt, daß die empfangene Datei verifiziert wird. Durch Neuberechnen des MD5 der verschlüsselten Datei 110 (z. B.) kann dieser neu berechnete MD5 mit dem verschlüsselten MD5 114 verglichen werden, um zu verifizieren, daß die identifizierte Datei in der Beschreiberdatei 130 in der Tat die Datei ist, die soeben wiedergewonnen wurde. Wird die Datei nicht verifiziert kann ein Schritt 642 wieder implementiert werden, um die richtige Datei zu finden.
Es sei angenommen, daß die Datei verifiziert wurde, so wird bei Schritt 654 die verschlüsselte Datei 110 unter Verwendung des Klartext-MD5 106 entschlüsselt, um die Original-Klartextdatei 102 zu erhalten. Bei diesem Ausführungsbeispiel der Erfindung ist ferner der Klartext-MD5 106 innerhalb der Beschreiberdatei 130 zusammen mit dem verschlüsselten MD5 114 vorhanden. Bei anderen alternativen Ausführungsbeispielen ist es denkbar, daß der Klartext-MD5 106 nicht innerhalb der Datei 130 vorhanden sein muß sondern auf eine andere geeignete Weise an den Benutzer geliefert wird. Der Benutzer kann nun annehmen, daß die Datei 102 die Originaldatei ist, die vorangehend versiegelt wurde. Bei einem alternativen Ausführungsbeispiel kann der Benutzer ferner die Authentizität der Datei 102 durch Neuberechnen ihres MD5 und durch Vergleichen von deren neuberechnetem MD5 mit dem Klartext-MD5 106 verifizieren. Eine solche Prüfung verifiziert, daß eine skrupellose Partei eine Originaldatei 102 nicht durch eine falsche Datei ersetzt hat und dann die falsche Datei unter Verwendung des MD5 der Originaldatei verschlüsselt hat. Wenn die Datei nicht verifiziert wird, wird ein geeigneter Fehlerhandhaber 662 angerufen.
Wenn dieselbe verifiziert wurde, wird bei Schritt 666 eine Dateianforderungsliste aktualisiert, um anzuzeigen, daß die Datei 102 genau erhalten wurde. Wenn nicht alle Dateien, die in der Beschreiberdatei 130 identifiziert sind, empfangen wurden, dann kehrt die Steuerung zu einem Schritt 646 zurück, um eine andere Datei zu empfangen. Falls alle Dateien empfangen wurden, wird bei Schritt 674 eine Anzeige an den Benutzer geliefert, daß alle Dateien, die in der Beschreiberdatei 130 identifiziert wurden, erfolgreich wiedergewonnen wurden. Auf diese Weise wird einem Benutzer, dem die Haupt-MD5 146 und der Schlüssel-MD5 138 geliefert wurde, die Einrichtung geliefert, um die ursprünglich verschlüsselten und identifizierten Dateien zu erhalten, und ihm wird garantiert, daß die Originaldateien nicht geändert wurden, seit sie verschlüsselt wurden.
10 ist ein Flußdiagramm, das die Wiedergewinnung von Dateien beschreibt, die unter Verwendung des Ausführungsbeispiels von 7 eindeutig identifiziert wurden. Durch die Verwendung des Benutzer-MD5 464 und des Schlüssel-MD5 406 kann ein Benutzer später die Klartextversionen der Dateien lokalisieren und wiedergewinnen, die in der Beschreiberdatei 402 identifiziert wurden. Durch die Verwendung dieses Ausführungsbeispiels wird es einem Benutzer ermöglicht, nicht nur die verschlüsselte Beschreiberdatei sondern auch die verschlüsselten Datendateien wiederzugewinnen, um dieselben in seinem Besitz zu halten. Dies kann in gewissen Situationen vorteilhaft sein, wie z. B. bei treuhänderischer Softwareverwaltung und Vorratsverwaltung, wo ein Benutzer wünscht, die aktuellen, verschlüsselten Datendateien in seinem Besitz zu behalten. Diese Dateien können jedoch nicht entschlüsselt werden, bis der Schlüssel 406 ebenfalls an den Benutzer geliefert wird.
Die Schritte 702–710 können auf eine ähnliche Weise durchgeführt werden wie bei Schritten 602–610. Bei Schritt 710 ist die empfangene Datei jedoch wahrscheinlich die abgeflachte Klartext-Beschreiberdatei 460. Bei Schritt 714 kann der Benutzer ferner verifizieren, daß die empfangene, abgeflachte Beschreiberdatei authentisch ist, durch Neuberechnen eines Überblicks für die Datei und Vergleichen desselben mit dem Überblick, der innerhalb der Verwaltungsdaten 346 der Datei 460 (falls vorhanden) umfaßt ist.
Jetzt, da der Benutzer die abgeflachte Klartext-Beschreiberdatei erhalten hat, kann der Benutzer bei den Schritten 718 und 722 nach diesen verschlüsselten Datendateien suchen und dieselben wiedergewinnen, die durch ihre entsprechenden MD5s (z. B. 416, 422 und 432) identifiziert wurden, die in der Datei 460 umfaßt sind. Diese Dateien können auf jegliche geeignete Weise identifiziert und wiedergewonnen werden und werden vorzugsweise unter Verwendung der bei den Schritten 642, 646 und in 11 beschriebenen Techniken wiedergewonnen.
Bei Schritt 726 wird eine empfangene, verschlüsselte Datei durch Vergleichen von deren neu berechneter MD5 mit dem MD5 von der Datei 460 als authentisch verifiziert, die verwendet wurde, um dieselbe wiederzugewinnen. Falls nicht authentisch kehrt die Steuerung zurück zu Schritt 722, um auf eine andere Datei zu warten. Sobald sie verifiziert ist, wird bei Schritt 730 eine Dateianforderungsliste aktualisiert, um anzuzeigen, daß eine der verschlüsselten Datendateien erfolgreich wiedergewonnen wurde. Wenn bei Schritt 734 nicht alle Dateien wiedergewonnen wurden, dann kehrt die Steuerung zurück zu Schritt 722, um auf eine andere Datei zu warten.
Bei Schritt 738 wird der Haupt-MD5 456 aus der Datei 460 extrahiert. Durch Verwendung des Haupt-MD5 456, der innerhalb der abgeflachten Beschreiberdatei 460 vorhanden ist, kann der Benutzer jetzt die verschlüsselte Beschreiberdatei 452 lokalisieren und wiedergewinnen. Sobald dem Benutzer der Schlüssel MD5 406 von der Ursprungsdatei (sobald gewisse Bedingungen erfüllt sind, z. B.) geliefert wird, ist der Benutzer in der Lage, schließlich die Originaldatendateien wiederzugewinnen. Die Schritte 738–764 können z. B. durchgeführt werden, wie bei den Schritten 606–638 oben beschrieben ist. Es wird darauf hingewiesen, daß der Schlüssel-MD5 bei Schritt 750 nicht geliefert wird, außer der Urheber wünscht, daß der Benutzer Zugriff zu den Originaldateien hat.
Da der Benutzer bereits die verschlüsselten Datendateien wiedergewonnen hat, kann der Benutzer die verschlüsselten Dateien bei Schritt 768 unter Verwendung der Klartext-MD5s, die in der Beschreiberdatei 402 gefunden werden entschlüsseln, sobald die Verzeichnisstruktur aufgebaut wurde. Bei einem alternativen Ausführungsbeispiel müssen die Klartext-MD5s nicht in der Datei 402 umfaßt sein, sondern können auf eine bestimmte andere Weise an den Benutzer geliefert werden. Bei Schritt 772 können die Klartextdateien verifiziert werden, wie bei Schritt 658 beschrieben ist. Schließlich kann die Verzeichnisstruktur bei Schritt 776 mit den Klartextdateien besiedelt werden, um sie zu ihrem richtigen Ort zurückzubringen. Zusätzlich können jegliche Dateimetadaten, die in der Beschreiberdatei 402 umfaßt sind, ferner an jede Datei angelegt werden.
Somit ist ein Benutzer durch dieses Ausführungsbeispiel in der Lage, die verschlüsselte Beschreiberdatei und alle verschlüsselten Datendateien unter Verwendung eines Benutzer-MD5 464 wiederzugewinnen. Der Benutzer ist nicht in der Lage, die Datendateien zu entschlüsseln, bis der Schlüssel-MD5 406 geliefert wird.
11 ist ein Flußdiagramm, das beschreibt, wie eine Datei gemäß einem Ausführungsbeispiel der vorliegenden Erfindung gesucht und erhalten werden kann. Die Prozedur von 11 kann ferner verwendet werden, um die Schritte 606, 642, 706, 718 und 738 von 9 und 10 bei einem bevorzugten Ausführungsbeispiel der Erfindung zu implementieren.
Bei einem bevorzugten Ausführungsbeispiel wird eine Datei (z. B.) in Abschnitten oder Segmenten empfangen. Bei anderen Ausführungsbeispielen können Dateien ganz oder auf eine Weise empfangen werden, die durch ein Dateiübertragungsprotokoll spezifiziert wird. Eine Dateianforderungsliste umfaßt alle Dateien, die angefordert werden, bis diese Dateien in ihrer Gesamtheit empfangen werden. Es ist ferner möglich, daß eine Dateisegment-Anforderungsliste implementiert wird, die einzelne Segmente umfassen würde, die angefordert werden. Einzelne Dateisegmente können z. B. angefordert werden, wenn ein Daten- oder Code-Stück für eine Softwareanwendung erforderlich ist, oder wenn spezifische Einträge für eine Datenbank durch ein Speicher- oder Abfrage-Ergebnis erhalten werden. Ein Importierprogramm verwaltet die Übertragung von Daten an den Empfänger und bestimmt, wenn die Dateien vorliegen.
Bei einem Ausführungsbeispiel weist der Importierer eine spezifische Positionshierarchie in einem Computersystem (oder auf einem Netzwerk) auf, in dem derselbe nach den Dateien sucht, die in einer Beschreiberdatei aufgelistet sind. Somit kann der Importierer unter Verwendung eines verketteten Systems implementiert werden, das an unterschiedlichen Orten nach Dateien sucht. Somit werden Dateien zuerst an der günstigsten Stelle gesucht und dann an immer weniger günstigen Stellen. Diese „Anordnungslinie” ist hinsichtlich Art und Quantität von Importierern konfigurierbar und kann automatisch und dynamisch geändert werden, um Wirtschaftlichkeit, Sicherheit oder Verhalten zu optimieren. Da die MD5s als inhaltsbasierte Dateinamen dienen, die es dem Inhalt von Dateien ermöglichen, verifiziert zu werden, sobald die Dateien wiedergewonnen werden, ist es möglich, es den Dateien zu ermöglichen von willkürlichen Stellen wiedergewonnen zu werden, wo sie gefunden werden können, ohne den Inhalt der Datei unter Verwendung einer gewissen Art von Prüfsumme zu überprüfen.
Bei Schritt 802 wird der eindeutige Eigenidentifizierer (IUI) der Datei, die erhalten werden soll, identifiziert. Dieser IUI kann jeglicher geeignete Identifizierer sein, wie z. B. ein MD5, der eine Datendatei, eine Beschreiberdatei, jegliche verschlüsselte Datei oder andere digitale Informationen eindeutig identifiziert. Bei den folgenden Schritten kann der IUI unter Verwendung einer beliebigen aus einer Vielzahl von Techniken an eine bestimmte Datei angepasst werden. Bei einem bevorzugten Ausführungsbeispiel werden die Dateien zusammen mit ihren Dateinamen gespeichert, der der IUI der Datei ist. Anders ausgedruckt wird der codierte, alphanumerische 27-Bit-MD5 der Datei ferner als deren Dateiname verwendet. Bei diesem Ausführungsbeispiel wird ein Dateisystem eines Computers verwendet, um dabei zu helfen, den IUI an eine bestimmte Datei anzupassen. Bei anderen Ausführungsbeispielen kann eine Datenbank einen IUI als einen Nachschlageidentifizierer (oder Datenbankschlüssel) in der Datenbank verwenden, um die Stelle der Datei zu finden, die durch den IUI identifiziert wird. Die Datenbank kann einen Zeiger zu der Datei oder den eigentlichen Inhalt der Datei enthalten, wenn die Datei ein Dateiobjekt in einer objektorientierten Datenbank ist. Andere Techniken können verwendet werden, um einen IUI einer Datei in einer Speichervorrichtung zuzuordnen, um das Anpassen eines empfangenen IUI an eine bestimmte Datei auf der Speichervorrichtung zu erleichtern. Ein IUI kann z. B. einer Datei ferner als eine Dateieigenschaft zugeordnet werden. Es ist ferner möglich, einen IUI für eine gefundene Datei neu zu berechnen und denselben dann mit einem identifizierten IUI zu vergleichen, um zu bestimmen, ob die Datei die richtige Datei zum Wiedergewinnen ist. Andere Techniken umfassen eine Objektdatenbankspeicherung.
Bei Schritt 804 sucht ein Importiererprogramm nach der gewünschten Datei unter Verwendung des IUI derselben in einem lokalen Cache auf dem Computer. Bei einem bevorzugten Ausführungsbeispiel der Erfindung ist dieser Cache ein Vorrat von Dateien, in dem Dateien vorangehend gespeichert wurden, z. B. bei den Schritten 242 und 548. Vorteilhafterweise speichert dieser Dateivorrat den IUI einer Datei als deren Dateiname für eine effiziente Wiedergewinnung. Der Cache kann auf einer lokalen Festplatte, innerhalb eines RAM oder auf einer anderen lokalen Vorrichtung implementiert sein. Vorzugsweise ist der Vorratscache als eine Ordnerhierarchie organisiert, in der die umfaßten Dateien ihre IUIs als ihre Dateinamen verwenden. Der Vorratscache verwendet vorzugsweise eine Schlüssel-/Wert-Nachschlagemethode, wobei ein IUI der Schlüssel ist, und der Wert die wiederzugewinnende Bitsequenz ist. Wenn die Datei gefunden wird, wird dieselbe wiedergewonnen und das Verfahren endet.
Wird die Datei nicht lokal in einem Vorratscache gefunden, sucht der Importierer bei Schritt 806 in einem lokalen, herkömmlichen Speicher nach der Datei. Ist die Datei z. B. nicht in dem Vorratscache umfaßt, wo der IUI der Dateiname ist, ist es möglich, daß die Datei immer noch lokal gespeichert ist, und deren IUI der Datei auf eine bestimmte andere Weise zugeordnet ist. Der IUI kann z. B. eine Dateieigenschaft einer Datei sein, und alle Dateien auf einem herkömmlichen, lokalen Speicher (wie z. B. Speicher, Diskette, Band) können gescannt werden, um nach einer Dateieigenschaft zu suchen, die mit dem identifizierten IUI übereinstimmt. Als ein letztes Ergebnis, mit der Brechstangenmethode, kann die lokale Speicherung gescannt werden, um die Inhalte aller vorhandenen Dateien zu bestimmen, und ein IUI kann für alle diese Dateien neu berechnet werden. Der identifizierte IUI aus Schritt 802 kann dann mit jedem dieser neu berechneten IUIs verglichen werden, um die korrekte, wiederzugewinnende Datei zu bestimmen. Wenn die Datei gefunden wird, wird dieselbe wiedergewonnen und das Verfahren endet.
Wird die Datei nicht in der herkömmlichen Speicherung gefunden, wird bei Schritt 808 eine Dateipositionsanforderung an die Partnercomputer auf einem lokalen Netzwerk verteilt. Eine Dateianforderungsliste, die den IUI der Datei und dessen Sequenznummern umfasst, kann ebenfalls erzeugt werden. Vorzugsweise wird der identifizierte IUI an alle Computer auf dem Netzwerk verteilt, die einen Vorratscache implementieren. Diese Computer können dann durch Überprüfen des verteilten IUI bestimmen, ob die gewünschte Datei innerhalb ihres Vorrats enthalten ist. Zusätzlich ist es bei Partnercomputern möglich, deren herkömmliche, lokale Speicherung unter Verwendung der oben beschriebenen Techniken zu untersuchen. Wenn die Datei gefunden wird, schickt der Computer, die die Datei aufweist, einen Positionsanzeiger an den anfordernden Computer, der die Netzwerkposition der gewünschten Datei anzeigt.
Bei Schritt 810 errichtet der Originalcomputer eine Eins-Zu-Eins-Verbindung mit dem Computer, der die gewünschte Datei enthält, und fordert ein Herunterladen der Datei unter Verwendung einer Dateianforderung an. Bei diesem Ausführungsbeispiel wird die Datei Segment für Segment heruntergeladen, obwohl es möglich ist, daß die Datei auf einmal heruntergeladen wird. Bei Schritt 812 empfängt der ursprüngliche Computer ein Dateidatenpaket, das Segmentsdaten für die gewünschte Datei enthält. Die Sequenznummer des empfangenen Dateidatenpakets wird im Hinblick auf die Dateianforderungsliste überprüft, um zu bestimmen, ob das empfangene Paket für eine Datei ist, die erwünscht ist. Geeignete Beispiele eines Dateianforderungs- und Dateidaten-Pakets sind in den oben durch Bezugnahme aufgenommenen Anmeldungen Nrn. 09/236,366 und 09/235,146 gezeigt.
Wenn das Datenpaket dann für die aktuell gewünschte Datei gebraucht wird, werden die Segmentdaten aus dem Dateidatenpaket dann bei Schritt 814 als Teil der gewünschten Datei gespeichert, und die Dateianforderungsliste wird aktualisiert, um anzuzeigen, daß dieses bestimmte Segment wiedergewonnen wurde. Schritt 818 überprüft, ob die Datei komplett ist und alle Segmente empfangen wurden. Falls ja, wurde die Datei vollständig wiedergewonnen und das Verfahren endet. Wenn nicht, dann wartet der ursprüngliche Computer, um ein anderes, heruntergeladenes Dateidatenpaket bei Schritt 812 zu empfangen.
Wenn die gewünschte Datei bei Schritt 808 nicht gefunden wurde, dann sendet der Importierer bei Schritt 818 eine Anforderung nach der Datei an jeglichen, vorkonfigurierten oder bekannten Server, der einen Vorratscache implementiert. Ein Importierer kann z. B. vorkonfiguriert sein, um sich unter Verwendung einer IP-Adresse mit gewissen Servern zu verbinden, wenn bekannt ist, dass dieser Server einen Vorratscache implementiert. Durch Weiterleiten des IUI der gewünschten Datei an den bestimmten Server kann der Server bestimmen, ob die Datei innerhalb des Vorratscaches vorhanden ist, durch Überprüfen der Dateinamen seiner Dateien. Andere Adressierungstechniken können verwendet werden, um eine Verbindung mit einem dieser Server zu bilden. Wenn die Datei gefunden wird, wird dieselbe wiedergewonnen und das Verfahren endet.
Bei Schritt 808 können diesen Partnercomputern Vorratscacheserver ausschließlich zugeordnet werden, die ausschließlich zugeordnet sind, um Dateien zu sammeln und zu speichern, die durch ihren IUI identifiziert werden. Auf diese Weise ist das Verteilen an diese Vorratsserver insofern effizient, daß eine hohe Wahrscheinlichkeit besteht, daß einer dieser Server die gewünschte Datei in seinem Cache aufweist. Die Verteilung kann ferner gewisse Softwareagenten erreichen, die auf den Computern positioniert sind, deren Primärfunktion es ist, die eindeutigen Identifizierer zu erzeugen, wie in den 4 und 8 beschrieben ist. Diese Softwareagenten können die Dateien und ihre zugeordneten IUIs ferner in einem eigenen Vorratscache oder in einer herkömmlichen lokalen Speicherung speichern.
Wenn die Datei bei Schritt 818 nicht gefunden wurde, sucht der Importierer 820 dann auf jeglichen, befestigten Dateiservervolumen nach der gewünschten Datei, die an das lokale Netzwerk angebracht sind. In dieser Situation implementieren die identifizierenden Dateiserver nicht notwendigerweise einen Vorratscache in einem Standardformat aber können nichtsdestotrotz die gewünschte Datei auf einem befestigten Volumen, wie z. B. in einem RAM, auf einer Festplatte, etc. speichern. Der identifizierte IUI kann verwendet werden, um die gewünschte Datei unter Verwendung von jeglicher der bei Schritt 802 diskutierten Techniken zu finden. Wenn die Datei gefunden wird, wird dieselbe wiedergewonnen und das Verfahren endet. Wenn die Datei nicht gefunden wird, sucht der Importierer dann bei Schritt 822 auf jedem geeigneten FTP-Server z. B. unter Verwendung eines URL nach der gewünschten Datei. In dieser Situation kann auf die FTP-Server über das Internet unter Verwendung eines URL zugegriffen werden, und denselben wird der IUI der gewünschten Datei geliefert. Da die Server vielleicht keinen Vorratscache in einem Standardformat implementieren, kann jegliche der bei Schritt 802 beschriebenen Techniken verwendet werden, um die gewünschte Datei auf dem FTP-Server zu finden. Wenn die Datei gefunden wird, wird dieselbe wiedergewonnen und das Verfahren endet.
Wenn die Datei nicht gefunden wird, können andere Techniken verwendet werden, wie z. B. Durchführen einer Anforderung über ein GSM-Telephon und Wiedergewinnung über Satellit, unter Verwendung einer Web-Suchmaschine, um die Datei zu finden, die einem IUI zugeordnet ist, etc. Ein Fehlerhandhaber kann bei Schritt 824 angerufen werden, um wenn nötig eine geeignete Fehlermeldung zurückzusenden. Somit beschreibt das Verfahren von 11 eine Technik, durch die eine gewünschte Datei unter Verwendung des IUI derselben auf eine effiziente Weise gesucht wird. Lokale und wahrscheinliche Orte für die Datei werden zuerst durchsucht, während die entfernten und weniger wahrscheinlichen Orte später durchsucht werden.
Anwendungsbeispiele
Die hierin beschriebenen, unterschiedlichen Ausführungsbeispiele sind für eine Verwendung in einem breiten Bereich von technischen und geschäftlichen Anwendungen geeignet. Die Erfindung ist z. B. nützlich bei der sicheren Speicherung von Dokumenten, bei der Zugriffssteuerung, beim treuhänderischen Verwalten von Dokumenten, für Verschlüsselungsfragen und beim zuverlässigen Bereitstellen einer Erzeugung von Dokumenten. Die folgenden Beispiele können unter Verwendung jeglicher der hierin beschriebenen Ausführungsbeispiele implementiert werden, z. B. des Ausführungsbeispiels von 2, des Ausführungsbeispiels von 3 oder des Ausführungsbeispiels von 7.
Für jegliche Anwendung können Metadaten 470 der abgeflachten Beschreiberdatei 460 verwendet werden, um einer interessierten Datei dabei zu helfen, den interessierenden Inhalt zu suchen und zu finden. Wenn man z. B. von einem Buch ausgeht, dessen Kapitel verschlüsselt sind und auf dem Internet unter Verwendung eines Ausführungsbeispiels der vorliegenden Erfindung verteilt sind. Metadaten 470 können Paßwörter umfassen, die dabei helfen, das Buch zu beschreiben, und Positionen, wo der Benutzer-MD5 gefunden werden kann damit und eine Zahlung durchgeführt werden kann, um den Schlüssel-MD5 zu empfangen. Somit kann eine interessierte Partei eine Suche auf dem Internet nach einem Buch unter Verwendung des Autors, des Themas oder der Titelschlüsselwörter durchführen, wenn die abgeflachte Beschreiberdatei nicht verschlüsselt ist; wenn diese Paßwörter in Metadaten 470 vorhanden sind, dann kann die Partei die abgeflachte Beschreiberdatei empfangen und schließlich das Buch unter Verwendung der hierin beschriebenen Ausführungsbeispiele wiedergewinnen.
In dem Bereich der sicheren Speicherung ist es oft wünschenswert, in der Lage zu sein, Dokumente an einer öffentlichen Position zu speichern, auf die einfach durch gewisse Entitäten zugegriffen werden kann, aber nicht zu ermöglichen, daß die Dokumente geöffnet oder gelesen werden, außer durch autorisierte Parteien. 12 ist ein Blockdiagramm, das die Verwendung der Erfindung in dem sicheren Speicherungsbereich darstellt. Bei diesem Beispiel möchte eine Bank die Unterschriftkarte eines Kunden digitalisieren und dieselbe für deren verteilte Anschlüsse zum Zugreifen und Verifizieren zur Verfügung haben. Eine Schwierigkeit ist, daß die Karte sicher gehalten werden muß und nicht an außenstehende Parteien freigegeben werden darf. Die Digitale-Unterschrift-Datendatei 902 wird unter Verwendung eines Ausführungsbeispiels der vorliegenden Erfindung 904 verarbeitet, um einen Schlüssel-MD5 906 und einen Haupt-MD5 908 zu erzeugen. Als Teil des Prozesses wird ferner eine verschlüsselte Version der Kartendatei 910 erzeugt. Wenn er unter Verwendung des Ausführungsbeispiels von 2 implementiert wird, entspricht der Schlüssel 906 dem MD5 106, und der Haupt-Algorithmus 908 entspricht dem MD5 114. Bei dem Ausführungsbeispiel von 3 kann die Kartendatei mit einer anderen Datei und/oder Bank oder Kartenmetadaten kombiniert werden, um eine Beschreiberdatei zu erzeugen, die dann den Schlüssel 906 und den Haupt-Algorithmus 908 ergibt. Der Schlüssel 906 und der Haupt-Algorithmus 908 werden dann sicher innerhalb einer Bankanwendung 912 gespeichert, die auf einem Bankterminal 914 liegt. Das Terminal 914 kann in Kommunikation mit einem Bank-Mainframe sein, der ursprünglich die MD5s berechnet hat und dieselben auf das Terminal heruntergeladen hat. Bei diesem Beispiel sind die Sicherheit für diesen Haupt-Algorithmus und den Schlüssel-Algorithmus die Verantwortlichkeit der Bankanwendung.
Die verschlüsselte Kartendatei 910 kann dann über das Internet oder eine andere Datenverbindung an eine nicht sichere, öffentliche Speicherung 916 übertragen werden. Da die Datei 910 verschlüsselt ist, kann eine außenstehende Partei dieselbe nicht lesen, obwohl sie in einer öffentlichen Speicherung gespeichert ist. Wenn die Anwendung 112 einen Bedarf nach einer bestimmten Kartendatei hat kann dieselbe dann den Schlüssel 906 und den Haupt-Algorithmus 908 verwenden, um die verschlüsselte Datei aus der öffentlichen Speicherung 916 wiederzugewinnen und dieselbe zu entschlüsseln. Ein solches Szenario ist mit mehreren Kundendateien und/oder anderen Dokumenttypen möglich. Andere sichere Speicherungsanwendungen können in Bereichen, wie z. B. Versicherung und Gesundheit gefunden werden.
13 ist ein Blockdiagramm, das die Verwendung eines Ausführungsbeispiels der Erfindung in dem Bereich der Zugriffssteuerung darstellt. Häufig erzeugt eine Entität Dokumente oder Informationen, daß dieselbe an einen autorisierten Benutzer liefern möchte, aber nur auf eine Authentifizierung dieses Benutzers hin. Ferner möchte eine Entität diese Authentifizierung vielleicht nicht selbst durchführen, möchte aber vielleicht, daß eine andere Person die Authentifizierung durchführt. Bei diesem Beispiel hat der Urheber 921 eine Datei 922 erzeugt, von dem derselbe möchte, daß der Benutzer 923 auf dieselbe Zugriff hat, jedoch nur wenn der Benutzer 923 sich selbst authentifizieren kann, oder wenn eine gewisse Zeit vergangen ist, oder wenn andere Bedingungen erfüllt werden. Unter Verwendung eines geeigneten Ausführungsbeispiels der Erfindung 924 wird die Datei 922 verarbeitet, um eine verschlüsselte Version 925, einen Schlüssel-MD5 926 und einen Benutzer-MD5 927 zu erzeugen. Wenn die Ausführungsbeispiele verwendet werden, die in 2 oder 3 gezeigt sind, würde der Benutzer-MD5 927 dem verschlüsselten MD5 114 bzw. dem Haupt-MD5 146 entsprechen. Dem Urheber 921 steht dann frei, die verschlüsselte Datei an die öffentliche Speicherung 928 zu übertragen, dieselbe selbst zu behalten oder sogar dieselbe an den Benutzer 923 zu liefern. Da die Datei verschlüsselt ist, kann der Benutzer auf dieselbe nicht zugreifen.
Als nächstes wird der Benutzer-MD5 über E-Mail 929, eine andere Datenverbindung, ein Telephon oder jegliches andere physische Austauschmedium an den Benutzer geliefert. Durch Besitz des Benutzer-MD5 kann ein Benutzer 923 die verschlüsselte Datei lokalisieren und wiedergewinnen, ist jedoch nicht in der Lage, dieselbe zu entschlüsseln. Gleichzeitig oder nachfolgend werden die zwei MD5s an eine Authentifizierungsdatenbank 931 auf sichere Weise übertragen. Es kann z. B. eine Internetverbindung 930 unter Verwendung des SSL verwendet werden. Eine sichere Verbindung wird bevorzugt, da es ein Besitz beider MD5s jeglicher Partei erlauben würde, die verschlüsselte Datei zu lesen. Die Datenbank 931 kann auf jedem geeigneten Authentifikationsserver vorhanden sein, der einen Authentifikationsagenten für den Urheber 921 betreibt. Der Server kann z. B. ein LDAP-Server sein, und die Protokolle 930 und 935 können sichere LDAP-Protokolle sein. Beide MD5s werden zusammen mit den Authentifikationsinformationen 933 in einer Aufzeichnung 932 der Datenbank gespeichert. Die Informationen 933 sind jegliche geeignete Informationen, die zum Authentifizieren eines Benutzers 923 geeignet sind, wie z. B. ein Paßwort. Der Authentifikationsserver enthält ferner jeglichen aus einer breiten Vielzahl von Authentifikationsmechanismen zum Authentifizieren außenstehender Parteien. Derartige Authentifikationsmechanismen sind in der Technik bekannt.
Um auf die verschlüsselte Datei zuzugreifen, liefert der Benutzer 923 sowohl den Benutzer-MD5 und die Authentifikationsinformationen des Benutzers über eine Datenverbindung 934. Der Benutzer-MD5 dient als ein Aufzeichnungslokalisierer innerhalb der Datenbank, um den richtigen Schlüssel und die Authentifikationsinformationen zu lokalisieren. Als nächstes authentifiziert der Authentifikationsserver den Benutzer durch Vergleichen der Authentifikationsinformationen oder durch Durchführen eines anderen bekannten Prozesses. Ist er authentisch, wird dann der Schlüssel-MD5 über eine Datenverbindung 935 zurück an den Benutzer 923 geliefert. Vorzugsweise ist die Verbindung 935 eine sichere Verbindung, wie z. B. ein SSL-Protokoll, das den Schlüssel schützt. Sobald der Benutzer 923 im Besitz des Schlüssel-MD5 ist, kann derselbe nun die verschlüsselte Datei direkt entschlüsseln oder mittels Entschlüsseln einer verschlüsselten Beschreiberdatei.
Bei diesem Beispiel kann der Urheber 921 entscheiden, das Privileg des Benutzers zu widerrufen, die Datei jederzeit durch einfaches Kommunizieren mit dem Authentifikationsserver zu betrachten. Der Server würde dann angewiesen, die Authentifikation für den Benutzer immer abzuweisen. Alternativ kann die Aufzeichnung 932 jeglicher Anzahl von Benutzern zugeordnet sein, die authentifiziert werden könnten, um den Schlüssel-MD5 herunterzuladen.
Bei einem anderen Bereich der Zugriffssteuerung können Dateien, die Musik verkörpern, über das Internet an einen Benutzer geliefert werden, dem es nicht erlaubt ist, auf die Dateien zuzugreifen, bis er oder sie bezahlt hat. Unter Verwendung des Ausführungsbeispiels von 3 können die verschlüsselten Dateien z. B. mit einem Haupt-MD5 oder mit der verschlüsselten Beschreiberdatei 142 selbst geliefert werden. Sobald der Benutzer eine Kreditkartenzahlung über das Internet vervollständigt, liefert die herausgebende Entität den Schlüssel-MD5 138 an den Benutzer, der es dem Benutzer ermöglicht, die Beschreiberdatei zu entschlüsseln. Sobald dieselbe entschlüsselt ist, hat der Benutzer Zugriff auf die Klartext-MD5s, die es dem Benutzer ermöglichen, die Musikdatei zu entschlüsseln. Alternativ werden die verschlüsselten Musikdateien nicht an den Benutzer geliefert, sondern werden durch den Benutzer unter Verwendung des verschlüsselten MD5 114 lokalisiert und wiedergewonnen, der in der Beschreiberdatei umfaßt ist. Andere Beispiel in dem Bereich der Zugriffssteuerung, bei denen dieses Ausführungsbeispiel nützlich sein kann, sind im Internet veröffentlicht.
14 ist ein Blockdiagramm, das die Verwendung eines Ausführungsbeispiels der Erfindung für treuhänderische Verwaltungszwecke darstellt. Eine breite Vielzahl von Informationen können in die treuhänderische Verwaltung aufgenommen werden, wie z. B. experimentelle Aufzeichnungen, rechtliche Dokumente, Regierungsaufzeichnungen, etc. Bei diesem Beispiel produziert ein Softwareunternehmen 942 ein Softwareprogramm in der Form einer Softwaredatei 944, die durch einen Softwarebenutzer 946 verwendet wird. Für jeglichen aus einer Anzahl von Gründen sind beide Parteien übereingekommen, daß die Softwaredateien für späteren Zugriff durch den Benutzer, falls benötigt, in die treuhänderische Verwaltung aufgenommen werden. Das Unternehmen wünscht jedoch nicht, daß irgend jemand Zugriff auf die Dateien hat, außer die entsprechenden Bedingungen sind erfüllt. Dementsprechend verarbeitet ein Ausführungsbeispiel der Erfindung 948 Dateien 944, um verschlüsselte Dateien 950, einen Schlüssel-MD5 952 und einen Benutzer-MD5 954 zu erzeugen. Der Benutzer-MD5 wird dann an den Softwarebenutzer geliefert. Bei dem Ausführungsbeispiel von 7 können die Dateien 950 durch den Benutzer unter Verwendung einer abgeflachten Beschreiberdatei wiedergewonnen werden, oder die Datei kann einfach von dem Softwareunternehmen an den Benutzer geliefert werden. Bei dem Ausführungsbeispiel von 3 entspricht der Benutzer-MD5 dem Haupt-MD5, und die verschlüsselten Dateien können an einem öffentlichen Ort gespeichert werden, der durch den Treuhandagenten 956 angenommen wird, oder können sogar von dem Unternehmen an den Benutzer geliefert werden.
Der Schlüssel-MD5 952 wird an den Treuhandagenten 956 geliefert, der dieselbe zurückhält, bis eine Bedingung erfüllt wird, die vorangehend durch das Unternehmen und den Benutzer vereinbart wurde. Nach Zufriedenstellung der Bedingung wird der Schlüssel 952 an den Benutzer unter Verwendung jeglicher geeigneter Einrichtung geliefert 958. Sobald sich derselbe im Besitz des Schlüssels befindet, kann der Benutzer die verschlüsselte Beschreiberdatei entschlüsseln, um die Klartext-MD5s zu erhalten, die es dem Benutzer ermöglichen, die Dateien 950 zu entschlüsseln und zu lesen. Somit wird die treuhänderische Softwareverwaltung vereinfacht.
Bei einem anderen Beispiel über treuhänderisches Verwalten ist ein pharmazeutisches Unternehmen dabei, ein Medikament genehmigen zu lassen, und erzeugt umfangreiche Unterlagen und klinische Daten, die es benötigen könnte, um dieselben an die FDA (FDA = Food and Drug Administration) zu senden. Das Unternehmen könnte wünschen, den Genehmigungsprozeß zu beschleunigen, und sicherzustellen, daß die umfangreichen Datenmengen im Lauf der Zeit nicht geändert werden können. Die FDA wünscht auf ähnliche Weise eine Absicherung, daß derartige klinische Daten, falls sie sich in treuhänderischer Verwaltung befinden, sich im Lauf der Zeit nicht ändern. Unter Verwendung eines Ausführungsbeispiels der vorliegenden Erfindung kann ein einzelner MD5 (oder ein anderer Typ von Identifizierer) eine enorme Datenmenge darstellen, und für die FDA sicherstellen, daß die Dokumente, die ursprünglich verwendet wurden, um den MD5 zu erzeugen, sich seit dieser Zeit nicht geändert haben.
Bei diesem Beispiel erzeugt das Unternehmen regelmäßig einen Benutzer-MD5 und einen Schlüssel-MD5 basierend auf jeglicher Anzahl von Datendateien, auf die die Verwaltung eventuell zugreifen muß. Der Benutzer-MD5 wird dann an die FDA geliefert, und gleichzeitig können die Datendateien durch einen Treuhandagenten zurückgehalten werden, in eine öffentliche Speicherung gegeben werden oder sogar an die Regierung geliefert werden. Da das Unternehmen wünschen könnte, den Zugriff auf die Datendateien zu begrenzen, falls der Genehmigungsprozeß eingestellt wird, wurden die Dateien vorangehend unter Verwendung eines Ausführungsbeispiels der Erfindung verschlüsselt. Sollte das Unternehmen auf den Genehmigungsprozeß verzichten könnte es vorteilhafterweise auswählen, den Schlüssel-MD6 nicht an die FDA zu liefern, und somit wäre die FDA (oder irgend jemand anderes) nicht in der Lage, die Beschreiberdatei zu entschlüsseln.
Am Ende des Genehmigungsprozesses liefert das Unternehmen den Schlüssel-MD5 an die FDA, die denselben dann in Verbindung mit dem Benutzer-MD5 verwenden kann, um die Datendateien zu entschlüsseln und dieselben zu betrachten. Das Unternehmen wird gegen jeden geschützt, der die Dateien desselben vorzeitig betrachtet. Die FDA wird dagegen geschützt, daß die Daten in der Zwischenzeit geändert werden, da der Benutzer-MD5 und der Schlüssel-MD5 garantieren, daß die letztendlich entschlüsselten Dateien diejenigen sind, die ursprünglich verwendet wurden, um den Benutzer-MD5 und den Schlüssel-MD5 zu erzeugen.
Die vorliegende Erfindung kann ferner in Situationen verwendet werden, in denen die Regierung oder eine andere Entität über eine Entität beunruhigt ist, die eine Verschlüsselung verwendet, die undurchbrechbar ist. Aus nationalen Sicherheitsgründen kann die Regierung an einem bestimmten Punkt wünschen die Kommunikation einer privaten Partei zu entschlüsseln. Bei diesem Beispiel stimmt die private Partei zu, ihre Kommunikation unter Verwendung eines Ausführungsbeispiels der vorliegenden Erfindung zu verschlüsseln, bei der ein Schlüssel-MD5 und ein Haupt-MD5 (oder ein Benutzer-MD5) erzeugt werden. Die Dateien, die durch die private Partei verschlüsselt wurden, werden an eine öffentliche Speicherung oder an einen Regierungsserver zur sicheren Verwahrung geliefert. Basierend auf allgemein anerkannten, rechtlichen Prinzipien und einem Vertrag zwischen der privaten Partei und der Regierung werden der Schlüssel-MD5 und der Haupt-MD5 zur sicheren Verwahrung an ein geeignetes Regierungsorgan geliefert. Wenn irgendwann in der Zukunft rechtlich bestimmt wird, daß die Kommunikation der privaten Partei entschlüsselt werden muß, kann das Regierungsorgan sowohl den Schlüssel-MD5 als auch den Haupt-MD5 an eine geeignete, rechtliche Entität freigeben, die dann in der Lage wäre, die Dateien nicht nur zu lokalisieren und auf dieselben zuzugreifen, sondern ferner dieselben zu entschlüsseln. Aufgrund der Eigenschaft der vorliegenden Erfindung wird ferner beiden Parteien praktisch versichert, daß die schließlich entschlüsselten Dateien die Originaldateien sind, die die geheime Kommunikation der private Partei bilden.
Ausführungsbeispiele der vorliegenden Erfindung können ferner verwendet werden, um die Existenz von Aufzeichnungen an einem bestimmten Datum zu beweisen. Man nehme z. B. einen einzelnen Erfinder, der fleißig arbeitet, um eine Erfindung zu perfektionieren. Seine Aufzeichnungen umfassen digitale Textdateien, digitale Zeichnungen und/oder handschriftliche Dokumente, die digitalisiert werden können. An einem bestimmten Datum verwendet der Erfinder ein Ausführungsbeispiel der Erfindung, um einen Schlüssel-MD5 und einen Haupt-MD5 (oder einen Benutzer-MD5) für alle seine Aufzeichnungen in der Form von Computerdateien zu erzeugen. Der einzelne MD5 wird dann an das Patentamt geliefert. Das Patentamt protokolliert, daß der MD5 an einem gewissen Datum empfangen wurde und behält denselben für eine sichere Verwahrung. Sowohl der Haupt-MD5 als auch der Schlüssel-MD5 bleiben bei dem einzelnen Erfinder. Die eigentlichen, digitalen Dateien (verschlüsselt) können durch den Erfinder behalten werden, in eine öffentliche Speicherung plaziert werden oder sogar an die Regierung geliefert werden.
Sollte der Erfinder wünschen, seine Erfindung zurückzunehmen und dieselbe nicht zu offenbaren braucht er einfach den Schlüssel-MD5 nicht an das Patentamt liefern, und die Dateien könnten nicht entschlüsselt werden. Wenn der Erfinder zu einem späteren Zeitpunkt ein Entwurfsdatum beweisen möchte, wird der Schlüssel-MD5 an das Patentamt geliefert, das dann in der Lage ist, die Originaldokumente des Erfinders zu lokalisieren und zu entschlüsseln. Aufgrund des Original-Haupt-MD5, der an einem bestimmten Datum protokolliert wurde, kann zuverlässig bewiesen werden, daß die Originaldokumente, die schließlich unter Verwendung des Haupt-MD5 und des Schlüssel-MD5 entschlüsselt werden, in der Tat zu einem früheren Datum bestanden.
Bei einem anderen Beispiel darüber, wie die vorliegende Erfindung verwendet werden kann, um die Existenz von Aufzeichnungen zu einem bestimmten Datum zu beweisen, wird von einem Notar ausgegangen, der Zugriff zum Internet hat. Eine Partei, die einen Beweis über die Existenz eines Dokuments zu einem bestimmten Datum wünscht, verwendet ein Ausführungsbeispiel der Erfindung, um einen eindeutigen MD5 für dieses Dokument zu erzeugen. Die Ausführungsbeispiele von 2, 3 oder 7 können z. B. verwendet werden, wobei in dem Fall der Benutzer den MD5 114, den Haupt-MD5 146 oder den Benutzer-MD5 464 erzeugt. Der Benutzer sendet den MD5 (vorzugsweise codiert) über elektronische Post oder ein anderes geeignetes Verfahren an einem bestimmten Datum an den Notar. Der Notar empfängt den MD5, protokolliert denselben und beglaubigt notariell, daß derselbe an einem bestimmten Datum empfangen wurde. Zu einem späteren Zeitpunkt kann der entsprechende Schlüssel-MD5 durch den Benutzer bereitgestellt werden, um zuverlässig zu beweisen, daß das Dokument, das durch den Original-MD5 identifiziert wurde an dem Datum existierte, an dem der Notar den Original-MD5 empfangen hat.
Ein erzeugter, eindeutiger Eigenidentifizierer (IUI), wie z. B. ein alphanumerisch codierter MD5, kann in eine breite Vielzahl von physischen Objekten eingebaut, transportiert oder an dieselben angebracht werden. Jeder MD5 kann z. B. in eine elektronische Postmeldung eingebaut werden, um einen Dateiensatz zu spezifizieren. Alternativ können die MD5s automatisch durch eine Netzwerkvorrichtung erzeugt werden, die eine Sicherung der Dateien und der spezifizierten Verzeichnisse durchführt. Die MD5s können durch eine Geschäftsanwendung erzeugt werden, wodurch die relevanten, digitalen Informationen versiegelt werden, die sich auf eine bestimmte Transaktion beziehen. Zusätzlich können die MD5s aus anderen Gründen durch einen Benutzer, Netzwerkknoten, eine Anwendung oder eine Hardwarevorrichtung erzeugt werden, die eine Datei oder eine Gruppe von Dateien zu einem bestimmten Zweck eindeutig spezifizieren muß. Derartige MD5s können in Datenbankanwendungen, vorhandenen Anwendungen, die auf Großcomputern laufen, Textwiedergewinnungsanwendungen, Web-Sites, etc. eingebaut sein und es kann auf dieselben einfach zugegriffen werden.
Ferner könnte ein IUI (wie z. B. ein alphanumerisch codierter MD5) in einen digitalen Inhalt plaziert werden, um diesen Inhalt zu identifizieren, dessen Verwendung zu autorisieren, weitere Informationen zu adressieren, etc. Zum Beispiel eine Musikdatei, wie z. B. das MP3-Format könnte eingemischt sein, „eingespleißt” sein, oder ein Wasserzeichen verwenden, um einen IUI in die tatsächliche Musikdatei einzubauen. Ein derartiger IUI könnten ferner in ein genetisches Material eingebaut sein, um auf weitere Informationen über dieses genetische Material Bezug zu nehmen.
Ein IUI könnte physisch an ein physisches Objekt angebracht sein, um einen Bezug zu umfangreichen Informationen über dieses Objekt zu liefern. Ein Streifencode z. B., der einen IUI repräsentiert, könnte an einem Heimgerät vorhanden sein und ein Benutzerhandbuch darstellen. Oder die alphanumerische Darstellung eines IUI kann an einem Objekt vorhanden sein; ein Benutzer könnte dann den IUI in einen Computer eingeben, um Dateien über das Internet über dieses Objekt zu empfangen.
Ein IUI könnte innerhalb eines Speichers einer Rechenvorrichtung vorhanden sein, um Bezug auf ein umfangreicheres Programmieren oder Daten für diese Vorrichtung zu nehmen. Es wird z. B. eine typische Chipkarte mit einer Speicherkapazität von 2 K-Byte berücksichtigt. Dieser begrenzte Speicherraum wird für kleine Programme und Daten verwendet. Wenn dieselben in einen Chipkartenterminal eingeführt wird, wie z. B. einen Bankautomaten, werden Verbindungen mit anderen Rechenvorrichtungen hergestellt, um das begrenzte Programm und die Daten, die auf der Chipkarte gespeichert sind, auszuführen. Um die verwendbare Programmgröße zu erweitern, oder die Anzahl ausführbarer Programme auf einer Chipkarte, wird der IUI in den Speicher der Chipkarte eingebaut. Der IUI identifiziert zusätzliche Programme oder Daten eindeutig, die auf die Chipkarte geladen werden können oder durch den Terminal oder die Chipkarte ausgeführt werden können. Das gleiche würde mit anderen tragbaren Vorrichtungen funktionieren, wie z. B. Mobiltelephonen, persönlichen digitalen Assistenten, etc.
Computersystemausführungsbeispiel
15 ist ein Blockdiagramm, das eine Computernetzumgebung darstellt, die für eine Verwendung mit einem Ausführungsbeispiel der Erfindung geeignet ist. Ein Benutzercomputer 962, der zusammen mit anderen Computern mit dem LAN 964 verbunden ist, greift über einen Servercomputer 966 auf das Internet 968 zu. Hiermit ist ein anderer Servercomputer 974 verbunden, der an das LAN 970 angebracht ist, das einen Benutzercomputer 972 umfaßt. Wie sie in einem Softwareprogramm verkörpert ist, ist eine Agentensoftware, die auf jedem Computer 962 oder 872 vorhanden ist, angeordnet, um die Flüsse für 4 und 8 zu implementieren und verschlüsselte Dateien, Beschreiberdateien und den eindeutigen Eigenidentifizierer zu erzeugen. Die Dateien und der Identifizierer können dann lokal gehalten werden oder auf eine geeignete Weise durch das Netzwerk verteilt werden.
Beim Implementieren der Flüsse von 9 oder 10 umfaßt der Computer 972 eine Agentensoftware, die einen eindeutigen Eigenidentifzierer identifiziert und beginnt, nach demselben zu suchen. Wird derselbe nicht lokal gefunden wird die Anforderung nach einer Datei oder Dateien durch den Servercomputer 974 gehandhabt, der die Serversoftware implementiert. Eine solche Serversoftware kann die Flüsse von 9 und 10 und Abschnitte von 11 implementieren, um nach den angeforderten Dateien zu suchen, sie wiederzugewinnen, zu entschlüsseln und an den Computer 972 zu liefern. Bei einem alternativen Ausführungsbeispiel müssen die Funktionen, die durch die Agentensoftware und die Serversoftware implementiert werden, nicht getrennt werden, sondern können innerhalb eines einzelnen Softwareprogramms verkörpert sein, das auf einem Computer oder einer beliebigen Anzahl von Computern vorhanden ist.
16 und 17 stellen ein Computersystem 1000 dar, das zum Implementieren jeglicher der hierin erwähnten Computer geeignet ist. 16 zeigt eine mögliche, physikalische Form des Computersystems. Natürlich kann das Computersystem viele physikalische Formen aufweisen, die von einer integrierten Schaltung, einer gedruckten Schaltungsplatine und einer kleinen Handvorrichtung bis zu einem riesigen Supercomputer reichen. Das Computersystem 1000 umfaßt einen Monitor 1002, eine Anzeigevorrichtung 1004, eine Häusung 1006, ein Diskettenlaufwerk 1008, eine Tastatur 1010 und eine Maus 1012. Eine Diskette 1014 ist ein computerlesbares Medium, das verwendet wird, um Daten zu und von einem Computersystem 1000 zu übertragen.
17 ist ein Beispiel eines Blockdiagramms für das Computersystem 1000. Eine breite Vielzahl von Teilsystemen sind an dem Systembus 1020 angebracht. Prozessor(en) 1022 (die ferner als zentrale Verarbeitungseinheiten oder CPUs bezeichnet werden) sind mit Speicherungsvorrichtungen gekoppelt, die den Speicher 1024 einschließen. Der Speicher 1024 umfaßt einen Direktzugriffsspeicher (RAM = random access memory) und einen Nur-Lese-Speicher (ROM = read-only memory). Wie in der Technik bekannt ist, wirkt der ROM, um Daten und Befehle unidirektional an die CPU zu übertragen, und der RAM wird üblicherweise verwendet, um Daten und Befehle auf eine bidirektionale Weise zu übertragen. Beide dieser Speichertypen können jegliches geeignete, computerlesbare Medium umfassen, das nachfolgend beschrieben wird. Eine Festplatte bzw. stationäre Platte 1026 ist ferner bidirektional mit der CPU 1022 gekoppelt; sie liefert zusätzliche Datenspeicherungskapazität und kann ferner jegliches der computerlesbaren Medien umfassen, die nachfolgend beschrieben werden. Die Festplatte 1026 kann verwendet werden, um Programme, Daten und ähnliches zu speichern, und ist üblicherweise ein sekundäres Speicherungsmedium (wie z. B. eine Festplatte), das langsamer ist als eine primäre Speicherung. Es wird darauf hingewiesen, daß die Informationen, die innerhalb der Festplatte 126 gehalten werden, in geeigneten Fällen auf eine übliche Weise als virtueller Speicher in den Speicher 1024 integriert werden können. Eine entfernbare Platte 1014 kann die Form jeglicher der nachfolgend beschriebenen computerlesbaren Medien annehmen.
Die CPU 1022 ist ferner mit einer Vielzahl von Eingabe-/Ausgabe-Vorrichtungen gekoppelt, wie z. B. der Anzeige 1004, der Tastatur 1010, der Maus 1012 und den Lautsprechern 1030. Im allgemeinen kann eine Eingabe-/Ausgabe-Vorrichtung folgendes sein: Videoanzeigevorrichtungen, Steuerungsbälle, Mäuse, Tastaturen, Mikrophone, berührungsempfindliche Anzeigen, Umwandlerkartenleser, Magnet- oder Papier-Band-Leser, Tabletts, Taster, Stimm- oder Schrift-Erkenner, Biometrikleser oder andere Computer. Die CPU 1022 kann optional mit einem anderen Computer oder einem Telekommunikationsnetzwerk unter Verwendung der Netzwerkschnittstelle 140 gekoppelt sein. Mit einer solchen Netzwerkschnittstelle wird angenommen, daß die CPU Informationen von dem Netzwerk empfangen könnte oder Informationen im Lauf des Ausführens der oben beschriebenen Verfahrensschritte an das Netzwerk ausgeben könnte. Ferner können Verfahrensausführungsbeispiele der vorliegenden Erfindung nur auf der CPU 1022 arbeiten oder können über ein Netzwerk arbeiten, wie z. B. das Internet in Verbindung mit einer entfernten CPU, die einen Abschnitt des Verarbeitens gemeinschaftlich verwendet.
Zusätzlich dazu beziehen sich die Ausführungsbeispiele der vorliegenden Erfindung ferner auf Computerspeicherungsprodukte mit einem computerlesbaren Medium, die auf demselben einen Computercode zum Durchführen verschiedener computerimplementierter Operationen aufweist. Das Medium und der Computercode können spezifisch für die Zwecke der vorliegenden Erfindung entworfen und konstruiert worden sein, oder sie können von der Art sein, die für Fachleute im Bereich der Computersoftware verfügbar und bekannt sind. Beispiele computerlesbarer Medien umfassen folgende, sind jedoch nicht auf dieselben beschränkt: magnetische Medien, wie z. B. Festplatten, Disketten und Magnetband; optische Medien, wie z. B. CD-ROMs und holographische Vorrichtungen; magneto-optische Medien, wie z. B. floptische Platten; und Hardwarevorrichtungen, die spezifisch konfiguriert sind, um einen Programmcode zu speichern und auszuführen, wie z. B. anwendungsspezifische, integrierte Schaltungen (ASIC = application-specific integrated circuit), programmierbare Logikelemente (PLD = programmable logic device) und ROM- und RAM-Vorrichtungen. Beispiele eines Computercodes umfassen einen Maschinencode, wie er z. B. durch einen Kompilierer erzeugt wird, und Dateien, die höhere Codes enthalten, die unter Verwendung eines Interpretierers durch einen Computer ausgeführt werden.
Obwohl die vorangehende Erfindung zu Zwecken der Klarheit und des Verständnisses detailliert beschrieben wurde, ist es offensichtlich, daß gewisse Änderungen und Modifikationen innerhalb des Schutzbereichs der beigefügten Ansprüche durchgeführt werden können. Bei dem Ausführungsbeispiel von 7 könnte der Schlüsselidentifizierer z. B. zuerst an einen Benutzer geliefert werden, und dann erst der Hauptidentifizierer später, anstatt anders herum. Daher sollten die beschriebenen Ausführungsbeispiele darstellend und nicht einschränkend betrachtet werden, und die Erfindung sollte nicht auf die Details beschränkt werden, die hierin gegeben sind, sondern sollte durch die nachfolgenden Ansprüche und deren gesamten Schutzbereich von Entsprechungen definiert werden.

Claims

Ein Verfahren zum Erzeugen einer verschlüsselten Version eines Binärwerts, wobei das Verfahren folgende Schritte aufweist: Erzeugen eines eindeutigen Identifizierers (106) für den Binärwert, wobei der eindeutige Identifizierer (106) aus mindestens einem Abschnitt des Inhalts des Binärwerts berechnet wird, ohne Informationen betreffend eine Zugriffserlaubnis auf den Binärwert zu verwenden, und den Binärwert eindeutig identifiziert; Verschlüsseln des Binärwerts unter Verwendung des eindeutigen Identifizierers (106) als einen Schlüssel, wobei das Verschlüsseln zu der verschlüsselten Version des Binärwerts führt; und Bereitstellen des eindeutigen Identifizierers (106), um die verschlüsselte Version des Binärwerts zu entschlüsseln und die Integrität der entschlüsselten Version des Binärwerts zu verifizieren.
Ein Verfahren gemäß Anspruch 1, das ferner folgende Schritte aufweist: Erzeugen eines zweiten, eindeutigen Identifizierers für die verschlüsselte Version des Binärwerts, wobei der zweite, eindeutige Identifizierer aus mindestens einem Abschnitt der verschlüsselten Version des Binärwerts berechnet wird und die verschlüsselte Version des Binärwerts eindeutig identifiziert; und Bereitstellen des zweiten, eindeutigen Identifizierers für die Wiedergewinnung der verschlüsselten Version des Binärwerts, wodurch der zweite, eindeutige Identifizierer verwendet werden kann, um die verschlüsselte Version zu lokalisieren.
Ein Verfahren gemäß Anspruch 2, das ferner folgende Schritte aufweist: Erzeugen einer Beschreiberdatei, die den eindeutigen Identifizierer und den zweiten eindeutigen Identifizierer umfaßt; Erzeugen eines dritten Dateiidentifizierers, wobei der dritte Dateiidentifizierer aus mindestens einem Abschnitt der Beschreiberdatei berechnet wird und die Beschreiberdatei eindeutig identifiziert; Verschlüsseln der Beschreiberdatei unter Verwendung des dritten Identifizierers als einen Schlüssel, wobei das Verschlüsseln eine verschlüsselte Beschreiberdatei erzeugt; und Erzeugen eines vierten Dateiidentifizierers für die verschlüsselte Beschreiberdatei, wobei der vierte Dateiidentifizierer aus mindestens einem Abschnitt der verschlüsselten Beschreiberdatei berechnet wird und die verschlüsselte Beschreiberdatei eindeutig identifiziert, wodurch der dritte Dateiidentifizierer und der vierte Dateiidentifizierer verwendet werden können, um auf den Inhalt des Binärwerts zuzugreifen.
Ein Verfahren gemäß Anspruch 2 oder 3 zum eindeutigen und sicheren Identifizieren einer Computerdatei, wobei die Schritte des Erzeugens das Erzeugen eines ersten Dateiidentifizierers für eine Datei, wobei der erste Dateiidentifizierer aus mindestens einem Abschnitt der Datei berechnet wird und die Datei eindeutig identifiziert, und das Erzeugen eines zweiten Dateiidentifizierers für die verschlüsselte Datei, wobei der zweite Dateiidentifizierer aus mindestens einem Abschnitt der verschlüsselten Datei berechnet wird und die verschlüsselte Datei eindeutig identifiziert, umfassen; der Schritt des Verschlüsselns das Verschlüsseln der Datei umfaßt; und die Schritte des Bereitstellens das Bereitstellen des ersten Dateiidentifizierers und des zweiten Dateiidentifizierers für die Wiedergewinnung der Datei umfassen.
Ein Verfahren gemäß Anspruch 4, bei dem die Schritte des Erzeugens eine Hash-Funktion verwenden.
Ein Verfahren gemäß Anspruch 4, das ferner folgenden Schritt aufweist: Komprimieren der Datei in Verbindung mit dem Verschlüsseln.
Ein Verfahren zum eindeutigen und sicheren Identifizieren einer Gruppe von Binärwerten, wobei ein Binärwert digitale Informationen darstellt, wobei das Verfahren folgende Schritte aufweist: Berechnen eines eindeutigen Eigenidentifizierers (IUI) für jeden der Binärwerte, wobei der eindeutige Eigenidentifizierer (106) aus mindestens einem Abschnitt des Inhalts jedes Binärwerts berechnet wird, ohne Informationen betreffend eine Zugriffserlaubnis auf den Binärwert zu verwenden, und den Binärwert eindeutig identifiziert; Verschlüsseln von jedem der Binärwerte unter Verwendung des IUI jedes Werts als dessen Schlüssel, um eine verschlüsselte Version von jedem der Binärwerte zu erzeugen; Berechnen eines IUI von jedem der verschlüsselten Versionen; Erzeugen einer Datei, die die IUIs der Binärwerte umfaßt und die IUIs der verschlüsselten Versionen; Berechnen eines Schlüssel-IUI für die Datei; Verschlüsseln der Datei unter Verwendung des Schlüssel-IUI, um eine verschlüsselte Datei zu erzeugen; und Berechnen eines Haupt-IUI für die verschlüsselte Datei, wobei der Schlüssel-IUI und der Haupt-IUI die Binärwerte eindeutig darstellen und verwendet werden können, um die Werte zu lokalisieren.
Ein Verfahren gemäß Anspruch 7, bei dem die eindeutigen Eigenidentifizierer aus einem Abschnitt des Werts oder der Datei berechnet werden, für die sie berechnet werden, und den Wert oder die Datei, für die sie berechnet werden, eindeutig identifizieren.
Ein Verfahren gemäß Anspruch 8, bei dem jeder IUI unter Verwendung einer Hash-Funktion berechnet wird.
Ein Verfahren gemäß Anspruch 7, das ferner folgenden Schritt aufweist: Komprimieren von jedem der Binärwerte.
Ein Verfahren gemäß Anspruch 7, das ferner folgende Schritte aufweist: Erzeugen einer abgeflachten Datei, die die IUIs der verschlüsselten Versionen der Binärwerte und den Haupt-IUI umfaßt; und Berechnen eines Benutzer-IUI der abgeflachten Datei, wodurch ein Benutzer, der mit dem Benutzer-IUI ausgestattet ist, die abgeflachte Datei wiedergewinnen kann und dadurch die verschlüsselten Versionen der Binärwerte wiedergewinnen und die verschlüsselte Datei wiedergewinnen kann.
Ein Verfahren zum eindeutigen und sicheren Identifizieren einer Gruppe von Dateien, wobei das Verfahren folgende Schritte aufweist: Erzeugen einer Schlüsseldatei, die eine Mehrzahl kryptographischer Schlüssel umfaßt, wobei jeder Schlüssel einer der Gruppe von Dateien zugeordnet ist; Berechnen eines eindeutigen Identifizierers für die Schlüsseldatei, wobei der Schlüsseldateiidentifizierer aus einem Abschnitt des Inhalts der Schlüsseldatei berechnet wird, ohne Informationen betreffend eine Zugriffserlaubnis auf die Schlüsseldatei zu verwenden; Verschlüsseln der Schlüsseldatei unter Verwendung des Schlüsseldateiidentifizierers, um eine verschlüsselte Schlüsseldatei zu erzeugen; Berechnen eines eindeutigen Identifizierers für die verschlüsselte Schlüsseldatei, wobei der Identifizierer der verschlüsselten Schlüsseldatei aus einem Abschnitt des Inhalts der verschlüsselten Schlüsseldatei berechnet wird; Erzeugen einer abgeflachten Datei, die den Identifizierer der verschlüsselten Schlüsseldatei umfaßt und eindeutige Identifizierer für verschlüsselte Versionen der Dateien, wobei jeder eindeutige Identifizierer von einer der verschlüsselten Dateien aus dem Inhalt der zugeordneten, verschlüsselten Datei derselben berechnet wird, wobei jede verschlüsselte Datei unter Verwendung ihres zugeordneten Schlüssels entschlüsselt wurde, um die Klartextversion der Datei zu entschlüsseln; und Berechnen eines eindeutigen Benutzeridentifizierers für die abgeflachte Datei, wobei der eindeutige Benutzeridentifizierer aus einem Abschnitt des Inhalts der abgeflachten Datei berechnet wird, wodurch ein Benutzer, dem der eindeutige Benutzeridentifizierer bereitgestellt wird, die abgeflachte Datei und die verschlüsselten Versionen der Dateien wiedergewinnen kann, und wenn demselben der Schlüsseldateiidentifizierer bereitgestellt wird, kann der Benutzer die verschlüsselten Dateien entschlüsseln.
Ein Verfahren gemäß Anspruch 12, bei dem jeder der Schlüssel ein eindeutiger Identifizierer für dessen zugeordnete Datei ist und aus einem Abschnitt des Inhalts von dessen zugeordneter Datei berechnet wird.
Ein Verfahren gemäß Anspruch 12, bei dem die Schlüsseldatei Metadaten für jede der Dateien zusammen mit deren zugeordnetem Schlüssel umfaßt.