DE10041514A1 - Verfahren zum Speichern vertraulicher Daten durch partielle Verschlüsselung - Google Patents

Abstract

Ein Verfahren zur Speicherung vertraulicher Daten auf Rechnern wird beschrieben. Das Verfahren ermöglicht die Speicherung von Daten, derart, daß niemand außer dem Anwender selbst die Daten lesen und auswerten kann. Das Verfahren ist dadurch gekennzeichnet, daß gewisse Dateninhalte, die für Berechnungen durch Anwendungsprogramme auf der Seite des speichernden Rechners benötigt werden, unverschlüsselt gespeichert werden. Die notwendigen Ver- und Entschlüsselungen werden so durchgeführt, daß nur der Anwender im Besitz aller notwendigen Schlüssel ist. Insbesondere muß zu keinem Zeitpunkt eine Schlüsselverhandlung oder ein Schlüsselaustausch durchgeführt werden.

Description

Viele Anwendungen in der Informationstechnologie erfordern das Speichern von vertraulichen Daten auf einem zentralen Rechner, beispielsweise Kunden­ daten, Buchführungsdaten oder Gehaltslisten.

In vielen Anwendungsfällen ist die Speicherung solcher Daten auf Rechnern, die von fremden Personen oder Organisationen betrieben werden, zwar tech­ nisch, organisatorisch oder wirtschaftlich sinnvoll, aber bereits rein aus Gründen des Datenschutzes bedenklich.

Eine naheliegende Lösung dieses Problems wäre die verschlüsselte Speiche­ rung solcher Daten. Jedoch insbesondere wenn der Betreiber des zentralen Rechners neben der bloßen Speicherung der Daten auch eine Verarbeitung dieser Daten anbieten will, ergeben sich große Probleme, denn etwa Berech­ nungen mit verschlüsselten Daten ergeben entschlüsselt keine mathematisch korrekten Ergebnisse.

Eine Entschlüsselung der Daten vor der Verarbeitung würde das Vertrauen des Anwenders in den Betreiber voraussetzen, da der Betreiber im Rahmen der Verarbeitung vollständigen Zugriff auf die vertraulichen Anwenderdaten hat oder sich ohne Kenntnis des Anwenders verschaffen kann.

Die bloße Speicherung der Daten seitens des Betreibers und vollständige Ver­ arbeitung der Daten auf Anwenderseite stellt keine technisch sinnvolle Lösung dar.

Man versucht typischerweise, Anwendungen so zu entwerfen, daß recheninten­ sive Aufgaben auf Betreiberseite (Serverseite) erledigt werden und zum An­ wender (Client) vorverarbeitete Ergebnisse versandt werden. Der Client visuali­ siert die Daten, zumeist in einer graphischen Benutzeroberfläche und führt we­ niger aufwendige Berechnungen, beispielsweise Eingabeprüfungen, durch.

Durch Verteilung der Datenverarbeitung auf Server und Clients lassen sich viele typische Anwendungen effizienter und performanter gestalten. Man spricht dann von einer verteilten Anwendung. Die zunehmende Verbreitung von techni­ schen Standards für verteilte Anwendungen, zum Beispiel CORBA (vgl. http://www.omg.org/technology/documents/formal/corba2chps.htm), läßt an­ nehmen, daß verteilte Anwendungen in Zukunft eine zentrale Rolle in der In­ formationstechnologie spielen werden.

Im folgenden soll unter Anwender die Person oder Institution verstanden wer­ den, die rechtmäßiger "Eigentümer" der zu speichernden Daten ist, die Spei­ cherung der Daten initiiert und gespeicherte Daten abruft, ändert und auswertet. Der Anwender arbeitet an einem beliebigen Datenendgerät, das im folgenden Client genannt wird. Ein Client (13) kann beispielsweise ein Personal Compu­ ter, ein Organizer oder ein entsprechend ausgestattetes Mobiltelefon sein.

Der Betreiber sei die Person oder Institution, die einen zentralen Rechner be­ treibt, der im folgenden Server genannt wird. Auf dem Server (11) werden die Daten des Anwenders gespeichert. Der Server selbst kann physisch wiederum aus mehreren Rechnern bestehen. Im allgemeinen bietet der Betreiber dem Anwender auch Zugriff auf Anwendungsprogramme, die die gespeicherten An­ wenderdaten verarbeiten.

Client und Server kommunizieren miteinander über ein öffentliches oder priva­ tes Netzwerk (12).

Anwender und Betreiber können in Sonderfällen dieselbe Person oder Instituti­ on sein, im allgemeinen handelt es sich aber um verschiedene, voneinander unabhängige Personen oder Institutionen. Im Normalfall besteht zwischen An­ wender und Betreiber kein Vertrauensverhältnis bezüglich des Datenschutzes. Als illustrierendes Beispiel sei als Betreiber ein Dienstanbieter genannt, der sei­ nen Kunden (Anwender) die Nutzung einer Adressdatenbank anbietet. Die An­ wender können die Adressdatenbank über ein öffentliches Netzwerk (Internet) nutzen. Der Betreiber vermietet die Nutzung der Adressdatenbank und die Nut­ zung von Softwarefunktionen wie beispielsweise Erstellung von Adresslisten, Rundschreiben oder Statistiken. Allein aus Gründen des Datenschutzes darf der Betreiber keinen Zugriff auf die Anwenderdaten haben, die sich aber phy­ sisch in seinem Zugriffsbereich befinden.

Im folgenden sei encrypt die Verschlüsselung nach einem bestimmten Krypto­ system mit einem bestimmten Schlüssel key. Die zu encrypt inverse Operation sei decrypt, wobei stets gilt:

decrypt (encrypt (X)) = X

X sei ein Wort über dem Klartextalphabet, das einen Dateninhalt aus der Ge­ samtheit der Anwenderdaten darstellt. Der verwendete Schlüssel für decrypt sei ebenfalls key. Dies ist eine vereinfachende Betrachtung, da viele gängige kryptologische Verfahren (asymmetrische Verfahren) ein Schlüsselpaar beste­ hend aus einem öffentlichen und einem privaten Schlüssel verwenden. Den­ noch wird im folgenden aus Vereinfachungsgründen immer nur von einem Schlüssel key gesprochen.

Zur Verschlüsselung im Rahmen der Erfindung kann ein beliebiges kryptologi­ sches Verfahren mit beliebigem, allein vom Anwender zu bestimmenden Schlüssel key verwendet werden, solange es der Forderung genügt, daß zu beliebigen Zeitpunkten t1 und t2 gilt:

encrypt_t1(X) = encrypt₁₂(X)

wobei X wieder ein beliebiges Wort aus dem Klartextalphabet ist. Diese Ein­ deutigkeit muß gefordert werden, da sonst Vergleiche von Dateninhalten und Aggregationen der Anwenderdaten falsche Ergebnisse erzeugen würden.

Die gestellte Aufgabe lautet nun, die Anwenderdaten in einer Art und Weise zu speichern, daß sie weder für den Betreiber noch für Dritte interpretierbar sind, aber dennoch ein Anwendungsprogramm notwendige Berechnungen und Ag­ gregationen ausführen kann. Unter interpretierbar wird im folgenden verstan­ den, daß zwar gewisse Informationen über die Gesamtheit der Daten gewon­ nen werden können - und zwar durch Auswerten der unverschlüsselten Teile - aber diese Informationen nahezu wertlos sind, da sie nicht zugeordnet werden können.

Als illustrierendes Beispiel sei ein Datensatz einer Personaldatenbank genannt: zwar sind die Gehälter selbst unverschlüsselt gespeichert und damit für Betrei­ ber oder Dritte direkt lesbar, z. B. Gehalt 125.000 DM, aber es besteht keine Möglichkeit, die Gehälter den Personen zuzuordnen, da deren Namen ver­ schlüsselt gespeichert sind. Es ist also insbesondere nicht möglich herauszu­ finden, welches Gehalt Herr Müller hat, da dessen Name verschlüsselt gespei­ chert ist.

Die im folgenden beschriebene Erfindung stellt ein Verfahren dar, mit dem An­ wenderdaten teilweise verschlüsselt auf einem zentralen Rechner gespeichert werden können, so daß durch Software-Anwendungen notwendige Berechnun­ gen durchgeführt werden können, aber ohne daß der Betreiber die Daten ohne Kenntnis oder gegen den Willen des Anwenders auswerten kann.

Die Aufgabe wird dadurch gelöst, daß ein durch Anforderungen der jeweiligen Anwendung definierter Teil der Anwenderdaten verschlüsselt gespeichert wird. Vorzugsweise ist dieser Teil so gewählt, daß die unverschlüsselten Daten keine verwertbare Information für den Betreiber darstellen. Jede Ver- als auch Ent­ schlüsselung wird vom Anwenderrechner vorgenommen, insbesondere muß der Anwender Zugriff auf seinen Schlüssel key haben. Nur diejenigen Daten, die von der Anwendung auf Betreiberseite für Berechnungen verwendet wer­ den, bleiben unverschlüsselt. Die unverschlüsselten, im allgemeinen numeri­ schen Daten können direkt für Berechnungen genutzt werden.

Weitere vorteilhafte Ausgestaltungen des erfindungsgemäßen Verfahrens erge­ ben sich aus den abhängigen Ansprüchen.

Es zeigen

Fig. 1 zeigt den Rechner des Betreibers (Server), den Anwenderrechner (Cli­ ent) und das Kommunikationsnetzwerk, über das beide Systeme kommunizie­ ren.

Fig. 2 zeigt die Verschlüsselung und Speicherung eines Dateninhaltes im zeitli­ chen Ablauf

Fig. 3 zeigt das Lesen und Entschlüsseln eines Dateninhaltes im zeitlichen Ab­ lauf

Fig. 4 zeigt die Eingabemaske für einen Adressdatensatz

Fig. 5 zeigt die interne Repräsentation des Adressdatensatzes aus Fig. 4

Fig. 6 zeigt die Tabelle, aus der hervorgeht, welche Dateninhalte zu verschlüs­ seln sind

Fig. 7 zeigt die interne Repräsentation des Adressdatensatzes aus Fig. 4, wo­ bei die zu verschlüsselnden Dateninhalte verschlüsselt sind

Fig. 8 zeigt den Datensatz aus Fig. 4, zusammen mit anderen Datensätzen in der Datenbank gespeichert

Fig. 9 zeigt den Ablauf einer Datenspeicherung auf dem Betreiberrechner

Fig. 10 zeigt den Ablauf einer Datenabfrage vom Betreiberrechner

Fig. 11 zeigt die Maske zur Abfrage von Mitarbeitergehältern

Fig. 12 zeigt interne Repräsentation der Abfrage aus Fig. 11

Fig. 13 zeigt interne Repräsentation der Abfrage aus Fig. 11, wobei die zu ver­ schlüsselnden Dateninhalte verschlüsselt sind

Fig. 14 zeigt die interne Ergebnisrepräsentation der Abfrage aus Fig. 11

Fig. 15 zeigt die vom Anwenderrechner visualisierte Ergebnisdarstellung der Abfrage aus Fig. 11

Ausführungsbeispiele der Erfindung werden nachfolgend anhand der Zeichnun­ gen beschrieben.

Die nachfolgende Beschreibung von Ausführungsbeispielen betrifft die Speiche­ rung und den Zugriff auf einen exemplarisch gewählten Adressdatensatz. Es versteht sich, daß die Erfindung auf alle Arten von zu speichernden Daten und Anwendungsklassen anwendbar ist.

Es wird davon ausgegangen, daß die Daten in einer relationalen Datenbank gespeichert werden. Selbstverständlich ist die Erfindung gleichermaßen bei al­ ternativen Speicherungsformen (etwa nicht-relationale Datenbanksysteme oder Dateisysteme) anwendbar. Die Erfindung ist ebenso anwendbar, wenn die An­ wenderdaten nicht in einer, sondern verteilt in einer Vielzahl von Datenbanken oder einer Kombination aus Datenbanken und alternativen Speicherungsformen gespeichert werden.

Die in den Beispielen verwendete Notation zur internen Repräsentation von Dateninhalten ist dem XML-Format angelehnt (vgl. Fig. 4), stellt jedoch keine vollständige Beschreibung der Daten nach dem XML-Standard (vgl. http://www.w3.org/TR/REC-xml) dar. Die Erfindung ist gleichermaßen bei alter­ nativen internen Datenstrukturen und -repräsentationen anwendbar.

Die nachfolgende Beschreibung von Ausführungsbeispielen bezieht sich auf einen Anwender. Es versteht sich, daß die Erfindung gleichermaßen anwendbar ist, wenn eine Vielzahl von Anwendern gleichzeitig ihre Daten auf einem zen­ tralen Rechner ablegen.

Ebenso ist die Erfindung anwendbar, wenn "Anwender" in der Bedeutung meh­ rerer physischer Personen oder Institutionen verwendet wird, insbesondere wenn der Zugriff auf die Daten dann durch zusätzliche Zugriffskontrolle, Benut­ zerrechte oder Rollen für Einzelne eingeschränkt ist.

Die Erfindung erfordert, daß bei der Definition bzw. Erstellung der Datenbank einmalig festgelegt wird, welche Felder zu verschlüsseln sind und welche un­ verschlüsselt bleiben müssen. Die Anzahl der unverschlüsselten Felder sollte sich auf das Minimum der Felder beschränken, die für Berechnungen auf Be­ treiberseite, also auf dem Server (11) benötigt werden. Eine mögliche Reprä­ sentation der Information, welche Felder zu verschlüsseln sind, zeigt Fig. 6. Hierbei stehen alle einzelnen Dateninhalte (Attribute) in Spalte 61, und die In­ formation, ob diese zu verschlüsseln sind, in Spalte 62. Der Zeile 63 kann bei­ spielsweise entnommen werden, daß das Feld Vorname zu verschlüsseln ist.

In alternativen Ausführungsbeispielen sind auch andere Repräsentationen der Information, welche Felder zu verschlüsseln sind, denkbar. Insbesondere könnte diese Information auch direkt in die interne Repräsentation der Datenin­ halte (in Fig. 5 gezeigt) eingeflochten sein.

Weiterhin muß der Anwender einen Schlüssel (bzw. das Schlüsselpaar) key wählen bzw. generieren. Das Vorgehen hierzu ergibt sich durch das verwen­ dete Verschlüsselungsverfahren. Der bzw. die Schlüssel key müssen sicher gespeichert werden, beispielsweise auf einer Chipkarte.

In alternativen Ausführungsbeispielen ist auch die Auswahl des verwendeten Verschlüsselungsverfahrens durch den Anwender denkbar.

Fig. 2 zeigt die Speicherung eines Dateninhaltes auf dem Server. Der Datenin­ halt 21, der auf dem Client im Klartext vorliegt, wird dort verschlüsselt. Der ver­ schlüsselte Dateninhalt 22 wird über eine Netzwerkverbindung 23 zum Server übertragen. Der Server speichert den empfangenen verschlüsselten Dateninhalt 24 in der Datenbank 25.

Fig. 9 stellt diesen Vorgang noch detaillierter dar. Der Anwender erfaßt einen Datensatz (gezeigt in Fig. 4) in einer graphischen Benutzeroberfläche (91). In Zeile 41 wird beispielsweise der Vorname, in Zeile 42 das Gehalt erfaßt. Der Client konvertiert die erfaßten Daten (92) in ein internes Format, das in Fig. 5 dargestellt ist. In Zeile 51 steht beispielsweise der Vorname, in Zeile 52 das Gehalt, zunächst beide unverschlüsselt im Klartext. Im Schritt 93 wird anhand der Tabelle Fig. 6 für jeden einzelnen Dateninhalt geprüft, ob er zu verschlüs­ seln ist. Laut Zeile 63 muß beispielsweise der Vorname verschlüsselt werden, während laut Zeile 64 das Gehalt unverschlüsselt bleibt. In Schritt 94 werden nun alle zu verschlüsselnden Datenfelder vom Client mit dem Schlüssel key verschlüsselt. Zur Verschlüsselung wird ein gängiges als sicher erachtetes Verfahren mit ausreichender Schlüssellänge verwendet (vgl. Bruce Schneier: "Angewandte Kryptographie", Addison-Wesley-Verlag, 1996). Die interne Da­ tenrepräsentation entspricht nun der in Fig. 7 gezeigten. Zeile 71 zeigt bei­ spielsweise den verschlüsselten Vornamen, während das in Zeile 72 darge­ stellte Gehalt unverschlüsselt ist. Die teilweise verschlüsselten, in Fig. 7 darge­ stellten Daten werden, wie bereits anhand von Fig. 2 erläutert, in Schritt 95 über die Netzwerkverbindung 23 vom Client 13 an den Server 11 übertragen. Der Server 11 empfängt die teilweise verschlüsselten Daten (96) und speichert sie in Schritt 97 in der Datenbank 25. Einen Auszug aus dem Datenbestand der Serverdatenbank zeigt Fig. 8. Man erkennt beispielsweise in Spalte 81 die ver­ schlüsselten Vornamen, in Spalte 82 die Gehälter im Klartext. Zeile 83 reprä­ sentiert den Datensatz aus Fig. 4 bzw. Fig. 7.

Man beachte, daß zu keinem Zeitpunkt eine Schlüsselverhandlung oder ein Schlüsselaustausch stattgefunden hat und daß kein Schlüssel den Anwender­ rechner verläßt.

Die Abfrage eines Dateninhaltes vom Server durch den Client wird in Fig. 3 be­ schrieben. Hier liest der Server den veschlüsselten Dateninhalt 32 aus der Da­ tenbank 31 und überträgt ihn über die Netzwerkverbindung 33 zum Client. Der Client entschlüsselt den empfangenen verschlüsselten Dateninhalt 34 und er­ hält so den Dateninhalt im Klartext 35.

Dieser Vorgang wird in Fig. 10 noch detaillierter erläutert. Der Anwender stellt in einer graphischen Benutzeroberfläche die in Fig. 11 gezeigte Anfrage nach dem Gehalt des Mitarbeiters Hans Müller (101). Der Client konvertiert die An­ frage in Schritt 102 in das interne Format gezeigt in Fig. 12. Nun wird anhand analog dem oben beschriebenen Ausführungsbeispiel anhand der Tabelle in Fig. 6 für jeden einzelnen Dateninhalt geprüft, ob er zu verschlüsseln ist (103). Die zu verschlüsselnden Datenfelder werden im Schritt 104 vom Client mit dem Schlüssel key verschlüsselt. Das Verfahren zur Verschlüsselung wurde oben bereits beschrieben und wird analog verwendet. Die interne Datenrepräsentati­ on der Anfrage entspricht nun der in Fig. 13 gezeigten, enthält jedoch aber - in der Abbildung nicht gezeigt - noch Informationen darüber, welches Daten­ bankfeld (in diesem Fall das Gehalt) des Datensatzes mit den übergebenen Parametern gelesen werden soll. Die in Fig. 13 dargestellten Daten werden zusammen mit dieser zusätzlichen Information, wie bereits anhand von Fig. 2 erläutert, über die Netzwerkverbindung 23 vom Client 13 an den Server 11 übertragen (105). Der Server 11 empfängt die Daten (106). Im Schritt 107 führt der Server die Anfrage aus. Dazu können zusätzliche Verarbeitungsschritte oder Transformationen notwendig sein. Die Abfrage bezieht sich auf Zeile 83 der Datenbank Fig. 8 und fragt den Eintrag in Spalte 82 ab. Dieses Ergebnis der Abfrage (in Fig. 14 gezeigt) wird im Schritt 108 an den Client zurückgesen­ det. Für jedes einzelne Datenfeld der in 109 vom Client empfangenen Daten (in Fig. 14 gezeigt) wird anhand der Tabelle in Fig. 6 geprüft, ob das jeweilige Feld zu entschlüsseln ist. Hier ergibt die Zeile 64, daß der Dateninhalt Gehalt nicht entschlüsselt werden muß. In diesem Beispiel entfällt damit der Schritt 111; üb­ licherweise würden hier die verschlüsselt übertragenen Dateninhalte entschlüs­ selt. Im letzten Schritt 112 werden nun die Daten in Fig. 14 vom Client visuali­ siert dargestellt wie in Fig. 15 gezeigt.

Die hier beschriebene Erfindung schafft eine Basis zum Speichern und Verar­ beiten vertraulicher Informationen auf zentralen Rechnern, ohne daß der Be­ treiber dieses Rechners für den Anwender vertrauenswürdig sein muß. Als Speicherungsort kommen also auch öffentlich zugängliche Rechner in Frage. Die Erfindung ist somit Basis für eine große Anzahl von Cli­ ent/Serveranwendungen und verteilten Anwendungen.

Claims (10)

1. Verfahren zur Speicherung und Bearbeitung von Anwenderdaten auf einem zentralen Rechner, bei dem:
die Daten teilweise verschlüsselt und teilweise unverschlüsselt gespei­ chert sind,
Bearbeitungsschritte vom Betreiber vorgenommen werden
die verschlüsselten Daten für die vom Betreiber vorgenommenen Bear­ beitungsschritte nicht entschlüsselt werden, und
die Daten zumindest insoweit unverschlüsselt gespeichert sind, als dies zum Durchführen der Bearbeitungsschritte durch den Betreiber erforder­ lich ist.

2. Verfahren nach Anspruch 1, bei dem ferner: die Daten zumindest in einem solchem Umfang verschlüsselt gespei­ chert sind, daß aus der Gesamtheit der verschlüsselt und unverschlüs­ selt gespeicherten Daten durch den Betreiber keine vertraulichen Infor­ mationen ableitbar sind.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß der Be­ treiber zu keinem Zeitpunkt einen Schlüssel zum Verschlüsseln oder Ent­ schlüsseln der Daten erhält.

4. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß die Ver- und Entschlüsselung der Anwenderdaten ausschließlich auf einem auf den zentralen Rechner zugreifenden Anwenderrechner durchgeführt wird.

5. Verfahren nach Anspruch 4, dadurch gekennzeichnet, daß die Verfahrens­ schritte zum Ver- und Entschlüsseln durch ein vom Betreiber in Form von Software oder Hardware zur Verfügung gestelltes Computerprogrammpro­ dukt durchgeführt werden.

6. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß der Anwender über eine definierte technische Schnittstelle ein eigenes Ver­ fahren zur Verschlüsselung und Entschlüsselung einsetzen kann.

7. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß verschlüsselte Daten seitens des Betreibers (im Sinne des Klartextes) kor­ rekt sortiert werden können durch Erweiterung der verschlüsselten Daten um eine Information zu deren Sortierreihenfolge.

8. Verfahren nach einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, daß die Ver- und Entschlüsselung der Anwenderdaten weder auf dem Anwen­ derrechner, noch auf dem Betreiberrechner, sondern auf einem dritten Rechner durchgeführt wird.

9. Vorrichtung mit mindestens einem zentralen Rechner zur Ausführung eines Verfahrens nach einem der Ansprüche 1 bis 8.

10. Computerprogrammprodukt zur Ausführung durch mindestens einen zen­ tralen Rechner, wobei das Computerprogrammprodukt Befehle aufweist, die mindestens einen zentralen Rechner zur Durchführung eines Verfahrens nach einem der Ansprüche 1 bis 8 veranlassen.