DE19925910A1 - Verfahren zum Be- oder Verarbeiten von Daten - Google Patents

Abstract

Verfahren zum Be- oder Verarbeiten von Daten, die in wenigstens einer Datenbank in zumindest teilweise verschlüsselter Form gespeichert werden, wobei die Daten von einem mit der Datenbank über eine Kommunikationsverbindung kommunizierenden Anwender ausgelesen und gegebenenfalls neue Daten gespeichert werden können, wobei die Daten ausschließlich beim Anwender unter Verwendung eines in einer zentralen weiteren Datenbank gespeicherten, ausschließlich an den autorisierten Anwender übermittelbaren Schlüssels entschlüsselt und/oder verschlüsselt werden.

Description

Die Erfindung betrifft ein Verfahren zum Be- oder Verarbeiten von Daten, die in wenigstens einer Datenbank in zumindest teilweise verschlüsselter Form gespeichert werden, wobei die Daten von einem mit der Datenbank über eine Kommunikations­ verbindung kommunizierenden Anwender ausgelesen und gegebe­ nenfalls neue Daten gespeichert werden können.

In einer Datenbank zu speichernde Daten setzen sich immer häufiger aus unkritischen Datenteilen, deren Inhalt keiner besonderen Geheimhaltung bedarf, und kritischen Daten, die wenn überhaupt nur einem begrenzten Anwenderbereich zugäng­ lich sein dürfen, zusammen. Um diese kritischen Daten zu­ griffsicher zu hinterlegen ist es bekannt, diese in ver­ schlüsselter Form zu speichern. Hierzu dienen kryptographi­ sche Verfahren (z. B. DES, RAS, IDEA), welche sich zur Ver­ schlüsselung der Daten symmetrischer oder asymmetrischer Schlüssel bedienen. Bei bisher bekannten Verfahren zur siche­ ren Kommunikation erfolgt eine Verschlüsselung der Daten wäh­ rend der Datenübertragung (Leitungsverschlüsselung) zwischen dem Client und dem Server, die Daten liegen dann an der zen­ tralen Stelle wieder in unverschlüsselter Form vor und werden meistens unverschlüsselt in einer zentralen Datenbank gespei­ chert. Bei diesen Verfahren besteht eine Sicherheitslücke, da jeder, der Administratorrechte an der zentralen Datenbank hat, alle Daten lesen kann. Eine Lösung dieses Problems ist bekannt, die Daten werden auf dem zentralen Server verschlüs­ selt und in verschlüsselter Form in der Datenbank abgelegt. Auch hier besteht noch eine Sicherheitslücke bei Angriffen, die an der zentralen Stelle stattfinden: die Daten können, da sie im zu einem Zeitpunkt im Klartext auf dem Server vorlie­ gen, vor oder während der Verschlüsselung kopiert werden. Ein Verfahren der eingangs genannten Art ist beispielsweise im medizinischen oder ärztlichen Bereich einsetzbar, im Rahmen dessen beispielsweise mehrere Ärzte als Anwender Zugriff auf die in einer zentralen Datenbank gespeicherten Daten von Pa­ tienten haben.

Der Erfindung liegt damit das Problem zugrunde, ein Verfahren anzugeben, welches eine sichere Datenübertragung in einem solchen System, bei dem auf eine zentrale Datenbank mehrere Anwender Zugriff haben, ermöglicht wird.

Zur Lösung dieses Problems ist bei einem Verfahren der ein­ gangs genannten Art erfindungsgemäß vorgesehen, dass die Da­ ten ausschließlich beim Anwender unter Verwendung eines in einer zentralen weiteren Datenbank gespeicherten, ausschließ­ lich an den autorisierten Anwender übermittelbaren Schlüssels entschlüsselt und/oder verschlüsselt werden.

Das erfindungsgemäße Verfahren geht also ab von der Ver- und Entschlüsselung der Daten auf Seiten des zentralen Servers selbst oder einer Leitungsverschlüsselung, sondern sieht dem­ gegenüber vor, dass dies ausschließlich beim Anwender er­ folgt. Dabei liegen die Daten nur beim Arzt unverschlüsselt vor (d. h. am Client), vor der Übertragung auf die zentrale Datenbank (Server) werden die Daten bereits beim Arzt ver­ schlüsselt. Damit werden Angriffe an der gefährdeten zentra­ len Stelle zur Datenspeicherung sehr erschwert, insbesondere auch Angriffe durch die Systemadministration. Es werden also beim erfindungsgemäßen Verfahren über die anzapfbare Kommuni­ kationsverbindung nur verschlüsselte Daten bzw. nur ver­ schlüsselte Datenteile, die kritische Informationen enthalten und infolgedessen besonders zu schützen sind, übertragen. Un­ kritische Daten können selbstverständlich auch unverschlüs­ selt übertragen werden. Der Schutz vor einem unberechtigten Datenzugriff wird weiterhin dadurch gewährleistet, dass zum Ver- und/oder Entschlüsseln ein besonderer Schlüssel erfor­ derlich ist, der von einer zentralen weiteren Datenbank aus ausschließlich an autorisierte Anwender vergeben wird. Dieser Schlüssel wird also nur an zugriffsberechtigte Anwender, bei­ spielsweise nur an zugriffsberechtigte Ärzte übergeben.

Die Daten können sich aus eine Person oder ein Objekt identi­ fizierenden und eine Person oder ein Objekt beschreibenden Datenteilen sowie Zuordnungsdaten zusammensetzen, wobei die identifizierenden Datenteile in einer ersten Datenbank und die beschreibenden Datenteile in einer zweiten Datenbank je­ weils mit einem Zuordnungsdatum gespeichert werden, wobei an­ hand der identisch ausgeprägten Zuordnungsdaten die in der jeweils anderen Datenbank gespeicherten Datenteile auffindbar sind, und wobei zumindest das Zuordnungsdatum der identifi­ zierenden Datenteile, gegebenenfalls auch die beschreibenden Datenteile verschlüsselt werden und unter Verwendung des übermittelten Schlüssels zu entschlüsseln sind. Es kommen hier also zwei getrennte Datenbanken zum Einsatz, die bevor­ zugt, jedoch nicht zwingend nicht miteinander kommunizieren. Bei den Datenbanken handelt es sich um objektorientierte Da­ tenbanken, die beispielsweise die Daten von Patienten in Form patientenspezifischer Akten enthalten. Zumindest die kriti­ schen Daten sind verschlüsselt, unkritische Daten müssen nicht notwendigerweise in verschlüsselter Form in der zweiten Datenbank abgelegt sein. Handelt es sich beispielsweise um medizinisch relevante Patientendaten, so sind in der die be­ schreibenden Datenteile enthaltenden zweiten Datenbank solche Daten, die entweder auf die Person hinweisen oder sonstige kritische Information beinhalten, wie auch das Zuordnungsda­ tum verschlüsselt, unkritische Daten, auf die beispielsweise im Rahmen epidemiologischer Erhebungen ohne Einschränkung zu­ gegriffen werden kann, sind unverschlüsselt abgelegt. Demge­ genüber sind in der ersten Datenbank die demographischen Pa­ tientendaten abgelegt und als verschlüsselte Referenz das verschlüsselte Zuordnungsdatum. Da die patientenidentifizie­ renden Daten in der ersten Datenbank unverschlüsselt abgelegt sind, ist es möglich, in dieser nach dem Patienten zu suchen und das verschlüsselte Zuordnungsdatum zu ermitteln, ein Zu­ griff auf die zweite Datenbank mit den beschreibenden Daten ist aber nur dann möglich, wenn das Zuordnungsdatum ent­ schlüsselt werden kann, so dass nach dem in der zweiten Da­ tenbank unverschlüsselt abgelegten Zuordnungsdatum gesucht und die Daten abgerufen werden können. Daneben ist es mög­ lich, eine weitere Verschlüsselungsstufe vorzusehen, nämlich dann, wenn die erste und die zweite Datenbank miteinander kommunizieren. In einem solchen Fall ist es möglich, die re­ levanten Daten nach einem Verfahren, wie es beispielsweise in WO 97/49211 oder US-PS 5606610 beschrieben ist, zu sichern.

Weiterhin kann erfindungsgemäß vorgesehen sein, dass die be­ schreibenden Datenteile samt Zuordnungsdaten in einer grup­ penspezifischen zweiten Datenbank gespeichert werden, die ei­ ner bestimmten Anwendergruppe, welche Personen umfasst, die autorisierten Zugriff auf die gespeicherten Daten haben dür­ fen, zugeordnet ist. Hiernach werden also Anwendergruppen ge­ bildet, wobei jeder Anwendergruppe eine gruppenspezifische zweite Datenbank zugeordnet ist. Sämtliche Gruppenmitglieder haben auf diese Datenbank autorisierten Zugriff. Eine solche Gruppe kann beispielsweise eine Gruppe aus mehreren Ärzten sein, die sich zusammengeschlossen haben. Alle haben auf ei­ nen gemeinsamen Patientenstamm Zugriff und können, da ihnen autorisiert der Schlüssel vorliegt bzw. gegeben werden kann, ohne Einwilligung des Patienten die entsprechenden Daten ab­ fragen. Die jeweiligen Gruppen können in ihrer Zusammenset­ zung wechseln, daneben ist es natürlich auch möglich, dass ein Arzt mehrerer Gruppen angehört, wie es natürlich auch möglich ist, dass ein Patient in mehreren Gruppendatenbanken eine Akte besitzt, beispielsweise in einer ersten Gruppe, in welcher mehrere Allgemeinärzte zusammengefasst sind, und in einer zweiten Gruppe, welche beispielsweise mehrere Interni­ sten umfasst. Daneben ist es auch möglich, dass der Patient im Bedarfsfall den Zugriff auf seine Daten für eine bestimmte Gruppe sperrt und im Bedarfsfall freigeben kann.

Die identifizierenden Datenteile samt Zuordnungsdaten können erfindungsgemäß in einer für alle Anwender bzw. alle Anwender einer Gruppe gemeinsamen ersten Datenbank gespeichert sein. Diese stellt eine Auskunftsdatenbank dar, in welche sich je­ der Anwender zwingend einzuwählen hat, um überhaupt an die relevanten Zuordnungsdaten zu kommen. Dies schafft auf einfa­ che Weise die Möglichkeit, die Autorisierung des anfragenden Anwenders zu überprüfen. Zur Autorisierung des Zugriffs auf Daten der ersten Datenbank vom Anwender kommende Autorisie­ rungsdaten können so nämlich in einer Autorisierungsdaten enthaltenden weiteren Datenbank, die der ersten Datenbank quasi vorgeschaltet ist, geprüft werden, wobei in Abhängig­ keit des Prüfungsergebnisses der Zugriff auf Daten der ersten Datenbank freigegeben oder gesperrt wird.

Der an den Anwender übermittelte Schlüssel kann diesem ledig­ lich ein einziges Mal übermittelt werden, er liegt dann sta­ tionär beim autorisierten Anwender. Es hat sich jedoch als zweckmäßig erwiesen, wenn der relevante Schlüssel mit jeder Anfrage an den Anwender übermittelt wird, da sich der Schlüs­ sel natürlich im Laufe der Zeit auch ändern kann. Um sicher­ zustellen, dass der Schlüssel nicht im Rahmen dieser Über­ mittlung unbefugterweise ausgelesen wird, was zur Folge hät­ te, dass ein unbefugter Dritter an die Daten kommen könnte, ist nach einer zweckmäßigen Weiterbildung des Erfindungsge­ dankens vorgesehen, dass der an den Anwender übermittelte Schlüssel mit einem anwenderbezogenen öffentlichen Schlüssel (IndPubKey) verschlüsselt ist und vom Anwender mit einem an­ wenderbezogenen privaten Schlüssel (IndPrivKey) entschlüsselt wird. D. h., jeder autorisierte Anwender, also beispielsweise der Arzt einer Ärztegruppe hat einen privaten Schlüssel. Ihm wird der zum Ver- und Entschlüsseln benötigte Schlüssel in verschlüsselter Form zugeschickt, zum Verschlüsseln dient der asymmetrische öffentliche Schlüssel. Der Arzt kann diesen nun mit seinem privaten Schlüssel entschlüsseln und mit dem dann unverschlüsselt vorliegenden Schlüssel die relevanten Daten abfragen.

Erfindungsgemäß kann der an den Anwender übertragene Schlüs­ sel ein einer bestimmten Anwendergruppe zugeordneter privater Gruppenschlüssel (DomPrivKey) sein, mittels dem ein öffentli­ cher Gruppenschlüssel (DomPubKey), mittels welchem das Zuord­ nungsdatum und gegebenenfalls weitere Datenteile verschlüs­ selt werden, entschlüsselt bzw. beim Speichern von Daten ver­ schlüsselt wird. Bei dem übertragenen Schlüssel handelt es sich also auch um einen asymmetrischen privaten Schlüssel, mittels dem der öffentliche Gegenschlüssel, mit dem die rele­ vanten Datenteile verschlüsselt sind, geöffnet werden kann. Es kommen also in diesem Fall zwei unterschiedliche asymme­ trische Schlüsselpaare zum Einsatz.

Alternativ hierzu kann vorgesehen sein, dass das Zuordnungs­ datum mit einem öffentlichen Aktenschlüssel (FilePubKey) ver­ schlüsselt wird, und dass dem verschlüsselten Zuordnungsdatum ein privater Aktenschlüssel (FilePrivKey), mit welchem das mit dem öffentlichen Aktenschlüssel verschlüsselte Zuord­ nungsdatum verschlüsselt bzw. entschlüsselt werden kann, zu­ geordnet wird, der seinerseits mit dem öffentlichen Gruppen­ schlüssel (DomPubKey) verschlüsselt bzw. entschlüsselt wird. In diesem Fall ist also noch zusätzlich das asymmetrische Ak­ tenschlüsselpaar vorgesehen, mittels dem die Daten verschlüs­ selt bzw. entschlüsselt werden, wobei der private Akten­ schlüssel wiederum mit dem öffentlichen Gruppenschlüssel ver­ schlüsselt ist, den der Arzt durch Entschlüsseln mit dem ihm vorliegenden privaten Gruppenschlüssel öffnen kann. Bei die­ ser Verfahrensvariante kommen also drei asymmetrische Schlüs­ selpaare zum Einsatz. Alternativ kann das Zuordnungsdatum auch mit einem symmetrischen Aktenschlüssel (FileSymKey) ver­ schlüsselt werden, der seinerseits mit dem öffentlichen Grup­ penschlüssel (DomPubKey) verschlüsselt bzw. entschlüsselt wird.

Um auch der Person, deren Daten gespeichert sind, Zugriff auf seine Daten zu ermöglichen, kann erfindungsgemäß vorgesehen sein, dass auch diese Person den privaten Aktenschlüssel (Fi­ lePrivKey), mittels welchem wie beschrieben das Zuordnungsda­ tum und gegebenenfalls weitere Datenteile verschlüsselt sind, besitzt, so dass sie selbständig auf die personeneigenen Da­ ten zugreifen und diese gegebenenfalls ändern und verschlüs­ selt abspeichern kann. Dies ist beispielsweise dann zweckmä­ ßig, wenn die Person zu Hause medizinisch relevante Daten aufnimmt, die auf diese Weise dann in die personenspezifische Datenakte eingetragen werden kann. Bei solchen Daten kann es sich beispielsweise um Blutdruckwerte oder aber den Insulin­ gehalt oder dergleichen handeln, also Daten, die der Patient zu Hause aufnehmen kann. Hierdurch wird ein umständlicher Gang zum Arzt vermieden.

Erfindungsgemäß können die in der zweiten Datenbank zu spei­ chernden, verschlüsselten Datenteile mit dem öffentlichen Gruppenschlüssel (DomPubKey) oder dem öffentlichen Akten­ schlüssel (FilePubKey) verschlüsselt werden. Die Entschlüsse­ lung erfolgt mit dem jeweils asymmetrischen privaten Schlüs­ sel. Ein Problem kann sich daraus ergeben, wenn die person­ identifizierenden Daten, sofern diese auch in der zweiten Da­ tenbank abgelegt werden, mit einem öffentlichen Schlüssel verschlüsselt werden, da dieser Schlüssel bekannt ist. Ein unbefugter Dritter kann nun, wenn er Daten einer bestimmten Person sucht, die ihm bekannten Identifikationsdaten, z. B. den Namen und den Vornamen der Person, mit dem bekannten öf­ fentlichen Schlüssel verschlüsseln und mit dem sich hieraus ergebenden String in der zweiten Datenbank nach dem Patienten suchen. Die gleiche Angriffsmöglichkeit kann sich in umge­ kehrter Richtung ergeben, wenn die in der zweiten Datenbank unverschlüsselt hinterlegten Zuordnungsdaten systematisch mit öffentlichen Schlüsseln verschlüsselt werden und dann in der ersten Datenbank nach den verschlüsselten Zuordnungsdaten ge­ sucht wird. Um hier Abhilfe zu schaffen sieht eine zweckmäßi­ ge Weiterbildung der Erfindung vor, dass die zu verschlüs­ selnden Datenteile und/oder Zuordnungsdaten vor der Ver­ schlüsselung um Zufallsdaten erweitert und die erweiterten Daten mit dem öffentlichen Gruppenschlüssel (DomPubKey) oder dem öffentlichen Aktenschlüssel (FilePubKey) verschlüsselt werden. Da dem unbefugten Dritten nicht bekannt ist, welche Zufallsdaten angehängt werden, kann er keinen String erzeu­ gen, der ihm ein Suchen in welcher Datenbank auch immer er­ möglicht. Hierdurch wird die Sicherheit des Verfahrens noch verbessert. Beim Auslesen werden die angehängten Zufallsdaten automatisch als solche erkannt und bleiben unbeachtet.

Wie beschrieben ist es eventuell auch vonnöten, beschreibende Datenteile zu verschlüsseln. Da es sich hierbei mitunter um große Datenmengen handeln kann, erweist sich eine Verschlüs­ selung derselben mit einem asymmetrischen Schlüssel als sehr zeitaufwendig. Um hier Abhilfe zu schaffen kann erfindungsge­ mäß vorgesehen sein, dass zumindest die zu verschlüsselnden, gegebenenfalls erweiterten Datenteile zunächst mit einem sym­ metrischen Datenschlüssel (DatSymKey) verschlüsselt werden, der seinerzeit mit dem öffentlichen Gruppenschlüssel (DomPub- Key) oder dem öffentlichen Aktenschlüssel (FilePubKey) ver­ schlüsselt wird. Dieser verschlüsselte symmetrische Daten­ schlüssel wird zusammen mit den Datenteilen abgelegt und kann entsprechend entschlüsselt werden. Die Verschlüsselung mit einem symmetrischen Schlüssel erfolgt um ca. einen Faktor 2000 mal schneller als die Verschlüsselung mit einem asymme­ trischen Schlüssel.

Erfindungsgemäß können die Schlüssel von einer zentralen Er­ zeugungsstelle, gegebenenfalls einer gruppeneigenen zentralen Erzeugungsstelle erzeugt werden. Hierbei kann es sich bei­ spielsweise um ein Trust Center handeln, im Falle einer grup­ peneigenen zentralen Erzeugungsstelle kann aber auch ein Gruppenmitglied als "Erzeugungsstelle" bestimmt werden, der die entsprechende Autorisierung zur Schlüsselerzeugung erhält und bei dem die entsprechenden Erzeugungsmaschinen instal­ liert sind. Alternativ hierzu können die Schlüssel auch beim Anwender selbst erzeugt werden.

Erfindungsgemäß können den in der zweiten Datenbank zu spei­ chernden, zu verschlüsselnden Datenteilen weitere Daten, die eine zur Verschlüsselung verwendete Verschlüsselungsmaschine angeben, zugeordnet und zusammen verschlüsselt werden. Beim Anwender können verschiedene Verschlüsselungsmaschinen, die jeweils mit bestimmten Schlüssellängen arbeiten oder nur be­ stimmte Teile der Daten verschlüsseln, installiert sein. Mit­ tels der zugeordneten weiteren Daten werden Informationen diesbezüglich abgespeichert, so dass der die anwenderseitige Datenbe- oder Verarbeitung vornehmende Algorithmus erkennen kann, auf welche Verschlüsselungsmaschine er zumindest zum Entschlüsseln zugreifen muss.

Jeder Person oder jedem Objekt innerhalb einer Anwendergruppe kann erfindungsgemäß nur ein Zuordnungsdatum zugeordnet wer­ den. Um Veränderungen innerhalb der hinterlegten Daten kennt­ lich und nachvollziehbar zu machen, kann erfindungsgemäß vor­ gesehen sein, dass bei Speicherung neuer Daten die vorher vorhandenen Daten als Datumsversion gespeichert werden, es wird also bei jeder Speicherung eine Versonierung vorgenom­ men. Um weiterhin transparent zu machen, wer eine etwaige Än­ derung vorgenommen hat oder aber Daten aufgerufen hat, kann erfindungsgemäß vorgesehen sein, dass jedem aufgerufenen und/oder neu gespeicherten Datum ein Identifikationsdatum des aufrufenden oder speichernden Anwenders beigefügt wird, es wird also eine Anwendersignatur angehängt.

Es hat sich als zweckmäßig erwiesen, wenn im Rahmen der Ver­ schlüsselung eine anwenderseitig vorliegende, Informationen über diejenigen zu verschlüsselnden Datenabschnitte, die zur Erhaltung der Datenintegrität vorzunehmenden Datenänderungen oder Datenerweiterungen sowie die Verschlüsselung selbst ent­ haltende Verschlüsselungstabelle verwendet wird. Eine solche Verschlüsselungstabelle, die beispielsweise für eine spezifi­ sche Anwendergruppe gilt, legt fest, welche Teile der Patien­ tendaten verschlüsselt werden müssen, zum Beispiel der Name oder der Vorname, mit welchen Algorithmen und welchen Schlüs­ sellängen die Daten verschlüsselt werden müssen, und mit wel­ chen genauen Schlüsseln die Datenteile bzw. die Zuordnungsda­ ten verschlüsselt werden müssen. Ferner wird hierdurch be­ stimmt, welche Dummy-Information in die Daten eingetragen werden muss, so dass die Datenintegrität nach dem vorgegebe­ nen Datenmodell, als welches sich beispielsweise ein HL7- Modell eignet, sichergestellt ist. Hierzu kann mit einem Kryptohashtable gearbeitet werden, was an und für sich be­ kannt ist. Mit der Verschlüsselungstabelle ist ein einfaches Arbeiten möglich, gleichermaßen können etwaige Änderungen im Verschlüsselungsmodus auf einfache Weise durch Ändern der Ta­ belle vorgenommen werden. Es können also problemlos Änderun­ gen im Algorithmus, der Schlüssellänge und dergleichen vorge­ nommen werden. Da bevorzugt jede Gruppe eine eigene Ver­ schlüsselungstabelle besitzt, sind zwischen verschiedenen Gruppen auch unterschiedliche Verschlüsselungskonzepte mög­ lich.

Nach einer ersten Erfindungsausgestaltung kann vorgesehen sein, dass die Verschlüsselungstabelle in der ersten Daten­ bank gespeichert und bei einem möglichen autorisierten Zu­ griff auf die Daten der ersten Datenbank an den Anwender übertragen wird, was es ermöglicht, etwaige Änderungen zen­ tral an der ersten Datenbank vorzunehmen. Alternativ kann die Verschlüsselungstabelle auch anwenderseitig erzeugt werden.

Weitere Vorteile, Merkmale und Einzelheiten der Erfindung er­ geben sich aus dem im folgenden beschriebenen Ausführungsbei­ spiel sowie anhand der Zeichnungen. Dabei zeigen:

Fig. 1 ein Diagramm zur Darstellung des erfindungsgemäßen Verfahrens sowie der hierfür erforderlichen rele­ vanten Komponenten, und

Fig. 2 ein Diagramm zur Darstellung einer Verschlüsse­ lungsmöglichkeit.

Wie Fig. 1 zeigt, wird zwischen der Seite des Anwenders und der der Zentrale unterschieden. Auf Seiten der Zentrale ist eine erste Datenbank 1 und eine zweite Datenbank 2 vorgese­ hen. In der ersten Datenbank sind die Identifikationsdaten einer Person oder eines Objekts sowie für die jeweilige Per­ son bzw. das Objekt spezifische Zuordnungsdaten sowie eine Verschlüsselungstabelle abgelegt. In der zweiten Datenbank 2 sind in unverschlüsselter Form die Zuordnungsdaten sowie ge­ gebenenfalls zumindest teilweise verschlüsselt beschreibende personenspezifische Daten sowie weitere Daten, die beispiels­ weise die zur Verschlüsselung verwendete Kryptomaschine ange­ ben, abgelegt.

Der ersten Datenbank vorgeschaltet ist eine dritte Datenbank (User-DB) 3, in welcher Autorisierungsdaten abgelegt sind, mittels welchen überprüft wird, ob ein den Zugriff auf Daten der ersten Datenbank anfragender Anwender hierzu berechtigt ist. Über Kommunikationsverbindungen, die in beliebiger Form ausgestaltet sein können (leitungsgebunden oder drahtlos), hat der Anwender Zugriff auf die jeweiligen Datenbanken, so­ fern er hierzu autorisiert ist. Anwenderseitig ist ein Algo­ rithmus 4 vorgesehen, über welchen die Ver- und Entschlüsse­ lung der Daten bearbeitet wird. Ferner ist eine Verschlüsse­ lungstabelle 5, die im Ausführungsbeispiel jeweils bei Kommu­ nikation mit der ersten Datenbank 1 übertragen wird, vorhan­ den. In dieser Verschlüsselungstabelle sind sämtliche Infor­ mationen enthalten, die zur Ver- und Entschlüsselung erfor­ derlich sind, beispielsweise welche Teile einer Patientenakte verschlüsselt werden müssen, mit welchen Algorithmen und wel­ chen Schlüssellängen sowie welchen Schlüsseln und derglei­ chen. Ferner sind im gezeigten Beispiel drei Kryptomaschinen 6, 7, 8 vorgesehen, mittels denen die Ver- und Entschlüsse­ lung vorgenommen wird, was mittels maschinenspezifischer öf­ fentlicher Schlüssel (. . .PubKey) bzw. privater Schlüssel (. . .PrivKey) erfolgt, wobei die öffentlichen Schlüssel der Kryptomaschinen 6, 7 und 8 wie auch die privaten Schlüssel identisch sein können.

Will nun ein Anwender, beispielsweise ein Arzt auf Daten in der ersten Datenbank zugreifen, beispielsweise weil nach ei­ ner Patientenuntersuchung neue Daten einzugeben sind, so startet er zunächst eine Autorisierungsanfrage und übersendet seine Autorisierungsdaten, die in der dritten Datenbank 3 überprüft werden. Sofern er autorisiert ist, kann er mit der ersten Datenbank 1 kommunizieren. Dort kann er nach den un­ verschlüsselten personenspezifischen Identitätsdaten des Pa­ tienten suchen und diese abrufen. Diesen Identitätsdaten ist ein verschlüsseltes Zuordnungsdatum angehängt, welches in entschlüsselter Form die Referenz zu den jeweils beschreiben­ den Personendaten in der zweiten Datenbank liefert. Mittels verschiedener Schlüssel, auf die nachfolgend noch eingegangen wird, kann der Arzt nun anwenderseitig die Zuordnungsdaten entschlüsseln und mittels der unverschlüsselten Zuordnungsda­ ten dann nach diesen in der zweiten Datenbank suchen und dort die Daten abrufen, die ihrerseits wiederum teilweise ver­ schlüsselt sein können. Nach erfolgter Entschlüsselung dieser Daten kann er dann entsprechende Änderungen oder dergleichen vornehmen. Etwaige Änderungen werden versioniert und mit ei­ nem Anwenderkennzeichen beispielsweise in Form einer Signatur versehen. Sollen nun die geänderten Daten abgespeichert wer­ den, so werden vom Algorithmus 4 die jeweiligen Verschlüsse­ lungsschritte aus der Verschlüsselungstabelle 5 ausgelesen und mittels der entsprechenden Kryptomaschine durchgeführt. Gezeigt ist ferner ein Zufallsgenerator 9 vorgesehen, mittels welchem Zufallsdaten generiert werden, die beispielsweise an in der ersten Datenbank verschlüsselt hinterlegte Zuordnungs­ daten als Dummy-Information gehängt und mitverschlüsselt wer­ den, um auf diese Weise zu vermeiden, dass öffentliche Schlüssel, welche zum Verschlüsseln dieser Daten dienen, und die möglicherweise bei unbefugten Dritten vorhanden sind, zum Verschlüsseln der in der zweiten Datenbank 2 unverschlüsselt vorhandenen Zuordnungsdaten genutzt werden, was dem unbefug­ ten Dritten verschiedene Strings liefert, nach welchen er dann in der ersten Datenbank suchen könnte und so eine Ver­ bindung zwischen Personendaten der ersten und zweiten Daten­ banken schaffen könnte.

Fig. 2 zeigt ein Beispiel, wie Daten verschlüsselt und ent­ schlüsselt werden können. In der ersten Datenbank sind wie beschrieben in unverschlüsselter Form die Identitätsdaten und in verschlüsselter Form das Zuordnungsdatum zu den beschrei­ benden Daten der zweiten Datenbank abgelegt. Das Zuordnungs­ datum ist zunächst mit einem öffentlichen Aktenschlüssel FilePubKey (File Public Key) verschlüsselt. Hieran ist ein privater Aktenschlüssel FilePrivKey (File Private Key) ge­ hängt, welcher wiederum mit einem öffentlichen Gruppenschlüs­ sel DomPubKey (Domain Public Key) verschlüsselt ist. Dieser öffentliche Gruppenschlüssel ist einer Gruppe von Anwendern zugeordnet, die alle autorisiert sind, auf Daten der ersten Datenbank zugreifen zu können. Bei dieser Gruppe kann es sich beispielsweise um eine Gruppe von Ärzten handeln: An den öf­ fentlichen Gruppenschlüsseln DomPubKey ist der private Grup­ penschlüssel DomPrivKey (Domain Private Key) gehängt, mittels welchem der verschlüsselte öffentliche Gruppenschlüssel Dom- PubKey entschlüsselt werden kann. Der private Domänenschlüs­ sel DomPrivKey ist wiederum mit einem anwenderbezogenen öf­ fentlichen IndPubKey (Individual Public Key) verschlüsselt. Dieser wiederum kann mit dem anwenderbezogenen privaten Schlüssel IndPrivKey (Individual Private Key) geöffnet wer­ den. Dieser private Schlüssel IndPrivKey ist der individuelle Arztschlüssel, welcher beim Arzt beispielsweise auf einer Chipkarte gespeichert vorhanden ist. Es sind im vorliegenden Fall insgesamt drei asymmetrische Schlüsselpaare vorhanden, die zum Verschlüsseln und gleichermaßen zum Entschlüsseln dienen. Es bleibt darauf hinzuweisen, dass die Verschlüsse­ lung auch lediglich mit zwei asymmetrischen Schlüsselpaaren, nämlich dem Gruppenschlüsselpaar DomPubKey und DomPrivKey und dem anwenderbezogenen Schlüsselpaar IndPubKey und IndPrivKey erfolgen kann. Wird jedoch mit drei Schlüsselpaaren ver­ schlüsselt, so besteht die Möglichkeit, dem Patienten selbst ein Zugriffsrecht auf seine Privatdaten einzuräumen, indem ihm der private Aktenschlüssel FilePrivKey überlassen wird. Mit diesem kann er unmittelbar den das Zuordnungsdatum ver­ schlüsselnden öffentlichen Aktenschlüssel FilePubKey öffnen und mittels des dann unverschlüsselten Zuordnungsdatums als Referenz auf seine Daten in der zweiten Datenbank zugreifen und diese gegebenenfalls ändern oder ergänzen.

Sämtliche Schlüssel werden dem Anwender nach erfolgter Auto­ risierung über die Kommunikationsverbindung gegeben. Die Ent­ schlüsselung wie auch die Verschlüsselung erfolgt ausschließ­ lich beim Anwender.

Wurde nun anwenderseitig das Zuordnungsdatum entschlüsselt, so kann in der zweiten Datenbank nach dem unverschlüsselten Zuordnungsdatum gesucht werden. Unter dem Zuordnungsdatum sind die beschreibenden Daten beispielsweise des Patienten abgelegt, sowie gegebenenfalls weitere Daten, die nähere In­ formationen zu dem Verschlüsselungsverfahren, mittels welchem die beschreibenden Daten verschlüsselt sind, enthalten. So­ wohl die beschreibenden Daten wie auch gegebenenfalls die weiteren Daten können, sofern es sich um große Datenmengen handelt, mittels eines symmetrischen Datenschlüssels DatSym- Key (Data Symmetrical Key) verschlüsselt sein. Die Verwendung eines symmetrischen Datenschlüssels ermöglicht eine weitaus schnellere Verschlüsselung, als wenn dies mit einem asymme­ trischen Schlüssel erfolgt. Der symmetrische Datenschlüssel ist mittels eines öffentlichen Schlüssels, im gezeigten Bei­ spiel entweder dem öffentlichen Gruppenschlüssel DomPubKey oder dem öffentlichen Aktenschlüssel FilePubKey verschlüs­ selt. Für den Fall, dass der Patient direkt auf seine Akte Zugriff haben soll, wäre der öffentliche Aktenschlüssel zu verwenden, damit dem Patienten die Entschlüsselung des symme­ trischen Datenschlüssels DatSymKey möglich ist.

Anstelle des asymmetrischen Aktenschlüsselpaares FilePubKey und FilePrivKey kann auch ein symmetrischer Aktenschlüssel FileSymKey verwendet werden, der seinerseits mit dem öffent­ lichen Gruppenschlüssel DomPubKey verschlüsselt bzw. ent­ schlüsselt wird.

Ferner besteht die Möglichkeit, die Identitätsdaten auch in der zweiten Datenbank verschlüsselt zu speichern, wobei zur Ver- bzw. Entschlüsselung der gleiche Schlüssel wie zur Ver- bzw. Entschlüsselung der beschreibenden Daten verwendet wer­ den kann. Durch die Speicherung der identifizierenden Daten auch in der zweiten Datenbank sind personen- oder objektspe­ zifische Änderungen, z. B. eine Namensänderung auf einfache Weise direkt in der "Akte" vornehmbar, so dass stets eine korrekte und transparente Personen- oder Objektzuordnung bzw. -übereinstimmung der in den beiden Datenbanken abgelegten Da­ ten gegeben ist.

Claims (20)

1. Verfahren zum Be- oder Verarbeiten von Daten, die in we­ nigstens einer Datenbank in zumindest teilweise verschlüssel­ ter Form gespeichert werden, wobei die Daten von einem mit der Datenbank über eine Kommunikationsverbindung kommunizie­ renden Anwender ausgelesen und gegebenenfalls neue Daten ge­ speichert werden können, dadurch gekenn­ zeichnet, dass die Daten ausschließlich beim An­ wender unter Verwendung eines in einer zentralen weiteren Da­ tenbank gespeicherten, ausschließlich an den autorisierten Anwender übermittelbaren Schlüssels entschlüsselt und/oder verschlüsselt werden.

2. Verfahren nach Anspruch 1, dadurch ge­ kennzeichnet, dass sich die Daten aus eine Person oder ein Objekt identifizierenden und eine Person oder ein Objekt beschreibenden Datenteilen sowie Zuordnungsdaten zusammensetzen, wobei die identifizierenden Datenteile in ei­ ner ersten Datenbank und die beschreibenden Datenteile in ei­ ner zweiten Datenbank jeweils mit einem Zuordnungsdatum ge­ speichert werden, wobei anhand der identisch ausgeprägten Zu­ ordnungsdaten die in der jeweils anderen Datenbank gespei­ cherten Datenteile auffindbar sind, und wobei zumindest das Zuordnungsdatum der identifizierenden Datenteile und gegebe­ nenfalls die beschreibenden Datenteile verschlüsselt werden und unter Verwendung des übermittelten Schlüssels zu ent­ schlüsseln sind.

3. Verfahren nach Anspruch 2, dadurch ge­ kennzeichnet, dass die beschreibenden Daten­ teile samt Zuordnungsdaten in einer gruppenspezifischen zwei­ ten Datenbank gespeichert werden, die einer bestimmten An­ wendergruppe, welche Personen umfasst, die autorisierten Zu­ griff auf die gespeicherten Daten haben dürfen, zugeordnet ist.

4. Verfahren nach Anspruch 2 oder 3, dadurch gekennzeichnet, dass die identifizierenden Datenteile samt Zuordnungsdaten in einer für alle Anwender bzw. für alle Anwender einer Gruppe gemeinsamen ersten Daten­ bank gespeichert werden.

5. Verfahren nach einem der Ansprüche 2 bis 4, da­ durch gekennzeichnet, dass der an den Anwender übermittelte Schlüssel mit einem anwenderbezoge­ nen öffentlichen Schlüssel (IndPubKey) verschlüsselt ist und vom Anwender mit einem anwenderbezogenen privaten Schlüssel (IndPrivKey) entschlüsselt wird.

6. Verfahren nach einem der Ansprüche 2 bis 5, da­ durch gekennzeichnet, dass der an den Anwender übertragene Schlüssel ein einer bestimmten An­ wendergruppe zugeordneter privater Gruppenschlüssel (DomPriv- Key) ist, mittels dem ein öffentlicher Gruppenschlüssel (Dom- PubKey), mittels welchem das Zuordnungsdatum und gegebenen­ falls weitere Datenteile verschlüsselt werden, entschlüsselt bzw. beim Speichern von Daten verschlüsselt wird.

7. Verfahren nach einem der Ansprüche 2 bis 5, da­ durch gekennzeichnet, dass das Zu­ ordnungsdatum mit einem öffentlichen Aktenschlüssel (FilePub- Key) verschlüsselt wird, und dass dem verschlüsselten Zuord­ nungsdatum ein privater Aktenschlüssel (FilePrivKey), mit welchem das mit dem öffentlichen Aktenschlüssel verschlüssel­ te Zuordnungsdatum verschlüsselt bzw. entschlüsselt werden kann, zugeordnet wird, der seinerseits mit dem öffentlichen Gruppenschlüssel (DomPubKey) verschlüsselt bzw. entschlüsselt wird, oder dass das Zuordnungsdatum mit einem symmetrischen Aktenschlüssel (FileSymKey) verschlüsselt wird, der seiner­ seits mit dem öffentlichen Gruppenschlüssel (DomPubKey) ver­ schlüsselt bzw. entschlüsselt wird.

8. Verfahren nach Anspruch 7, dadurch ge­ kennzeichnet, dass als Anwender auch die Per­ son, deren Daten gespeichert ist, den privaten Aktenschlüssel (FilePrivKey) besitzt und selbständig auf die personeneigenen Daten zugreifen und diese gegebenenfalls ändern und ver­ schlüsselt speichern kann.

9. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die in der zweiten Datenbank zu speichernden, verschlüsselten Da­ tenteile mit dem öffentlichen Gruppenschlüssel (DomPubKey) oder dem öffentlichen Aktenschlüssel (AktPubKey) verschlüs­ selt werden.

10. Verfahren nach einem der Ansprüche 2 bis 9, da­ durch gekennzeichnet, dass die zu verschlüsselnden Datenteile und/oder Zuordnungsdaten vor der Verschlüsselung um Zufallsdaten erweitert und die erweiterten Daten mit dem öffentlichen Gruppenschlüssel (DomPubKey) oder dem öffentlichen Aktenschlüssel (FilePubKey) verschlüsselt werden.

11. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass zu­ mindest die zu verschlüsselnden, gegebenenfalls erweiterten Datenteile zunächst mit einem symmetrischen Datenschlüssel (DatSymKey) verschlüsselt werden, der seinerseits mit dem öf­ fentlichen Gruppenschlüssel (DomPubKey) oder dem öffentlichen Aktenschlüssel (FilePubKey) verschlüsselt wird.

12. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass die Schlüssel von einer zentralen Erzeugungsstelle, gegebenen­ falls einer gruppeneigenen zentralen Erzeugungsstelle oder beim Anwender selbst erzeugt werden.

13. Verfahren nach einem der Ansprüche 2 bis 12, da­ durch gekennzeichnet, dass den in der zweiten Datenbank zu speichernden, zu verschlüsselnden Datenteilen weitere Daten, die eine zur Verschlüsselung ver­ wendete Verschlüsselungsmaschine angeben, zugeordnet und zu­ sammen verschlüsselt werden.

14. Verfahren nach einem der Ansprüche 3 bis 13, da­ durch gekennzeichnet, dass jeder Person oder jedem Objekt innerhalb einer Anwendergruppe nur ein Zuordnungsdatum zugeordnet wird.

15. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass zur Autorisierung des Zugriffs auf Daten der ersten Datenbank vom Anwender kommende Autorisierungsdaten in einer Autorisie­ rungsdaten enthaltenden weiteren Datenbank geprüft werden und in Abhängigkeit des Prüfungsergebnisses der Zugriff auf Daten der ersten Datenbank freigegeben oder gesperrt wird.

16. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass bei Speicherung neuer Daten die vorher vorhandenen Daten als Da­ tumsversion gespeichert werden.

17. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass je­ dem aufgerufenen und/oder neu gespeicherten Datum ein Identi­ fikationsdatum des aufrufenden oder speichernden Anwenders beigefügt wird.

18. Verfahren nach einem der vorangehenden Ansprüche, dadurch gekennzeichnet, dass im Rahmen der Verschlüsselung eine anwenderseitig vorliegende, Informationen über diejenigen zu verschlüsselnden Datenab­ schnitte, die zur Erhaltung der Datenintegrität vorzunehmen­ den Datenänderungen oder Datenerweiterungen sowie die Ver­ schlüsselung selbst enthaltende Verschlüsselungstabelle ver­ wendet wird.

19. Verfahren nach Anspruch 18, dadurch ge­ kennzeichnet, dass die Verschlüsselungstabelle in der ersten Datenbank gespeichert und bei einem möglichen autorisierten Zugriff auf die Daten der ersten Datenbank an den Anwender übertragen wird, oder dass die Verschlüsselungs­ tabelle anwenderseitig erzeugt wird.

20. Verfahren nach Anspruch 18 oder 19, dadurch gekennzeichnet, dass zu jeder Anwendergruppe eine eigene Verschlüsselungstabelle vorgesehen ist.