DE60204049T2 - Systeme, verfahren und einrichtungen zur sicheren datenverarbeitung - Google Patents

Systeme, verfahren und einrichtungen zur sicheren datenverarbeitung Download PDF

Info

Publication number
DE60204049T2
DE60204049T2 DE60204049T DE60204049T DE60204049T2 DE 60204049 T2 DE60204049 T2 DE 60204049T2 DE 60204049 T DE60204049 T DE 60204049T DE 60204049 T DE60204049 T DE 60204049T DE 60204049 T2 DE60204049 T2 DE 60204049T2
Authority
DE
Germany
Prior art keywords
file
data
encrypted
function
subset
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60204049T
Other languages
English (en)
Other versions
DE60204049T8 (de
DE60204049D1 (de
Inventor
Massimo Di Pierro
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Metacryption Chicago LLC
METACRYPTION LLC
Original Assignee
Metacryption Chicago LLC
METACRYPTION LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Metacryption Chicago LLC, METACRYPTION LLC filed Critical Metacryption Chicago LLC
Publication of DE60204049D1 publication Critical patent/DE60204049D1/de
Application granted granted Critical
Publication of DE60204049T2 publication Critical patent/DE60204049T2/de
Publication of DE60204049T8 publication Critical patent/DE60204049T8/de
Active legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
    • G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information

Description

  • HINTERGRUND DER ERFINDUNG
  • Das Sicherstellen des Datenschutzes und der Echtheit von Daten kann ein wichtiger Gesichtspunkt vieler Aufgaben im Computerwesen sein. Dies gilt insbesondere, da verteilte Rechenanlagen entwickelt werden, bei denen Anwendungen auf einer oder mehreren nicht vertrauenswürdigen Maschinen laufen. Es gilt auch insbesondere, da die Wechselwirkung zwischen Betriebssystemen und Anwendungen komplexer geworden ist, was mehr Möglichkeiten öffnet, die Sicherheit des Umfelds zu kompromittieren, in dem sensible Daten bearbeitet werden.
  • Herkömmliche Datenschutz- und Authentifizierungssysteme konzentrieren sich auf das Schützen von Daten, die zwischen einer Ursprungsmaschine und einer Zielmaschine übermittelt werden, insbesondere über ein öffentliches Netz. Eine Standard-Emailmitteilung kann zum Beispiel an viele verschiedene und unbekannte Server weitergegeben werden, bevor sie bei einer Zielmaschine ankommt. Jeder dieser unbekannten Server kann als offensichtliche Ausspionier- oder Datenmanipulationsgefahr dienen. Herkömmliche Verschlüsselungs- und Authentifizierungssysteme versuchen daher, die Informationen auf ihrem Weg zwischen Maschinen unbekannter Vertrauenswürdigkeit zu schützen. Diese Verfahren nutzen eine Verschlüsselung, die im Allgemeinen von einem auf einer vertrauenswürdigen Maschine installierten Betriebssystem gehandhabt wird. Verschlüsselte und authentifizierte Daten, die mittels bekannter Sicherheitsverfahren erzeugt und über nicht vertrauenswürdige Server geschickt werden, unterliegen weit weniger einer nicht autorisierten Aneignung oder Änderung als die Rohdaten selbst.
  • Wenn sensible Daten in einer nicht vertrauenswürdigen Umgebung verwendet werden müssen, sind herkömmliche Systeme in ihrer Wirksamkeit beschränkt. Eine Anwendung, die zum Beispiel versucht, sensible Daten legitim zu manipulieren, ist gegenüber Ausspionieren und Verfälschung hilflos, wenn die Maschine, auf der sie läuft, selbst nicht vertrauenswürdig ist. Herkömmliche Verfahren können diese Probleme der Sicherheit zwischen Anwendungen nicht lösen.
  • U.S. Patent Nr. 6,021,491 für Renaud lehrt die Verifizierung von Datenechtheit unter Verwendung einer Signaturdatei mit einer digitalen Signatur, die mit Hilfe eines Signaturverifizierungsalgorithmus geprüft wird. Diese Verifizierung vergleicht einfach eine mit einer Identifizierung in der digitalen Signatur identifizierte Datei.
  • U.S. Patent Nr. 5,892,904 für Atkinson, et al. lehrt ein Signierverfahren, bei dem ein Softwarecode eine Signatur empfängt, um Echtheit und Unversehrtheit einer Datei für einen Empfänger des Codes sicherzustellen. Das Signierverfahren bildet eine Herausgebersignatur unter Verwendung eines Hashwerts der Datei.
  • Die internationale veröffentlichte Anmeldung WO 00/59177 lehrt das Prüfen einer digitalen Signatur einer Datei vor dem Übermitteln der Datei von einem Server. Wurde die Datei manipuliert, ist die digitale Signatur ungültig und der Server sendet die Datei nicht.
  • Die U.S. Patentanmeldung 2001/0037454 lehrt die Verwendung einer Secure Clock für das Erzeugen eines Datums und eines zyklischen Redundanzcode-Algorithmus (CRC), um für eine Datei unabhängige Daten zu erzeugen. Wird die Datei später geändert, ändern sich die unabhängigen Daten in der Datei und stimmen daher nicht mit den ursprünglichen unabhängigen Daten überein. Wenn die unabhängigen Dateien in der Datei mit den ursprünglichen Daten übereinstimmen, kann die Datei verifiziert werden.
  • Das U.S. Patent Nr. 5,953,419 für Lohstroh, et al. lehrt die Verwendung eines Dateientschlüsselungsschlüssels, um die sichere Verteilung von Dateien zu ermöglichen. Der Dateientschlüsselungsschlüssel ist in einer Datei enthalten und wird von einem privaten Schlüssel dechiffriert, der sich nur im Besitz eines berechtigten Empfängers der Datei befindet.
  • Diese Vorgehen und andere bekannte Verfahren erfordern eine vertrauenswürdige Umgebung oder sind andernfalls in ihrer Anwendbarkeit beschränkt.
  • KURZBESCHREIBUNG DER ERFINDUNG
  • Nach Anspruch 1 betrifft eine Ausgestaltung der Erfindung ein Verfahren für das Sichern, Verwenden und Übertragen sensibler Informationen, welches folgende Schritte umfasst: Berechnen einer digitalen Signatur für eine Datei; Speichern der digitalen Signatur in der Datei; Verschlüsseln der Datei einschließlich der digitalen Signatur und Ausführen einer Datei-Eingabe-Ausgabe-Operation an einer geeigneten Untermenge der Datei in einer Weise, die diese Eingabe-Ausgabe-Operation ohne die Notwendigkeit der Entschlüsselung der gesamten Datei zulässt.
  • Nach Anspruch 12 betrifft eine weitere Ausgestaltung der Erfindung ein maschinenlesbares Medium, welches einen Computercode umfasst, wobei der Computercode weiterhin eine erste Funktion für das Lesen einer verschlüsselten Datei mit einer verschlüsselten digitalen Signatur und eine zweite Funktion für das Schreiben in eine verschlüsselte Datei mit einer verschlüsselten digitalen Signatur umfasst; und wobei die erste und die zweite Funktion keine Entschlüsselung der gesamten Datei erfordern.
  • Eine Ausführung der Erfindung betrifft ein Verfahren für das Verwalten sensibler Daten, welches umfasst: Speichern der sensiblen Daten in einer verschlüsselten Datei mit einer verschlüsselten digitalen Signatur und einer verschlüsselten Anwendersignatur; und Speichern einer temporären verschlüsselten Kopie der Datei; Entschlüsseln einer geeigneten Untermenge der temporären verschlüsselten Kopie der Datei in einer in einer vertrauenswürdigen Anwendung angesiedelten Funktion bei Ausführen einer Lese-Operation; Entschlüsseln einer geeigneten Untermenge der temporären verschlüsselten Kopie der Datei in einer in einer vertrauenswürdigen Anwendung angesiedelten Funktion bei Ausführen einer Schreib-Operation; Aktualisieren der digitalen Signatur der verschlüsselten, temporären Datei unter Verwendung der geeigneten Untermenge und einer in die verschlüsselte temporäre Datei zu schreibenden Datenuntermenge; Verschlüsseln der in die temporäre verschlüsselte Datei zu schreibenden Datenuntermenge und Schreiben der Datenuntermenge in die temporäre verschlüsselte Datei; und Verwenden der verschlüsselten digitalen Signatur und der verschlüsselten Anwendersignatur, um die verschlüsselte temporäre Kopie der Datei zu authentifizieren und Aktualisieren der Datei mit der verschlüsselten temporären Kopie der Datei bei Ausführen einer Dateischließoperation. Andere Ausführungen der Erfindung gehen aus der Beschreibung hervor.
  • KURZBESCHREIBUNG DER FIGUREN
  • Die Erfindung wird beispielhaft und nicht einschränkend in den Begleitzeichnungen veranschaulicht, bei denen gleiche Bezugszeichen gleiche Elemente bezeichnen. Hierbei zeigen:
  • 1 ein Daten- und Prozessflussdiagramm, welches eine verteilte Rechenanlage 100 zeigt, in der erfindungsgemäße Ausführungen für nützlich gehalten werden.
  • 2 eine Fernrechenanlage 200, in der erfindungsgemäße Ausführungen für nützlich gehalten werden.
  • 3 ein Datenflussdiagramm, welches ein System von Anwendern und Rechnern 300 zeigt, in dem erfindungsgemäße Ausführungen für nützlich gehalten werden.
  • 4 ein Logikflussdiagramm einer erfindungsgemäßen Ausführung.
  • 5 einen Datenfluss bei Ausführen normaler (unverschlüsselter und nicht authentifizierter) Lese-, Such- und Schreib-Operationen.
  • 6 ein Datenflussdiagramm einer erfindungsgemäßen Ausführung.
  • 7 ein Logikflussdiagramm, welches eine Dateiöffnungsroutine 700 einer bevorzugten Ausführung zeigt.
  • 8 ein Logikflussdiagramm, welches eine Dateischließroutine 800 einer bevorzugten Ausführung zeigt.
  • 9 ein Logikflussdiagramm, welches eine Dateileseroutine 900 einer bevorzugten Ausführung zeigt.
  • 10 ein Logikflussdiagramm, welches eine Dateischreibroutine 1000 einer bevorzugten Ausführung zeigt.
  • 11 ein Logikflussdiagramm, welches eine Dateisuchroutine 1100 einer bevorzugten Ausführung zeigt.
  • 12 ein Logikflussdiagramm, welches eine Dateienderoutine 1200 einer bevorzugten Ausführung zeigt.
  • 13 ein charakteristisches Rechenumfeld 1300, wobei beschrieben wird, wie ein einfaches „Hello, world!" Programm ohne die erfindungsgemäßen Ausführungen geschrieben werden kann.
  • 14 ein charakteristisches Rechenumfeld 1400, wobei beschrieben wird, wie ein einfaches „Hello, world!" Programm geändert werden kann, um ihm die erfindungsgemäßen Schutzmaßnahmen zu gewähren.
  • EINGEHENDE BESCHREIBUNG DER ERFINDUNG
  • Im Allgemeinen werden Systeme, Vorrichtungen und Verfahren für das Verbessern der Sicherheit und das Wahren der Authentizität sensibler Daten beschrieben. In der folgenden Beschreibung werden zum Zweck der Erläuterung zahlreiche spezifische Einzelheiten aufgeführt, um ein tiefgehendes Verständnis der beispielhaften Ausführungen zu bieten. In bestimmten Fällen ist es aber für den Fachmann offenkundig, dass die vorliegende Erfindung ohne diese spezifischen Einzelheiten umgesetzt werden kann.
  • Zum Beispiel werden viele der hier beschriebenen erfindungsgemäßen Ausführungen in allgemeiner Programmiersprache wie z.B. C geschrieben. Hier handelt es sich aber um rein beispielhafte Ausführungen, die in ihren Details gezeigt werden, um die allgemeinen Grundsätze der Erfindung zu erhellen. Aus der Lehre der Schrift und dank Fachwissen ist klar, dass viele spezifische Umsetzungsdetails nicht zwingend sind und in vielerlei Weise verwirklicht werden könnten.
  • Dies gilt insbesondere bezüglich einzelner oder kleiner Gruppen von Quellcode-Operationen. Bei der Computerprogrammierung ist es allgemein möglich, jedes logische Ergebnis auf mehreren unterschiedlichen Wegen zu verwirklichen. Man kann zum Beispiel die Zahl 4 durch Addieren von 2 und 2, aber auch durch Multiplizieren von 2 mal 2, durch Addieren von 1 und 3, durch Dividieren von 10 durch 2 und dann Subtrahieren von 1 vom Ergebnis usw. erhalten. Ausführungen der Erfindung könnten auch zum Beispiel mit Hilfe anderer Programmiersprachen oder anderen Verfahren in der gleichen Sprache erzeugt werden. Manchmal ist die Abweichung zwischen verschiedenen Ausführungen der Erfindung eine einfache Frage der Effizienz oder gar des persönlichen Geschmacks.
  • Im Allgemeinen bieten die Ausführungen der Erfindung mehrere Vorteile, die hilfreich sind, wenn Datensicherheit und Authentizität erforderlich sind. Die erfindungsgemäßen Ausführungen werden am nützlichsten gesehen, wenn eine Anwendung sensible Daten in eine Datei lesen oder schreiben muss. Datei wird hier in der breitesten Bedeutung als eine in einem Medium gespeicherte Datenstruktur verwendet. Es ist nicht erforderlich, dass das die Datei speichernde Endmedium eine Festplatte oder ein anderes herkömmliches Verfahren für die Dateispeicherung ist, sondern könnte vielmehr einen internen Computerspeicher, ein Kommunikationsnetz, Papier oder jedes andere Medium umfassen, das Daten zur Speicherung entgegennehmen kann.
  • In Fällen, da eine Anwendung sensible Daten aus einer Datei lesen oder in diese schreiben muss, unterliegt die Anwendung dem Risiko eines Angriffs aus der Maschine heraus, auf der die Anwendung läuft (nachstehend als „Verarbeitungsmaschine" bezeichnet). „Sensible Daten" bedeutet Daten, die aus welchen Grund auch immer vor Diebstahl oder Änderung geschützt werden müssen. Solche Angriffe können Versuche sein, die sensiblen Daten zu kopieren, zu manipulieren oder anderweitig zu kompromittieren. Eine Anwendung unterliegt immer dann einem Risiko, wenn die Verarbeitungsmaschine unzuverlässig ist oder kompromittiert ist. Dies kann eintreten, wenn die Anwendung zur Ausführung an eine ferne (und nicht gesteuerte) Verarbeitungsmaschine geschickt wird, zum Beispiel wenn komplexe Modellierprogramme zu Spitzenrechenanlagen geschickt werden, um die Ausführungszeit zu senken. Dies kann auch eintreten, wenn in eine lokale, gesteuerte Verarbeitungsmaschine eingedrungen wurde, wenn der Systemadministrator bzw. die Systemadministratoren skrupellos sind, wenn ein Virus das System befallen hat oder wenn die Sicherheit anderweitig kompromittiert wurde.
  • Eine andere Situation, in der eine Anwendung einem Risiko ausgesetzt sein kann, liegt vor, wenn ein rechnerisch teures Programm in Stücke zerteilt werden muss, um von zahlreichen Rechnern verarbeitet zu werden. Ein Beispiel für eine solche Berechnung ist ein Screensaver-Berechnungsprogramm, bei dem eine große Anwendung oder eine eine große Datenmenge analysierende Anwendung über tausende von Arbeitsplatzrechnern verteilt ist, um von Screensaver-Programmen ausgeführt zu werden, die arbeiten, wenn der Anwender den Prozessor nicht anderweitig nutzt. Eine noch andere Situation dieser Art kommt vor, wenn eine Anwendung Daten auf einer potenziell unsicheren Maschine speichert, unabhängig davon, ob die Anwendung selbst auf einer vertrauenswürdigen Maschine bzw. Maschinen läuft. Wie aus der vorstehenden Beschreibung ersichtlich sein sollte, setzt eine sensible Daten verwendende Anwendung diese Daten nahezu immer einem gewissen Risiko aus.
  • Die erfindungsgemäßen Ausführungen verwenden eine Kombination aus Verschlüsselung und Authentifizierung, um Datensicherheit für Anwendungen zu verwirklichen, die in potenziell unsicheren Umfeldern laufen. Im Allgemeinen erlauben die Ausführungen der Erfindung einem Anwender, aus einer verschlüsselten Datei zu lesen und in diese zu schreiben, ohne mehr als kleine Segmente dieser Datei zu verschlüsseln oder zu entschlüsseln, so dass signifikante Teile des unverschlüsselten Dateiinhalts nie auf dem potenziell unsicheren System – selbst nicht im Speicher – gespeichert werden müssen. Dies reduziert das durch unzuverlässige Systeme als Umfeld für das Ausführen des Anwendungscodes, der sensible Daten verwenden muss, erzeugte Risiko erheblich.
  • Die Ausführungen der Erfindung können mehrere Vorteile für die üblichen Sicherheits- und Authentifizierungsmaßnahmen bieten. Zu diesen Vorteilen zählen die Verschlüsselung von Daten, eine digitale Signatur, die eine Datenauthentifizierung zulässt, eine weitere (Anwender)-Signatur, die eine Unterscheidung von verschlüsselten Dateien zulässt, Schutz vor Dateimanipulation oder Dateinachahmung, einfache Implementierung von Verfahren zur Erzeugung von Verschlüsselung und Authentifizierung, inkrementale Verschlüsselung und Entschlüsselung (d.h. die Fähigkeit, einen Teil einer Datei zu ändern oder zu lesen, ohne die gesamte Datei zu verschlüsseln und zu entschlüsseln) und die Fähigkeit der Daten, während eines Systemausfalls sicher zu bleiben. Aus der folgenden Beschreibung ist ersichtlich, dass nicht all diese Vorteile in allen Ausführungen erforderlich oder gegeben sind und dass jeder Vorteil in bestimmter Hinsicht in einer bestimmen Ausführung unterschiedlich ausfallen kann.
  • 1 zeigt eine Situation, in der Ausführungen der Erfindung von Nutzen sein können. 1 ist ein Daten- und Prozessflussdiagramm, welches eine verteilte Rechenanlage 100 zeigt. Der Begriff verteilte Rechenanlage wird hier so benutzt, dass er jedes System mit mehreren unabhängig, aber in direkter oder indirekter Verbindung arbeitenden Verarbeitungsrechnern bedeutet. Die verteilte Rechenanlage 100 hat einen Anwender 102, eine lokale (vertrauenswürdige) Maschine 104, eine ferne (nicht vertrauenswürdige) Maschine 106, eine ferne (nicht vertrauenswürdige) Maschine 108, einen Schritt 110, welcher die Übermittlung einer Anwendung und von Eingabedaten zu einer verteilten Anlage darstellt, einen Schritt 112, der das Übertragen der Eingabe zu einer Anwenderanwendung darstellt, einen Schritt 114, der die Ausführung der Anwenderanwendung auf einer fernen (nicht vertrauenswürdigen) Maschine 106 darstellt, einen Schritt 116, der die Übertragung der Ausgabe der Anwenderanwendung auf die ferne (nicht vertrauenswürdige) Maschine 108 darstellt, und einen Schritt 118, der die Übermittlung der Ausgabe zu der lokalen (vertrauenswürdigen) Maschine 104 darstellt.
  • In 1 wünscht der Anwender 102, dass eine Anwendung auf einer fernen Maschine 106 läuft, welche ein Spitzenrechner sein kann, der in der Lage ist, die erforderliche Verarbeitungszeit zu reduzieren. Der Anwender 102 veranlasst bei Schritt 110 das Übertragen der Anwendung und der erforderlichen Eingabedaten zur fernen Maschine 106. Die ferne Maschine 106 liefert bei Schritt 112 der Anwendung die Eingabedaten und die Anwendung läuft bei Schritt 114. Bei Schritt 116 liefert die Anwendung Ausgabedaten an die ferne Maschine, die wiederum bei Schritt 118 die Ausgabe an die lokale Maschine 104 liefert.
  • Eine Datei-Eingabe-Ausgabe-Operation, die hier als Lese-, Schreib- oder Such-Operation definiert ist, kann erfordern, dass eine Anwendung auf Daten in unverschlüsselter Form zugreift, was ein Datensicherheitsrisiko bildet, selbst für eine vertrauenswürdige Anwendung, welche mit einem verschlüsselten Dateisystem arbeitet. Während des in 1 gezeigten Prozesses werden die Daten zum Beispiel potenziell auf verschiedene Weise kompromittiert. Zum einen kann die lokale Maschine 104, auch wenn sie für vertrauenswürdig gehalten wird, infiltriert worden sein. Zum anderen können die Eingabedaten während Schritt 110 oder an der fernen Maschine 106 während der Schritte 112 und 114 abgefangen oder geändert worden sein. Zum Dritten können Ausgabedaten während der Schritte 116 oder 118 abgefangen oder geändert worden sein. Auch wenn sie während der Übertragungsschritte 116 und 118 verschlüsselt sind, könnten die Daten immer noch durch die ferne Maschine 106 abgefangen werden, wenn die Anwendung auf großen Stücken unverschlüsselter Daten laufen oder Betriebssystemroutinen verwenden muss, um Daten zur Übertragung zu verschlüsseln. Sind die Daten sensibel, sollten gewisse Mittel eingesetzt werden, um den Datenschutz und/oder die Authentizität der Informationen zumindest an den schwächsten Punkten der Anlage 100 zu garantieren.
  • Eine zweite Situation, in der die Erfindung für nützlich gehalten wird, wird in 2 gezeigt. 2 zeigt eine ferne Rechenanlage 200 mit Anwendern 202 und 204, fernen (nicht vertrauenswürdigen) Informationssystemen 206 und 208, einer auf einer fernen Maschine 210 laufenden Anwendung und Datenaustauschschritte 212 und 214.
  • In 2 greifen Computeranwender 202 und 204 auf die Rechenanlage 200 durch Einsatz ferner (nicht vertrauenswürdiger) Informationssysteme 206 und 208 zu. Die Anwender 202 und 204 wollen mittels der fernen Systeme 206 und 208 der Anwendung 210 Informationen übermitteln und/oder von dieser erhalten. Die Anwender 202 und 204 können aber nicht sicher sein, dass über die fernen Systeme 206 und 208 gelangende Daten oder das System, auf dem die Anwendung 210 läuft, vor Ausspionieren und/oder Verfälschung sicher sind.
  • 3 zeigt eine dritte typische Lösung, bei der die vorliegende Erfindung für nützlich gehalten wird. 3 ist ein Datenflussdiagramm, welches ein System von Anwendern und einen Rechner 300 zeigt, das einen Anwender 302, eine lokale Maschine 304, nicht vertrauenswürdige Mittelsmänner 306 und Datenübertragungsschritte 312 und 314 umfasst. Der Anwender 302 versucht, auf der lokalen Maschine 304 eine Anwendung auszuführen, und tauscht bei Schritt 312 Daten mit der lokalen Maschine 304. Ohne Wissen des Anwenders 302 wurde die lokale (und zuvor vertrauenswürdige) Maschine 304 von einem oder mehreren nicht vertrauenswürdigen Mittelsmännern 306 infiltriert, welche einen Systemadministrator, einen anderen Anwender der lokalen Maschine 304, einen Hacker, ein Betriebssystem mit Fehlfunktion oder eine verbrecherische Anwendung, beispielsweise einen Virus, umfassen können. In dieser Situation sind die Daten des Anwenders 302 selbst in der lokalen Maschine 304 des Anwenders 302, einem Umfeld, das die meisten Anwender für sicher halten, unsicher.
  • Eine erfindungsgemäße Ausführung betrifft die Verwendung eines Verschlüsselungs- und Authentifizierungsschemas zusammen mit einem Dateispeicherprotokoll. Eine solche Ausführung ermöglicht die verschlüsselte Speicherung von Daten in solcher Weise, dass es möglich ist, aus der verschlüsselten Datei zu lesen und in diese zu schreiben, ohne zuerst die gespeicherte Datei zu entschlüsseln. Das bedeutet, dass die auf unzuverlässigen Systemen arbeitenden Anwendungen verschlüsselte Dateien lesen und manipulieren können, ohne eine Kopie der unverschlüsselten Datei im Speicher zu halten oder diese über einen nicht vertrauenswürdigen Kommunikationskanal zu übertragen.
  • Eine Ausführung der Erfindung nutzt einen Algorithmus, um einen digitale Signatur für die Authentifizierung zu erzeugen, speichert diese digitale Signatur in dem Dateivorsatz oder anderweitig mit der Datei und verschlüsselt dann die digitale Signatur zusammen mit den Daten in der Datei. Die digitale Signatur wird erzeugt und so aktualisiert, dass sichere Les- und Schreib-Operationen erfolgen können, ohne die gesamte Datei zu entschlüsseln. Dies macht die Daten in der Datei erheblich sicherer als bei standardmäßigen Verschlüsselungs- und Authentifizierungsverfahren.
  • 4 ist ein Logikflussdiagramm einer Ausführung der Erfindung. 4 zeigt einen Prozess für das Sichern von Dateien zur Verwendung durch eine Anwendung auf einer nicht vertrauenswürdigen Maschine 400. Der Prozess 400 umfasst einen Schritt 401, welcher das Anlegen einer sicheren Datei („Dateianlegeschritt") darstellt, einen Schritt 402, welcher das sichere Schreiben in die sichere Datei („Dateischreibschritt") darstellt, und einen Schritt 403, welcher das Schließen der sicheren Datei („Dateischließschritt") darstellt. Der Dateianlegeschritt 401 umfasst weiterhin einen Schritt 404, welcher das Anlagen von Dateidaten darstellt, einen Schritt 408, welcher die Berechnung einer digitalen Signatur darstellt, und einen Schritt 412, welcher die Verschlüsselung der Datei darstellt. Der Dateischreibschritt 402 umfasst weiterhin einen Schritt 416, welcher das Ermitteln der Stelle in der Datei, an der geschrieben werden soll, darstellt, einen Schritt 420, der die Entschlüsselung des Geheimcodeblocks darstellt, in dem das Schreiben in die Datei zu erfolgen hat, einen Schritt 424, der die Verschlüsselung der zu schreibenden Daten darstellt, einen Schritt 428, der die Änderung der digitalen Signatur darstellt, und einen Schritt 432, der das Schreiben der verschlüsselten Daten in die Datei darstellt. Der Dateischließschritt 403 umfasst weiterhin einen Schritt 434, der das Schreiben einer modifizierten digitalen Signatur in die Datei darstellt, und einen Schritt 438, der das Dateischließen darstellt.
  • Bei Schritt 401 wird eine Datei, die im vorliegenden Fall eine Reihe von Daten ist, in normaler Weise durch zuerst Erzeugen der zu sichernden Daten bei Schritt 404 angelegt. Als Nächstes berechnet der Prozess 400 eine digitale Signatur und legt die Signatur bei Schritt 408 in der Dateistruktur ab. Die digitale Signatur wird im Allgemeinen mit den Vorsatzangaben der Datei abgelegt, dies muss aber nicht sein. Im Schritt 412 verschlüsselt der Prozess 400 die Datei, einschließlich Vorsatz und die digitale Signatur, meist unter Verwendung eines vorab festgelegten Verschlüsselungsschlüssels.
  • Wenn der Prozess 400 in die verschlüsselte Datei schreiben muss, verwendet er den Dateischreibschritt 402, der zuerst bei Schritt 416 die verschlüsselte Datei durchsucht (oder durchzählt), um die korrekte Stelle für das Schreiben von Daten zu finden. Schritt 416 kann eines von verschiedenen Mitteln für das Mapping der unverschlüsselten Dateiposition zur verschlüsselten Dateiposition umfassen. Bei Schritt 420 entschlüsselt der Prozess 400 einen Datenblock, in dem die Datenposition ist, in die geschrieben werden soll. Die Größe des zu entschlüsselnden Blocks hängt von dem verwendeten jeweiligen Verschlüsselungs- und Entschlüsselungsverfahren ab, und kann stark schwanken. Als Nächstes verschlüsselt der Prozess 400 bei Schritt 424 die Daten, die in die Datei geschrieben werden sollen. Bei Schritt 428 ändert der Prozess 400 als Nächstes die verschlüsselte digitale Signatur der Datei, so dass sie eine Datei wiedergibt, bei der die neuen Daten die alten Daten ersetzen. Bei Schritt 432 schreibt der Prozess 400 die neu verschlüsselten Daten in die Datei.
  • Bei Schließen der Datei in Schritt 403 schreibt der Prozess 400 zuerst die korrigierte digitale Signatur bei Schritt 434 in die Datei und beginnt dann bei Schritt 438 die normalen Schließschritte. Zu beachten ist, dass viele der Schritte in Prozess 400 in einer anderen Reihenfolge als hier gezeigt durchgeführt werden könnten. Zum Beispiel ist es möglich, im Gegensatz zu der Schließ-Operation 403 eine neue digitale Signatur nach jedem Schreibvorgang 402 zu schreiben. Möglich wäre auch, zum Beispiel die Reihenfolge der Schritte 420 und 424 umzukehren.
  • Eine digitale Signatur, wie sie in dem vorliegenden Kontext verwendet wird, bedeutet einen String von Authentifizierungsdaten, die aus einem String tatsächlicher Daten erzeugt werden, wobei die Größe der Authentifizierungsdaten meist kleiner als die Größe der tatsächlichen Daten ist. Digitale Signaturen, die zur Verwendung in der vorliegenden Erfindung geeignet sind, können durch ein beliebiges Verfahren aus einer Reihe von Verfahren erzeugt werden. In einer Ausführung der Erfindung wird eine digitale Signatur mit Hilfe einer Funktion Q(a,b) erzeugt, wobei a und b separate Datenteile sind. Die digitale Signatur (DS) wird durch Iteration von DS = Q(DS, ai) berechnet, ai ist eine Menge einer Datenuntermenge gleicher Länge, wobei i = {0...N} und die Länge der zu authentifizierenden Daten in der Datei das N-fache der Länge jedes Werts ai ist. In dieser Ausführung kann der Anfangswert von DS willkürlich festgelegt werden.
  • Bevorzugt wird, dass die Funktion Q(a,b) umkehrbar ist, so dass Q(Q(a, b), b) = a. Wenn zum Beispiel a und b 8-Byte-Strings sind, dann ergibt Q(a, b) einen 8-Byte-String c. Dann ergibt Q(c, b) den ursprünglichen 8-Byte-String a. Analog ergibt Q(c, a) den 8-Byte-String b. Es ist ferner wünschenswert, dass die Funktion symmetrisch ist, d.h. dass Q(a,b) = Q(B, a) und dass Q(Q(a, b), c) = Q(Q(c, b)a).
  • In einer Ausführung der vorliegenden Erfindung wird eine Exklusiv-ODER-Funktion Q („XOR") verwendet, um eine digitale Signatur zu erzeugen, so dass Q(a,b) = a XOR b. Die XOR-Funktion ist eine binäre Funktion, die ein wahres Ergebnis erzeugt, wenn einer (aber nicht beide) der Eingabewerte wahr sind. Wenn zum Beispiel a die binäre Sequenz „1010" ist und b die binäre Sequenz „1001" ist, dann Q(a,b) = a XOR b = 0011 = c. Dann Q(c, b) = 1010 = a und die bevorzugten Beziehungen für die Funktion Q sind erfüllt.
  • Aus einer relativ großen Menge tatsächlicher Daten kann durch Zerlegen einer Datei in kleine Blöcke gleichmäßiger Größe (die erwünschte Größe der digitalen Signatur) und Verwenden der XOR-Funktion zwischen all diesen kleinen Blöcken eine relativ kleine digitale Signatur erzeugt werden. Zum Beispiel angenommen eine tatsächliche Datenuntermenge von 16 Bytes benötigt eine digitale Signatur von 4 Bytes. Die 16-Byte-Datenfolge kann in vier 4-Byte-Blöcke b0, b1, b2 und b3 zerlegt werden. Durch die Operation DS = b0 XOR b1 XOR b2 XOR b3 kann eine digitale Signatur DS gebildet werden. Diese Operation ergibt einen 4-Byte-Block, der als digitale Signatur verwendet werden kann. Natürlich ist die Wahl einer 4-Byte-Blocklänge willkürlich.
  • Die kommutativen und assoziativen Eigenschaften der Funktion Q sind bei Manipulieren von Daten nützlich. Zum Beispiel angenommen, dass wir den 4-Byte-Datenblock b2 ändern wollen, indem wir ihn durch den 4-Byte-Block R ersetzen wollen. Die neue digitale Signatur DS' könnte dann mit Hilfe der Formel DS' = b0 XOR b1 XOR R XOR b3 berechnet werden, könnte aber auch mit Hilfe der Formel DS' = DS XOR b2 XOR R berechnet werden. Wenn die Anzahl an 4-Byte-Blöcken groß wird, wird das letztere Verfahren relativ effizient.
  • Die Verschlüsselung (im Gegensatz zur Authentifizierung) einer Datei kann auch durch eine Reihe anderer Mittel verwirklicht werden. In einer Ausführung der Erfindung wird der Blowfish-Algorithmus eingesetzt. Die Blowfish-Verschlüsselung ist ein von Bruce Schneier entwickeltes symmetrisches Block-Verschlüsselungsverfahren. Dies ist ein bevorzugter Algorithmus zur Verwendung mit erfindungsgemäßen Ausführungen, da er einfach ist (erfordert im Allgemeinen weniger als 5K Speicher für die Implementierung), da er schnell ist (erfordert im Allgemeinen Taktzeiten von 18 pro Byte), die Schlüssellänge variabel ist und bis zu 448 Bits lang sein kann; er schlüsselabhängige S-Boxen verwendet, was Brute-Force-Angriffe aufgrund der zeitraubenden Subkey-Erzeugung schwieriger als wahrnehmbar macht; und er verwendet Mischoperatoren, was die Kryptoanalyse sehr schwierig macht. Ein den Blowfish-Algorithmus implementierender Code ist für eine Reihe von Programmiersprachen öffentlich erhältlich. Siehe Stallings, Cryptography and Network Security, 2. Ausgabe, Prentice Hall, Upper Saddle River, JN, 1998, was hiermit durch Erwähnung Bestandteil wird, wo der Blowfish und andere Algorithmen beschrieben werden, die für die vorliegende Erfindung geeignet sind.
  • Der in einer erfindungsgemäßen Ausführung verwendete Blowfish-Algorithmus ist ein Algorithmus symmetrischen Schlüssels, was heißt, dass der Verschlüsselungsschlüssel („EK") gleich dem Entschlüsselungsschlüssel („DK") ist, und kann gleich oder in etwa gleich einem willkürlichen Schlüssel von einer Länge unter 448 Bits sein, der von einem Anwender (ein „Anwenderschlüssel" oder „UK") gewählt wird. Der Blowfish-Algorithmus ist aber nicht die einzige mögliche Wahl. Es können auch andere Systeme mit symmetrischem Schlüssel oder sogar ein asymmetrischer Verschlüsselungsalgorithmus (bei dem EK sich von DK unterscheidet) verwendet werden.
  • Unabhängig von der Verwendung des Blowfish-Algorithmus verwenden die erfindungsgemäßen Ausführungen im Allgemeinen Funktionen für das Verschlüsseln und Entschlüsseln von Datenuntermengen. Eine solche Funktion kann als encrypt(X, i, EK) bezeichnet werden, wobei X die zu verschlüsselnden Daten sind, i ein zur Festlegung der Position in einem größeren Datenblock (Datei), in der sich X befindet, verwendeter Dateizähler und EK der Verschlüsselungsschlüssel ist. Die Entschlüsselungsfunktion decrypt(X, i, DK) entschlüsselt die Daten X unter Verwendung des Entschlüsselungsschlüssels DK. Bei den erfindungsgemäßen Ausführungen ist bevorzugt, dass decrypt(encrypt(X, i, EK), i, DK) = X für jedes i und dass encrypt(X, i, EK) ungleich X und ungleich encrypt(X, j, EK') für i unterschiedlich zu j oder EK unterschiedlich zu EK' ist.
  • Bei Verschlüsseln einer Datei wird bei Verwendung des Blowfish-Algorithmus dieser vorzugsweise durch die Verwendung eines positionsabhängigen Scrambling-Mechanismus oder eines anderen Mittels für das weitere Schützen von Daten verbessert, da die Ausgabe des Blowfish-Algorithmus eine Eins-zu-Eins-Mapping-Eigenschaft hat, so dass Textdateien, die in einer bekannten Sprache geschrieben werden, basierend auf der Häufigkeit von Buchstabengebrauch statistischen Angriffen unterliegen. In einer erfindungsgemäßen Ausführung mit den Funktionen Blowfish_encrypt(X, EK) und Blowfish_decrypt(X, DK) werden daher die mit Hilfe der Verschlüsselungsfunktion zu verschlüsselnden Daten mit dem Dateizähler Exklusiv-OR unterzogen, so dass encrypt(X, i, EK) = Blowfish_encrypt(XOR i, i, EK). Für die Entschlüsselung werden die Ergebnisse der Entschlüsselungsfunktion wieder mit dem Dateizeiger XOR unterzogen, so dass decrypt(X, i, DK) = Blowfish_decrypt(X, DK) XOR i.
  • Aus den 5 und 6 lassen sich mehrere erfindungsgemäße Ausführungen entnehmen. 5 stellt den Datenfluss dar, wenn normale (nicht verschlüsselte und nicht authentifizierte) Les-, Such- und Schreiboperationen (wie in der Programmiersprache C) ausgeführt werden. 5 ist in eine Anwendungsseite 500 und eine Betriebssystem- und Hardwareseite 501 unterteilt und hat ein Anwenderprogramm 502, Datenuntermengen 506 und 510, eine normale Lesefunktion 514, eine normale Suchfunktion 518, eine normale Schreibfunktion 522, einen Zähler 526 und eine normale Speicherdatei 530. Diese auf der Anwendungsseite 500 gezeichneten Operationen werden im Anwendungscode verwirklicht, die auf der Betriebssystem- und Hardwareseite 501 gezeichneten Operationen werden im Betriebssystemcode und/oder in der Hardware verwirklicht.
  • Bei einer normalen Suchfunktion 518, wie in 5 dargestellt, fordert ein Anwenderprogramm, dass der logische Zeiger 526 auf eine anwenderdefinierten Position in der Datei 530 gesetzt wird. Die Such-Operation ermöglicht den direkten Zugriff auf die Datei 530. Wenn das Anwenderprogramm 502 die Datei 530 an einer durch den logischen Zeiger 526 festgelegten Position lesen muss, kann es die normale Lese-Funktion 514 aufrufen und eine Datenuntermenge 506 erhalten („Datenuntermenge", wie sie in dieser Schrift verwendet wird, kann Daten beliebiger Länge umfassen, bedeutet aber im Kontext von 5 meist ein einzelnes Byte. Eine „geeignete Untermenge", wie sie in dieser Schrift verwendet wird, bedeutet eine Datenuntermenge aus einer Datei, die kleiner als die gesamte Datei ist und nicht leer ist). Bei den meisten Implementierungen wird der logische Dateizeiger 526 dann um die Anzahl gelesener Zeichen erhöht. Wenn das Programm 502 Daten in die Position schreiben muss, auf welche der logische Zeiger 526 verweist, ruft sie die normale Schreibfunktion 522 unter Weitergeben der Datenuntermenge 510 auf, welche dann wiederum in die Datei 530 in der von dem logischen Zeiger 526 festgelegten Position geschrieben wird.
  • Der in 5 gezeigte Datenfluss kann dem Datenfluss einer in 6 dargestellten erfindungsgemäßen Ausführung gegenübergestellt werden. 6 ist ganz wie 5 in eine Anwendungsseite 600 und eine Betriebssystem- und Hardwareseite 601 unterteilt und hat ein Anwenderprogramm 602, Datenuntermengen 606 und 610, eine Lesefunktion 614, eine Suchfunktion 618, eine Schreibfunktion 622, einen physikalischen Zieger 628, eine verschlüsselte physikalische Speicherdatei 630, eine verschlüsselte temporäre Speicherdatei 632 und verschlüsselte Datenuntermengen 634, 636 und 638. Die Lesefunktion 614 umfasst weiterhin einen Schritt 644, welcher die Authentifizierung von Daten darstellt, einen Schritt 642, welcher die Entschlüsselung von Daten darstellt, und einen Schritt 640, welcher das Lesen der Daten darstellt. Die Suchfunktion 618 umfasst weiterhin einen Schritt 646, welcher das Zähler-Mapping darstellt, und einen Schritt 648, welcher das Suchen der vom Anwender festgelegten Dateiposition darstellt. Die Schreibfunktion 622 umfasst weiterhin einen Schritt 650, welcher das Lesen von Daten darstellt, einen Schritt 652, welcher die Entschlüsselung von Daten darstellt, einen Schritt 654, welcher das Aktualisieren einer digitalen Signatur darstellt, einen Schritt 656, welcher die Verschlüsselung von Daten darstellt, und einen Schritt 658, welcher das Schreiben von Daten darstellt. Die auf der Anwendungsseite 600 gezeichneten Operationen werden im Anwendungscode verwirklicht, die auf der Betriebssystem- und Hardwareseite 601 gezeichneten Operationen werden im Betriebssystemcode und in der Hardware verwirklicht.
  • In dem Datenfluss von 6 hat das Anwenderprogramm 602 einen physikalischen Zeiger 628 erzeugt, der in einem Variablenspeicher des Betriebssystems (System Heap oder dergleichen) gespeichert wird. Dieser physikalische Zeiger enthält die aktuelle Position in einer verschlüsselten temporären Datei, ähnlich wie der logische Zähler 526 von 5 (der vom Betriebssystem verwaltet wird), der in der aktuellen Position in der normalen Datei 530 enthalten ist. In 6 wird eine verschlüsselte temporäre Datei 632 angelegt, möglicherweise im Speicher, zusammen mit dem physikalischen Zeiger 628, um eine gewisse Absturzstabilität zu bieten. Das Anwenderprogramm 602 liest nur aus der verschlüsselten temporären Datei und sucht und schreibt nur in diese. Auf diese Weise geht bei einem Systemabsturz der Originaldateiinhalt nicht verloren und wird nicht unbrauchbar geändert. Bei Schließen der Datei wird die verschlüsselte temporäre Datei 632 in die physikalische Datei 630 kopiert.
  • Bei Ausführen einer Suchoperation ruft das Programm 602 die Funktion 618 auf. Die in 6 dargestellten erfindungsgemäßen Ausführungen sind für das Anwenderprogramm 602 transparent ausgelegt, so dass ein Aufruf vom Anwenderprogramm 602 zur Suchfunktion 618 aus der Sicht des Programmierers der Anwendung 602 auf dem logischen Zeiger basiert, ähnlich dem in 5 gezeigten Normalfall. Dadurch besteht in 6 der erste Schritt 646 der Suchfunktion 618 darin, den logischen Zeiger dem physikalischen Zeiger 628 zuzuordnen, so dass auf der verschlüsselten temporären Datei 632 gearbeitet wird, nicht auf der verschlüsselten physikalischen Datei 630. Die Suchfunktion 618 führt dann eine standardmäßige Suchoperation bei Schritt 648 aus, verwendet aber den physikalischen Zeiger 628 anstelle des logischen Zeigers.
  • Bei Ausführen einer Leseoperation ruft das Anwenderprogramm 602 die Lesefunktion 614 auf. Die Lesefunktion 614 liest zuerst bei Schritt 640 ein Segment verschlüsselter Daten 634 aus der verschlüsselten temporären Datei 632. Die Datenuntermenge 634 wird dann von einer in der Anwendung 601 angesiedelten Funktion (soll heißen auf der Anwendungsseite 600) bei Schritt 642 entschlüsselt. Die entschlüsselten Daten werden dann mit Hilfe der digitalen Signatur der verschlüsselten temporären Datei 632 authentifiziert und bei Erfolg vom Anwenderprogramm 602 verwendet.
  • Bei Ausführen einer Schreibfunktion ruft das Anwenderprogramm 602 die Schreibfunktion 622 unter Weitergeben der Datenuntermenge 610 auf. Zuerst führt die Schreibfunktion 622 bei Schritt 650 ein Lesen der verschlüsselten Datenuntermenge 636 an der Position aus, an der das Anwenderprogramm 602 schreiben will, wie durch den physikalischen Zeiger 628 festgelegt wird. Die Datenuntermenge 636 wird dann in einer lokalen Funktion bei Schritt 652 entschlüsselt. Die nicht verschlüsselte digitale Signatur der verschlüsselten temporären Datei 632, die bei Öffnen der verschlüsselten temporären Datei 632 im Speicher gespeichert wurde, wird mit Hilfe der jetzt unverschlüsselten Datenuntermenge (zuvor Datenuntermenge 636), die aus der verschlüsselten temporären Datei 632 gelesen wurde, und der unverschlüsselten Datenuntermenge 610, die in die verschlüsselte temporäre Datei 632 geschrieben wird, aktualisiert.
  • D.h. die aus der temporären Datei gelesenen unverschlüsselten Daten und die zu schreibenden verschlüsselten Daten können zum Aktualisieren der digitalen Signatur verwendet werden, ohne diese ganz neu zu berechnen. Die Datenuntermenge 610 wird dann bei Schritt 656 verschlüsselt und bei Schritt 658 in die verschlüsselte temporäre Datei 632 als verschlüsselte Datenuntermenge 638 geschrieben. Bei Dateischließen wird die geänderte digitale Signatur (nicht gezeigt), die speicherresident ist, in die verschlüsselte temporäre Datei 632 geschrieben, welche über die physikalische Datei 630 kopiert wird.
  • Für die Ausführungen der Erfindung ist es vorteilhaft, Dateiverwaltungsprozesse zu verwenden, wie sie in den 7–12 gezeigt werden. In der folgenden Beschreibung werden die 7–12 als Logikflussdiagramme vorgestellt, die in bevorzugten erfindungsgemäßen Ausführungen verwendet werden können. Für ein leichteres Verständnis werden zur Darstellung von Objekten und Funktion in den 7–12 verwendete Begriffe durchgehend einheitlich verwendet. Wenn eine temporäre Datei bezüglich 7 verwendet wird, kann daher der Leser erwarten, dass ein Verweis auf eine „temporäre Datei" unter Bezug auf 10 das Gleiche bedeutet, sofern nichts anderes vermerkt wird. Zudem wird an bestimmten Punkten ein Objekt und ein Verweis auf dieses Objekt gleich bezeichnet. Für den Fachmann auf dem Gebiet ist klar, wann ein Verweis und wann das Objekt selbst gemeint ist. Tabelle 1 listet die verschiedenen Abkürzungen und deren Bedeutungen auf, die unter Bezug auf 7 bis 12 verwendet werden.
  • Tabelle II Objekte, auf die das Programm eines Anwenders zugreifen kann
    Figure 00200001
  • Von Kryptographie-/Authentifizierungsfunktionen intern verwendete Objekte, Zugriff durch das Dateiobjekt F möglich
    Figure 00200002
  • Von Kryptographie-/Authentifizierungsfunktionen intern verwendete Objekte
    Figure 00210001
  • 7 ist ein Logikflussdiagramm, welches eine Dateiöffnungsroutine 700 einer bevorzugten Ausführung zeigt. 7 hat die Schritte 702 bis 759, welche verschiedene abstrakte logische Operationen darstellen, die in einer Dateiöffnungsroutine 700 erfindungsgemäßer Ausführungen ausgeführt werden können.
  • Die Dateiöffnungsroutine 700 beginnt mit einem Benutzeraufruf einer spezialisierten Dateiöffnungsfunktion bei Schritt 702. In der vorliegenden Ausführung gibt die aufrufende Anwendung der Dateiöffnungsroutine 700 vier Parameter: den Dateinamen (FN), den Modus (M) (zum Beispiel einen Parameter, der anzeigt, ob die Datei nur gelesen, nur geschrieben, nur angehängt werden soll, etc.), einen Anwenderschlüssel (UK), der gleichwertig zu dem vom Anwender oder Programmierer gewählten Passwort ist, der für Verschlüsselungszwecke verwendet werden soll, und eine Anwendersignatur (US). Die Anwendersignatur (US) ähnelt dem Anwenderschlüssel, wird aber zum Unterscheiden einer verschlüsselten Datei von der anderen verwendet. Die Anwendersignatur darf nicht mit der digitalen Signatur verwechselt werden.
  • Bei Schritt 704 berechnet die Routine 700 aus dem Anwenderschlüssel (UK) einen Verschlüsselungsschlüssel (EK) und einen Entschlüsselungsschlüssel (DK). Wenn die zu verwendende Verschlüsselung symmetrisch ist, ist der Anwenderschlüssel (UK) in etwa gleich dem Verschlüsselungsschlüssel (EK), der exakt gleich dem Entschlüsselungsschlüssel (DK) ist. Bei Verwendung eines asymmetrischen Verschlüsselungssystems wie RSA unterscheidet sich der Verschlüsselungsschlüssel (EK) vom Entschlüsselungsschlüssel (DK).
  • Bei Schritt 706 verwendet die Routine 700 eine standardmäßige Öffnungsfunktion, um die Datei, so wie sie ist, zu öffnen und zu sperren. Das Betriebssystem gibt eine Dateistruktur aus, die einen Zeiger (PF) zu den tatsächlichen Dateidaten umfasst, die der Datei des Dateinamens FN zugeordnet sind. Die Routine 700 verwendet auch einen temporären Dateistrom (TF) im Speicher. TF enthält eine Kopie der verschlüsselten Datei. TF kann man sich als einen Zeiger zur temporären verschlüsselten Datei 632 von 6 vorstellen. Der Zweck des temporären Dateistroms ist das Ausführen aller Operationen zuerst im Speicher, so dass das Abstürzen eines fernen oder feindseligen Systems nicht zu Datenkorruption durch teilweises oder unvollständiges Schreiben in die tatsächliche Datei führt. Dadurch kann mittels einer temporären Datei eine erfindungsgemäße Ausführung zu ihrer Form vor Verwendung zurückkehren, wenn ein auf eine Datei, die von einer erfindungsgemäßen Ausführung geschützt ist, zugreifendes System abstürzt.
  • Als Nächstes prüft die Routine 700 den Dateimodus bei Schritt 708. Wenn die Datei schreibgeschützt ist, legt die Routine 700 keine neue temporäre Datei im Speicher an, sondern TF wird vielmehr bei Schritt 716 der Wert PF zugewiesen. Dies bedeutet, dass der temporäre Dateistromverweis zur tatsächlichen Datei zeigt – was in einem absturzsicheren System akzeptabel ist, wenn die Datei schreibgeschützt ist.
  • Dann prüft die Routine 700 die Datei bei Schritt 710 auf den Status Nur Schreiben. Wenn die Datei den Status Nur Schreiben hat, wird bei Schritt 718 eine temporäre Datei im Speicher angelegt. Bei Schritt 720 führt die Routine 700 dann eine Reihe von Operationen im Hinblick auf ihre Unfähigkeit aus, die digitale Signatur DS (oder sogar Informationen) von der tatsächlichen Datei zu lesen. Zuerst setzt die Routine 700 die Variable, die eine Kopie der digitalen Signatur (DS) der Datei enthält, auf Null, definiert die interne Vorsatzobjektvariable, welche eine Version der digitalen Signatur enthält, die (normalerweise) aus der tatsächlichen Datei (H.DS) gelesen wird, auf Null, setzt die interne Vorsatzobjektvariable, die eine Version der Anwendersignatur enthält, die (normalerweise) von der tatsächlichen Datei gelesen wird, gleich der Anwendersignatur (US), wie sie der Routine 700 übergegeben wird, und setzt die interne Vorsatzaufgabenvariable, die die Dateilänge enthält, auf Null.
  • Bei Schritt 722 ruft die Routine 700 eine Schreibfunktion (ähnlich der in 10 dargestellten Funktion) auf. Die bei Schritt 722 aufgerufene Schreibfunktion ändert die Vorsatzobjektvariable, die eine Kopie der digitalen Signatur (H.DS) enthält, die normalerweise aus der tatsächlichen Datei gelesen wird, aber im vorliegenden Fall von Nur-Lesen auf Null gesetzt wurde, was die Zuweisung in Schritt 724 erfordert. Im Fall von Nur-Schreiben muss die tatsächliche Datei vollständig überschrieben werden, daher ist keine Authentifizierung der tatsächlichen Datei erforderlich. Dann rückt die Routine 700 zu Schritt 756 vor, wo sie ein Dateiobjekt, das komplexer als normal ist, bildet, das als variable Felder den physikalischen Dateiverweis (PF), den temporären Dateiverweis (TF), den Anwenderschlüssel (UK), den Verschlüsselungsschlüssel (EK), den Entschlüsselungsschlüssel (DK), das Vorsatzobjekt (H) und den physikalischen Zeiger (PP) aufweist, wobei der letztere zur Position in der temporären Datei zeigt.
  • Wenn die Datei weder Nur-Schreiben noch Nur-Lesen sein soll, geht die Routine 700 von Schritt 710 direkt zu Schritt 712. Bei Schritt 712 legt die Routine 700 eine temporäre Datei an und sperrt sie und kopiert bei Schritt 712 den verschlüsselten Inhalt der tatsächlichen Datei in den Inhalt der temporären Datei. Als Nächstes ruft die Routine 700 bei Schritt 714 eine Lesefunktion (ähnlich wie in 9 dargestellt) auf, um eine unverschlüsselte Version des Dateivorsatzes aus der temporären Datei zu lesen, wobei sie den unverschlüsselten Dateivorsatz in Objekt H speichert.
  • Bei Schritt 726 erfolgt eine Form von Authentifizierung unter Verwendung der Anwendersignatur (US). Die Anwendersignatur ist einfach ein Datenstück, das in den Vorsatz jeder durch eine erfindungsgemäße Ausführung geschützten Datei eingefügt wird. Die Anwendersignatur löst ein Sicherheitsproblem, wenn mehrere ähnliche verschlüsselte Dateien erzeugt werden, insbesondere wenn diese Dateien mit Hilfe des gleichen Anwenderschlüssels erzeugt werden. Die Dateien können auf einem Speichersystem mit einer Block Allocation Map verweilen, die Dateinamen logisch mit tatsächlichen Daten verbindet. Es ist aber relativ einfach, Daten zu ändern, die auf einem Speichersystem angesiedelten Daten einen Dateinamen zuweisen, und ein Anwender ist eventuell nicht in der Lage, mehrere ähnliche verschlüsselte Dateien zu unterscheiden, es sei denn durch Datennamen. Die Anwendersignatur löst dieses Bedürfnis, indem sie dem Anwender erlaubt, eine einzigartige Identifizierung in dem verschlüsselten Teil der Datei unterzubringen, wodurch für jede Datei eine sichere, einzigartige Identifizierung geliefert wird. Die Anwendersignatur wird als besonders nützlich betrachtet, wenn eine Anwendung Ausgaben iterativ erzeugt. Nach zehn Ausgabezyklen kann ein nicht autorisierter Mittelsmann versuchen, den letzten Satz der Ausgabe durch einen vorherigen Satz der Ausgabe zu ersetzen. Selbst wenn die Dateien ansonsten im Wesentlichen identisch sind, würde die Anwendersignatur dem Anwender das Unterscheiden der Dateien ermöglichen.
  • Bei Schritt 726 vergleicht die Routine 700 dann die der Routine 700 übergegebene Anwendersignatur mit der in dem Dateivorsatz enthaltenen Anwendersignatur. Wenn die Anwendersignatur nicht übereinstimmt, gibt die Routine 700 ein Nulldateiobjekt aus, was ein fehlgeschlagenes Öffnen anzeigt.
  • Unter der Annahme, dass die Anwendersignaturen übereinstimmen, führt die Routine 700 dann einen zweiten Authentifizierungsschritt aus. Zuerst berechnet die Routine 700 bei Schritt 730 die digitale Signatur der temporären verschlüsselten Datei, die sich im Speicher befindet. Schritt 730 umfasst zum Beispiel die Schritte 734–752. Bei Schritt 734 wird ein Zählerindex i auf Null gesetzt, ebenso wie eine Variable für die digitale Signatur (DS). Der Zähler i wird dazu verwendet, durch den Inhalt der temporären Datei zu gehen. Bei Schritt 736 prüft die Routine 700, um sicherzustellen, dass der Zähler i nicht zu einem Bereich der Datei zeigt, der nicht zur Berechnung der digitalen Signatur verwendet wird. Diese Angaben werden von den Indizes im Vorsatzobjekt (IH) geliefert. Der Zähler i geht dann mittels der Schritte 736 und 746 durch den nicht berechneten Bereich.
  • Wenn der Zähler i für die Zwecke der Berechnung der digitalen Signatur auf den logischen Anfangspunkt der Datei angehoben wird, wird der Dateizeiger für die temporäre Datei TF auf die Position gesetzt, die durch den Zähler i bei Schritt 738 angezeigt wird. Bei Schritt 740 wird eine Datenuntermenge aus der temporären Datei in ein verschlüsseltes Datenfeld (ED) gelesen. Bei Schritt 742 wird die jüngste Datenuntermenge entschlüsselt und das entschlüsselte Ergebnis wird in einem entschlüsselten Datenfeld (D) gespeichert. Bei Schritt 744 wird eine aktualisierte digitale Signatur mit Hilfe der letzten entschlüsselten Datenuntermenge D[i] berechnet und der Prozess fährt mit den Schritten 746, 736 und 750 fort, bis das Ende der Datei erreicht ist. Wenn Informationen, die nicht in die Berechnung der digitalen Signatur aufgenommen werden sollten (zum Beispiel die digitale Signatur selbst), in verschiedenen nicht benachbarten Datenuntermengen innerhalb der Datei gefunden werden, werden sie in der Prozessberechnung durch das in dem Objekt IH vorgesehene Mapping übersprungen. Bei Schritt 752 wird die berechnete digitale Signatur ausgegeben, wenn die Schritte 732–752 als separate Funktion ausgelegt sind.
  • Dann geht die Routine 700 durch Vergleichen der digitalen Signatur, die in den Schritten 732–752 berechnet wurde, mit der aus der Datei gelesenen digitalen Signatur von Schritt 730 zu Schritt 754. Wenn die Signatur nicht übereinstimmt, bedeutet dies, dass die Datei geändert wurde, und die Routine 700 gibt bei Schritt 728 ein Nulldateiobjekt aus, was ein Fehlschlagen beim Dateiöffnen anzeigt. Wenn die Signaturen übereinstimmen, wurde die Datei erfolgreich geöffnet und authentifiziert. Dann baut die Routine 700 ein spezialisiertes Dateiobjekt wie zuvor in Schritt 756 beschrieben und gibt bei Schritt 758 das Dateiobjekt aus.
  • Ein beispielhafter Dateischließalgorithmus für eine erfindungsgemäße Ausführung wird in 8 gezeigt. 8 ist ein Logikflussdiagramm, welches eine Dateischließroutine 800 einer bevorzugten Ausführung zeigt. Die Dateischließroutine 800 weist Schritte 802 bis 812 auf, welche verschiedene abstrakte Logikoperationen darstellen, die bei einer Dateischließroutine 800 von erfindungsgemäßen Ausführungen ausgeführt werden können.
  • Die Dateischließroutine 800 beginnt mit einem Benutzeraufruf 802, welcher ein Dateiobjekt (F) übergibt. Zuerst prüft die Routine 800 bei Schritt 804, ob die Datei F im Nur-Lesen-Modus verwendet wird, indem sie prüft, ob die temporäre Datei gleich der tatsächlichen Datei ist (da die temporäre Datei im Nur-Lesen-Modus unnötig ist und daher in dieser Ausführung nicht angelegt wird). Wenn die Datei eine Nur-Lesen-Datei ist, schließt die Routine 800 bei Schritt 810 einfach die Datei und kehrt bei Schritt 812 zurück.
  • Wenn die Datei keine Nur-Lesen-Datei ist, aktualisiert die Routine 800 die tatsächliche Datei mit dem Inhalt der temporären Datei. Die Verwendung einer temporären Datei zur Vornahme von Änderung erlaubt wieder ein gewisses Maß an Absturzsicherheit, ist aber kein notwendiger Teil der Erfindung. Bei Schritt 806 schreibt die Routine 800 mittels einer Schreibfunktion (ähnlich der in 9 gezeigten) eine aktualisierte Version des entschlüsselten Vorsatzobjekts H in die verschlüsselte temporäre Datei im Speicher. Bei Schritt 808 kopiert die Routine 800 den Inhalt der temporären (verschlüsselten) Datei in die tatsächliche Datei, wodurch alle Änderungen, die an der temporären Datei vorgenommen wurden, in die tatsächliche Datei übernommen werden. Dann wird die temporäre Datei gelöscht. Bei den Schritten 810 und 812 schließt und entsperrt die Routine 800 die tatsächliche Datei und kehrt zurück.
  • Ein beispielhafter Dateilesealgorithmus für eine erfindungsgemäße Ausführung wird in 9 gezeigt. 9 ist ein Logikflussdiagramm, welches eine Dateileseroutine 900 einer bevorzugten Ausführung zeigt. Die Dateileseroutine 900 weist die Schritte 902 bis 918 auf, welche verschiedene abstrakte Logikoperationen darstellen, die in einer Dateileseroutine 900 der erfindungsgemäßen Ausführungen ausgeführt werden können.
  • Die Routine 900 steigt bei Schritt 902 bei einem Benutzeraufruf ein, der ein Dateiobjekt F und einen Größenparameter (S) übergibt, der die Größe der aus der Datei F zu lesenden Daten anzeigt. Bei Schritt 904 werden zwei Zähler gesetzt. Zähler i wird auf den physikalischen Zeiger (PP) und Zähler j auf Null gesetzt. Bei Schritt 906 wird der physikalische Zeiger der Datei TF auf den Wert des Zählers i oder den Wert des physikalischen Zeigers PP gesetzt. Das Lesen der Datei beginnt dann bei Schritt 908. Eine standardmäßige Lesefunktion wird bei Schritt 908 für das Erhalten einer verschlüsselten Datenuntermenge aus der temporären Datei (TF), welche in einem verschlüsselten Datenfeld (ED) gespeichert ist, verwendet. Die so erhaltenen verschlüsselten Daten werden bei Schritt 910 entschlüsselt und einem entschlüsselten Datenfeld D zugewiesen. Die Zähler i und j werden bei Schritt 912 angehoben und die Schleife wird bei Schritt 914 wiederholt, bis j die Größe (S) der zu lesenden Daten erreicht, was anzeigt, dass alle erforderlichen Daten gelesen wurden. Bei Schritt 916 weist die Routine 900 PP den Endwert von i zu (welcher zur Position in der temporären Datei zeigt).
  • Ein beispielhafter Dateischreibalgorithmus für eine erfindungsgemäße Ausführung wird in 10 dargestellt. 10 ist ein Logikflussdiagramm, welches eine Dateischreibroutine 1000 einer bevorzugten Ausführung zeigt. Die Dateischreibroutine 1000 weist die Schritte 1002 bis 1032 auf, welche verschiedene abstrakte Logikoperationen darstellen, die in einer Dateischreibroutine 1000 erfindungsgemäßer Ausführungen ausgeführt werden können.
  • Die Routine 1000 beginnt bei Schritt 1002 mit einem Benutzeraufruf ein, der der Routine 1000 ein Dateiobjekt (F), ein Datenobjekt (D) und eine Größenvariable (S) als Parameter übergibt. Dateiobjekt (F) ist die Datei, in die geschrieben werden soll, Datenobjekt (D) sind die zu schreibenden Daten und die Größenvariable (Größe) ist die Größe des Datenobjekts (D). Bei Schritt 1004 setzt die Routine zwei Zähler: Zähler i wird auf den Ort des physikalischen Zeigers (PP) und Zähler j auf Null gesetzt.
  • Als Nächstes begibt sich die Routine 1000 in eine Schleife bei Schritt 1006. Zuerst prüft die Routine 1000 ein Indizes-im-Vorsatz-Objekt (IH), um zu ermitteln, ob der Dateizeiger aktuell in eine Datenuntermenge zeigt, die nicht zur Berechnung der digitalen Signatur verwendet wird. Wenn i nicht auf Daten zeigt, die bei der Berechnung der digitalen Signatur verwendet werden, springt die Routine 1000 sofort zu Schritt 1016, um eine verschlüsselte Schreibsequenz zu beginnen.
  • Wenn i auf Daten zeigt, die bei der Berechnung der digitalen Signatur verwendet werden, dann muss die digitale Signatur korrigiert werden, um mit den neuen zu schreibenden Daten übereinzustimmen. Zur Verwirklichung dieser Aufgabe setzt die Routine 1000 bei Schritt 1008 zuerst den Dateizeiger der temporären Datei auf die aktuelle Position von i. Als Nächstes verwendet die Routine 1000 bei Schritt 1010 eine standardmäßige Leseroutine, um eine verschlüsselte Datenuntermenge aus der temporären Datei (TF) zu erhalten. Die verschlüsselte Datenuntermenge wird in einem verschlüsselten Datenfeld ED gespeichert. Dann wird die verschlüsselte Datenuntermenge bei Schritt 1012 entschlüsselt und einer temporären Variablen X zugewiesen. Eine aktualisierte digitale Signatur wird bei Schritt 1014 berechnet und dem entschlüsselten Vorsatzobjekt H unter Verwendung der Funktion Q, der entschlüsselten tatsächlichen Daten und der zu schreibenden entschlüsselten Daten zugewiesen. Aufgrund der bisher erläuterten Eigenschaften der Funktion Q kann die berichtigte digitale Signatur schnell beurteilt werden. Bei Schritt 1016 wird der Ort des physikalischen Zeigers in der temporären Datei wieder auf den aktuellen Wert i aktualisiert.
  • Bei Schritt 1018 werden die von dem Datenobjekt D zu schreibenden Daten mit Hilfe des Verschlüsselungsschlüssels verschlüsselt und dem verschlüsselten Datenfeld (ED) zugewiesen. Dann verwendet die Routine 1000 eine normale Schreibfunktion, um die verschlüsselte Datenuntermenge in die temporäre Datei zu schreiben. Bei den Schritten 1022 und 1024 werden die Zähler i und j angehoben und die Schleife wird verarbeitet, bis j gleich der Größe der zu schreibenden Daten ist (Größe). Sobald die Schleife bestehend aus den Schritten 1006 bis 1024 fertig ist, prüft die Routine 1000 dann, um sicherzustellen, dass die Dateigrößenvariable des Vorsatzobjekts H (H.FS) richtig ist. Bei Schritt 1026 prüft die Routine 1000, um zu sehen, ob die Daten über dem Ende der aktuellen Datei geschrieben wurden (ein Hinzufüg-Schreiben). Wenn ja, aktualisiert die Routine 1000 die in dem Vorsatzobjekt (H.FS) gespeicherte Dateilänge auf die richtige Größe. Die Routine 1000 weist dann den aktuellen Ort des physikalischen Zeigers bei Schritt 1030 zu und gibt die Anzahl der in Schritt 1032 geschriebenen Datenuntermengen aus.
  • In 11 wird ein beispielhafter Dateisuchalgorithmus für eine erfindungsgemäße Ausführung dargestellt. 11 ist ein Logikflussdiagramm, welches eine Dateisuchroutine 1100 einer bevorzugten Ausführung zeigt. Die Dateisuchroutine 1101) weist die Schritte 1102 bis 1110 auf, welche verschiedene abstrakte Logikoperationen darstellen, die in einer Dateisuchroutine 1100 erfindungsgemäßer Ausführungen ausgeführt werden können.
  • Die Dateisuchroutine 1100 beginnt von einem Benutzeraufruf aus zu laufen, der ein Dateiobjekt (F) und einen logischen Zeiger (LP) übergibt. Bei Schritt 1104 prüft die Routine 1100, um zu sehen, ob der logische Zeiger (LP) größer als die aktuelle Dateigröße (H.LS) ist. Die Routine 1100 prüft mit anderen Worten, um zu sehen, ob der aktuelle Dateizeiger zu einer Position zeigt, die sich nach dem Ende der Datei ergibt. Wenn ja, springt die Routine 1100 zu Schritt 1110 und gibt einen Fehler aus.
  • Wenn der logische Zeiger (LP) aber in die Grenzen der Datei zeigt, geht die Routine 1100 zu Schritt 1106, wo dem physikalische Zeiger PP (der für den Zugriff auf die temporäre verschlüsselte Datei verwendet wird) der Wert des logischen Zeigers plus der Vorsatzgröße zugewiesen wird, denn der logische Zeiger (LP) setzt normalerweise die Nullposition am Ende eines Dateivorsatzes. Nach Ausführen dieser Anpassung gibt die Routine 1100 einen Wert aus, der ihre erfolgreiche Ausführung anzeigt.
  • In 12 wird ein beispielhafter Dateiendealgorithmus (eof) für eine erfindungsgemäße Ausführung dargestellt. 12 ist ein Logikflussdiagramm, welches eine Datei-eof-Routine 1200 einer bevorzugten Ausführung zeigt. Die eof-Routine 1200 weist die Schritte 1202 bis 1208 auf, welche verschiedene abstrakte Logikoperationen darstellen, die in einer eof-Routine 1200 erfindungsgemäßer Ausführungen ausgeführt werden können.
  • Die eof-Routine 1200 dient der Ermittlung, ob der physikalische Zeiger zur temporären Datei derzeit am Ende der Datei steht. Sie beginnt den Ablauf mit einem Benutzeraufruf, der bei Schritt 1202 ein Dateiobjekt (F) übergibt. Bei Schritt 1204 prüft die Routine 1200, um zu sehen, ob der physikalische Zeiger minus der Vorsatzgröße (HS) gleich der Dateigrößenvariablen ist, die in dem Vorsatzobjekt (H.FS) gespeichert ist. Wenn ja, dann hat die Routine 1200 an der aktuellen Dateiposition ein Dateiende festgestellt und gibt bei Schritt 1208 Wahr aus. Wenn der physikalische Zeiger minus der Vorsatzgröße (HS) nicht gleich der Dateigrößenvariablen ist, die in dem Vorsatzobjekt (H.FS) gespeichert ist, dann zeigt der physikalische Zeiger nicht zum Ende der Datei, und die Routine 1200 gibt bei Schritt 1206 Falsch aus.
  • Ein spezifisches Beispiel von Softwareausführungen der vorliegenden Erfindung kann als „DAP-Ausführung" (wobei das Akronym DAP für „Distributed Authentication Protocol" = verteiltes Authentifizierungsprotokoll steht) bezeichnet werden. Die Funktionen der DAP-Ausführung können in der C-Sprache implementiert werden, mit der Absicht, dass deren Operation für den Programmierer völlig transparent ist, wobei lediglich der Name der normalen stdio-C-Funktionen durch Hinzufügen eines „DAP"-Präfixes geändert werden muss. Um zum Beispiel die C/C++ Funktion fwrite mit den Schutzmaßnahmen der erfindungsgemäßen Ausführungen zu verwenden, würde der Programmierer einfach den relevanten Code zum Kompilierzeitpunkt aufnehmen und die Funktion DAP_fwrite[F, D, size) nennen, anstatt das normale fwrite, wobei alle anderen Aspekte des Programms unverändert bleiben. Insbesondere äquivalente Funktionen verwenden die gleichen Argumente in der gleichen Reihenfolge und geben die gleiche Art von Variable aus. Die gesamte Entschlüsselung und Authentifizierung wird in sicherer Weise ausgeführt, wie unter Bezug auf die erfindungsgemäßen Ausführungen beschrieben wird, aber so, dass deren Details verborgen sind, um den Programmierer Zeit und Mühe zu sparen.
  • In der Schrift wird eine „Funktionsbibliothek" oder „Bibliothek" so verwendet, dass sie eine Sammlung von Funktionen in Quellcode oder anderweitig bezeichnet, die zu einem bestimmten Ende hin ausgerichtet sind. Die DAP-Ausführung wird vorzugsweise in drei Schichten als Funktionsbibliothek implementiert. Eine erste Schicht verschlüsselt/entschlüsselt Daten in Eingabe/Ausgabe mit Hilfe eines nicht lokalen Verschlüsselungsalgorithmus mit einem Schlüssel willkürlicher Länge. Eine zweite Schicht implementiert die Authentifizierungsverfahren, wie sie zum Beispiel vorstehend beschrieben wurden, sowie eine Dateigrößenprüfung. Bevorzugt ist, dass die digitale Signatur auf den unverschlüsselten Daten einschließlich der Anwendersignatur und aller Metadaten (soll heißen sekundäre Daten, die in einer Datei enthalten sind, um die Attribute der primären Daten zu beschreiben), in der Datei gespeicherter Informationen (ausschließlich der Bytes, bei denen die digitale Signatur selbst gespeichert wird) berechnet wird. Eine dritte Schicht ordnet virtuellen Zeiger dem physikalischen Zeiger zur Datei zu.
  • In einer solchen geschichteten Ausführung kann ein Programm, das den Anwenderschlüssel und die Anwendersignatur kennt, eine DAP-Datei öffnen, in ihr Daten lesen und schreiben, ohne die DAP-Schichten und Metadaten zu sehen, die unser Protokoll zusammen mit den realen Daten speichert. Diese Schichten sind in einer bevorzugten Ausführung für das Anwenderprogramm unsichtbar.
  • Nach der DAP-Ausführung kann ein Anwenderprogramm durch die folgenden Grundfunktionen DAP_fopen, DAP_fopenq, DAP_fclose, DAP_fwrite, DAP_fread, DAP_fseek und DAP_ftell auf DAP-Routinen zugreifen. In der Praxis werden eigentlich mehr Funktionen implementiert, können aber alle aus den hier dargestellten abgeleitet werden. Die Namen dieser Funktionen sind irrelevant und sie sind keine Bedingung des Protokolls.
  • In der DAP-Ausführung arbeiten die Funktionen wie folgt:
    DAP_fopen: diese Funktion nimmt als Argument den Namen der zu öffnenden Datei (FN), den Modus, mit dem wir auf die Datei zugreifen wollen (M = lesen/schreiben/hinzufügen), den Anwenderschlüssel (UK), um die Datei zu verschlüsseln/zu entschlüsseln, und die Anwendersignatur (US). Wenn die Datei nicht existiert, legt sie die Datei an und schreibt die verschlüsselten Metadaten (digitale Signatur, Anwendersignatur und logische Dateigröße). Sobald die Datei existiert: öffnet sie die Datei, sperrt sie, kopiert sie in eine temporäre Datei, führt eine Validierung der digitalen Signatur durch lokales Entschlüsseln der Datei mit Hilfe des vorgegebenen Anwenderschlüssels aus und vergleicht die echte Anwendersignatur mit der als Eingabe erzeugten Anwendersignatur. Wenn eine dieser Prüfungen fehlschlägt, entsperrt die Funktion die Datei und gibt irgendein Fehlersignal aus. Wenn alle Prüfungen erfolgreich sind, gibt die Funktion irgendeinen Verweis auf eine Struktur aus, die Zeiger zu den beiden Dateien (die alte und die temporäre) und zu den internen Variablen enthält. Die Funktion hat die folgende Syntax:
    FILE *DAP_fopen (char *filename, char *mode, char *key, char *signature);
    Die DAP_fopen Funktion öffnet die Datei mit dem Dateinamen „filename", ordnet sie einem Stream zu und gibt einen Zeiger zu dem Objekt aus, das den Stream steuert. Die Anfangszeichen von „mode" bestimmen, wie das Programm den Stream manipuliert und ob es den Stream als binär auslegt. Die Anfangszeichen müssen eine der folgenden Sequenzen sein: „rb" – um eine vorhandene binäre Datei zum Lesen zu öffnen; „wb" – um zum Schreiben eine binäre Datei anzulegen oder eine vorhandene binäre Datei zu öffnen und zu trunkieren; „ab" – um zum Schreiben eine binäre Datei anzulegen oder eine vorhandene binäre Datei zu öffnen (die Dateipositionsanzeige befindet sich am Ende der Datei (möglicherweise nach willkürlicher Null Byte Auffüllung) vor jedem Schreiben); „rb+" – um zum Lesen und Schreiben eine vorhandene binäre Datei zu öffnen; „wb+" – um zum Lesen und Schreiben eine binäre Datei anzulegen oder eine vorhandene binäre Datei zu öffnen und zu trunkieren; „ab+" – um zum Lesen und Schreiben eine binäre Datei anzulegen oder eine bestehende binäre Datei zu öffnen. Die Dateipositionsanzeige ist vor jedem Schreiben am Ende der Datei (möglicherweise nach willkürlicher Null Byte Auffüllung) positioniert.
  • Wenn die Datei durch die DAP_open Funktion angelegt wird, wird sie mit der vorgegebenen Signatur signiert und mit Hilfe des vorgegebenen Schlüssels verschlüsselt. Wenn die Datei bereits vorliegt, wird sie mit Hilfe des vorgegebenen Schlüssels und der vorgegebenen Signatur authentifiziert. Die Funktion gibt 0 aus (Null Zeiger), wenn die Datei nicht authentifiziert werden kann. Der von der Funktion ausgegebene Stream ist eigentlich ein Zeiger einer internen Datenstruktur, erzeugt durch DAP_fopen, in einen Zeiger zur Datei gecasted (um die Verwendung einer temporären Datei für Absturzsicherheit zu bewirken). Alle DAP-Funktionen nehmen den Ausgabestrom, der von DAP_fopen ausgegeben wird, als Eingabe. Der Ausgabestrom verhält sich, als wäre er ein Zeiger zur DAP-Datei.
  • DAP_fopenq hat die gleiche Syntax wie fopen, funktioniert aber wie DAP_fopen. Bei Verwendung von DAP_fopenq, wird der Anwender nach einem Schlüssel und einer Signatur gefragt, wobei die Standardeingabe und die Standardausgabe verwendet werden.
  • Die Funktion DAP_fclose nimmt als Argument nur einen Verweis auf die zu schließende Datei. Sie kopiert die temporäre Datei zurück in die ursprüngliche Datei, entfernt alle Sperren und entfernt die temporäre Datei. Die Syntax lautet:
    int DAP_fclose(FILE *stream);
    Die Funktion schließt die dem DAP-Strom „stream" zugeordnete Datei. Sie gibt bei Erfolg DAP_OK aus; andernfalls gibt sie DAP_KO aus. Die Funktion fclose schreibt eine gepufferte Ausgabe in die tatsächliche Datei, gibt den Streampuffer frei, wenn er automatisch zugewiesen worden war, und entfernt die Zuordnung zwischen dem Stream und der Datei. DAP_OK und DAP_KO sind in der DAP-Vorsatzdatei (dap.h) definiert und entsprechen 1 bzw. 0.
  • Die Funktion DAP_fwrite nimmt einige Anwenderdaten als Eingabe. Sie erlaubt es dem Anwenderprogramm, auf die verschlüsselte, doppelt signierte DAP-Datei zu schreiben. Es aktualisiert die digitale Signatur, so dass sie die neuen Daten enthält, verschlüsselt die Daten mit Hilfe des zur Datei zugeordneten Verschlüsselungsschlüssels und schreibt die verschlüsselten Daten in die temporäre Kopie der Datei. Die Syntax lautet:
    size_t DAP_fwrite(const void *restrict ptr, size_t size, size_t nelem, FILE *stream);
    Die Funktion schreibt Zeichen zum ausgegebenen DAP-Strom „stream", wobei sie auf Werte von aufeinander folgenden Elementen eines Felds zugreift, dessen erstes Element die Adresse (char *)ptr hat, bis die Funktion size*nelem Zeichen schreibt. Sie gibt n/size aus, wobei n die Anzahl geschriebener Zeichen ist.
  • Die Funktion DAP_fread erlaubt es dem Anwenderprogramm, aus der DAP-Datei zu lesen. Es liest Daten aus der temporären Kopie der Datei, entschlüsselt die Daten mit Hilfe des zugeordneten Schlüssels und gibt sie aus. Die Syntax lautet:
    size_t DAP_fread(void *restrict ptr, size_t size, size_t nelem, FILE *restrict stream);
    Die Funktion liest Zeichen aus dem eingegebenen DAP-Strom „stream" und speichert sie in aufeinander folgenden Elementen eines Felds, dessen erstes Element die Adresse (char *)ptr hat, bis die Funktion size*nelem Zeichen speichert. Funktion gibt n/size aus, wobei n die Anzahl gelesener Zeichen ist. Ist n nicht ein Mehrfaches der Größe, ist der in dem letzten Element gespeicherte Wert unbestimmt.
  • Die Funktion DAP_fseek ordnet einen virtuellen Zeiger, der als Argument übergeben wird, dem realen physikalischen Zeiger zu, der der Datei zugewiesen ist. Sie erlaubt es zum Anwenderprogramm, sich in der Datei nach oben und unten zu bewegen, ohne irgendwelche Metadaten und Verschlüsselung zu sehen. Die Syntax lautet;
    int DAP_fseek(FILE *stream, long offset, int mode);
    Die Funktion setzt den logischen Zeiger (LP) für den Strom „stream" (wie durch Offset und Mode festgelegt), löscht den Dateiende-Indikator für den Stream und gibt bei Erfolg DAP_OK aus, ansonsten DAP_KO. „offset" ist ein signierter Offset in Bytes: wenn „mode" den Wert SEEK_SET hat, setzt fseek den logischen Zeiger (LP) auf den Wert des Offsets; wenn „mode" den Wert SEEK CUR hat, addiert fseek den Offset zum aktuellen Wert des logischen Zeigers; wenn „mode" den Wert SEEK_END hat, setzt fseek den logischen Zeiger zum Ende der logischen Datei (Stream), minus des Werts des Offset.
  • Die Funktion DAP_ftell ist das Gegenteil von DAP_fseek. Sie gibt die aktuelle Position des logischen Zeigers zu den Daten in der Datei aus. Sie erlaubt dem Anwender die Abfrage der aktuellen Position in der Datei. Die Syntax lautet:
    long DAP_ftell(FILE *stream);
    Die Funktion gibt eine kodierte Form des Dateipositionsindikators für den Strom „stream" aus oder gibt den Wert –1 aus. Bei einer binären Datei gibt ein erfolgreicher Ausgabewert die Anzahl an Bytes vom Anfang der Datei an.
  • Die Funktion DAP_feof gibt einen Nichtnullwert aus, wenn der logische Zeiger das Ende der logischen Datei erreicht, die dem Strom „stream" zugewiesen ist. Die Syntax lautet:
    int DAP_feof(FILE *stream);
    Die Funktion DAP_fflush schreibt eine gepufferte Ausgabe in die Datei, die dem Strom „stream" zugeordnet ist, kopiert die temporäre Datei in die physikalische Datei und gibt bei Erfolg DAP_OK aus; andernfalls gibt sie DAP_KO aus. Die Syntax lautet:
    int DAP_fflush(FILE *stream);
    Die Funktion DAP_fgetc liest das nächste Zeichen c (falls vorhanden) aus dem Eingabestrom „stream", rückt den logischen Zeiger vor und gibt (int)(unsigned char)c aus.
    int DAP_fgetc(FILE *stream)
  • Die Funktion DAP_fputc schreibt das Zeichen (unsigned char)c zum Ausgabestrom „stream", rückt den logischen Zeiger vor und gibt (int)(unsigned char)c aus. Die Syntax lautet:
    int DAP_fputc(int c, FILE *stream);
    Die Funktion DAP_fsize gibt die Größe der Datei aus, die dem Strom zugewiesen ist. Die Syntax lautet:
    int DAP_fsize(FILE *stream);
    Die Funktion DAP_ftruncate trunkiert die dem Strom zugewiesene Datei bei der festgelegten Größe. Bei Erfolg gibt sie DAP_OK aus, andernfalls DAP_KO. Die Syntax lautet:
    int DAP_ftruncate(FILE *stream, size_t size);
    Die Funktion DAP_faccess versucht, auf die Datei zuzugreifen, die dem Strom für binäres Lesen/Schreiben zugewiesen ist, und versucht, die Datei zu authentifizieren. Wenn auf die Datei nicht zugegriffen werden kann oder diese nicht authentifiziert wird, gibt sie DAP_KO aus. Bei Erfolg gibt sie DAP_OK aus. Die Syntax lautet:
    int DAP_faccess(FILE *stream);
    Die Funktion DAP_secure nimmt die normale Eingabedatei und erzeugt eine Ausgabedatei, die mit dem vorgegebenen Schlüssel und der vorgegebenen Signatur gesichert wird. Die Syntax lautet:
    int DAP_secure(char *input, char *output, char *key, char *signature);
    Die Funktion DAP_unsecure nimmt eine sichere Eingabedatei und erzeugt eine normale Ausgabedatei. Die Syntax lautet:
    int DAP_unsecure(char *input, char *output, char *key, char *signature);
    Die Funktion DAP_add_parity(a, b) dient zum Anlegen einer digitalen Signatur zwischen den Datenuntermengen a und b und ist das Äquivalent der oben beschriebenen abstrakten Funktion Q(a,b).
  • Die DAP-Ausführung wird als Application Programm Interfaces, geschrieben in der „C"-Sprache, implementiert. Der zuvor beschriebene Blowfish-Algorithmus wurde für die Verschlüsselung mit positionsabhängigem Scrambling verwendet. Die digitale Signatur wird mit Hilfe einer 32 bit XOR-Prüfsumme berechnet. Die DAP-Bibliothek ist so ausgelegt, dass sie Namen aufweist, die ähnlich denen der standardmäßigen Eingabe-/Ausgabefunktion für Datei/Ströme der „C"-Sprache sind, wie in der ANSI „stdio.h"-Bibliothek festgelegt. Siehe Tabelle III für eine Vergleichsliste
  • Figure 00370001
  • Mit Ausnahme der Funktionen DAP_fopen() haben die Funktionen der DAP-Ausführung auf Anwenderprogrammebene die gleiche Funktionalität wie die entsprechenden stdio-Funktionen. Intern sind sie sehr anders, da die ersteren die Datei nicht nur lesen und schreiben, sondern auch das DAP-Protokoll implementierten und die Datei automatisch gesperrt, verschlüsselt und signiert/authentifiziert wird.
  • Die einzige Funktion, die sich von der entsprechenden stdio-Funktion unterscheidet, ist DAP_fopen. Sie hat den folgenden Funktionsprototyp:
    FILE*fopen(char *filename, char *mode, char *key, char *signature)
  • Die ersten beiden Argumente sind die gleichen wie bei stdio fopen. Die letzteren beiden Argumente werden von dem DAP-Protokoll benötigt. Die Argumente sind wie folgt: „filename" ist ein Zeiger zu einem String, wo der Name der zu öffnenden (oder anzulegenden Datei (FN) gespeichert wird; der Parameter „mode" ist ein Zeiger zu einem String, der festlegt, wie die Datei geöffnet (M) wird (unterstützte Modi sind die Standard-ANSI-Modi: rb, wb, ab, rb+, wb+, ab+ (die Datei wird immer im binären Modus geöffnet)); „key" ist ein Zeiger zu einem String, wo der Anwenderschlüssel (UK) bei der Verschlüsselung/Entschlüsselung der Datei gespeichert wird. signature ist ein Zeiger zu dem String, wo die Anwendersignatur (US) der Datei gespeichert wird. Wenn die Datei „filename" nicht existiert und im Modus wb, wb+, ab oder ab+ geöffnet wird, wird die Datei mit dem vorgegebenen Schlüssel und der vorgegebenen Signatur angelegt. Wenn die Datei existiert, dann wird die von dem DAP-Protokoll festgelegte Überprüfung ausgeführt. Bei Erfolg wird die Datei geöffnet und gesperrt und eine sich von Null unterscheidende Zahl wird ausgegeben. Andernfalls wird die Datei geschlossen und 0 ausgegeben. Zu beachten ist, dass der ausgegebene Wert ein Zeiger zu einer internen Struktur ist, die in ein FILE* gecasted wird. Dies kann für das entsprechende Argument der anderen DAP-Funktionen verwendet werden. Aufrufe zu DAP-Funktionen und stdio-Funktionen können für die gleiche Datei nicht gemischt werden.
  • Andere Funktionen wie fprintf und fscanf sind hier nicht aufgelistet, weil sie intern fwrite und fread für die Eingabe/Ausgabe verwenden, daher würde ihre DAP-Implementierung aus dem Ersetzen dieser internen Aufrufe mit DAP-Aufrufen bestehen.
  • Ein Beispiel einer DAP-Ausführung wird in den 13–14 gezeigt. 13 zeigt, wie ein einfaches „Hello, world!" Programm ohne die DAP-Ausführungen geschrieben werden kann. 13 zeigt ein charakteristisches Rechenumfeld 1300, einschließlich mehrerer Dateien und von Ausführungscodegruppen (der Einfachheit halber in 13 als nicht kompilierter Quellcode gezeigt). 13 hat eine erste Quellcode-Bildschirmseite 1302, eine erste Ausgabe-Bildschirmseite 1304, eine erste Textdatei 1306, eine zweite Quellcode-Bildschirmseite 1308, eine zweite Ausgabe-Bildschirmseite 1310, einen Korruptionsschritt 1312, eine korrumpierte Textdatei 1314, eine dritte Quellcode-Bildschirmseite 1316 und eine dritte Ausgabe-Bildschirmseite 1318.
  • Wenn der Quellcode in der Bildschirmseite 1302 ausgeführt wird, wird eine Textdatei 1306 mit der einfachen Mitteilung „Hello, world!" angelegt. Das erfolgreiche Anlegen wird durch die Ausgabe-Bildschirmseite 1304 dokumentiert. Die Textdatei 1306 existiert in dem charakteristischen Rechenumfeld 1300 in einem unverschlüsselten Zustand, wobei alle Anwender auf sie zugreifen können, die wissen, wo sie zu finden ist. Wenn der Quellcode in der Bildschirmseite 1308 ausgeführt wird, werden die Daten bestehend aus dem Text „Hello, world!" aus der Textdatei 1306 gelesen und das erfolgreiche Lesen wird in der Ausgabe-Bildschirmseite 1310 angezeigt. Bei Schritt 1312 wird die Textdatei 1306 aber durch einen nicht vertrauenswürdigen Anwender bzw. ein nicht vertrauenswürdiges Programm korrumpiert, wobei sie zu der korrumpierten Datei 1314 wird. Wenn der Quellcode in der Bildschirmseite 1316 ausgeführt wird, wird der korrumpierte Datenstring gelesen, aber der Ausführungscode kann nicht die Korruption der Textdatei 1314 erkennen und zeigt in der Ausgabe-Bildschirmseite 1318 Erfolg an.
  • 14 zeigt, wie ein einfaches „Hello, world!" Programm mit einer DAP-Ausführung modifiziert werden kann, um ihm die erfindungsgemäßen Schutzmaßnahmen zu bieten. 14 zeigt ein charakteristisches Rechenumfeld 1400, einschließlich mehrerer Dateien und Ausführungscodegruppen (der Einfachheit halber in 14 als nicht kompilierter Quellcode gezeigt). 14 hat eine erste Quellcode-Bildschirmseite 1402, eine erste Ausgabe-Bildschirmseite 1404, eine erste Textdatei 1406, eine zweite Quellcode-Bildschirmseite 1408, eine zweite Ausgabe-Bildschirmseite 1410, einen Korruptionsschritt 1412, eine korrumpierte Textdatei 1414, eine dritte Quellcode-Bildschirmseite 1416 und eine dritte Ausgabe-Bildschirmseite 1418.
  • Der Quellcode der Bildschirmseite 1402 unterscheidet sich von dem Quellcode der Bildschirmseite 1302 von 13 darin, dass die Funktionsaufrufe so modifiziert werden, dass sie in der mit einer DAP-Ausführung verwendeten Form vorliegen. Wenn der Quellcode in der Bildschirmseite 1402 ausgeführt wird, wird eine Textdatei 1406 mit der einfachen Mitteilung „Hello, world!" angelegt. Das erfolgreiche Anlegen wird durch die Ausgabe-Bildschirmseite 1404 dokumentiert. Die Textdatei 1406 existiert in dem charakteristischen Rechenumfeld 1400 in einem verschlüsselten Zustand, wobei alle Anwender, die nicht den Anwenderschlüssel (bzw. den Entschlüsselungsschlüssel bei einer asymmetrischen Verschlüsselung) haben, nicht auf sie zugreifen können. Wenn der Quellcode in der Bildschirmseite 1408 ausgeführt wird, werden die verschlüsselten Daten mit dem Text „Hello, world!" aus der Textdatei 1406 gelesen und entschlüsselt, alles transparent für den Programmierer, und das erfolgreiche Lesen wird in der Ausgabe-Bildschirmseite 1410 angezeigt. Bei Schritt 1412 wird die Textdatei 1406 aber durch einen nicht vertrauenswürdigen Anwender bzw. ein nicht vertrauenswürdiges Programm korrumpiert, wobei sie zu der korrumpierten Datei 1414 wird. Wenn der Quellcode in der Bildschirmseite 1416 ausgeführt wird, erkennt der dem Funktionsaufruf DAP_fopen() zugrunde liegende Ausführungscode, bevor der korrumpierte Datenstring von DAP_fread() gelesen wird, dass die digitale Signatur nicht mit dem Inhalt der Datei übereinstimmt. Der Ausführungscode ermittelt erfolgreich die Korruption der Textdatei 1414 und zeigt in der Ausgabe-Bildschirmseite 1418 ein Fehlschlagen an
  • In 14 lesen, suchen und schreiben die Anwenderprogramme (dargestellt durch die Quellcode-Bildschirmseiten 1402, 1408 und 1416) in einer temporären Datei, welche eine Kopie der ursprünglichen Datei ist, um ein Maß an Absturzstabilität zu bieten. Die Kopie wird nur in die ursprüngliche Datei rückgeführt, wenn die Datei ordnungsgemäß geschlossen oder geleert wird. Auf diese Weise geht bei einem Absturz des Systems oder des Anwenderprogramms der ursprüngliche Dateiinhalt nicht verloren bzw. wird nicht unbrauchbar geändert.
  • Häufig sind sichere Daten in der Datenbank eines Remote Server resident. Diese Datenbanken können zum Speichern von Kundeninformationen, militärischen Spezifikationen, Finanzdaten, Laborexperimenten oder von jedem denkbaren Satz sensibler Informationen verwendet werden. Die erfindungsgemäßen Ausführungen werden als besonders nützlich für Datenbanksicherheit betrachtet.
  • Dementsprechend ist ein zweites Beispiel eine eingebettete Allzweck-Datenbankbibliothek, die sicher mit Hilfe der DAP-Ausführungen (DAPDB) läuft. Die DAPDB-Datenbank ist mit der Anwenderanwendung verbunden und ist in dem gleichen Adressraum wie die Anwenderanwendung resident. DAPDB wird in Form einer Funktionsbibliothek (oder „Bibliothek") implementiert. Die Datenbank ist so aufgebaut, dass jede Tabelle einer einzelnen DAP-Datei (verschlüsselt, geprüft, signiert) zugeordnet ist; dass die Datenbank aus offenkundigen Sicherheitsgründen nicht im Speicher entschlüsselt wird; dass jeder Datensatz der Tabelle aus einem Datensatzschlüssel (nicht mit einem Verschlüsselungsschlüssel, einem Entschlüsselungsschlüssel oder einem Anwenderschlüssel zu verwechseln) und einem Datensatzkörperstring besteht; dass der Datensatzschlüssel und der Datensatzkörperstring für jeden Datensatz eine willkürliche Größe haben kann und nicht homogene Strukturen (zum Beispiel können Datensatzkörper Strings willkürlicher Länge oder anwenderdefinierte Datenstrukturen, in gleicher Weise kann der Datensatzschlüssel jede anwenderdefinierte Datenstruktur sein) enthalten; dass eine schnell Datensatzschlüsselsuche, die keine Datensatzschlüsselentschlüsselung oder das Anlegen eines temporären Indexes erfordert, verwendet werden kann; dass die Datensätze in der Datenbank angefügt, gelöscht und ersetzt werden können; dass auf die Datensätze in der Datenbank in der Reihenfolge zugegriffen werden kann, in der sie angefügt oder geändert wurden (der letzte angefügte/geänderte Datensatz erscheint immer als der letzte Datensatz in der Datenbank) und dass die Datenbank transaktionssicher ist (für Operationen in einer einzelnen Tabelle). In der vorliegenden Ausführung ist jede Datentabelle einer Hash-Tabelle von Prüfsummen von Datensatzschlüsseln zugeordnet. Jede Hash-Tabelle ist zusammen mit der entsprechenden Datenbanktabelle in einer DAP-Datei gespeichert, signiert und verschlüsselt. Sobald eine Tabelle geöffnet wird, wird die Hash-Tabelle entschlüsselt und für schnelle Suche im Speicher gespeichert.
  • Als Beispiel einer DAP-Datenbank wird eine DAPDB-Tabelle vorgesehen, welche ein Italienisch-Englisch-Wörterbuch zusammen mit einem C-Programm (dapdb_example.c) enthält, das die DAPDB-Bibliotheksfunktionen verwendet und eine einfache Textmodus-Anwenderschnittstelle zum Lesen/Schreiben einer DAPDB-Tabelle liefert. Das Beispielprogramm kann zum Suchen, Lesen und Ändern der Wörterbuchdatei verwendet werden. Der Wörterbuch-Dateiname lautet „italian.ddb". Diese Datei wird mit einem Anwenderschlüssel „test" und einer Anwendersignatur „italian.ddb" verschlüsselt.
  • In der vorliegenden Ausführung besteht die DAPDB-Bibliothek aus einer Vielzahl von Funktionen, die in den folgenden Absätzen beschrieben werden.
  • Die Funktion DAPDB open öffnet die Datenbanktabelle, die in der DAP-Datei „filename" gespeichert ist, mit Hilfe von Schlüssel und Signatur als Anwenderschlüssel (UK) bzw. Anwendersignatur (US). Bei Erfolgt gibt die Funktion einen Verweis auf die offene Tabelle aus (DAPDB ist eine C-Struktur, die in dem DAPDB-Vorsatz dapdb.h definiert ist). Wenn die Datei nicht authentifziert werden kann, gibt sie 0 aus. Die Syntax lautet:
    DAPDB* DAPDB_open(char *filename, char *key, char *signature);
    Die Funktion DAPDB_close schließt die mit db bezeichnete Tabelle und schließt die der Tabelle zugeordnete DAP-Datei. Die Syntax lautet:
    int DAPDB_close(DAPDB* db);
    DAPDB_ropen() ist gleich der Funktion DAPDB_open(), öffnet aber die Tabelle im Schreibschutzmodus. Die Syntax lautet:
    DAPDB* DAPDB_ropen(char *filename, char *rkey, char *signature);
    Die DAPDB_find Funktion sucht die mit db bezeichnete Tabelle nach einem Datensatzschlüssel k gleich den ersten key_size Zeichen ab, auf die durch die eingegebene Variable rkey gezeigt wird. Wird der Datensatz gefunden, setzt die Funktion einen internen Datensatzzeiger auf die Position dieses Datensatzes. Die Funktion gibt bei Erfolg DAP_OK und bei Fehlschlagen DAP_KO aus. Die Syntax lautet int DAPDB_find(DAPDB* db, char *key, long key_size);
    Die Funktion DAPDB_find_next ist gleich wie die Funktion DAPDB_find, beginnt die Suche aber ab dem Datensatz neben dem Datensatz, auf den durch den aktuellen Wert des Datensatzzeigers gezeigt wird. Die Funktion gibt bei Erfolg DAP_OK und bei Fehlschlagen DAP_KO aus. Die Syntax lautet
    int DAPDB_find_next(DAPDB* db, char *key, long key_size);
    Die Funktion DAPDB_fast_append() fügt der mit db bezeichneten Tabelle einen neuen Datensatz hinzu. Der Datensatz wird mit einem Schlüssel der Größe key_size und einem String (str) der Größe str_size gefüllt. Der Datensatz wird ohne Prüfen angehängt, ob der Datensatzschlüssel bereits existiert. Die Funktion gibt bei Erfolg DAP_OK und bei Fehlschlagen DAP_KO aus. Die Syntax lautet
    int DAPDB_fast append()(DAPDB* db, char *key, long key_size, char *str, long str_size);
    Die Funktion DAPDB_append() ist gleich wie die Funktion DAPDB_fast append(), sucht aber nach vorhandenen Datensätzen, die dem eingegebenen Datensatzschlüssel entsprechen. Existiert ein solcher Datensatz, gibt die Funktion DAP_KO aus und der neue Datensatz wird nicht angefügt. Die Funktion gibt DAP_OK aus, wenn der neue Datensatz angefügt wird.
    int DAPDB_append(DAPDB* db, char *key, long key_size, char *str, long str_size));
    Die Funktion DAPDB_first bewegt den Datensatzzeiger der Tabelle db zum ersten Datensatz (definiert als der letzte hinzugefügte oder geänderte Datensatz). Die Funktion gibt bei Erfolg DAP_OK und bei Fehlschlagen DAP_KO aus. Die Syntax lautet
    int DAPDB_first(DAPDB* db);
    Die Funktion DAPDB_last bewegt den Datensatzzeiger der Tabelle db zum letzten Datensatz (definiert als der jüngste hinzugefügte oder geänderte Datensatz). Die Funktion gibt bei Erfolg DAP_OK und bei Fehlschlagen DAP_KO aus. Die Syntax lautet
    int DAPDB_last(DAPDB* db);
    Die Funktion DAPDB_prec bewegt den Datensatzzeiger der Tabelle db zum vorherigen Datensatz. Die Funktion gibt bei Erfolg DAP_OK und bei Fehlschlagen DAP_KO aus. Die Syntax lautet
    int DAPDB_prec(DAPDB* db);
    Die Funktion DAPDB_next bewegt den Datensatzzeiger der Tabelle db zum nächsten Datensatz. Die Funktion gibt bei Erfolg DAP_OK und bei Fehlschlagen DAP_KO aus. Die Syntax lautet
    int DAPDB_next(DAPDB* db);
    Die Funktion DAPDB_getkey lädt den Datensatzschlüssel des aktuellen Datensatzes (auf den der Datensatzzeiger zeigt) der mit db bezeichneten Tabelle db in die Speicheradresse Schlüssel. Die Funktion gibt bei Erfolg DAP_OK und bei Fehlschlagen DAP_KO aus. Die Syntax lautet
    int DAPDB_getkey(DAPDB* db, void *key);
    Die Funktion DAPDB_getstr lädt den Datensatzkörperstring des aktuellen Datensatzes (auf den der Datensatzzeiger zeigt) der mit db bezeichneten Tabelle db in die Speicheradresse str. Die Funktion gibt bei Erfolg DAP_OK und bei Fehlschlagen DAP_KO aus. Die Syntax lautet
    int DAPDB_getstr(DAPDB* db, void *str);
    Die Funktion DAPDB_delete löscht den aktuellen Datensatz (auf den der Datensatzzeiger zeigt) der mit db bezeichneten Tabelle db. Die Funktion gibt bei Erfolg DAP_OK und bei Fehlschlagen DAP_KO aus. Die Syntax lautet
    int DAPDB_delete(DAPDB* db);
    Die Funktion DAPDB_replace ist gleich DAPDB_append(), ersetzt aber den aktuellen Datensatz mit dem neuen. Die Syntax lautet
    int DAPDB_replace(DAPDB* db, char *key, long key_size, char *str, long str size);
    Die Funktion DAPDB_transact schließt eine Datenbanktransaktion an der mit db bezeichneten Tabelle. Wenn ein Programm, das die Funktion DAPDB Bibliothek verwendet, während der Ausführung ausfällt, wird nach der letzten erfolgreichen DAPDB_close() oder DAPDB_transact() Operation der Inhalt aller von dem Programm geöffneten Tabellen wiederhergestellt. Die Syntax lautet
    int DAPDB_transact(DAPDB* db);
    Die Funktion DAPDB_keysize gibt die Größe in Zeichen des Datensatzschlüssels des aktuellen Datensatzes der mit db bezeichneten Tabelle aus. Die Syntax lautet long DAPDB_keysize(DAPDB* db);
    Die Funktion DAPDB_strsize gibt die Größe in Zeichen des Datensatzkörperstrings des aktuellen Datensatzes der mit db bezeichneten Tabelle aus. Die Syntax lautet
    long DAPDB_strsize(DAPDB* db);
    Die Erfinder haben sich bemüht, die Beispiele in Bezug auf Struktur und Syntax der C-Sprache zu beschreiben und zu erzeugen. Für den Fachmann wird aber ersichtlich sein, dass eine beliebige Anzahl anderer Programmiersprachen und Strategien verwendet werden könnte. Zudem sind die zur Erläuterung und Veranschaulichung der Grundsätze der Erfindung verwendeten Datenstrukturen im Allgemeinen flexibel und können in vielerlei Weise implementiert werden, ebenso wie logische Operationen, die während des Programmflusses ausgeführt werden.
  • Die Erfindung wurde in beispielhafter Weise mittels Ausführungen beschrieben, die mit der Lehre der vorliegenden Erfindung leicht verständlich sind. Dies soll nicht implizieren, dass die Erfindung auf diese Ausführungen beschränkt ist. Vielmehr werden die Methoden und Vorrichtungen der vorliegenden Erfindung als überall dort nützlich gesehen, wo eine Anwendung unter Verwendung sensibler Daten in einer nicht vertrauenswürdigen Umgebung laufen muss. Die Erfindung soll nicht durch die beispielhafte Beschreibung der Offenbarung beschränkt sein, sondern vielmehr nur durch die folgenden Ansprüche.

Claims (20)

  1. Verfahren für das Verwalten sensibler Daten, welches umfasst: a) einen Schritt (401) des Anlegens einer Datei, welcher umfasst: Anlegen einer sensible Daten enthaltenden Datei (404); Berechnen einer digitalen Signatur für die Datei (408); Speichern der digitalen Signatur zusammen mit den sensiblen Daten in der Datei; und Verschlüsseln der die sensiblen Daten und die digitale Signatur enthaltenden Datei (412), um eine verschlüsselte Datei zu erzeugen; und b) einen Dateioperationsschritt (402), welcher umfasst: Ausführen einer Eingabe-Ausgabe-Operation an einer geeigneten Untermenge der verschlüsselten Datei (630) ohne die Notwendigkeit der Entschlüsselung der gesamten Datei; wobei der Dateioperationsschritt dadurch gekennzeichnet ist, dass er Folgendes umfasst: Entschlüsseln einer geeigneten Untermenge der Datei in einer in einer zuverlässigen Anwendung angesiedelten Funktion bei Ausführen einer Lese-Operation (642); Entschlüsseln einer geeigneten Untermenge der Datei in einer in einer zuverlässigen Anwendung angesiedelten Funktion bei Ausführen einer Schreib-Operation (652); Aktualisieren der digitalen Signatur der Datei unter Verwendung der entschlüsselten geeigneten Untermenge (654); Verschlüsseln der in die Datei zu schreibenden geeigneten Untermenge (424); Schreiben der verschlüsselten geeigneten Untermenge in die Datei; Verschlüsseln der digitalen Signatur (428); und Hinzufügen der verschlüsselten digitalen Signatur zu der Datei, um diese zu authentifizieren (434).
  2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Schritt des Ausführens einer Datei-Eingabe-Ausgabe-Operation an der Datei weiterhin umfasst: Eingeben einer Datenuntermenge aus einem Dateistrom (634); und Entschlüsseln der Datenuntermenge in einer lokalen Funktion (652).
  3. Verfahren nach Anspruch 2, welches weiterhin den Schritt des Aktualisierens der digitalen Signatur unter Verwendung der aus dem Datenstrom eingegebenen Datenuntermenge und einer in die Datei zu schreibenden Datenuntermenge (744) umfasst.
  4. Verfahren nach Anspruch 3, welches weiterhin die folgenden Schritte umfasst: Verschlüsseln der in die Datei zu schreibenden Datenuntermenge in einer lokalen Funktion, um eine verschlüsselte zu schreibende Datenuntermenge zu erzeugen (656); und Schreiben der verschlüsselten, in die Datei zu schreibenden Datenuntermenge (432).
  5. Verfahren nach Anspruch 3, dadurch gekennzeichnet, dass der Schritt des Ausführens der Datei-Eingabe-Ausgabe-Operation an der Datei weiterhin das Authentifizieren der Datei unter Verwendung der digitalen Signatur (754) umfasst.
  6. Verfahren nach Anspruch 4, dadurch gekennzeichnet, dass der Schritt des Ausführens der Datei-Eingabe-Ausgabe-Operation an der Datei weiterhin das Authentifizieren der Datei unter Verwendung einer Anwendersignatur (726) umfasst.
  7. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass der Schritt des Ausführens einer Datei-Eingabe-Ausgabe-Operation Folgendes umfasst: Eingeben einer Datenuntermenge (634, 636, 638) aus einer verschlüsselten, temporären Kopie der Datei (640); und Entschlüsseln der Datenuntermenge in einer lokalen Funktion, um eine aus der temporären, verschlüsselten Datei gelesene unverschlüsselte Datenuntermenge zu erzeugen (642).
  8. Verfahren nach Anspruch 7, welches weiterhin die folgenden Schritte umfasst: Aktualisieren der digitalen Signatur unter Verwendung der aus der verschlüsselten, temporären Kopie der Datei eingegebenen Datenuntermenge und einer in die Datei zu schreibenden Datenuntermenge (654); Verschlüsseln der der in die verschlüsselte, temporäre Datei zu schreibenden Datenuntermenge in einer lokalen Funktion (656); und Schreiben der in die verschlüsselte, temporäre Datei zu schreibenden Datenuntermenge (658).
  9. Verfahren nach Anspruch 8, welches weiterhin folgende Schritte umfasst: Kopieren der digitalen Signatur im Speicher in die verschlüsselte, temporäre Datei (658); und Kopieren der verschlüsselten, temporären Datei in die Datei (808); und Schließen der Datei (403, 438, 810).
  10. Verfahren nach Anspruch 8, welches weiterhin die Schritte des Authentifizierens der Datei unter Verwendung der digitalen Signatur (754) umfasst.
  11. Verfahren nach Anspruch 9, welches weiterhin die Schritte des Authentifizierens der Datei unter Verwendung einer Anwendersignatur (726) umfasst.
  12. Maschinenlesbares Medium, welches einen Code für das Veranlassen eines Computers umfasst, die Schritte des Verfahrens gemäß Anspruch 1 auszuführen, wobei eine erste Funktion den Schritt des Anlegens einer Datei und eine zweite Funktion den Dateioperationsschritt ausführt.
  13. Maschinenlesbares Medium nach Anspruch 12, dadurch gekennzeichnet, dass der Computercode weiterhin eine dritte Funktion für das Öffnen einer Datei umfasst, wobei die dritte Funktion eine Datei mit einer verschlüsselten digitalen Signatur authentifizieren kann.
  14. Maschinenlesbares Medium nach Anspruch 13, dadurch gekennzeichnet, dass die dritte Funktion weiterhin einen Code für das Anlegen einer temporären, verschlüsselten Datei und das Erzeugen eines Dateistroms daraus umfasst.
  15. Maschinenlesbares Medium nach Anspruch 14, dadurch gekennzeichnet, dass der Computercode weiterhin einen Code für das Implementieren einer digitalen Signatur unter Verwendung einer symmetrischen, invertierbaren Funktion umfasst.
  16. Maschinenlesbares Medium nach Anspruch 15, dadurch gekennzeichnet, dass der Computercode weiterhin für Authentifizierungszwecke einen Code für das Implementieren einer Anwendersignatur innerhalb der Datei umfasst.
  17. Maschinenlesbares Medium nach Anspruch 16, dadurch gekennzeichnet, dass der Computercode weiterhin eine Quellcode-Bibliothek mit Funktionen umfasst, die implementiert werden, damit Verschlüsselung, Entschlüsselung und Authentifizierung für einen Quellcode-Programmierer transparent sind.
  18. Maschinenlesbares Medium nach Anspruch 16, dadurch gekennzeichnet, dass der Computercode in dem gleichen Adressraum wie eine Anwenderanwendung ausgeführt wird.
  19. Maschinenlesbares Medium nach Anspruch 16, dadurch gekennzeichnet, dass der Computercode weiterhin eine die ersten und zweiten Funktionen verwendende Datenbank-Bibliothek umfasst.
  20. Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass: der Schritt des Anlegens einer Datei weiterhin das Speichern einer Anwendersignatur in der Datei zusammen mit den sensiblen Daten umfasst; der Schritt des Verschlüsselns der die sensiblen Daten enthaltenden Datei weiterhin die Anwendersignatur umfasst; und der Dateioperationsschritt weiterhin das Verschlüsseln der Anwendersignatur und das Hinzufügen der verschlüsselten Anwendersignatur zu der Datei zu deren Authentifizieren umfasst.
DE60204049T 2001-11-06 2002-11-05 Systeme, verfahren und einrichtungen zur sicheren datenverarbeitung Active DE60204049T8 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US993450 2001-11-06
US09/993,450 US20030088783A1 (en) 2001-11-06 2001-11-06 Systems, methods and devices for secure computing
PCT/US2002/035598 WO2003044643A2 (en) 2001-11-06 2002-11-05 Systems, methods and devices for secure computing

Publications (3)

Publication Number Publication Date
DE60204049D1 DE60204049D1 (de) 2005-06-09
DE60204049T2 true DE60204049T2 (de) 2006-01-19
DE60204049T8 DE60204049T8 (de) 2006-04-27

Family

ID=25539560

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60204049T Active DE60204049T8 (de) 2001-11-06 2002-11-05 Systeme, verfahren und einrichtungen zur sicheren datenverarbeitung

Country Status (7)

Country Link
US (1) US20030088783A1 (de)
EP (1) EP1451664B1 (de)
AT (1) ATE294973T1 (de)
AU (1) AU2002364695A1 (de)
CA (1) CA2465910C (de)
DE (1) DE60204049T8 (de)
WO (1) WO2003044643A2 (de)

Families Citing this family (63)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7260555B2 (en) 2001-12-12 2007-08-21 Guardian Data Storage, Llc Method and architecture for providing pervasive security to digital assets
US7681034B1 (en) 2001-12-12 2010-03-16 Chang-Ping Lee Method and apparatus for securing electronic data
US8006280B1 (en) 2001-12-12 2011-08-23 Hildebrand Hal S Security system for generating keys from access rules in a decentralized manner and methods therefor
US7921450B1 (en) 2001-12-12 2011-04-05 Klimenty Vainstein Security system using indirect key generation from access rules and methods therefor
US7930756B1 (en) 2001-12-12 2011-04-19 Crocker Steven Toye Multi-level cryptographic transformations for securing digital assets
US8065713B1 (en) 2001-12-12 2011-11-22 Klimenty Vainstein System and method for providing multi-location access management to secured items
US10033700B2 (en) 2001-12-12 2018-07-24 Intellectual Ventures I Llc Dynamic evaluation of access rights
US7478418B2 (en) * 2001-12-12 2009-01-13 Guardian Data Storage, Llc Guaranteed delivery of changes to security policies in a distributed system
US7565683B1 (en) 2001-12-12 2009-07-21 Weiqing Huang Method and system for implementing changes to security policies in a distributed security system
US7921288B1 (en) 2001-12-12 2011-04-05 Hildebrand Hal S System and method for providing different levels of key security for controlling access to secured items
US7178033B1 (en) 2001-12-12 2007-02-13 Pss Systems, Inc. Method and apparatus for securing digital assets
US7631184B2 (en) * 2002-05-14 2009-12-08 Nicholas Ryan System and method for imposing security on copies of secured items
US7380120B1 (en) 2001-12-12 2008-05-27 Guardian Data Storage, Llc Secured data format for access control
USRE41546E1 (en) 2001-12-12 2010-08-17 Klimenty Vainstein Method and system for managing security tiers
US7921284B1 (en) 2001-12-12 2011-04-05 Gary Mark Kinghorn Method and system for protecting electronic data in enterprise environment
US10360545B2 (en) 2001-12-12 2019-07-23 Guardian Data Storage, Llc Method and apparatus for accessing secured electronic data off-line
US7783765B2 (en) 2001-12-12 2010-08-24 Hildebrand Hal S System and method for providing distributed access control to secured documents
US7950066B1 (en) 2001-12-21 2011-05-24 Guardian Data Storage, Llc Method and system for restricting use of a clipboard application
US6898587B2 (en) * 2002-01-18 2005-05-24 Bea Systems, Inc. System and method for performing commutative operations in data access systems
US6959309B2 (en) * 2002-01-31 2005-10-25 Freescale Semiconductor, Inc. Interface between programming languages and method therefor
US8176334B2 (en) 2002-09-30 2012-05-08 Guardian Data Storage, Llc Document security system that permits external users to gain access to secured files
US8613102B2 (en) 2004-03-30 2013-12-17 Intellectual Ventures I Llc Method and system for providing document retention using cryptography
US7421579B2 (en) * 2002-06-28 2008-09-02 Microsoft Corporation Multiplexing a secure counter to implement second level secure counters
US7512810B1 (en) 2002-09-11 2009-03-31 Guardian Data Storage Llc Method and system for protecting encrypted files transmitted over a network
US7836310B1 (en) 2002-11-01 2010-11-16 Yevgeniy Gutnik Security system that uses indirect password-based encryption
US7330863B2 (en) * 2002-11-28 2008-02-12 International Business Machines Corporation Method and systems for hyperlinking files
US7890990B1 (en) 2002-12-20 2011-02-15 Klimenty Vainstein Security system with staging capabilities
US7401105B2 (en) * 2003-10-02 2008-07-15 International Business Machines Corporation Method, system, and program product for retrieving file processing software
US7603553B1 (en) * 2003-04-25 2009-10-13 Netapp, Inc. System and method to make file handles opaque to clients
US9678967B2 (en) 2003-05-22 2017-06-13 Callahan Cellular L.L.C. Information source agent systems and methods for distributed data storage and management using content signatures
US8707034B1 (en) 2003-05-30 2014-04-22 Intellectual Ventures I Llc Method and system for using remote headers to secure electronic files
US7703140B2 (en) 2003-09-30 2010-04-20 Guardian Data Storage, Llc Method and system for securing digital assets using process-driven security policies
US8127366B2 (en) 2003-09-30 2012-02-28 Guardian Data Storage, Llc Method and apparatus for transitioning between states of security policies used to secure electronic documents
KR100549504B1 (ko) * 2003-10-10 2006-02-03 한국전자통신연구원 서명 암호화를 이용한 웹서비스 보안에서의 ｓｏａｐ메시지 생성 및 검증 방법
KR101006322B1 (ko) * 2004-04-08 2011-01-06 인터내셔널 비지네스 머신즈 코포레이션 파일 처리 방법 및 파일 인증 방법 장치와 컴퓨터 판독가능한 매체 및 시스템
US20060004846A1 (en) * 2004-06-16 2006-01-05 Bmc Software, Inc. Low-overhead relational database backup and restore operations
US7707427B1 (en) 2004-07-19 2010-04-27 Michael Frederick Kenrich Multi-level file digests
GB0421774D0 (en) * 2004-09-30 2004-11-03 Ttp Communications Ltd Source code protection
AU2006200628B2 (en) * 2005-02-17 2011-07-28 Nortonlifelock Inc Post-signing modifications of software
US8356295B2 (en) * 2005-02-17 2013-01-15 Symantec Corporation Post-signing modification of software
US8074069B2 (en) * 2005-02-24 2011-12-06 International Business Machines Corporation Reading a locked windows NFTS EFS encrypted computer file
US8484476B2 (en) * 2005-05-20 2013-07-09 Rovi Technologies Corporation Computer-implemented method and system for embedding and authenticating ancillary information in digitally signed content
US8397072B2 (en) * 2005-05-20 2013-03-12 Rovi Solutions Corporation Computer-implemented method and system for embedding ancillary information into the header of a digitally signed executable
US7752676B2 (en) * 2006-04-18 2010-07-06 International Business Machines Corporation Encryption of data in storage systems
US7904732B2 (en) * 2006-09-27 2011-03-08 Rocket Software, Inc. Encrypting and decrypting database records
WO2008147400A1 (en) * 2006-11-30 2008-12-04 Brown University Authentication for operations over an outsourced file system stored by an untrusted unit
US20080189767A1 (en) * 2007-02-01 2008-08-07 Microsoft Corporation Accessing file resources outside a security boundary
CA2701776A1 (en) * 2007-07-31 2009-02-05 Macrovision Corporation A computer-implemented method and system to enable out of band tracking for digital distribution
US9275401B2 (en) * 2007-09-06 2016-03-01 Adobe Systems Incorporated Tamper resistant video rendering
US8417954B1 (en) * 2009-02-11 2013-04-09 Hewlett-Packard Development Company, L.P. Installation image including digital signature
US9218349B2 (en) * 2009-07-27 2015-12-22 International Business Machines Corporation Method and system for transformation of logical data objects for storage
US8788842B2 (en) 2010-04-07 2014-07-22 Apple Inc. System and method for content protection based on a combination of a user PIN and a device specific identifier
US8589680B2 (en) 2010-04-07 2013-11-19 Apple Inc. System and method for synchronizing encrypted data on a device having file-level content protection
US8510552B2 (en) 2010-04-07 2013-08-13 Apple Inc. System and method for file-level data protection
EP2378766A1 (de) * 2010-04-16 2011-10-19 Liberty Global Europe Holding B.V. Verfahren und System zur komprimierung eines elektronischen Programmführers
US8949688B2 (en) * 2011-04-01 2015-02-03 Cleversafe, Inc. Updating error recovery information in a dispersed storage network
US10298684B2 (en) 2011-04-01 2019-05-21 International Business Machines Corporation Adaptive replication of dispersed data to improve data access performance
US11418580B2 (en) 2011-04-01 2022-08-16 Pure Storage, Inc. Selective generation of secure signatures in a distributed storage network
US9424271B2 (en) * 2012-08-30 2016-08-23 International Business Machines Corporation Atomic incremental load for map-reduce systems on append-only file systems
US9716700B2 (en) * 2015-02-19 2017-07-25 International Business Machines Corporation Code analysis for providing data privacy in ETL systems
CN109104279B (zh) * 2018-08-31 2021-11-16 国网河北省电力有限公司沧州供电分公司 一种电力数据的加密方法、系统及终端设备
US11429794B2 (en) 2018-09-06 2022-08-30 Daniel L. Coffing System for providing dialogue guidance
EP3850781A4 (de) * 2018-09-14 2022-05-04 Coffing, Daniel L. Faktenverwaltungssystem

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE68927705T2 (de) * 1989-06-13 1997-07-17 Ibm Verfahren zum Entfernen unbestätigter Änderungen an gespeicherten Daten durch ein Datenbankverwaltungssystem
US4981370A (en) * 1990-01-29 1991-01-01 Dziewit Halina S Document authentication apparatus
US5721777A (en) * 1994-12-29 1998-02-24 Lucent Technologies Inc. Escrow key management system for accessing encrypted data with portable cryptographic modules
US5748738A (en) * 1995-01-17 1998-05-05 Document Authentication Systems, Inc. System and method for electronic transmission, storage and retrieval of authenticated documents
US6070198A (en) * 1995-10-19 2000-05-30 Hewlett-Packard Company Encryption with a streams-based protocol stack
US5999622A (en) * 1995-11-22 1999-12-07 Microsoft Corporation Method and apparatus for protecting widely distributed digital information
US5953419A (en) * 1996-05-06 1999-09-14 Symantec Corporation Cryptographic file labeling system for supporting secured access by multiple users
US6021491A (en) * 1996-11-27 2000-02-01 Sun Microsystems, Inc. Digital signatures for data streams and data archives
US5892904A (en) * 1996-12-06 1999-04-06 Microsoft Corporation Code certification for network transmission
US6154843A (en) * 1997-03-21 2000-11-28 Microsoft Corporation Secure remote access computing system
US6249866B1 (en) * 1997-09-16 2001-06-19 Microsoft Corporation Encrypting file system and method
US5982892A (en) * 1997-12-22 1999-11-09 Hicks; Christian Bielefeldt System and method for remote authorization for unlocking electronic data
US6148336A (en) * 1998-03-13 2000-11-14 Deterministic Networks, Inc. Ordering of multiple plugin applications using extensible layered service provider with network traffic filtering
US6185681B1 (en) * 1998-05-07 2001-02-06 Stephen Zizzi Method of transparent encryption and decryption for an electronic document management system
US6446109B2 (en) * 1998-06-29 2002-09-03 Sun Microsystems, Inc. Application computing environment
US20020062451A1 (en) * 1998-09-01 2002-05-23 Scheidt Edward M. System and method of providing communication security
US6295639B1 (en) * 1998-09-01 2001-09-25 Aidministrator Nederland B.V. Securely accessing a file system of a remote server computer
US20010037454A1 (en) * 2000-05-01 2001-11-01 Botti John T. Computer networked system and method of digital file management and authentication
JP2002540540A (ja) * 1999-03-31 2002-11-26 ブリティッシュ・テレコミュニケーションズ・パブリック・リミテッド・カンパニー ファイルの保全性を保証するサーバコンピュータ
IL140267A0 (en) * 2000-12-13 2003-09-17 Milsys Ltd Dual processor trusted computing environment

Also Published As

Publication number Publication date
CA2465910A1 (en) 2003-05-30
EP1451664B1 (de) 2005-05-04
AU2002364695A1 (en) 2003-06-10
AU2002364695A8 (en) 2003-06-10
DE60204049T8 (de) 2006-04-27
CA2465910C (en) 2009-10-06
WO2003044643A2 (en) 2003-05-30
ATE294973T1 (de) 2005-05-15
DE60204049D1 (de) 2005-06-09
WO2003044643A3 (en) 2003-11-20
US20030088783A1 (en) 2003-05-08
EP1451664A2 (de) 2004-09-01

Similar Documents

Publication Publication Date Title
DE60204049T2 (de) Systeme, verfahren und einrichtungen zur sicheren datenverarbeitung
DE69431944T3 (de) Verfahren zum effizienten Aktualisieren des Hashwertes einer Datei
DE10084964B3 (de) Verfahren zum sicheren Speichern, Übertragen und Wiedergewinnen inhaltsadresssierbarer Informationen
US7426752B2 (en) System and method for order-preserving encryption for numeric data
Agrawal et al. Order preserving encryption for numeric data
US7721345B2 (en) Data security system and method
DE102013203126B4 (de) System, Verfahren und Programmprodukt zum transparenten Zugreifen auf verschlüsselte nicht-relationale Daten in Echtzeit
DE69815599T2 (de) Verfahren und Vorrichtung zum Schutz von Anwendungsdaten in sicheren Speicherbereichen
US8639947B2 (en) Structure preserving database encryption method and system
US7669051B2 (en) Data security system and method with multiple independent levels of security
US9311499B2 (en) Data security system and with territorial, geographic and triggering event protocol
DE69725833T2 (de) Gesicherte zweiteilige Benutzer-Authentifizierung in einem Rechnernetz
DE202018002074U1 (de) System zur sicheren Speicherung von elektronischem Material
WO2020112525A1 (en) Accountably redactable data structure
US11403414B2 (en) Method and system for secure storage of digital data
DE112020005429T5 (de) Zufallsknotenauswahl für zulassungsbeschränkte Blockchain
DE112021002053T5 (de) Verrauschte Transaktion zum Schutz von Daten
DE112011103580T5 (de) Verfahren, sichere Einheit, System und Computerprogrammprodukt für das sichere Verwalten des Benutzerzugriffs auf ein Dateisystem
DE112022000906T5 (de) Trennen von blockchain-daten
EP2491513B1 (de) Verfahren und system zum bereitstellen von edrm-geschützten datenobjekten
EP0947072A1 (de) Verfahren zur elektronisch gesicherten speicherung von daten in einer datenbank
CH712679B1 (de) Verfahren zur Maskierung und eindeutigen Signierung von Datenbank-Quellcodes.
Hardjono Applications of cryptography for the security of database and distributed database systems
Rjaibi Holistic Database Encryption.
Koka An Approach for Securely Sharing Data in an Encrypted Database

Legal Events

Date Code Title Description
8364 No opposition during term of opposition