Zusammenfassung

Im Rahmen der Arbeit am Projekt TheMPO (= Therapie-Unterstützung und Management in der Pädiatrischen Onkologie) wurde daher ein Sicherheitskonzept entworfen, das unbefugtes Lesen oder Ändern von Daten auf allen Ebenen verhindern soll. Grundlage ist ein mehrstufiges Verschlüsselungsverfahren, das neben der online-Verschlüsselung von Daten auch die Möglichkeit zur kryptographischen Signatur von Dokumenten (z. B. von Therapieverordnungen durch den Arzt) bietet. Der einzelne Benutzer braucht dazu eine vertrauenswürdige Ablage (PSE = personal secure environment) für seine persönlichen Schlüssel zur Chiffrierung und Dechiffrierung der Daten und zur kryptographischen Signatur. Im Idealfall sollte dieses PSE durch eine persönliche Chipkarte für jeden Benutzer realisiert werden. Solange passende Chipkarten technisch nicht verfügbar sind, werden sie durch persönliche Disketten simuliert. Eine solche ist ihrerseits, um Mißbrauchsmöglichkeiten einzudämmen, durch eine `PIN' verschlüsselt, die dem Benutzer als Paßwort zugeordnet ist und die er bei der Anmeldung eingeben muß. Der Benutzer selbst braucht sich nur diese PIN zu merken; alle übrigen Informationen werden der Chipkarte oder Diskette entnommen und vom System automatisch umgesetzt.

Datenschutzanforderungen in einem klinischen Anwendungssystem

Klinische Anwendungssysteme dieser Art laufen in der Regel auf alleinstehenden oder vernetzten PCs, zunehmend auch auf UNIX-Rechnern, jedenfalls in Systemumgebungen, die kaum Sicherheitsfunktionen bieten, also "offen" im Sinne des Datenschutzes sind. Auch wenn die Anwendung selbst die differenzierte Festlegung von Zugriffsrechten gestattet, sind die Daten doch auf der Ebene des Betriebssystems für jedermann sichtbar; unter MS-DOS ist das evident, UNIX bietet elementare, aber nicht ausreichende Schutzfunktionen. Handelt es sich dabei um personenbezogene Daten, z.B. Patientendaten, sind die Vorschriften des Datenschutzrechts verletzt. Im Pflichtenheft von TheMPO sind daher folgende Anforderungen festgelegt:

• Die Patientendaten dürfen außerhalb des Anwendungsprogramms nicht lesbar sein.
• Der Datenzugriff muß innerhalb des Anwendungsprogramms durch eine Berechtigungsmatrix geregelt sein.
• Ärztliche Verordnungen müssen beweissicher unterzeichnet sein.
• Die Datenschutzmaßnahmen sollen eine angemessene Sicherheitsstufe gewährleisten.

Lösungsansatz

Kryptographische Grundlagen

• Verschlüsselungsverfahren, z. B. "DES" (`Data Encryption Standard'),
• Signaturverfahren, z. B. das aus "MD5" (`Message Digest') und "RSA" (nach RIVEST, SHAMIR und ADLEMAN) zusammengesetzte.

Patientendaten werden dann vom Anwendungsprogramm ver- bzw. entschlüsselt. Dabei wird ein vom Benutzer unabhängiger Hauptschlüssel verwendet, der aber datensatzspezifisch (etwa mit der Aufnahmenummer des Patienten) modifiziert wird; diese Modifikation soll eine mögliche Schwächung des Verfahrens verhindern, die durch die tausendfache Verwendung von immer dem gleichen Schlüssel entstehen könnte.

Verordnungen werden signiert, indem ihnen eine verschlüsselte Prüfsumme (in einem dafür vorgesehenen Datenfeld) angehängt wird. Die Prüfsumme wird mit einer sogenannten Hash-Funktion (wie MD5) gebildet; es ist hierbei unmöglich, ein Dokument zu ändern, ohne auch eine andere Prüfsumme zu erhalten. Das alleine ist noch kein Schutz, da ein Angreifer zu einem gefälschten Dokument auch die passende Prüfsumme erzeugen kann. Daher wird die Prüfsumme mit dem privaten Signaturschlüssel des Unterzeichners verschlüsselt; dazu braucht man ein asymmetrisches Verschlüsselungsverfahren (wie RSA), bei dem es unmöglich ist, aus dem ("öffentlich bekannten") Prüfschlüssel des Unterzeichners Kenntnisse über den Signaturschlüssel abzuleiten. Jeder kann die Gültigkeit der Unterschrift (und die Echtheit des gesamten Dokuments!) mit Hilfe des Prüfschlüssels nachprüfen.

Das Personal Secure Environment

Wo wird nun dieses PSE aufbewahrt? Dazu gibt es drei Möglichkeiten mit zunehmender Sicherheit:

• eine Datei im System,
• eine persönliche Diskette,
• eine Chipkarte.

Gegenstück des PSE ist ein öffentliches Verzeichnis der Prüfschlüssel, das vom Systemverwalter signiert wird. Und damit dieses wirklich vertrauenswürdig ist, verwahrt jeder Benutzer den Prüfschlüssel des Systemverwalters sicher auf: in seinem eigenen PSE. Durch diese Maßnahme wird das Signaturverfahren erst beweissicher. Der Systemverwalter ist somit eine absolute Vertrauensinstanz in diesem System.

Was steht nun alles im PSE? Alles, was der Benutzer wissen muß, aber sich nicht merken kann, und alles, worauf er sich verlassen muß:

• ein Kennwort, das zur Prüfung der korrekten Entschlüsselung und damit zur Verifikation des Schlüssels dient (etwa der Name der Anwendung),
• der Name des Besitzers,
• der Hauptschlüssel der Anwendung,
• der private Signaturschlüssel,
• der Prüfschlüssel des Systemverwalters.

Der Überprüfungsmechanismus

Ein Benutzerwechsel soll ohne Beenden der Anwendung durch Wechsel der Diskette möglich sein. Er wird durch Wahl des Menüpunktes "Benutzerwechsel" oder direkt durch (gegebenenfalls Auswerfen der alten und) Einlegen einer neuen Benutzer-Diskette eingeleitet. Im ersten Fall wird ebenfalls die alte Diskette, sofern sie noch eingelegt ist, ausgeworfen und eine neue verlangt. In beiden Fällen läuft anschließend die beschriebene Überprüfungsprozedur ab.

Die Sicherheitsarchitektur

Abbildung 1. Das Sicherheitsschema für Datenschutz und Signatur

Während das Signaturverfahren problemlos in die Anwendung integriert werden kann, bietet die Verschlüsselung technische Probleme. Sie wird in einen Programmteil namens "kryptographischer Treiber" gepackt, für den es folgende Optionen gibt:

• Ein kryptographischer Gerätetreiber, der als Hardwarelösung oder Betriebssystemzusatz realisiert ist. Solche Treiber werden im PC-Bereich von den gängigen Sicherheitssystemen verwendet. Im UNIX-Bereich scheint der Markt hierfür noch leer zu sein.
• Eine Verschlüsselungsfunktion, die in ein Datenbanksystem eingebaut ist.
• Bei selbstprogrammierter Datenverwaltung lassen sich die Verschlüsselungsfunktionen in den Lade- und Speicherroutinen unterbringen.
• Als Notlösung kann man bei Verwendung einer Datenbank die separate Verschlüsselung der relevanten Felder ins Auge fassen.

Abgestufte Zugriffsregelungen

	Datengruppe
Benutzergruppe	1	2	...	n
A	w	w	...	r
B	w	r	...	-
.	.	.		.
Z	r	r	...	-

Abbildung 2. Die Zugriffsmatrix

Abbildung 3. Paßwörter für abgestufte Zugriffsrechte

Um solche differenzierten Zugriffssperren auch auf der Betriebssystemebene abzusichern, reicht das oben skizzierte Verfahren mit einem Hauptschlüssel für alle Daten nicht aus. Statt dessen ist für jede Datengruppe ein gesonderter Schlüssel zu verwenden gemäß Abbildung 3. Der Benutzer hat in seinem PSE die Schlüssel genau der Datengruppen, auf die er Zugriffsberechtigung hat; für die anderen Datengruppen hat er unsinnige Dummy-Schlüssel. Will er die Daten außerhalb der Anwendung lesen, muß er sich zunächst das Verschlüsselungsverfahren in selbständig lauffähiger Form verschaffen, kann dann aber mit Hilfe der Paßwörter, über die er verfügt, auch nur die ihm erlaubten Daten entziffern. Der Unterschied zwischen Schreib- und Leserechten wird hier nicht gemacht. Er scheint aus datenschutzrechtlichen Überlegungen nicht zwingend, und signaturgeschützte Daten sind sowieso vor unbemerkter Fälschung gefeit. Für die Zugriffsmatrix im Beispiel hätte also ein Benutzer der Gruppe B die korrekten Schlüssel für die Datengruppen 1 und 2, aber einen unbrauchbaren für die Datengruppe n.

Diskussion

Verbleibende Sicherheitsprobleme

Paßwortfallen.

Dazu müßte der Angreifer in der Hardware eine "Wanze" installieren, die den Datenverkehr im System mithört; bei einem vernetzten System wären auch die Übertragungsleitungen abhörbar. In der Software könnte er ein "Trojanisches Pferd" installieren, das einen Teil des Datenverkehrs parallel in eine Datei abzweigt.

Klartextattacke.

Der Angreifer kann versuchen, das Verschlüsselungsverfahren zu brechen mit Hilfe seiner Kenntnis (oder Ahnung) der Klartexte zu gewissen verschlüsselten Daten.

Gedanken zur praktischen Anwendung

Bei aller Beachtung der Bequemlichkeit des Benutzers besteht doch ein Zielkonflikt zwischen Datenschutz und Ergonomie. Es ist sicher keine nennenswerte Abschwächung des Systems, wenn für den Routinebetrieb auf der Station ein gemeinsames PSE mit Minimalrechten vorgesehen wird, damit nicht jede Schwester, die schnell mal etwas nachsehen will, eine umständliche Überprüfung über sich ergehen lassen muß. Für die Ausübung weitergehender Rechte ist die Überprüfung jedoch unvermeidlich. Kann man es einem Arzt zumuten, bei Verordnungen seine Diskette zu zücken und ein Paßwort einzugeben? Immerhin wird ihm dadurch zugesichert, daß ihm niemand fremde Fehler unterschieben kann.

Es gibt sicher keine Patentlösungen. Ein Sicherheitssystem muß immer unter Aufwands-Nutzen-Äbwägungen konzipiert und auf die konkrete Situation zugeschneidert werden. Insbesondere bei Einbindung in ein Kliniksinformationssystem sind natürlich auch einige Randbedingungen zu beachten. Wirksamer Datenschutz in offenen und vernetzten Systemen ist nur mit kryptographischen Verfahren möglich. Konkrete Vorschläge für die notwendige "kryptographische Infrastruktur" (auch für Kliniksinformationssysteme) müssen von den Medizin-Informatikern kommen.

Literatur

[Beu]

Albrecht Beutelspacher: Kryptologie. Vieweg, Braunschweig 1987.

[Pom]

Klaus Pommerening: Datenschutz und Datensicherheit. BI-Wissenschaftsverlag, Mannheim usw. 1991.

[Sec]

Wolfgang Schneider: SecuDE Overwiew. Gesellschaft für Mathematik und Datenverarbeitung, Darmstadt 1992.

[ZSI]

Zentralstelle für Sicherheit in der Informationstechnik (Hrsg.): IT-Sicherheitskriterien -- Kriterien für die Bewertung der Sicherheit von Systemen der Informationstechnik (IT). Bundesanzeiger, Köln 1989.

[ZS2]

Zentralstelle für Sicherheit in der Informationstechnik (Hrsg.): IT-Evaluationshandbuch -- Handbuch für die Prüfung der Sicherheit von Systemen der Informationstechnik (IT). Bundesanzeiger, Köln 1990.