DE69730321T2

DE69730321T2 - Verfahren und vorrichtung zum schützen von daten mit mehreren auf datenelementebene anwendbaren verschlüsselungsstufen

Info

Publication number: DE69730321T2
Application number: DE69730321T
Authority: DE
Inventors: Ulf Dahl
Original assignee: Protegrity Res & Dev AB; Protegrity Research & Development AB
Current assignee: PROTEGRITY RESEARCH & DEVELOPMENT AB,, SKELLEFTEA,
Priority date: 1996-06-20
Filing date: 1997-06-18
Publication date: 2005-09-08
Anticipated expiration: 2017-06-19
Also published as: EP0891661B1; NO985985L; CN1222272A; RU2198423C2; ES2230609T3; NO985985D0; AU3282397A; PT891661E; SE506853C2; EP1477881A2; KR20000022057A; US20020174352A1; JP4167300B2; SE9602475D0; EP0891661A1; US6321201B1; WO1997049211A1; US8402281B2; IL127645A0; ATE274264T1

Description

TECHNISCHES GEBIET
Die vorliegende Erfindung betrifft das technische Gebiet der rechnergestützten Informationsverwaltung und betrifft insbesondere ein Verfahren und eine Vorrichtung zur Datenverarbeitung gemäß dem Oberbegriff von Anspruch 1 beziehungsweise Anspruch 8, um einen besseren Schutz gegen unbefugtes Verarbeiten von Daten zu erreichen.
STAND DER TECHNIK
Auf dem Gebiet der rechnergestützten Informationsverwaltung besteht ein starkes Bedürfnis, dass der Schutz gegen unbefugten Datenregisterzugriff, insbesondere gegen die Verletzung der persönlichen Integrität eines Individuums bei der Erstellung und Führung von Personenregistern, d. h. Registern mit Informationen über Individuen, verbessert wird. Vor allem gibt es Vorschriften, welche die Verknüpfung und Anpassung von Personenregistern beschränken und verbieten. Auch auf anderen Gebieten, wie beispielsweise Industrie, Abwehr, Bankwesen, Versicherung usw., wird ein besserer Schutz gegen unbefugten Zugriff auf Werkzeuge, Datenbanken, Anwendungen usw., welche zur Verwaltung und Speicherung von vertraulicher Information verwendet werden, gewünscht.
WO95/15628, das denselben Inhaber wie die vorliegende Anmeldung hat, offenbart ein Verfahren zum Speichern von Daten, welches zu erweiterten Verknüpfungs- und Anpassungsmöglichkeiten ohne die Gefahr verminderter Integrität führt. Das Verfahren, das in 1 und 2 auf den beigefügten Zeichenblättern schematisch veranschaulicht ist, betrifft das Speichern von Information, welche einerseits einen Informationskennzeichnungsteil oder eine Originalidentität OID, zum Beispiel persönliche Kennzahlen Pcn (für engl. personal code numbers), und andererseits deskriptive Information DI umfasst. Die Information OID + DI wird gemäß dem folgenden Prinzip als Datensätze P in einer Datenbank O-DB gespeichert:
Schritt 1: Die OID (Pcn) wird mittels eines ersten, vorzugsweise irreversiblen Algorithmus ALG1 zu einer Aktualisierungsidentität UID (für engl. update identity) verschlüsselt.
Schritt 2: Die UID wird mittels eines zweiten, reversiblen Algorithmus ALG2 zu einer Speicheridentität SID verschlüsselt.
Schritt 3: Die SID und die DI werden als ein Datensatz P in der Datenbank O-DB gespeichert, wobei die SID als eine Datensatzkennzeichnung dient.
Schritt 4: Zu vorbestimmten Zeitpunkten erfolgt eine Änderung der SID in allen oder ausgewählten Datensätzen P, indem die SID dieser Datensätze mittels eines Entschlüsselungsalgorithmus ALG3 zur UID entschlüsselt wird, worauf die UID mittels eines modifizierten zweiten, reversiblen Algorithmus oder ALG2' zu einer neuen Speicheridentität SID' verschlüsselt wird, welche als eine neue Datensatzkennzeichnung im zugeordneten Datensatz P als Ersatz für die vorherige SID eingeführt wird. Dies führt zu einer „gleitenden" Änderung der SID der Datensätze, welche die Sicherheit verbessert.
Für eine genauere Beschreibung der Einzelheiten und Vorteile dieses Verschlüsselungs- und Entschlüsselungsverfahrens wird auf WO95/15628 verwiesen. Das zuvor erwähnte Speicherungsprinzip gemäß Schritt 1 bis 4 wird im Folgenden als PTY bezeichnet, was eine Abkürzung des Begriffs PROTEGRITY ist, der für „Protection and Integrity" (Schutz und Integrität) steht.
Eine ausführliche technische Beschreibung von PTY wird auch im Dokument „PROTEGRITY (ASIS) Study 2", Ver. 1.2, 1. März 1996, von Leif Johnson, geliefert.
Auf dem betreffenden technischen Gebiet sind heutzutage jedoch so genannte Schalenschutze das vorherrschende Schutzverfahren. Schalenschutz umfasst einerseits die externe Sicherheit (Prämissen) und andererseits ein Berechtigungsprüfungssystem ACS (für engl. authorisation check system) mit Benutzerpasswörtern zur Kontrolle des Zugriffs. Das ACS wird als Schalenschutz für Großrechner, Client/-Server-Systeme und PC verwendet, gewährt aber keinen vollen Schutz, und die betreffende Information kann oft verhältnismäßig leicht unbefugtem Zugriff ausgesetzt sein. Dieser Schutz hat sich als immer weniger zufrieden stellend herausgestellt, da in zunehmendem Maße „vertrauliche" Information gespeichert wird, was Verwalten per Verteilung, Speicherung und Verarbeitung in sich dynamisch ändernden Umgebungen, insbesondere lokaler Verteilung an Personalcomputer, zulassen muss. Gleichzeitig mit dieser Entwicklung werden die Grenzen des Systems immer undeutlicher, und die Wirkung, die durch einen Schalenschutz erzielt wird, verschlechtert sich.
KURZDARSTELLUNG DER ERFINDUNG
Angesichts der vorstehenden Darlegungen ist es die Aufgabe der vorliegenden Erfindung, ein besseres Verfahren zum Verarbeiten von Information bereitzustellen, mithilfe dessen es möglich ist, den Schutz gegen unbefugten Zugriff auf vertrauliche Information zu verbessern.
Eine besondere Aufgabe der Erfindung ist die Bereitstellung einer Technik zur Datenverarbeitung und -verwaltung, welche es für die Person, die für das System, die Verwaltung der Organisation usw. verantwortlich ist, möglich macht, für einen Benutzer die Möglichkeit zum Verarbeiten von gespeicherter Information, die zu schützen ist, problemlos zu schaffen und kontinuierlich anzupassen.
Eine weitere Aufgabe der Erfindung ist die Bereitstellung einer Technik zur Datenverarbeitung, welche Schutz gegen Versuche unbefugter Datenverarbeitung mithilfe von nicht anerkannter Software gewährt.
Eine weitere Aufgabe der Erfindung ist die Bereitstellung einer Technik zur Datenverarbeitung gemäß den zuvor erwähnten Aufgaben, welche zusammen mit dem zuvor beschriebenen PTY-Prinzip verwendet werden kann, um ein Sicherheitssystem mit einem äußerst hohen Niveau von Schutz bereitzustellen.
Diese und andere Aufgaben der Erfindung werden durch das Verfahren gemäß Patentanspruch 1 und die Vorrichtung gemäß Patentanspruch 8 erreicht, wobei bevorzugte Ausführungsformen der Erfindung in den abhängigen Ansprüchen dargelegt sind.
Somit stellt die Erfindung ein Verfahren zum Verarbeiten von zu schützenden Daten bereit, welches die Maßnahme des Speicherns der Daten als verschlüsselte Datenelementwerte von Datensätzen in einer ersten Datenbank (O-DB) umfasst, wobei jeder Datenelementwert mit einem entsprechenden Datenelementtyp verbunden ist.
Das erfinderische Verfahren ist durch die folgenden Schritte gekennzeichnet:
Speichern in einer zweiten Datenbank (IAM-DB) eines Datenelementschutzkatalogs, welcher für jeden einzelnen Datenelementtyp ein oder mehr Schutzattribute enthält, welche Verarbeitungsregeln für Datenelementwerte festlegen, welche in der ersten Datenbank mit dem einzelnen Datenelementtyp verbunden sind, bei jeder benutzerveranlassten Maßnahme, welche das Verarbeiten eines bestimmten Datenelementwerts in der ersten Datenbank beabsichtigt, anfängliches Herstellen eines zwingenden Anrufs an den Datenelementschutzkatalog, um das Schutzattribut oder die Schutzattribute, welche dem entsprechenden Datenelementtyp zugeordnet sind, einzuholen, und zwingendes Steuern des Verarbeitens des bestimmten Datenelementwerts in Übereinstimmung mit dem erhobenen Schutzattribut oder den erhobenen Schutzattributen.
In der vorliegenden Anmeldung werden die folgenden Definitionen verwendet:

• „Verarbeiten" kann jede Art von Maßnahmen umfassen, die irgendeine Form von Lesen, Drucken, Ändern, Codieren, Bewegen, Kopieren usw. von Daten, die durch das erfinderische Verfahren zu schützen sind, bedeuten.
• „Datenelementtyp" betrifft einen bestimmten Typ von Daten mit einer Bedeutung, wie vereinbart.
• „Datenelementwert" betrifft einen Wert, welcher in einem bestimmten Datensatz einen Datenelementtyp spezifiziert.
• „Datensatz" betrifft eine Anzahl von Datenelementwerten, welche zusammengehören und welche mit den jeweiligen Datenelementtypen verbunden sind, wobei sie wahlweise auch eine Datensatzkennzeichnung umfassen, mit deren Hilfe der Datensatz identifiziert werden kann. Beispiel:
• „Schutzattribut, welches Verarbeitungsregeln angibt" kann betreffen:
– Daten, welche im Datenelementschutzkatalog gespeichert sind und eine vollständige Information über die Regel oder die Regeln bereitstellen, welche für die Verarbeitung des entsprechenden Datenelements gelten, und/oder
– Daten, welche im Datenelementschutzkatalog gespeichert sind und zusätzliche Anrufe um Information erfordern, welche an irgendeinem anderen Ort gespeichert ist und welche wahlweise zusammen mit den Schutzattributen die betroffenen Verarbeitungsregeln festlegt.
• „Einholung von Schutzattributen" kann betreffen:
– Einholung der Schutzattribute in der Form, wie im Datenelementschutzkatalog gespeichert, und/oder
– Einholung von Daten, welche aus den Schutzattributen zum Beispiel durch Entschlüsselung davon wiederhergestellt werden.
• „Verschlüsselung" kann jede Form von Verschlüsselung, Trikryption, Umwandlung der Codierung von Klartextdaten in nicht interpretierbare (verschlüsselte) Daten betreffen und betrifft insbesondere auch Umwandlungsverfahren, welche Hash-Codierung umfassen.

Das erfinderische Verfahren gewährt eine neue Art von Schutz, welche sich wesentlich vom Schalenschutz des Stan des der Technik unterscheidet und welche auf dem Zell- oder Datenelementniveau arbeitet. Jeder Datenelementtyp, der in den Datensätzen in den ersten Datenbanken verwendet wird, ist daher einem oder mehreren Schutzattributen zugeordnet, die in einem getrennten Datenelementschutzkatalog gespeichert sind, wobei die Schutzattribute Regeln darüber festlegen, wie die entsprechenden Datenelementwerte zu verarbeiten sind. Es ist besonders zu erwähnen, dass der Anruf an den Datenelementkatalog zwingend ist. Dies bedeutet, dass in einem System, in welchem das Verfahren gemäß der Erfindung realisiert ist, es so ist, dass vorausgesetzt wird, dass ein Benutzer, der zum Beispiel einen bestimmten Datenelementwert in einem bestimmten Datensatz in der ersten Datenbank zu lesen wünscht, durch seinen Versuch, auf den Datenelementwert zuzugreifen, automatisch und zwingend einen Systemanruf an den Datenelementschutzkatalog in der zweiten Datenbank herstellt, um die Schutzattribute, welche den entsprechenden Datenelementtypen zugeordnet sind, einzuholen. Die weitergeführte Verarbeitungsprozedur (Auslesen des Datenelementwerts) des Systems wird in Übereinstimmung mit dem erhobenen Schutzattribut oder den erhobenen Schutzattributen, welche für die entsprechenden Datenelementtypen gelten, ebenfalls zwingend gesteuert.
Der Begriff „Datenelementschutzkatalog" und seine Verwendung gemäß der Erfindung darf nicht mit dem bekannten Begriff „aktives Wörterbuch" verwechselt werden, was bedeutet, dass es zusätzlich zu einer operativen Datenbank eine spezielle Tabelle gibt, welche verschiedene Definitionen oder Wahlen für Datenelementwerte in der operativen Datenbank angibt, zum Beispiel, dass sich ein Datenelementwert „Gelb" bezüglich der Definition auf einen Farbcode bezieht, der innerhalb eines numerischen Intervalls ist, der in solch einer Bezugstabelle festgelegt ist.
Vorzugsweise sind die Verarbeitungsregeln, welche durch die Schutzattribute festgelegt werden, für den Benutzer unzu gänglich, und die ausgelesenen oder erhobenen Schutzattribute werden vorzugsweise rein intern durch das System zum Steuern der Verarbeitung verwendet. Ein bestimmter Benutzer, der zum Beispiel Information bezüglich eines bestimmten Individuums zu lesen wünscht, die in der Datenbank gespeichert ist, braucht sich daher der Tatsache nicht bewusst sein, das bestimmte Schutzattribute aktiviert wurden und dazu führten, dass eine bestimmte, vertrauliche Information für dieses Individuum von der Information ausgeschlossen wird, die z. B. auf einer Anzeige verfügbar gemacht wird. Jede benutzerveranlasste Maßnahme, welche das Verarbeiten von Datenelementwerten beabsichtigt, umfasst daher einerseits einen zwingenden Anruf an den Datenelementschutzkatalog und andererseits eine weiterführende Verarbeitung, welche jenen Verarbeitungsregeln, die durch die Schutzattribute festgelegt sind, zwingend unterworfen ist, und dies kann demnach bewerkstelligt werden, ohne dass der Benutzer Information darüber erhält, welche Regeln die betreffende Verarbeitung steuern, und insbesondere ohne dass der Benutzer irgendeine Möglichkeit hat, Zugriff auf die Regeln zu haben.
Durch Ändern, Hinzufügen und Entfernen von Schutzattributen im Datenelementschutzkatalog kann die Person, die für das System verantwortlich ist, oder eine entsprechende Person für jeden einzelnen Datenelementtyp problemlos die Verarbeitungsregeln bestimmen, die für Datenelementwerte gelten, welche dem einzelnen Datenelementtyp zugeordnet sind, und auf diese Weise eine hohe und klare Sicherheitsqualität im System aufrechterhalten.
Gemäß der Erfindung ist es daher das einzelne Datenelement (Datenelementtyp) und nicht das ganze Register, das zur Steuereinheit für die Art und Weise wird, auf welche die Organisation, der Betreiber usw., die für das System verantwortlich sind, das Qualitäts-, Verantwortlichkeits- und Sicherheitsniveau in Bezug auf die Informationsverwaltung bestimmt haben.
Um ein hohes Niveau von Schutz zu erhalten, wird der Datenelementschutzkatalog vorzugsweise verschlüsselt, um unbefugten Zugriff darauf zu verhindern.
Als bevorzugte Schutzattribute stellt die vorliegende Erfindung die folgenden Möglichkeiten bereit, welche jedoch als eine unvollständige veranschaulichende Liste anzusehen sind:

1. Festlegung, welche „Stärke" oder welches „Niveau" (zum Beispiel keines, 1, 2 ...) von Verschlüsselung zum Speichern der entsprechenden Datenelementwerte in der Datenbank zu verwenden ist. Verschiedene Datenelementwerte innerhalb ein und desselben Datensatzes können daher mit einer voneinander verschiedenen Stärke verschlüsselt werden.
2. Festlegung, welche „Stärke" oder welches „Niveau" (zum Beispiel keines, 1, 2 ...) von Verschlüsselung für die entsprechenden Datenelementwerte zu verwenden ist, wenn diese in einem Netz zu senden sind.
3. Festlegung eines Programms und/oder von Programmversionen, welche befugt sind, zum Verarbeiten der entsprechenden Datenelementwerte verwendet zu werden.
4. Festlegung des „Eigentümers" des Datenelementtyps. Verschiedene Datenelementwerte innerhalb ein und desselben Datensatzes können daher verschiedene Eigentümer aufweisen.
5. Festlegung von Aussortierregeln für die entsprechenden Datenelementwerte, zum Beispiel Festlegung von Verfahren und Zeitpunkt für die automatische Entfernung der entsprechenden Datenelementwerte aus der Datenbank.
6. Festlegung, ob beim Verarbeiten der entsprechenden Datenelementwerte automatisches Protokollieren zu erfolgen hat.

Gemäß einer besonders bevorzugten Ausführungsform der Erfindung wird das zuvor beschriebene PTY-Speicherverfahren zur Verschlüsselung aller Daten verwendet, welche sowohl in der Datenbank (d. h. die Datenelementwerte) als auch im Datenelementschutzkatalog (d. h. die Schutzattribute) zu verschlüsseln sind. Im Normalfall, in dem jeder Datensatz eine Datensatzkennzeichnung (die der zuvor erwähnten SID entspricht) aufweist, wird vorzugsweise auch die Datensatzkennzeichnung mittels PTY geschützt. Insbesondere kann eine gleitende Änderung der Datenkennzeichnungen sowohl in der operativen Datenbank als auch im Datenelementschutzkatalog in gewünschten Intervallen und zu willkürlich gewählten Zeitpunkten in Übereinstimmung mit dem zuvor beschriebenen PTY-Prinzip erfolgen. In der bevorzugten Ausführungsform kann vor allem der verkapselte Prozessor, welcher für die PTY-Verschlüsselung verwendet wird, auch für die Realisierung der Anrufe an den Datenelementschutzkatalog und die Prozedur zur Verarbeitung gemäß den erhobenen Schutzattributen verwendet werden.
Die Erfindung wird nun unter Bezugnahme auf die beiliegenden Zeichnungen, welche das in einem veranschaulichenden Datensystem realisierte erfinderische Prinzip schematisch darstellen, ausführlicher beschrieben.
KURZE BESCHREIBUNG DER ZEICHNUNGEN
1 (Stand der Technik) stellt das Prinzip des Speicherns von Dateninformation gemäß dem PTY-Prinzip in WO95/15628 schematisch dar.
2 (Stand der Technik) stellt das Prinzip des Erzeugens von gleitenden Speicheridentitäten gemäß dem PTY-Prinzip in WO95/15628 schematisch dar.
3 stellt ein Rechnersystem zur Realisierung des Verfahrens gemäß der Erfindung schematisch dar.
4 stellt das Prinzip der Datenverarbeitung gemäß der Erfindung mit zwingenden Anrufen an einen Datenelementschutzkatalog schematisch dar.
5 stellt ein Beispiel eines Anzeigebildes zur Bestimmung von Schutzattributen im Datenelementschutzkatalog dar.
BESCHREIBUNG DER BEVORZUGTEN AUSFÜHRUNGSFORM
Im Folgenden wird die Bezeichnung IAM (die für Informationsanlagenverwalter nach engl. Information Asset Manager steht) für die Komponenten und Anwendungen verwendet, welche in der Ausführungsform für die Realisierung der Erfindung wesentlich sind.

– Zuerst wird auf 3 Bezug genommen, die ein Datenverwaltungssystem schematisch darstellt, in welchem die vorliegende Erfindung realisiert ist und in welchem die folgenden Datenbanken zum Speichern von Information, in diesem Beispiel personenbezogener Information, enthalten sind:
– eine offene Datenbank P-DB, die allgemein zugängliche Daten, wie beispielsweise einen Personennamen, Artikelnamen, Adresse usw., mit der persönlichen Kennzahl Pcn als Klartext als Datensatzkennzeichnung enthält;
– eine operative Datenbank O-DB, welche Daten enthält, die zu schützen sind. Eine verschlüsselte Identifikation, in diesem Fall eine verschlüsselte persönliche Kennzahl, wird als Datensatzkennzeichnung (= Speicheridentität SID) verwendet. Die O-DB wird durch befugte Benutzer zum Verarbeiten von einzelnen Datensätzen, wie beispielsweise auslesen und aktualisieren, verwendet;
– eine Archivdatenbank A-DB, welche Daten enthält, die von der operativen Datenbank O-DB übertragen (aussortiert) wurden, und welche für statistische Fragen verwendet wird, aber nicht für Fragen, die an die einzelnen Datensätze gerichtet sind. Die Übertragung von der O-DB zur A-DB kann in Schüben erfolgen;
– eine Datenbank IAM-DB, welche eine Datenbank ist, die für die Realisierung der Erfindung wesentlich ist. Diese Datenbank enthält einen Datenelementschutzkatalog mit Schutzattributen für solche Datenelementtypen, welche den Datenelementwerten in Datensätzen in der operativen Datenbank O-DB zugeordnet sind. Diese Datenbank IAM-DB ist vorzugsweise von der anderen O-DB physikalisch getrennt und für den Benutzer unzugänglich. Es können jedoch zwei oder mehr Sätze des Datenelementschutzkatalogs verfügbar sein: einerseits eine Originalversion, auf welche nur ein befugter IAM-Betreiber Zugriff hat, und andererseits eine Kopieversion, welche den Datenelementschutzkatalog von der Originalversion importiert und welche wahlweise auf demselben Dateispeicher wie die operative Datenbank O-DB gespeichert werden kann. Die beiden Versionen können voneinander entfernt sein, sich zum Beispiel in zwei verschiedenen Städten befinden.

Das Datensystem in 3 umfasst ferner eine Hardware-Komponente 10, ein Steuermodul 20 (IAM-API) und ein Programmmodul 30 (PTY-API). Die Funktion dieser drei Komponenten wird nun ausführlicher beschrieben.
HARDWARE-KOMPONENTE 10
Die Hardware-Komponente 10 fungiert als ein eigener verteilter Prozessor in einem Rechner. Er weist eine Verkapselung auf, die ihn gegen unbefugte Eingriffe völlig sicher macht, was bedeutet, dass ein Überwachen durch so genannte Ablaufverfolgungswerkzeuge nicht möglich ist.
Die Hardware-Komponente 10 kann als eine unabhängige Einheit wenigstens die folgenden Funktionen ausführen:

– Erzeugen von variablen, reversiblen und irreversiblen Verschlüsselungsalgorithmen für die PTY-Verschlüsselung und Versehen dieser Algorithmen mit den notwendigen Variablen;
– Einleiten von Änderungen von Speicheridentitäten (SID) in gespeicherten Daten gemäß PTY, einerseits Daten in der O-DB und andererseits Daten im Datenelementschutzkatalog der IAM-DB;
– Speichern von Benutzerberechtigungen mit Zugriff auf Datensätze in der O-DB; und
– Verbinden von Originalidentitäten OID mit den korrekten Datensätzen in der O-DB.

STEUERMODUL 20 (IAM-API)
Das Steuermodul steuert die Bearbeitung der Datenschutzarten, welche das System liefern kann.
Das Steuermodul führt die Verarbeitung aus, welche über eine API-Programmierschnittstelle (Anwendungsprogrammschnittstelle nach engl. Application Programm Interface) angefordert wird.
PROGRAMMMODUL 30 (PTY-API)
Das Programmmodul (PTY-API) 30 bearbeitet den Dialog zwischen der Anwendung 40, welche beteiligt ist (und ein ACS umfasst), und der Hardware-Komponente 10. Dieses Modul kann ferner Ereignisse protokollieren und die Aussortierung/Entfernung von Daten aus der operativen Datenbank O-DB steuern.
Es wird nun auf 4 Bezug genommen, welche dieselben vier Datenbanken (P-DB, O-DB, A-DB, IAM-DB) wie in 3 veranschaulicht und welche schematisch darstellt, wie die Verarbeitung von einzelnen Datenelementen gemäß der Erfindung gemäß den Regeln gesteuert wird, welche durch Schutzattribute im Datenelementschutzkatalog festgelegt sind, der in der Datenbank IAM-DB gespeichert ist.
Die Daten, die zu speichern sind, betreffen in diesem Beispiel ein bestimmtes Individuum und enthalten: (1) allgemein zugängliche Daten, wie beispielsweise Name und Adresse, (2) Erkennungsinformation, wie beispielsweise eine persönliche Kennzahl (Pcn), und (3) deskriptive Information (DI). Die allgemein zugänglichen Daten Name und Adresse werden zusammen mit der persönlichen Kennzahl (Pcn) in der offenen Datenbank P-DB gespeichert, wobei die Speicherung als Klartext erfolgen kann, da diese Information von der Art ist, die allgemein zugänglich ist.
Zum Speichern der Erkennungsinformation zusammen mit der deskriptiven Information DI werden jedoch die folgenden Schritte durchgeführt, in welchen die folgenden Bezeichnungen verwendet werden, um Verschlüsselungs- und Entschlüsselungsalgorithmen zu beschreiben. Allgemein gesprochen können die Verschlüsselungs- und Entschlüsselungsalgorithmen folgendermaßen beschrieben werden:
F_TYPE (willkürliche Zahl, Eingabedaten) = Ergebnisse,
wobei
F eine Funktion bezeichnet.
Type gibt die Art von Funktion an, wie folgt:
F_KIR = Irreversibler Verschlüsselungsalgorithmus
F_KR = Reversibler Verschlüsselungsalgorithmus
F_DKR = Entschlüsselungsalgorithmus
Willkürliche Zahl
stellt eine oder mehrere Konstanten und/oder Variablen dar, die in der Funktion F enthalten sind.
Eingabedaten
sind die zu verschlüsselnden oder zu entschlüsselnden Daten, und
Ergebnisse
geben einen eindeutigen Funktionswert für eine bestimmte Funktion an.
Schritt 1: Teilung der Information
Die Erkennungsinformation wird von der deskriptiven Information getrennt;
Schritt 2: Erzeugung der Speicheridentität SID
Eine Originalidentität OID wird basierend auf der Erkennungsinformation ausgewählt. Die OID wird hier so ausgewählt, dass sie gleich der persönlichen Kennzahl Pcn des Individuums ist. Die OID wird mittels eines irreversiblen Verschlüsselungsalgorithmus ALG1, der durch die Hardware-Komponente 10 zufällig erzeugt wird, folgendermaßen zu einer Aktualisierungsidentität UID verschlüsselt:
ALG1: F_KIR(zufällige Zahl, OID) = UID
Der ALG1 ist derart, dass Versuche, die UID zur OID zu entschlüsseln, zu einer großen Anzahl von Identitäten führen, was es unmöglich macht, eine spezifische UID mit der entsprechenden OID zu verbinden.
Dann wird die UID mittels eines reversiblen Algorithmus ALG2, der ebenfalls aufs Geratewohl durch die Hardware-Komponente 10 erzeugt wird, folgendermaßen zur Erzeugung einer Speicheridentität SID verschlüsselt:
ALG2: F_KR (zufällige Zahl, UID) = SID
Der ALG2 ist derart, dass ein entsprechender Entschlüsselungsalgorithmus ALG3 existiert, mithilfe dessen die SID entschlüsselt werden kann, um die UID wiederherzustellen.
Die Speicheridentität SID wird, wie in dem zuvor erwähnten Schritt 4 beschrieben, beim Speichern von verschlüsselten Datenelementwerten DV in der operativen Datenbank O-DB als eine verschlüsselte Datensatzkennzeichnung verwendet.
Schritt 3: Erzeugung von verschlüsselten Datenelementwerten DV:
Die deskriptive Information DI, die mit der Originalidentität OID verbunden ist, wird in einen oder mehr verschlüsselte Datenelementwerte DV umgewandelt, die jeweils mit einem Datenelementtyp DT verbunden sind.
Die Verschlüsselung erfolgt, wie im Folgenden beschrieben, mit einer reversiblen Verschlüsselungsfunktion F_KR, welche wie die zuvor erwähnten Algorithmen ALG1 und ALG2 ebenfalls aufs Geratewohl durch die Hardware-Komponente 10 erzeugt wird. Die Erfindung zeichnet sich durch einen zwingenden Anruf aus, der hier an den Datenelementschutzkatalog in der Datenbank IAM-DB gesendet wird, um automatisch das Schutzattribut einzuholen, das mit dem betreffenden Datenelementtyp verbunden ist und das die „Stärke" oder den Grad angibt, mit dem die Verschlüsselung der deskriptiven Daten zu erfolgen hat, um den Datenelementwert DV zu erzeugen.
Die Tabelle, welche in 4 unter der Datenbank IAM-DB dargestellt ist, symbolisiert einen beispielhaften Inhalt des Datenelementschutzkatalogs, der hier mit DC bezeichnet ist. Als ein Beispiel kann hier angenommen werden, dass die Schutzfunktion Func1 dem „Verschlüsselungsgrad" entspricht. Wenn die betreffende deskriptive Information DI als ein Datenelementwert, der dem spezifischen Datenelementtyp DT1 im Datenelementschutzkatalog zugeordnet ist, zu speichern ist, wird das Schutzattribut „5", das im Datenelementschutzkatalog registriert ist, in diesem Fall automatisch eingeholt. Die betreffende deskriptive Information DI wird auf diese Weise automatisch und zwingend mit der Stärke „5" verschlüsselt, um einen verschlüsselten Datenelementwert DV folgendermaßen zu erzeugen:
F_KR (zufällige Zahl, DI) = verschlüsselter Daten elementwert DV
Zum Speichern eines weniger vertraulichen Datenelements, zum Beispiel eines Datenelements des Datenelementtyps DT3, hätte der zwingende Anruf an den Datenelementschutzkatalog in der IAM-DB stattdessen dazu geführt, dass das Schutzattribut „Nein" eingeholt worden wäre, in welchem Fall keine Verschlüsselung an den betreffenden deskriptiven Daten vorgenommen worden wäre, welche dann als Klartext in der operativen Datenbank O-DB hätten gespeichert werden können.
Schritt 4: Speichern von Datensätzen in der operativen Datenbank O-DB
Die verschlüsselte Speicheridentität SID gemäß Schritt 2 zusammen mit dem entsprechenden Datenelementwert oder den entsprechenden Datenelementwerten DV gemäß Schritt 3 werden als ein Datensatz in der operativen Datenbank O-DB gespeichert.
Wie aus den vorstehenden Darlegungen hervorgeht, hat ein gespeicherter Informationsdatensatz P das folgende allgemeine Aussehen:
Die Originalidentität OID wird gemäß dem PTY-Prinzip in zwei Schritten verschlüsselt, wobei der erste irreversibel und der zweite reversibel ist. Demnach ist es weder möglich, die deskriptive Information DI zusammen mit einer Speicheridentität SID, die nie mit der Originalidentität OID verbunden werden kann, zu speichern noch „Gleiten" zu erzeugen, d. h. was im Zeitablauf Speicheridentitäten SID ändert, während die Möglichkeit des Lokalisierens der zugeordneten deskriptiven Information DI, die gespeichert ist, für eine bestimmte Originalidentität OID bewahrt wird.
Die deskriptiven Daten DI werden gemäß den Schutzattributen, welche mit jedem einzelnen Datenelement verbunden sind, gespeichert. Dies führt zu einem noch höheren Niveau von Schutz und einem höheren Grad von Flexibilität im Hinblick auf das Aufstellen von Regeln, wie vertrauliche Daten bis hinab zum Datenelementniveau verwendet werden dürfen und verwendet werden können, und ihre kontinuierliche Anpassung.
Um das Niveau von Schutz weiter zu erhöhen, wird der Datenelementschutzkatalog DC vorzugsweise in der IAM-DB in verschlüsselter Form gemäß dem PTY-Prinzip gespeichert, in welchem Fall zum Beispiel die Datenelementtypen der zuvor erwähnten Speicheridentität entsprechen und die Schutzattribute den zuvor erwähnten deskriptiven Daten oder Datenelementwerten entsprechen, wie in 4 schematisch veranschaulicht. Dies verhindert wirksam jeden Versuch, den Datenelementschutz durch unbefugten Zugriff und Interpretation des Inhalts des Datenelementschutzkatalogs zu umgehen.
In der veranschaulichten Ausführungsform kann die PTY demnach die folgenden Funktionen haben:

– Schützen der Originalidentität OID in verschlüsselter Form (SID) in der operativen Datenbank O-DB (wie aus dem erwähnten WO95/15628 bekannt),
– Schützen von Information in der IAM-DB, insbesondere der Schutzattribute des Datenelementschutzkatalogs und der zugeordneten Datensatzkennzeichnung, und
– Schützen von deskriptiver Information DI in der Form von verschlüsselten Datenelementwerten DV für die Datenelementtypen, welche den entsprechenden Schutz im Datenelementschutzkatalog aktiviert aufweisen, und gemäß den entsprechenden Schutzattributen.

FUNKTIONALITÄTSSCHUTZ
In der zuvor beschriebenen Ausführungsform der Prozedur zum Eingeben von Daten in der operativen Datenbank O-DB wurde bis jetzt nur der „Grad von Verschlüsselung" als Datenelementschutzattribut im Datenelementschutzkatalog DC erörtert. Dies ist jedoch nur ein Beispiel unter etlichen möglichen Schutzattributen im Datenelementschutzkatalog, welcher normalerweise eine Mehrzahl von Schutzattributen für jedes Datenelement anbietet. Bevorzugte Schutzattribute wurden zuvor in der allgemeinen Beschreibung angegeben.
Ein besonders interessantes Schutzattribut sind „geschützte Programme". Die Verwendung dieses Datenelementschutzattributs bedeutet, dass das Datensystem eine neue Art von Schutz anbieten kann, welche hier „Funktionalitätsschutz" genannt wird, was bedeutet, dass nur anerkannte und geprüfte Programme im System bei der Verarbeitung von Daten verwendet werden dürfen und verwendet werden können. Es ist zu erwähnen, dass diese Art von Schutz gemäß der Erfindung noch auf dem Datenelementniveau ist.
Nehmen wir nunmehr zu Veranschaulichungszwecken an, dass Func2 im Datenelementschutzkatalog DC in 4 diesem Schutzattribut entspricht und dass Datenelemente des Datenelementtyps DT1 beziehungsweise DT2 nur mit den anerkannten Anwendungen oder Programmen P1 beziehungsweise P2 verarbeitet werden dürfen. Die unbefugte Bearbeitung der entsprechenden Datenelemente zum Beispiel mittels eines anderen Programms P3 oder einer modifizierten Version P1' von P1 soll verhindert werden. Als Schutzattribut im Datenelementschutzkatalog sind daher Daten gespeichert, welche P1 und P2 identifizieren. In einer bevorzugten Ausführungsform wird eine kryptografische Prüfsumme P1* beziehungsweise P2* basierend auf jedem anerkannten Programm P1 beziehungsweise P2 auf eine an sich bekannte Weise erzeugt. Diese Prüfsummen können so betrachtet werden, dass sie einen eindeutigen Fingerabdruck der jeweiligen anerkannten Programme bilden, und diese Fingerabdrücke können als Schutzattribute im Datenelementschutzkatalog gespeichert werden, wie in 4 schematisch dargestellt. Es ist jedoch zu erwähnen, dass diese Prüfsummen für anerkannte Programme wahlweise in ihrem eigenen Datenelementschutzkatalog zur Registrierung von anerkannten Programmen getrennt vom Datenelementschutzkatalog mit Schutzattributen für Verschlüsselungsstärke gespeichert werden können.
Wenn die zuletzt erwähnte Art von Schutz „geschützte Programme" verwendet wird, ist auch zu beachten, dass das System in Verbindung mit einer benutzerveranlassten Maßnahme, welche das Verarbeiten eines bestimmten Datenelementwerts beabsichtigt, zum Beispiel Eingeben eines neuen Datenelementwerts in einem bestimmten Datensatz, keine vollständige Überprüfung aller im System anerkannten Programme durchzuführen braucht. Wenn zum Beispiel der Benutzer versucht, ein Programm P3 zum Eingeben eines neuen Datenelementwerts in der operativen Datenbank O-DB zu verwenden, wird ein zwingender Anruf an den Datenelementschutzkatalog in Verbindung mit dem entsprechenden Daten elementtyp, zum Beispiel DT1, gesendet. Das zugeordnete Schutzattribut P1* wird dann vom Datenelementschutzkatalog eingeholt, was bedeutet, dass solch ein Datenelementwert nut mittels des Programms P1 gespeichert werden darf. Der Versuch, den Datenelementwert mittels des Programms P3 zu registrieren, würde scheitern.
Durch periodische Verwendung des zuvor beschriebenen Funktionalitätsschutzes ist es möglich, zu enthüllen und/oder zu verhindern, dass eine unbefugte Person (zum Beispiel ein „Hacker") mittels eines nicht anerkannten Programms in das System einbricht und deskriptive Daten auf eine derartige Weise modifiziert und/oder hinzufügt, dass die deskriptiven Daten dann für den Datensatz identifizierend sind. Es wird somit nicht zugelassen, dass die Datenelementwerte in der operativen Datenbank O-DB identifizierend werden.
VERFOLGBARKEIT/PROTOKOLLIERUNG
„Protokollierung" oder „Verfolgbarkeit" ist eine andere Art von Schutz, welche gemäß der Erfindung mit einem Datenelementtyp im Datenelementschutzkatalog verbunden werden kann. Wenn dieser Schutz für einen bestimmten Datenelementtyp aktiviert wird, führt jede Verarbeitung der entsprechenden Datenelementwerte in der operativen Datenbank O-DB automatisch und zwingend dazu, dass relevante Information über die Verarbeitung („Benutzer", „Datum", „Datensatz", „Benutzerprogramm usw.) auf eine geeignete Weise protokolliert wird, so dass es basierend auf dem Protokoll möglich ist, nachträglich zu erforschen, wer die betreffenden Datenelementwerte wann, mithilfe welches Programms usw. verarbeitet hat.
AUSLESEN VON DATEN AUS DER OPERATIVEN DATENBANK O-DB
In Verbindung mit einer benutzerveranlassten Maßnahme, welche das Auslesen/Ändern von Datenelementwerten in den gespeicherten Datensätzen in der operativen Datenbank O-DB beabsichtigt, werden die folgenden Schritte ausgeführt, welche insbesondere auch einen zwingenden Anruf an den Datenelementschutzkatalog und „Entpacken" der Daten, welche durch die erhobenen Schutzattribute automatisch und zwingend gesteuert werden, umfassen.
Schritt 1: Der Datensatz wird durch Erzeugen der betreffenden Speicheridentität SID basierend auf der Originalidentität OID, (Pcn), die dem auszulesenden Datenelementwert DV zugeordnet ist, folgendermaßen identifiziert:
F_KR (F_KIR (OID)) = SID
Schritt 2: Wenn der Datensatz mittels der SID gefunden wurde, wird der verschlüsselte Datenelementwert DV (d. h. die verschlüsselten deskriptiven Daten, die auszulesen sind) mittels eines Entschlüsselungsalgorithmus F_DKR folgendermaßen entschlüsselt:
F_DKR (DV) = deskriptive Daten (Klartext)
Die Ausführung dieser Entschlüsselung des Datenelementwerts erfordert jedoch, dass zuerst das die Verschlüsselung steuernde Schutzattribut des Datenelements, d. h. das Attribut, welches angibt, mit welcher Stärke oder auf welchem Niveau der in der O-DB gespeicherte Datenelementwert DV verschlüsselt wurde, durch das System vom Datenelementschutzkatalog eingeholt wird. Wie in der zuvor beschriebenen Prozedur zum Eingeben von Daten in der O-DB wird somit auch beim Auslesen ein zwingender Anruf an den Datenelementschutzkatalog DC gesendet, um Information, welche zum Durchführen der Verarbeitung, in diesem Fall des Entpackens, notwendig ist, einzuholen.
Es ist zu erkennen, dass solch ein zwingender Anruf an den Datenelementschutzkatalog DC bei der Durchführung eines Versuchs des Auslesens aus mehreren Gründen in Abhängigkeit vom betreffenden Schutzattribut, welches mit dem/den auszulesenden Datenelementwert/en verbunden ist, zum völligen oder teilweisen Scheitern des Versuchs führen kann. Zum Beispiel kann der Versuch des Auslesens infolge dessen, dass der Benutzer versucht, ein nicht anerkanntes Programm zu verwenden, und/oder nicht befugt ist, den betroffenen Begriff auszulesen, unterbrochen werden.
Wenn der Datenelementschutzkatalog verschlüsselt ist, kann der Decodierschlüssel an einer von der ersten und zweiten Datenbank getrennten Speicherstelle gespeichert werden.
5 stellt ein Beispiel einer Benutzeroberfläche in der Form eines Dialogfeldes dar, mithilfe dessen eine Person, die für den IAM verantwortlich ist, d. h. eine Person, die für die Sicherheit verantwortlich ist, die Schutzattribute, welche im Datenelementschutzkatalog festgelegt sind, auslesen und/oder ändern kann. Im Beispiel in 5 wurden die Datenelementtypen „Wohngeld" und „Sozialbeihilfe" beide mit Schutzattributen versehen, welche Verschlüsselung, Aussortierung, Protokollierung und Eigentümer betreffen. Außerdem hat in Untermenüs die Registrierung von befugten Benutzern und geschützten Programmen, welche mit dem Datenelementtyp „Sozialbeihilfe" verbunden sind, stattgefunden.

Claims

Verfahren zum Verarbeiten von Daten, welche zu schützen sind, umfassend die Maßnahme des Speicherns der Daten als verschlüsselte Datenelementwerte (DV) in Datensätzen (P) in einer ersten Datenbank (O-DB), wobei jeder Datenelementwert mit einem entsprechenden Datenelementtyp (DT) verbunden ist, und gekennzeichnet durch die folgenden Schritte: Speichern in einer zweiten Datenbank (IAM-DB) eines Datenelementschutzkatalogs (DC), welcher für jeden einzelnen Datenelementtyp (DT) ein oder mehrere Schutzattribute enthält, welche Verarbeitungsregeln für Datenelementwerte (DV) festlegen, welche in der ersten Datenbank (O-DB) mit dem einzelnen Datenelementtyp (DT) verbunden sind, für jede benutzerveranlasste Maßnahme, welche das Verarbeiten eines bestimmten Datenelementwerts (DV) in der ersten Datenbank (O-DB) beabsichtigt, anfängliches Herstellen eines zwingenden Anrufs an den Datenelementschutzkatalog, um das Schutzattribut oder die Schutzattribute, welche dem entsprechenden Datenelementtyp zugeordnet sind, einzuholen, und zwingendes Steuern des Benutzers Verarbeiten des bestimmten Datenelementwerts in Übereinstimmung mit dem erhobenen Schutzattribut oder den erhobenen Schutzattributen.
Verfahren nach Anspruch 1, welches ferner die Maßnahme des Speicherns des Schutzattributs oder der Schutzatt ribute des Datenelementkatalogs (DC) in verschlüsselter Form in der zweiten Datenbank (IAM-DB) und bei Einholen des Schutzattributs oder der Schutzattribute aus dem Datenelementschutzkatalog (DC) Bewirken von Entschlüsselung davon umfasst.
Verfahren nach einem der vorangehenden Ansprüche, wobei jeder Datensatz (P) in der ersten Datenbank (O-DB) eine Datensatzkennzeichnung aufweist, und wobei das Verfahren ferner die Maßnahme des Speicherns der Datensatzkennzeichnung in verschlüsselter Form (SID) in der ersten Datenbank (O-DB) umfasst.
Verfahren nach einem der vorangehenden Ansprüche, wobei die Verschlüsselung von Daten in der ersten Datenbank (O-DB) und/oder die Verschlüsselung von Daten in der zweiten Datenbank (IAM-DB) gemäß dem PROTEGRITY-PTY-Prinzip mit gleitender Speicheridentität ausgeführt werden.
Verfahren nach einem der vorangehenden Ansprüche, wobei das Schutzattribut oder die Schutzattribute der Datenelementtypen Attribute umfassen, welche Regeln zur Verschlüsselung der entsprechenden Datenelementwerte in der ersten Datenbank (O-DB) festlegen.
Verfahren nach einem der vorangehenden Ansprüche, wobei das Schutzattribut oder die Schutzattribute der Datenelementtypen Attribute umfassen, welche Regeln dafür festlegen, welches Programm oder welche Programme oder Programmversionen zum Verwalten der entsprechenden Datenelementwerte in der ersten Datenbank (O-DB) verwendet werden dürfen.
Verfahren nach einem der vorangehenden Ansprüche, wobei das Schutzattribut oder die Schutzattribute der Datenelementtypen Attribute umfassen, welche Regeln zum Protokollieren der entsprechenden Datenelementwerte in der ersten Datenbank (O-DB) festlegen.
Vorrichtung zum Verarbeiten von Daten, welche zu schützen sind, umfassend eine erste Datenbank (O-DB) zum Speichern der Daten als verschlüsselte Datenelementwerte (DV) in Datensätzen (P), wobei jeder Datenelementwert mit einem entsprechenden Datenelementtyp (DT) verbunden ist, und gekennzeichnet durch eine zweite Datenbank (IAM-DB) zum Speichern eines Datenelementschutzkatalogs (DC), welcher für jeden einzelnen Datenelementtyp (DT) ein oder mehrere Schutzattribute enthält, welche Verarbeitungsregeln für Datenelementwerte (DV) festlegen, welche in der ersten Datenbank (O-DB) mit dem einzelnen Datenelementtyp (DT) verbunden sind, Mittel, welche so ausgelegt sind, dass sie bei jeder benutzerveranlassten Maßnahme, welche das Verarbeiten eines bestimmten Datenelementwerts (DV) in der ersten Datenbank (O-DB) beabsichtigt, anfänglich einen zwingenden Anruf an den Datenelementschutzkatalog herstellen, um das Schutzattribut oder die Schutzattribute, welche den entsprechenden Datenelementtypen zugeordnet sind, einzuholen, und Mittel, welche so ausgelegt sind, dass sie des Benutzers Verarbeiten des bestimmten Datenelementwerts in Übereinstimmung mit dem erhobenen Schutzattribut oder den erhobenen Schutzattributen zwingend steuern.