DE69332633T2

DE69332633T2 - Verfahren und Sytem um, auf Bescheinigung gestützt, Alias zu entdecken

Info

Publication number: DE69332633T2
Application number: DE69332633T
Authority: DE
Inventors: George Emil Gajnak; William Robert Shockley
Original assignee: Compaq Computer Corp
Current assignee: Compaq Computer Corp
Priority date: 1992-07-20
Filing date: 1993-06-01
Publication date: 2003-11-06
Anticipated expiration: 2013-06-02
Also published as: EP0581421A1; US5534855A; JP2686218B2; EP0581421B1; DE69332633D1; JPH0695947A

Description

Hintergrund der Erfindung

Die vorliegende Erfindung bezieht sich auf Computersysteme und insbesondere auf ein System zur Erfassung von Computer-Benutzerkonten- Pseudonymen.
Auf diesem Gebiet ist es bekannt, dass effektive Computer-Betriebssystem- Sicherheitsmaßnahmen dazu beitragen, einen unerlaubten Zugang und den Diebstahl betriebseigener Software, von Softwareplänen und von Computerzeit zu verhindern. Diese Maßnahmen können auch Ausrüstungsgegenstände, Software und Computerdateien gegenüber Schäden durch Einflussnahme von außen schützen. Die Quelle eines Sicherheitsbruches auf einem Computersystem kann normalerweise auf eine von drei Kategorien zurückgeführt werden: Benutzer- Unverantwortlichkeit, Benutzer-Vortasten oder Benutzer-Eindringen.
Eine Benutzer-Unverantwortlichkeit bezieht sich normalerweise auf Situationen, wo ein autorisierter Benutzer absichtlich oder unabsichtlich einen beträchtlichen Schaden verursacht. Ein Beispiel wäre ein Computerbenutzer, der die Erlaubnis hat, auf bestimmte Computerdateien zuzugreifen, und der eine erlaubte Kopie einer Schlüsseldatei zum unerlaubten Transfer anfertigt. Diese Art des Bruches kann als ein Vertrauensbruch bezeichnet werden. Ein Computerbetriebssystem kann wenig tun, um Sites gegenüber dieser Quelle von Sicherheitsversagen zu schützen, da der anfängliche Zugriff auf die Datei vollkommen erlaubt war und der Bruch durch den unerlaubten Transfer der Früchte des erlaubten Zugriffs zustande kam.
Beim Benutzer-Vortasten handelt es sich um Situationen, wo ein Computerbenutzer einen unerlaubten Zugang durch die Ausnutzung unzureichend geschützter Teile des Computersystems erlangt. Bei diesem tastenden Vorgehen werden typischerweise Einrichtungen auf höchster Ebene erforscht, zu welchen ein Computerbenutzer einen legitimen Zugang hat, um durch das Computersystem zu schnüffeln.
Bei dem Benutzer-Eindringen wird ein Versuch unternommen, bestehende Sicherheitskontrollen zu umgehen, indem relativ unbekannte Fehler in ihrer Implementierung gesucht werden.
Zum Schutz gegen Benutzer-Vortasten und Benutzer-Eindringen weisen Computersysteme typischerweise Verfahren zur Authentifizierung der Identität eines Benutzers auf. Die Authentifizierung einer Benutzeridentität in einem Computersystem ist die Überprüfung einer Benutzeridentität, so dass die Sicherheitsvorkehrungen in korrekter Weise auf Anfragen von diesem Benutzer angewendet werden können. Bei der Authentifizierung werden typischerweise die Ausweisungsangaben eines Menschen, wie zum Beispiel biometrische Information, Verschlüsselungsinformation und so weiter überprüft.
In auf mittlerer bis hoher Ebene verteilten Computersystemen ist es oft der Fall, dass ein bestimmter Computerbenutzer über mehrere unterschiedliche Computerbenutzerkonten Zugang zum Computernetz hat, von denen jedes legitim ist. Zum Beispiel kann es sein, dass ein Computerbenutzer über ein Computersystem eines Mitarbeiters an einem Arbeitsplatz Zugang zum Computer über das Netzwerk hat, sowie über einen PC mit einem Modem zuhause. Wo Aufgabenteilungen oder ähnliche Verfahren von einem Computernetzserver durchgesetzt werden sollen, sollten Verfahren existieren, durch welche der Computernetzserver feststellen kann, ob zwei unterschiedliche Computeranfragen von voneinander getrennten oder unterschiedlichen Menschen sind oder nicht. Wo ein Mensch auf zwei oder mehr Benutzerkonten zugreifen kann, sind diese Konten als Pseudonymkonten dieses einen Menschen bekannt.
Daher wird ein Pseudonym als eine alternative Identität für einen Menschen definiert, der für seine/ihre Handlungen verantwortlich ist. Wo die Möglichkeit von Pseudonym-Computerbenutzerkonten existiert, ist der einfache Vergleich von Authentifizierungsdaten, z. B. Passwörtern, öffentlichen Schlüsseln usw. zum Verhindern einer unerwünschten Pseudonymbildung eines Benutzers schon einfach deswegen ungenügend, weil typischerweise keine Steuerungsmechanismen wirksam sind, damit ein Benutzer daran gehindert wird, getrennte Benutzerkonten zu erhalten, welche potentiell getrennte Authentifizierungsinformation enthalten.
Ein Typ einer Computersicherheit, die in vielen Geschäfts- und Handels- Anwendungen erforderlich ist, wird inzwischen als ein Verfahren zur Aufgabentrennung (Separation of Duties) genannt. Bei dieser Vorgehensweise müssen für wesentliche Geschäftsvorgänge bestimmte Schritte dieses Geschäftsvorgangs von unterschiedlichen Menschen durchgeführt werden. Der Zweck dieses Verfahrens ist das Verteilen von Verantwortlichkeit für eine Transaktion auf mehrere unterschiedliche Leute, so dass nicht eine allein handelnde Person den fraglichen Vorgang verursachen kann. Dabei wird angenommen, dass voneinander getrennte oder unterschiedliche Menschen mit unterschiedlichen Verantwortlichkeiten füreinander als Prüfinstanz auftreten.
Ein Beispiel eines Verfahrens für die Aufgabentrennung, die im täglichen Leben angetroffen werden kann, wäre zum Beispiel ein Schließfach in einer Bank. Eine Bank stellt üblicherweise die Anforderung, dass ein Bankangestellter und der Schließfachbesitzer zwei voneinander getrennte Schlüssel verwenden und dass beide eine Kladde abzeichnen, wenn der Inhaber des Schließfaches auf das Schließfach zugreifen will. Die Anforderung zweier Schlüssel wird als Zugangskontrolle (Access Control) bezeichnet. Die Anforderung, dass beide Menschen eine Kladde abzeichnen, wird als Prüfungskontrolle (Audit Control) bezeichnet. Die Vorschriften der Bank sind so, dass der Benutzer und der Bankangestellte zwei voneinander getrennte oder unterschiedliche Menschen sein müssen. Ein weiteres Beispiel wäre da, wo ein Geschäftsangestellter ein Spesenformular einreicht und möchte, dass ihm für diese Spesen ein Firmenscheck ausgestellt wird. Die Vorschriften in der Firma würden dann erfordern, dass der Spesenscheck nicht von der gleichen Person unterschrieben und bewilligt werden darf. Diese beiden Beispiele veranschaulichen, dass das Prinzip einer Erfordernis einer Aufgabentrennung für manuelle Systeme weit verbreitet ist.
Mehrere Vorgehensweisen wurden in der Vergangenheit für die Durchsetzung von Aufgabenteilungsplänen vorgeschlagen. Das am häufigsten verwendete Verfahren zur Durchsetzung einer Aufgabentrennung in automatischen Computersystemen bestand darin, dass der Sicherheitsadministrator voneinander getrennte Gruppen oder Rollen definiert und manuell sicherstellt, dass die Zuweisung von Menschen auf kritische Gruppen oder Rollen sich nicht überschneidet. Ein Problem bei dieser Vorgehensweise ist, dass sie eine Bedrohung nicht verhindert, die von einem bestimmten Menschen ausgeht, der von zwei verschiedenen Konten her Zugang auf ein Computersystem hat.
Bekannte Verfahren zur Authentifizierung und Identifizierung von Benutzern durch Benutzerkonten setzten allgemein voraus, dass eine Benutzerkontenpseudonymbildung durch die Verwendung von Betriebs- oder Vorgehensregeln verhindert wird. Verfahren zur Durchsetzung eines Aufgabenteilungsplans haben angenommen, dass keine Pseudonymbildung auftritt und das authentisierbare Benutzerkontenidentitäten daher ebenfalls zum Identifizieren von Menschen ausreichen. Das Problem bei dieser Vorgehensweise ist, dass die Voraussetzung, dass Pseudonymkonten nicht existieren, insbesondere bei großen Computersystemen allgemein inkorrekt ist. Außerdem wird das Verhindern einer Kontenpseudonymbildung in seiner praktischen Umsetzung immer ungünstiger, da die Netzwerke immer größer werden, weil auch wenn für einen Menschen einzigartige Identifikationsinformation, wie zum Beispiel biometrische Information, bei Eröffnung eines Kontos beschafft wird, um dieses neue Benutzerkonto einem anderen Benutzerkonto zuzuordnen, das vielleicht für diesen Menschen auf dem Netzwerk existiert, müsste eine erschöpfende Suche über jedes schon im System vorhandene Benutzerkonto durchgeführt werden. Eine solche Suche ist sogar für relativ kleine Computernetze kostspielig und für große Computernetze so gut wie unmöglich.
Ein weiterer Typ einer Benutzerauthentifizierung verwendet biometrische Lesegerätinformation, die während des Logins in ein Computersystem eingespeist wird. Biometrische Information wird von einem biometrischen Lesegerät an jedem Login-Punkt oder jeder Login-Station geliefert. Ein biometrisches Lesegerät kann typischerweise einzigartige Informationen oder Kennzeichen eines Menschen, wie zum Beispiel Augenabtastungen, Daumenabdrücke, DNA-Proben und so weiter erfassen. Zwar wird biometrische Information zum Zweck der Benutzerauthentifizierung oft verwendet, doch ist ihre Durchführung allgemein teuer, da an jedem Login-Punkt biometrische Lesegeräte benötigt werden. Wenn außerdem biometrische Information jemals offengelegt würde, bestünde keine Möglichkeit, den Schaden rückgängig zu machen. Aus diesen Gründen wurde nach wie vor die Verwendung von Verschlüsselungsinformation, wie zum Beispiel Passwörtern und/oder Smart Cards als eine bessere Alternative zur Authentifizierung als biometrische Daten angesehen.

Zusammenfassung der Erfindung

Die Erfindung weist Verfahren zum Betreiben eines verteilten Computersystems nach den Ansprüchen 1 und 5 auf. Die Erfindung weist ebenfalls ein verteiltes Computersystem nach Anspruch 13 auf.
Hier ist ein Verfahren zur Durchführung einer Pseudonymerkennung auf einem Computersystem beschrieben, das die folgenden Schritte aufweist: Speichern in entsprechenden Computerkonten von Identifikationsinformation, die jeden von mehreren Computerbenutzern eindeutig kennzeichnet, Einleiten der Ausführung einer Computersystemressource nach einer ersten Anforderung von einem ersten Benutzerkonto, Verarbeiten einer zweiten Anforderung zur Ausführung unter Verwendung eines Benutzerkontos, Vergleichen der Identifikationsinformation, die in dem Benutzerkonto gespeichert ist, das während der zweiten Anforderung verwendet wurde, mit der Identifikationsinformation im ersten Benutzerkonto, und Bestimmen, ob das erste Benutzerkonto und das bei der zweiten Anforderung verwendete Benutzerkonto Pseudonyme sind. Mit einer solchen Anordnung wird ein Pseudonymerkennungsverfahren vorgesehen, das zur Zeit der Ausführung einer Computerressource unter Verwendung einer zweiten Anforderung für eine Benutzerkonteninformation durchgeführt wird. Ein solches Verfahren kann zum Beispiel zum Steuern des Zugangs zu eingeschränkten Computerressourcen, zum Überwachen und Steuern der Existenz von Pseudonymkonten auf dem Computersystem und zur Umsetzung eines Aufgabentrennungsverfahrens auf Ressourcen des Computersystems verwendet werden.
Bei einer im Folgenden beschriebenen Modifikation enthält ein Verfahren zum Betreiben eines verteilten Computersystems die folgenden Schritte: Speichern in entsprechenden Benutzerkonten von Identifikationsinformation, welche jeden von mehreren Computerbenutzern eindeutig kennzeichnet, Speichern einer Liste ausgewählter Benutzerkonten in einem Autorisierungsspeicher, Einleiten der Ausführung eines Computersystemressourcen-Zugriffprogramms nach Anforderung von einem Benutzerkonto, und Verarbeiten der Anfrage vom Benutzerkonto zum Autorisieren von Zugang auf mehrere Computersystemressourcen durch Vergleichen der Identifikationsinformation, die im Benutzerkonto und in der Liste autorisierten Benutzerkonten gespeichert ist, und Bestimmen, ob das Benutzerkonto ein Pseudonym eines Kontos auf der Liste autorisierter Benutzerkonten ist. Mit einer solchen Anordnung wird die Pseudonymerkennung zu der Zeit durchgeführt, da ein Benutzer versucht, auf eine Computersystemressource zuzugreifen.
Bei einer weiteren im Folgenden beschriebenen Modifikation weist ein Verfahren zum Betreiben eines verteilten Computersystems die folgenden Schritte auf: Speichern in entsprechenden Benutzerkonten von Identifikationsinformation, die jeden von mehreren Computerbenutzern eindeutig kennzeichnet, und Einleiten der Ausführung einer Stufe eines ausgewählten Transaktionsprogramms mit mehren Stufen nach einer Anforderung von einem ersten Benutzerkonto. Das Verfahren weist ferner die folgenden Schritte auf: Verarbeiten einer Anfrage von einem zweiten Benutzerkonto zum Autorisieren der Ausführung einer nachfolgenden Stufe des ausgewählten Transaktionsprogramms durch Vergleichen der im ersten Benutzerkonto und im zweiten Benutzerkonto gespeicherten Identifikationsinformation, und Bestimmen, ob das zweite Benutzerkonto ein Pseudonym des ersten Benutzerkontos ist. Mit solch einer Anordnung wird die Pseudonymerkennung zu einer Zeit durchgeführt, da ein nachfolgender Benutzer versucht, die ausgewählte Transaktion zu vervollständigen. Indem nicht angenommen wird, dass die Login-Authentifizierung auch einen Benutzer eindeutig identifiziert, der nämlich Pseudonymkonten haben kann, sieht diese Anordnung die Erkennung von Pseudonymen an dem Punkt der Anwendung des Verfahrens vor, ohne dass dabei das Netzwerk nach potentiellen Pseudonymkonten durchsucht werden muss. Die vorliegende Erfindung nimmt nicht an, dass eine Benutzerkontenpseudonymbildung verhindert werden kann. Vielmehr wird angenommen, dass Pseudonymkonten frei erzeugt werden können, und verwendet Daten, die den Besitzer eines jeden Kontos eindeutig identifizieren, um die Existenz unerwünschter Pseudonymbildung an dem Zeitpunkt zu erkennen, unmittelbar bevor eine geschützte Aktivität beginnen soll.
Hier ist ebenfalls ein System zum Betreiben eines verteilten Computersystems zur Umsetzung einer Pseudonymerkennung vorgesehen, das Folgendes aufweist: das Speichern in entsprechenden Benutzerkonten digital signierter Kontenzertifikate, die Identifikationsinformation enthalten, die jeden von mehreren Computerbenutzern eindeutig kennzeichnet, das Einleiten der Ausführung einer Stufe eines ausgewählten Transaktionsprogramms mit mehreren Stufen aus einem Speicher von Anwendungsprogrammen auf dem Computersystem nach Anforderung von einem ersten Benutzerkonto, Verarbeiten einer Anforderung von einem zweiten Benutzerkonto zum Autorisieren der Ausführung einer nachfolgenden Stufe des ausgewählten Transaktionsprogramms durch Vergleichen der Identifikationsinformation, die in den Kontenzertifikaten enthalten ist, die im ersten Benutzerkonto und im zweiten Benutzerkonto gespeichert sind, Feststellen, ob das zweite Benutzerkonto ein Pseudonym des ersten Benutzerkontos ist und Erlauben, dass die Verarbeitungsanforderung zum Durchführen der nachfolgenden Stufe des ausgewählten Transaktionsprogramms ausgeführt werden darf, wenn das zweite Benutzerkonto kein Pseudonym des ersten Benutzerkontos ist. Mit einer solchen Anordnung ist ein Computer-Sicherheitssystem vorgesehen, das eine Kombination von biometrischen und kryptographischen Verfahren einsetzt. Insbesondere ist ein System zum Unterstützen einer Aufgabentrennung vorgesehen, das nicht von einer einzigen Kontenregistrierungsstelle oder einer strengen Kontenadministrierung zum Aufteilen von Konten in verschiedene sich nicht überlappende Gruppen oder Rollen (d. h. statische Durchsetzung einer Aufgabentrennung) oder von der Verhinderung mehrerer Konten für einen Menschen abhängt. Ein solches erfindungsgemäßes System kann die dynamische Durchsetzung einer Aufgabentrennung dadurch unterstützen, dass es einem Menschen erlaubt wird, nötigenfalls mehrere Rollen einzunehmen, und Sicherstellen, dass im Kontext einer vorgegebenen Geschäftsfunktion der Mensch keine miteinander in Konflikt stehenden Rollen angenommen hat. Dies wird durch den Einsatz digitalisierter biometrischer Daten oder sonst eindeutig identifizierender Daten erreicht, um zu bestimmen, ob unterschiedliche Konten von einem einzigen Menschen verwendet werden, d. h. Pseudonyme voneinander sind.

Kurzbeschreibung der Zeichnungen

Ein detaillierteres Verständnis der Erfindung kann aus der folgenden Beschreibung bevorzugter Ausführungsformen gezogen werden, die als Beispiel angeführt sind und anhand der Zeichnungen zu verstehen sind. Es zeigt:
Fig. 1 ein Blockdiagramm eines verteilten Computersystems, das zum Umsetzen einer auf Zertifikaten basierenden Pseudonymerkennung nach einer Ausführungsform der vorliegenden Erfindung verwendet werden kann;
Fig. 2 ein Blockdiagramm, das zeigt, wie ein Kontenzertifikat, das Zertifikat- Pseudonym-Erkennungsdaten enthält, erzeugt wird;
Fig. 3 ein Blockdiagramm, das zeigt, wie eine auf Zertifikaten basierende Pseudonymerkennung hier eingesetzt wird;
Fig. 4 ein Blockdiagramm eines Beispielsystems, das eine auf Zertifikaten basierte Pseudonymerkennung enthält.

Beschreibung bevorzugter Ausführungsformen

In Fig. 1 ist ein Computersystem 10 dargestellt, auf das einzelne Benutzer 10a-10c zugreifen können. Jeder einzelne Benutzer 10a-10c hat eine Workstation 12a-12c, die an ein lokales Netz 14 angeschlossen ist. Die Workstations 12a-12c geben jedem einzelnen Benutzer 10a-10c Zugang auf eine Menge von Anwendungen, um seine/ihre Aufgaben auszuführen. Die Anwendungen residieren in einem Anwendungsserversystem 16, das an das lokale Netz 14 angeschlossen ist. Das Anwendungsserversystem 16 ist ein Computersystem, das eine Menge von Anwendungsprogrammen (hiernach "Anwendungen") enthält, auf die auch von anderen (nicht gezeigten) Computerbenutzern über das lokale Netz 14 zugegriffen werden kann. Jeder einzelne Benutzer 10a-10c wird durch ein oder mehrere Konten identifiziert, die in einem Namendienstprogramm 19 auf einem Namenserversystem 18 unterhalten werden.
Das Namenserversystem 18 ist ein Computersystem, das Namendienstsoftware 19 enthält und über das lokale Netzwerk 14 jedem Computerbenutzer zugänglich ist. Die Namendienstsoftware 19 ermöglicht es, dass die Namen von Netzwerkanwendungen, Systemen und anderen über das Netzwerk zugänglichen Objekten von ihrem physischen Standort im lokalen Netzwerk 14 unabhängig sind. Zum Beispiel wird ein einzigartiger Name im Namendienstprogramm 19 auf dem Namenserversystem 18 gespeichert, damit es einzelnen Benutzern 10a-10c erlaubt wird, eine einzigartige Anwendung auf einem Anwendungsserversystem 16 auszuführen.
Im Namenserversystem 18 hat dann jeder einzelne Benutzer 10a-10c ein persönliches Konto und eines oder mehrere "spezielle" Konten; jedes Konto, ob es sich dabei um ein persönliches oder spezielles handelt, hat eine entsprechende Kontenidentifikation, damit es jedem einzelnen Benutzer 10a-10c ermöglicht wird, sich im Computersystem 10 einzuloggen, um eine bestimmte Anwendung zu benutzen, die im Namenserversystem 18 identifiziert ist. Jedes "spezielle Konto" entspricht einer bestimmten Stellungsfunktion, z. B. einer Rolle in einer Organisation. Ein einzelner Benutzer, der unter einem solchen spezialisierten Konto eingeloggt ist, kann diejenigen Anwendungen durchführen, die der entsprechenden Stellungsfunktion eigen sind.
In Fig. 2 liefert ein Antragssteller 100 biometrische Information 105 an einen Registrar 110 im Zusammenhang mit der Verarbeitung eines Kontos. Alle Konten im Computersystem 10 werden vom Kontenregistrar 110 verwaltet, einer Instanz mit ihren eigenen Identität mit Verantwortung für die Kontenverwaltung für eine bestimmte Firma. Während der Erstellung oder Modifikation eines Kontos fängt der Registrar 110 die biometrische Information 105 eines Antragsstellers 100 auf. Hier verwendet das System ein Verschlüsselungsverfahren mit einem öffentlichen Schlüssel zur Authentifizierung zum Liefern von Authentifizierungsdaten. Die Authentifizierungsdaten, die dem Konto zur Benutzung bei der Login- Authentifizierung zugeordnet werden, sind der öffentliche Schlüssel eines aus einem öffentlichen und einem privaten Schlüssel bestehenden Paares: Der Registrar 110 veranlasst, dass ein neues Paar aus einem öffentlichen und einem privaten Schlüssel erzeugt wird. Der private Schlüssel wird an den Benutzer ausgegeben (typischerweise in der Form gespeicherter Information in einer Vorrichtung, wie zum Beispiel einer Passcard), während der öffentliche Schlüssel für das Konto zusammen mit weiterer Konteninformation in einem sogenannten "Zertifikat" für dieses Konto gespeichert wird. Die vom Antragssteller 100 gelieferten biometrischen Daten 105 sind vorzugsweise zusammen mit den Authentifizierungsdaten (z. B. dem öffentlichen Schlüssel des Benutzers) und anderen sicherheitskritischen Informationen, die vom System gebraucht werden können (z. B. die autorisierte Rolle des Benutzers) integritäts-verschlossen. Die integritäts-verschlossenen digitalisierten kanonischen biometrischen Daten werden hiernach als "auf einem Zertifikat basierende Pseudonymerkennungsdaten (certificate-based alias detection data/CBAD)" bezeichnet. Die Registrarintegrität verschließt das Zertifikat durch Anhängen einer digitalen Signatur. Eine digitale Signatur in ihren einfachsten Form ist einfach eine verschlüsselte Kopie des Zertifikats, das unter Verwendung des zugewiesenen privaten Schlüssels des Registrars 110 (der nur dem Registrar 110 und der Workstation des Registrars bekannt ist) verschlüsselt wird. Die digitale Signatur wird mit den "zu integritäts-verschließenden" Daten verwendet, indem die Signatur zum Liefern einer kryptographischen Prüfsumme oder eines anderen geeigneten Codes verwendet wird. Ein Anhängen der digitalen Signatur liefert "integritätsverschlossene" oder digital signierte konten-/authentifizierungs-/zertifikats-basierte Pseudonymerkennungsdaten 120, die im Namendienstprogramm 19 gespeichert werden. Die oben erwähnten kryptographischen Verfahren mit öffentlichem Schlüssel werden verwendet um sicherzustellen, dass eine Einwirkung von außen auf konten- /authentifizierungs-/zertifikats-basierte Pseudonymerkennungsdaten erkennbar ist.
Zu einer späteren Zeit kann eine beliebige Instanz überprüfen, ob das Kontozertifikat 130 tatsächlich vom Registrar 110 signiert wurde, indem die digitale Signatur unter Verwendung des öffentlichen Schlüssels des Registrars 110 (der im gesamten System bekannt ist) entschlüsselt wird und die Ergebnisse mit einem entsprechenden Klartextzertifikat der entschlüsselten digitalen Signatur verglichen wird. Das Klartextzertifikat ist eine entschlüsselte Version der digitalen Signatur. Wenn sie identisch sind, ist sich die das Kontozertifikat verwendende Instanz sicher, dass weder die Klartextversion noch die verschlüsselte Version des Kontozertifikats modifiziert wurde, nachdem diese vom Registrar 110 erzeugt oder modifiziert wurden, und dass die Kontozertifikatsdaten aus der Workstation des Registrars stammen.
Wenn ein einzelner Benutzer sich bei einer Workstation einloggt, liefert der einzelne Benutzer Information (wie zum Beispiel den Namen des Benutzers), die vom lokalen Betriebssystem zum Lokalisieren und Herholen eines Kontozertifikats vom Namendienstprogramm 19 als dem ersten Schritt beim Authentifizieren oder bei der Bestätigung der Identität des einzelnen Benutzers verwendet wird. Das lokale Betriebssystem validiert dann die digitale Signatur des Kontozertifikats unter Verwendung des öffentlichen Schlüssels des Registrars 110. Wenn das Kontozertifikat gültig ist, ist der diesem Konto vom Registrar 110 zugeordnete öffentliche Schlüssel bekannt. Der einzelne Benutzer, der einzuloggen versucht, legt dann der Workstation ein digital signiertes "Login-Delegations-Zertifikat" vor. Unter einem Login-Delegations-Zertifikat versteht man das, was der Benutzer an das lokale Betriebssystem sendet, um authentifiziert zu werden. (Typischerweise würde das durch eine dem einzelnen Benutzer vom Registrar 110 ausgehändigte Smart Card geschehen, die den persönlichen privaten Schlüssel des einzelnen Benutzers enthält). Das Betriebssystem validiert das Login-Delegations-Zertifikat durch Entschlüsselung unter Verwendung des öffentlichen Schlüssels, den es vom Kontozertifikat erhalten hat. Wenn die Validation erfolgreich ist, weiß das Betriebssystem, das der öffentliche Schlüssel, den es vom Kontozertifikat bekommen hat, mit dem privaten Schlüssel im Besitz des einzelnen Benutzers, der sich einloggen will, übereinstimmt, und es befindet sich im Recht, wenn es diesem einzelnen Benutzer dem Konto zugeordnete Rechte oder Privilegien einräumt. Zu keiner Zeit während des Authentifizierungsvorgangs befinden sich die CBAD-Daten im verwendeten Kontozertifikat. Da CBAD-Daten den Erfolg oder das Fehlschlagen einer Login-Authentifizierung nicht bestimmen, wird die Integrität des Login- Authentifizierungssystems nicht gefährdet, wenn die CBAD-Daten öffentlich sind. Um eine entfernte Anwendung aufzurufen (z. B. vom Anwendungsserversystem 16), das für einen korrekt authentifizierten lokalen Benutzer oder auf dessen Anforderung ausgeführt werden soll, erzeugt das Betriebssystem der Workstation ein sogenanntes entferntes Delegationszertifikat für die Anforderung durch Anhängen des Login-Delegations-Zertifikats an die Anforderung des einzelnen Benutzers und durch ein digitales Signieren unter Verwendung des privaten Schlüssels der Workstation. Unter einem entfernten Delegationszertifikat versteht man das, was das Betriebssystem des lokalen Computers an das Anwendungsserversystem 15 sendet, um für den einzelnen Benutzer Dienste zu erhalten. Das Anwendungsserversystem 16 kann dann überprüfen, dass das entfernte Delegationszertifikat von der Workstation kommt (indem der öffentliche Schlüssel der Workstation auf die Signatur angewendet wird), und, wenn dies erfolgreich ist, die Identität des einzelnen Benutzers erneut authentifizieren, indem die Signatur des Benutzers auf dem enthaltenen entfernten Delegationszertifikat unter Verwendung des zugewiesenen öffentlichen Schlüssels des Benutzers überprüft wird. Vorausgesetzt, beide diese Tests sind erfolgreich, dann weiß das Anwendungsserversystem 16, dass die enthaltene Anforderung von der behaupteten Workstation stammt, die für ein behauptetes Benutzerkonto handelt, und/oder kann diese Information verwenden, um zu bestimmen, ob der Anfrage stattgegeben werden sollte oder nicht. Da CBAD- Daten nicht dazu verwendet werden, die Validität eines entfernten Delegationszertifikats festzustellen, wird das entfernte Anfrage- Authentifizierungssystem nicht gefährdet, wenn CBAD-Daten öffentlich sind.
Jeder Benutzer hat auch ein entsprechendes Kontozertifikat 130. Ein Benutzerzertifikat 130 ist eine Datenstruktur, die vom Betriebssystem erzeugt wird, die Benutzerinformation 120 und CBAD-Daten, wenn diese existieren, enthält, die zusammengebunden sind. Das Zusammenbinden dieser Daten kann dadurch geschehen, dass eine kryptographische Prüfsumme verwendet wird. Die Prüfsumme stellt sicher, dass jeder Verfälschung der Benutzerinformation 120 durch das System erkennbar ist. Die Verschlüsselung verwendet den privaten Schlüssel oder den Verschlüsselungscode des Registrars 110, wodurch eine digitale Signatur erzeugt wird, die die Quelle der Kontoinformation als den Registrar 110 eindeutig identifiziert. Das Kontozertifikat 130 wird dann vom Betriebssystem an das Namendienstsystem 135 geschickt. Auf diese Weise kann die Ausführung ausgewählter Aufgaben auf ausgewählte Benutzer oder Benutzergruppen eingeschränkt werden.
Während des Einloggens des Benutzers sammelt das Computersystem 10 Benutzerzertifikatinformation 130, wie oben erwähnt ist, um einen Validationsausweis für den bestimmten Benutzer zu erzeugen. Ein solcher Validationsausweis wird vom Computersystem 10 zum Identifizieren jedes Benutzers und dazu verwendet, zu bestimmen, ob der identifizierte Benutzer die erforderlichen Privilegien zur Ausführung einer bestimmten Anwendung genießt. An diesem Punkt verwendet das Computersystem 10 die Kontozertifikatsinformation 130 zum Erzeugen einer Validationsangabe, wenn der bestimmte Benutzer zum Ausführen der bestimmten identifizierten Transaktion autorisiert ist. Daher werden zur Erzeugung von Validationsangaben und um zu bestimmen, welche Benutzer auf bestimmte Computeranwendungen zugreifen dürfen, einzelne konten-/authentifizierungs- /zertifikats-basierte Pseudonymerkennungsdaten vom Registrar 110 gesammelt. Solche Informationen enthalten sowohl die herkömmliche Benutzerinformation wie zum Beispiel den Namen des Benutzers, wie oben erwähnt wurde, dem Benutzer zugewiesene oder von diesem empfangene Authentifizierungsdaten und digitalisierte kanonische biometrische Daten (BioM), die hier als zertifikatbasierte Pseudonymerkennungsdaten (CBAD) bezeichnet werden, wie oben erwähnt wurde. Das System kann Konten enthalten, die CBAD-Datenenthalten, und Konten, die keine CBAD-Daten enthalten. Die Auswirkungen der Anwesenheit oder der Abwesenheit von CBAD-Daten werden im Folgenden beschrieben.
Auch wenn das unten zu beschreibende Pseudonymerkennungssystem hier im Zusammenhang mit einem einzigen Gomputersystem erörtert wird, versteht es sich, dass diese Pseudonymerkennung auch auf einem über große Computernetze verbundenen Multi-Computer-System, wie zum Beispiel in überregionalen Netzen (WANs), implementiert werden kann. Hierdurch wird es Computerbenutzern erlaubt, im gesamten großen Computemetz eine gemeinsame Anwendung auszuführen.
Wie in Fig. 2 veranschaulicht, werden die CBAD-Daten als ein Teil des Kontenbetriebs aufgefangen und zur späteren Benutzung gespeichert, wenn ein Aufgabenteilungsplan durchgesetzt werden muss (wie unten noch vollständiger beschrieben wird). Hier werden sie dann zur Bestimmung einer eigenen Existenz des Benutzers und zum Erkennen von Pseudonymkonten verwendet. Diese Verwendung erlaubt die Durchsetzung eines Aufgabenteilungsverfahrens, das gegenüber Angriffen von skrupellosen Benutzern widerstandsfähig ist, die viele alltägliche Identitäten annehmen. Außerdem erlaubt sie die Durchsetzung eines Aufgabenteilungsverfahrens, auch wenn das System nachlässig administriert wird, wobei die Anzahl von einem einzelnen Benutzer erteilter Konten nicht minimiert wird. Außerdem ermöglicht sie die Erzeugung getrennter Konten für einzelne Menschen für spezielle Zwecke. Solche Verfahren widerstehen der Ansammlung von Privilegien, da sich Benutzer nur mit spezifischen Privilegsätzen einloggen, und nicht mit der Gesamtheit aller möglicher angesammelter Privilegien, die sie ausüben dürfen.
In Fig. 3 sind die Schritte gezeigt, die bei der zertifikatbasierten Pseudonymerkennung durchgeführt werden, die aufgerufen wird, wenn eine bestimmte Verarbeitungseinheit für mehr als einen Benutzer ausgeführt wird. Eine zertifikatbasierte Pseudonymerkennung wird auf der Betriebsplattform (z. B. dem Betriebssystem, der Transaktionsüberwachung) des Computersystems 10 in Fig. 1 vorgesehen.
Das Computersystem 10 erzeugt einen Validationsausweis für den entsprechenden Benutzer aus dem Kontozertifikat. Wie schon erwähnt, ist ein Validafionsausweis ein integritätsversiegeltes (d. h. digital signiertes) Paket, das die Identität eines authentifizierten Benutzers, eine Anfrage für diesen Benutzer und gegebenenfalls die CBAD-Daten für den Benutzerlogisch zusammenbindet. Ein authentifizierter Benutzer ist ein Benutzer mit einer vorbestimmten Erlaubnis zum Ausführen der bestimmten Ausführung. Die vorbestimmte Erlaubnis wird dem Benutzer durch einen Systemmanager oder Registrar erteilt, der die erforderlichen Privilegien hierfür hat. Das Zusammenbinden des integritätsversiegelten Pakets geschieht dadurch, dass das Betriebssystem die Benutzerinformation bei der Anwendungstransaktion anhängt. Vor dem Ausführen der Verarbeitungseinheit wird jedoch das Sicherheitsverfahren für diese Verarbeitungseinheit untersucht. Wenn dies zum Schutz der Sicherheit notwendig ist, wird eine zertifikatbasierte Pseudonymerkennung durch eine entsprechende Angabe im Sicherheitsverfahren (38 in Fig. 4) für die spezifische Anwendungstransaktion ausgelöst, welche der Benutzer ausführen möchte.
Die allgemeine Weise, in welcher Benutzerdaten und Pseudonymerkennungsdaten in einem Datenverarbeitungssystem im Zusammenhang mit der vorliegenden Erfindung verwendet werden können, wird nun erläutert. Es wird dabei angenommen, dass die zu beschreibende Transaktion zum Beispiel erfordert, dass eine Anwendungs-Einleitungsanforderung und ein Anwendungs-Gestattungseintrag durch unterschiedliche zugelassene Benutzer in das System eingegeben werden.
Wie in Fig. 3 gezeigt, wird die Transaktion bei Schritt 158 eingeleitet, wenn ein einzelner Benutzer, der sich in das System eingeloggt hat, eine Datenverarbeitungs- Anwendungs-Einleitungsanforderung eingibt. Ein Überprüfungs- oder Erlaubniseintrag wird dann bei Schritt 158 eingegeben, bevor eine weitere Verarbeitung der Transaktion geschehen kann.
Bei Schritt 160 werden die digitale Signatur auf dem Delegationszertifikat für die Benutzer-Einleitungs-Anfrage und die digitale Signatur auf dem Delegationszertifikat für die Zustimmungsanfrage zuerst einzeln validiert. Wenn dieser Schritt erfolgreich ist, dann weiß das Anwendungsserversystem 16, dass keines der Zertifikate verfälscht wurde, und weiß die zugewiesenen öffentlichen Schlüssel für die diesen beiden Anforderungen zugeordneten einzelnen Benutzerkonten, d. h. das Konto, für das die Einleitungsanfrage gemacht wurde, und das Konto, für welches die Erlaubnisanfrage gemacht wurde. Wenn diese beiden öffentlichen Schlüssel identisch sind, dann wurden beide Anfragen für das gleiche Konto gemacht, was anzeigt, dass beide Anfragen für ein und denselben Benutzer gemacht wurden, dem dieses Konto zugewiesen wurde. In diesem Fall geschieht keine weitere Verarbeitung der Transaktion, und der Zustimmungseintrag wird zurückgewiesen.
Wenn der Identifikationsschritt zur Identifikation unterschiedlicher Benutzerkonten führt, werden bei Schritt 162 die beiden Sätze von Kontenangaben dahingehend überprüft, ob CBAD-Daten vorhanden sind. Eine Überprüfung, dass die gelieferten CBAD-Daten für die Anfrage tatsächlich genau diejenigen CBAD-Daten sind, die der Registrar 110 aufgefangen hat, ist in dem Vorgang implizit, bei dem das Anwendungsserversystem 16 das Kontozertifikat erhält und validiert. Die CBAD- Daten und die Authentifizierungsdaten werden vom Registrar 110 in ein Kontozertifikat zusammengebunden.
Wie schon erwähnt, ist die Computerplattform für das Validieren des Kontozertifikats verantwortlich, das beim Einloggen erhalten wird, bevor mit der Benutzerauthentifizierung fortgefahren wird. Außerdem ist die Computerplattform durch ihr Betriebssystem zum Zusammenbinden einer Anfrage zum Ausführen einer Transaktion mit dem Kontozertifikat und für das Versiegeln dieser Information zum Liefern integritätsversiegelter Kontozertifkate verantwortlich. Die Computerplattform ist für das Validieren dieses Kontozertifikats vor seiner Verwendung verantwortlich. Eine Anfrage kann einfach deshalb fehlschlagen, weil entweder der authentifizierte Benutzer und/oder die authentifizierte Computerplattform für eine bestimmte Aktion keine Erlaubnis haben. Nur wenn die Computerplattform die Angabe validiert und die Nachfrage für die bestimmte Aktion autorisiert ist, werden gegebenenfalls CBAD- Überprüfungen durchgeführt. Wenn ein Satz von Kontoangaben keine CBAD-Daten enthält, wird bei Schritt 163 angenommen, dass beide Sätze von Kontoangaben dem gleichen Benutzer zugeordnet sind, und der Zustimmungseintrag wird zurückgewiesen, und der Vorgang wird beendet. Wenn beide Sätze von Kontoangaben CBAD-Daten enthalten, werden bei Schritt 164 die in jedem Satz von Kontoangaben vorhandenen digitalisierten biometrischen Daten verglichen.
Wenn die verglichenen digitalisierten biometrischen Daten innerhalb eines vorbestimmten Bereichs einer Ähnlichkeit sind, wird bei Schritt 169 angenommen, dass die beiden Sätze von Kontoangaben dem gleichen Benutzer gehören, und der Zustimmungseintrag wird zurückgewiesen, und der Vorgang wird beendet. Ein Ähnlichkeitsbereich, im Gegensatz zu einer Identität, zwischen den beiden Sätzen von Kontoangaben wird hauptsächlich durch normale Variationen und Fluktuationen in biometrischen Daten verursacht, die von einem bestimmten Benutzer empfangen werden. Demnach sollte der bei der Ähnlichkeit erlaubte Bereich oder die entsprechende Toleranz so eng gefasst sein, dass eine Überlagerung zwischen tatsächlich unterschiedlichen Benutzern verhindert wird, sollte jedoch so breit sein, dass normal zu erwartende Variationen in der biometrischen Information des selben Benutzers enthalten sind. Wenn die beiden Sätze von Kontoangaben bei Schritt 168 als unterschiedlich bestimmt werden, wird bei Schritt 167 angenommen, dass die Anwendungs-Einleitungsanfrage und der Zustimmungseintrag von unterschiedlichen Benutzern stammen, und dieses Vergleichsergebnis wird bei Schritt 170 zur weiteren Verarbeitung der Transaktion berichtet.
Wenn die Anwendungs-Einleitungsanfrage und die Zustimmungs- Eintragsanfrage von unterschiedlichen Menschen gemacht werden, wird dem die Zustimmungs-Eintragsanfrage einleitenden Benutzer erlaubt, diese Anwendungsanfrage zuzulassen, wenn er in einer Zugangskontrollliste, die dem Programm zugeordnet ist und unten beschrieben ist, dazu autorisiert ist.
Es folgt eine Beschreibung eines Beispiels der vorliegenden Erfindung anhand einer typischen computerbasierten Spesenabrechnungs- und -Genehmigungsprozedur in einer Büroumgebung. Ein beliebiger Mensch kann eine Spesenabrechnung ausfüllen und einreichen. Die Spesenabrechnung muss bewilligt werden, bevor sie zur Zahlstelle weitergeleitet wird, wo ein Erstattungsscheck ausgestellt wird. Die wesentliche Anforderung bei der Aufgabentrennung besteht darin, dass kein einzelner seine/ihre Spesenabrechnung selbst bewilligen darf.
Wieder mit Bezug auf Fig. 1 kann jeder einzelne Benutzer 10a-10c einen persönlichen Spesenabrechnungsantrag ausführen, der im Namendienstsystem 18 gespeichert ist, wenn er unter seinem/ihrem persönlichen Konto eingeloggt ist. Der Spesenabrechnungsantrag zeigt an einer Workstation ein Formular an, das der Benutzer ausfüllen kann. Ein Benutzer kann dann eine Spesenabrechnung einreichen. Eine Einreichungstransaktion verursacht; dass eine Spesenabrechnung an eine Schlange auf einem Wartenschlangen-Serversystem 20 geschickt wird, das an das lokale Netzwerk 14 angeschlossen ist, wo sie zur Überprüfung einbehalten wird. Ein Warteschlangen-Serversystem 20 ist ein Computersystem, das mehrere Warteschlangen enthält, z. B. Druck-Warteschlangen, Stapel-Warteschlangen usw., auf die von einem einzelnen Computerbenutzer 10a-10c über das lokale Netzwerk 14 zugegriffen werden kann.
Ein oder mehrere ausgewählte Menschen (10b zum Beispiel) haben "Verwaltungskonten" bekommen, d. h. ein solcher Mensch hat die Erlaubnis, Spesenabrechnungen zu überprüfen und entweder zuzulassen oder abzuweisen. Hierbei handelt es sich um ein "Spezialkonto", wie das oben im Zusammenhang mit der vorhergehenden Erörterung erwähnt wurde. Bei einer Abweisung wird die Spesenabrechnung an den Autor zurückgeschickt, bei einer Bewilligung wird die Abrechnung an eine Warteschlange für zu leistende Auszahlungen auf dem Warteschlangen-Serversystem 20 weitergeleitet. Ein Mensch in der Zahlstelle (zum Beispiel 10c) kann einen Scheck erzeugen, um die bewilligte Spesenabrechnung abzuarbeiten. Die Transaktion zum "Erzeugen eines Schecks" erzeugt nicht nur den Scheck, sondern legt die Spesenabrechnung in einem Archiv ab und teilt dem Autor mit, dass seine/ihre Spesenabrechnung verarbeitet wurde und ein Scheck ausgestellt wurde.
Weiter in Fig. 1 leitet der einzelne Benutzer 10a auf der Workstation 12a über das lokale Netzwerk 14 den Spesenabrechnungsantrag ein, der auf dem Anwendungsserversystem 16 residiert. Das Ergebnis ist eine noch nicht bewilligte Spesenabrechnung, die von der Anwendung über das lokale Netzwerk 14 an das Warteschlagen-Serversystem 20 geleitet wird. Nachfolgend versucht ein zweiter einzelner Benutzer 10b auf der Workstation 12b, die Spesenabrechnung auf dem Warteschlangen-Serversystem 20 über das lokale Netzwerk 14 zu überprüfen und zu bewilligen, indem die Spesenabrechnungsanwendung auf dem Anwendungsserversystem 16 ausgeführt wird. Die Anfrage zum Bewilligen der Spesenabrechnung, die vom einzelnen Benutzer 10a erzeugt/eingeleitet wurde, löst das auf Zertifikaten basierte Pseudonymerkennungsverfahren aus. Der Ablageort und der Betrieb der auf Zertifikaten basierten Pseudonymerkennung wird unten vollständiger beschrieben.
Fig. 4 veranschaulicht die allgemeinen Datenstrukturen zum Unterstützen einer Aufgabentrennung unter der Verwendung einer auf Zertifikaten basierten Pseudonymerkennung (CBAD). Eine Namendienstdatenbank 30 in einem Namenserversystem 48 enthält Kontenzertifikate für einzelne Benutzerkonten (33a- c). Jedes Kontenzertifikat (33a-c), das wie zuvor beschrieben erzeugt wurde, enthält relevante Information über jeden Menschen, einschließlich digital signierter, digitalisierter kanonischer biometrischer Daten für den Menschen; dies wird als CBAD-Daten beschrieben, die vollständig anhand von Fig. 2 beschrieben sind. Die Konten 33a-c enthalten auch die Signatur der Kontenregistratur, was auch schon zuvor beschrieben wurde. Persönliche und "spezielle" Konten eines einzelnen Benutzers enthalten die gleichen digitalisierten kanonischen biometrischen Daten, d. h. CBAD-Daten, weil sie zwei oder mehrere Konten repräsentieren, die dem selben einzelnen Benutzer gehören. Konten für unterschiedliche einzelne Benutzer werden dadurch identifiziert, dass die GBAD-Daten für jeden einzelnen Benutzer unterscheidbar sind.
Anwendungs-Systemprogramme 35a-d residieren jeweils in einer Programmbibliothek 36 im Anwendungsserversystem 50. Hierdurch wird es jedem einzelnen Benutzer auf dem lokalen Netzwerk 52 ermöglicht, auf die Programmbibliothek 36 zuzugreifen. Jeder Transaktionstyp, wie zum Beispiel "erzeuge Spesenabrechnung", "reiche Spesenabrechnung ein", "bewillige Spesenabrechnung" usw. hat ein entsprechendes Anwendungssystemprogramm 35a-c, das jeweils in der Programmbibliothek 36 residiert und im Anwendungsserversystem 50 gespeichert ist. Jedem solchen Transaktionsprogramm ist ein Sicherheitsverfahren zugeordnet, das festlegt, dass Menschen oder Gruppen von Menschen die entsprechende Transaktion durchführen oder nicht durchführen können. Zum Beispiel ist ein Sicherheitsverfahren 38 in einer Zugriffssteuerungsliste (access control list/ACL) enthalten, die dem Transaktionsprogramm 35a zugeordnet ist. Eine ACL ist ein gemeinsamer Mechanismus zum Speichern von Zugriffsverfahren in vielen Computerbetriebssystemen. Das Sicherheitsverfahren und seine Auslösung ist als ein Anhang an die Zugriffsverfahrenssprache vorgesehen. Das Sicherheitsverfahren wird einem bestimmten Zugriffsverfahren- Speichermechanismus für das Plattformcomputersystem hinzugefügt. Die Zugriffs- Steuerungsüberwachung der Betriebssystemplattform drückt die Zugriffseinschränkung aus, speichert die Zugriffseinschränkung innerhalb des Sicherheitsverfahrens und sieht die Fähigkeit vor, zur Zeit, da das Zugriffsverfahren durchgesetzt wird, das geeignete Verfahren aufzurufen. Wie die bestimmte Erweiterung implementiert wird, ist eine Routinefunktion des Computer- Betriebssystems und wird hier daher nicht beschrieben. Die Durchsetzung oder Nicht-Durchsetzung einer Aufgabenteilung ist innerhalb des Sicherheitsverfahrens 38 für die relevante Transaktion 35a, zum Beispiel, definiert, d. h. die Verfahrensangabe 38 gibt an, dass die Pseudonymerkennung aufzurufen ist. Das Sicherheitsverfahren 38 erfordert, dass das Recht zum Ausführen des Programms "bewillige Spesenabrechnung" (approve_expns_rpt) 35a zu verweigern ist, wenn die Identität des Autors, oder des ersten Benutzers, die gleiche wie die Identität des zweiten Benutzers ist, d. h. des Benutzers, welcher versucht, die Spesenabrechnung in diesem Beispiel zu bewilligen. Dieser Vergleich wurde anhand von fig. 3 schon beschrieben.
Jedem Transaktionsaufruf durch einen Benutzer ist der Validationsausweis (44, 45 und 47 in Fig. 4) dieses Benutzers zugeordnet, die den Benutzer identifiziert, der die Transaktion eingeleitet hat. Ein Validationsausweis ist eine integritätsversiegelte Verarbeitungseinheit, die vom Betriebssystem erzeugt wurde, die ein Kontenzertifikat eines Benutzers, wie es in Fig. 2 beschrieben ist, mit einer angeforderten Anwendung zusammenbindet. Nach dem Transaktionsaufruf wird die Validationsangabe des Benutzers in einem geschützten Systemspeicher 46 der Verarbeitungseinheit · 49 und in der Namendienstdatenbank 30 des Namenserversystems 48 gespeichert, welche einen Nachweis der Identität des Benutzers enthält, für den eine bestimmte Verarbeitungseinheit ausgeführt wird. In dieser Ausführungsform der Erfindung ist die Verarbeitungseinheit der Transaktionsaufruf. Die Zuordnung des Validationsausweises des einzelnen Menschen zum Transaktionsaufruf ist eine im Betriebssystem oder in der Transaktions-Verarbeitungsüberwachung vorhandene Funktion, die die Betriebsplattform für die Beispielanwendung bereitstellt.
Um mit der Beschreibung von Fig. 4 fortzufahren, loggt sich ein erster Benutzer in der Namendienstdatenbank 30 unter dem Konto UserA ein. Der entfernte Validationsausweis 44 von UserA (einschließlich der zertifikatsbasierten Pseudonymerkennungsdaten) wird durch das Betriebssystem in den geschützten Systemspeicher 46 der Verarbeitungseinheit · 49 eingegeben. UserA, der eine Spesenabrechnung erzeugen möchte, beantragt die Ausführung eines Programms "erzeuge Spesenabrechnung" (create_expns_rpt) 35b, das vom Anwendungsserversystem 50 geladen wird. Eine create_expns_rpt-ACL 40b, die zuvor so erzeugt oder geändert wurde, dass das Kontozertifikat oder die Kontozertifikate der Benutzerkonten genannt werden, die zur Durchführung des create_expns_rpt-Programms 35b autorisiert sind, wird zum Erhalten der öffentlichen Schlüssel für diese Konten benutzt, die dann zum Validieren des entfernten Delegationszertifikats verwendet werden. Wenn das entfernte Zertifikat validiert werden kann, wird der Anfrage stattgegeben, wodurch die Ausführung des create_expns_rpt-Programms 35b durch die Verarbeitungseinheit X 49 veranlasst wird und eine Spesenabrechnungsdatei erzeugt wird. Nun versucht UserA ein Programm "reiche Spesenabrechnung ein" (submit_expns_rpt) 35c auszuführen, das vom Anwendungsserver 50 geladen wird. Eine submit_expns_rpt-ACL 40c, die zuvor so erzeugt oder geändert wurde, dass das Benutzerkonto oder die Benutzerkonten darin genannt werden, die zum Ausführen des submin_expns_rpt-Programms 35c autorisiert sind, wird anhand des entfernten Validationsausweises 44 von UserA überprüft.
Eine Übereinstimmung zwischen dem Validationsausweis 44 des UserA und einem Konto eines Benutzers in der ACL 40c veranlasst die Ausführung des submin_expnsrpt-Programms 35c durch die Verarbeitungseinheit · 49, welche die Spesenabrechnungsdatei dadurch signiert, dass das UserA-Zertifikat 33a und zertifikatsbasierte Pseudonymerkennungsdaten (die noch vollständiger zu beschreiben sind) angehängt werden. Die Spesenabrechnungsdatei wird an eine Spesenabrechnungs-Warteschlange (expense_report_queue) 62 auf dem Warteschlangenserver 60 geschickt.
Nach diesen Transaktionen durch den UserA 33a loggt sich ein zweiter Benutzer, der die durch den UserA erzeugte Spesenabrechnungsdatei überprüfen und bewilligen möchte, unter dem Konto UserB ein. Das entfernte Delegationszertifikat 45 des UserB (das zertifikatsbasierte Pseudonymerkennungsdaten enthält) wird vom Betriebssystem in den geschützten Systemspeicher 46 der Verarbeitungseinheit · 49 eingegeben. UserB beantragt die Ausführung eines Programms "überprüfe Spesenabrechnung" (review_expns_rpt) 35d, das vom Anwendungsserver 50 geladen wird. Eine review_expns_rpt-ACL 40d, die zuvor so erzeugt oder geändert wurde, dass darin das Benutzerkonto oder die Benutzerkonten aufgeführt sind, die zur Durchführung des review_expns_rpt- Programms 35d autorisiert sind, wird zur Überprüfung des entfernten Validationsausweises 45 des UserB verwendet. Eine Übereinstimmung zwischen dem entfernten Validationsausweis 45 des UserB und einem Benutzerkonto in der ACL 40d verursacht die Ausführung des review_expns_rpt-Programms 35d durch die Verarbeitungseinheit · 49, das die Spesenabrechnungsdatei für UserB produziert, der sie zum Beispiel auf einer Video-Anzeigevorrichtung lesen/überprüfen kann.
Nun versucht UserB das Programm " bewillige Spesenabrechnung " (approve_expns_rpt) 35a zum Bewilligen der vom UserA erzeugten Spesenabrechnung auszuführen. Die digitale Signatur auf der Spesenabrechnung (die diejenige des Anwendungsserversystems 116 ist) wird zuerst validiert, um sicherzustellen, dass keine Veränderungen an der Abrechnung oder am ihr zugeordneten Kontozertifikat vorgenommen wurden. Das Kontozertifikat (das vom Registrar signiert ist) kann, muss jedoch nicht, erneut validiert werden. Es enthält die CBAD-Daten für den Benutzer, der die Abrechnung erzeugt hat, d. h. UserA. Das Anwendungsserversystem 116 hat nun zwei validierte Sätze von CBAD-Daten, einen für UserA und einen für UserB. Diese zwei Sätze von CBAD-Daten werden dann nach Ähnlichkeit überprüft. Wenn die Pseudonymerkennungsüberprüfung fehlschlägt, wird angenommen, dass die digitalisierten biometrischen Daten den gleichen Benutzer identifizieren, d. h. das Anwendungsserversystem 116 muss annehmen, dass UserA und UserB tatsächlich der gleiche Mensch sind (auch wenn die entsprechenden Kontozertifikate zu getrennten Konten gehörten, die potentiell auf unterschiedliche Benutzernamen registriert sind). Wenn die zertifikatsbasierte Pseudonymerkennungsüberprüfung angibt, dass UserA und UserB die gleichen sind, wird UserB der Zugriff auf das approve_expns_rpt-Programm 35a verweigert, und es kann ein Bericht zur Mitteilung an den Systemverwalter oder Registrar erstellt werden.
Das Beispiel mit der Spesenabrechnung hat gezeigt, wie die vorliegende Ausführungsform ein Aufgabentrennungsverfahren erfüllt, das es nicht zuließ, dass ein und der selbe Mensch eine Spesenabrechnung erzeugt und bewilligt. Es wird also nicht sichergestellt, dass UserA und UserB voneinander unterscheidbare Identitäten hatten, als ihre Benutzerkonten zuerst eingerichtet wurden, sondern es wurde erfindungsgemäß ein Vergleich zertifikatsbasierter Pseudonymerkennungsdaten von dem jeweiligen Benutzer zu der Zeit angestellt, da eine Anfrage zur Bewilligung einer Spesenabrechnung gemacht wurde. Die Validation der persönlichen Information des Benutzers musste nur vorgenommen werden, als das Benutzerkonto vom Systemadministrator anfänglich eingerichtet oder geändert wurde.
Nach einer Beschreibung einer bevorzugten Ausführungsform der Erfindung wird einem Fachmann klar, dass andere Ausführungsformen, die ihre Konzepte beinhalten, verwendet werden können. Die Beschreibung ist daher lediglich durch den Umfang der nachfolgenden Ansprüche eingeschränkt.

Claims

1. Verfahren zum Betreiben eines verteilten Computersystems (10) mit einer Pseudonymerkennung, mit den folgenden Schritten:

A) Speichern einzelnen Benutzerkonten (33a-33c) zugeordneter Identifikationsinformation in einem Benutzerkontenspeicher (30) des Computersystems, wobei die Identifikationsinformation für das jeweilige Benutzerkonto einen dem Konto zugeordneten Computerbenutzer (UserA, UserB, UserC) eindeutig kennzeichnet;

B) Einleiten der Ausführung einer Stufe (3bb, 35c) eines mehrere Stufen (35a- 35d) aufweisenden ausgewählten Transaktionsprogramms in Reaktion auf eine erste Anforderung von einem ersten Benutzerkonto (33a); und

C) Verarbeiten einer zweiten Anforderung von einem zweiten Benutzerkonto (33b) zur Bemächtigung zur Ausführung einer nächsten Stufe (35d, 35a) des ausgewählten Transaktionsprogramms durch Ausführung der folgenden Schritte:

i) Vergleichen der in dem Benutzerkontenspeicher (30) für das erste Benutzerkonto (33a) gespeicherten Identifikationsinformation und der in dem Benutzerkontenspeicher für das zweite Benutzerkonto (33b) gespeicherten Identifikationsinformation, und

ii) Verweigern der Bemächtigung für das zweite Benutzerkonto (33b), wenn die verglichene Identifikationsinformation übereinstimmt, wodurch angezeigt wird, dass das zweite Benutzerkonto (33b) ein Pseudonym des ersten Benutzerkontos (33a) ist.

2. Verfahren nach Anspruch 1, bei dem der Schritt der Einleitung der Ausführung einer Stufe eines Transaktionsprogramms die folgenden Schritte aufweist:

D) Vergleichen eines Validationsberechtigungsausweises (44), der das Transaktionsprogramm mit Benutzerzertifikaten von Konten verbindet, die zum Ausführen ausgewählter Transaktionen des Transaktionsprogramms berechtigt sind, mit einer Liste berechtigter Benutzerkonten (ACL, 40c), um festzustellen, ob das erste Benutzerkonto (33a) zum Ausführen der ersten Stufe (35c) des ausgewählten Transaktionsprogramms berechtigt ist; und

E) einen Schritt, bei welchem dem ersten Benutzerkonto (UserA) das Einleiten der Ausführung der ersten Stufe nur dann erlaubt wird, wenn es dazu bemächtigt ist.

3. Verfahren nach Anspruch 1, bei dem während des Verarbeitungsschrittes der zweiten Anforderung erlaubt wird, die nächste Stufe (35a) des ausgewählten Transaktionsprogramms auszuführen, wenn das zweite Benutzerkonto (UserB) nicht ein Pseudonym des ersten Benutzerkontos (UserA) ist.

4. Verfahren nach Anspruch 1, bei dem der Verarbeitungsschritt weiter einen Schritt aufweist, bei dem, wenn das zweite Benutzerkonto das gleiche wie das erste Benutzerkonto ist (160) oder wenn das zweite Benutzerkonto keine zugeordnete Identifikationsinformation in dem Benutzerkontenspeicher enthält (163) oder wenn die Identifikationsinformation des zweiten Benutzerkontos die gleiche ist wie die Identifikationsinformation des ersten Benutzerkontos (169), die Ermächtigung für die zweite Anforderung verweigert wird.

5. Verfahren zum Betreiben eines verteilten Computersystems mit einer Pseudonymerkennung, mit den folgenden Schritten:

A) Speichern in einem Benutzerkontenspeicher (30) des Computersystems (10) jeweiligen mehrerer Benutzerkonten zugeordneter Identifikationsinformation (120), wobei die Identifikationsinformation für das jeweilige Benutzerkonto einen dem Konto zugeordneten Computerbenutzer (33a-33c) eindeutig kennzeichnet;

B) Speichern von Listen ausgewählter der Benutzerkonten, denen der Zugriff auf bestimmte Computersystemressourcen gestattet ist; dann

C) Einleiten eines Zugriffs auf eine der Computersystemressourcen (35b, 35c) in Reaktion auf eine Anforderung für ein erstes der Benutzerkonten (33a); und

D) nach Schritt C) Verarbeiten der Anforderung vom ersten Benutzerkonto für den Zugriff auf diejenige der Computersystemressourcen (35b, 35c) durch Ausführen folgender Schritte:

i) Vergleichen der in dem Benutzerkontenspeicher in Zuordnung zum ersten Benutzerkonto gespeicherten Identifikationsinformation (120) und jedem der Benutzerkonten der Liste ausgewählter Benutzerkonten zugeordneter Identifikationsinformation, und

ii) Zugreifen auf die eine Computersystemressource (35b, 35c), wenn die verglichene Identifikationsinformation übereinstimmt, wodurch angezeigt wird, dass das erste Benutzerkonto zum Zugreifen auf die eine Computersystemressource berechtigt ist;

E) Einleiten des Zugriffs auf eine weitere der Computersystemressourcen (35d, 35a) in Reaktion auf eine Anforderung für das zweite der Benutzerkonten (33b);

F) Verarbeiten der Anforderung vom zweiten Benutzerkonto zur Bemächtigung des Zugriffs auf die weitere Computersystemressource durch das Ausführen der folgenden Schritte:

i) Vergleichen der in dem Benutzerkontenspeicher in Zuordnung zum zweiten Benutzerkonto gespeicherten Identifikationsinformation (120) mit dem ersten Benutzerkonto und mit jedem der Benutzerkonten der Liste ausgewählter Benutzerkonten zugeordneter Identifikationsinformation, und

ii) Ausführen der weiteren Computersystemressource (35d, 35a), wenn

a) die dem zweiten Benutzerkonto und der Liste ausgewählter Benutzerkonten zugeordnete verglichene Identifikationsinformation übereinstimmt, wodurch angezeigt wird, dass das zweite Benutzerkonto zum Zugreifen auf die weitere Computersystemressource berechtigt ist; und

b) die dem zweiten Benutzerkonto und dem ersten Benutzerkonto zugeordnete verglichene Information nicht übereinstimmt, wodurch angezeigt wird, dass das zweite Benutzerkonto kein Pseudonym des ersten Benutzerkontos ist.

6. Verfahren nach Anspruch 5, bei dem jeder der Schritte zum Einleiten eines Zugriffs auf eine Computersystemressource die folgenden Schritte aufweist:

G) Vergleichen eines Validationsberechtigungsausweises (44 oder 45), der die eine Computersystemressource (35b, 35c) oder die weitere Computersystemressource (35d, 35a) mit entsprechenden Benutzerzertifikaten der ausgewählten Benutzerkonten (ACL) verbindet, um festzustellen, ob das erste Benutzerkonto zum Zugreifen auf die eine Computersystemressource (35b, 35c) berechtigt ist beziehungsweise ob das zweite Benutzerkonto zum Zugreifen auf die weitere Computersystemressource (35d, 35a) berechtigt ist.

7. Verfahren nach Anspruch 5, bei dem der Verarbeitungsschritt F) weiter den Schritt aufweist: bei dem der Anforderung nicht erlaubt wird, die weitere Computersystemressource auszuführen, wenn eines der folgenden Ereignisse eintrifft, das aus dem Vergleich der dem zweiten Benutzerkonto und dem ersten Benutzerkonto zugeordneten Information resultiert: i) Das erste Benutzerkonto ist das gleiche wie das zweite Benutzerkonto; ii) das zweite Benutzerkonto hat keine zugeordnete Identifikationsinformation im Benutzerkontenspeicher; und iii) die Identifikationsinformation des zweiten Benutzerkontos in dem Benutzerkontenspeicher ist die gleiche wie die Identifikationsinformation des ersten Benutzerkontos.

8. Verfahren nach Anspruch 1 oder Anspruch 5, bei dem die Identifikationsinformation (120) für das jeweilige Benutzerkonto Authentifizierungsinformation, digitalisierte biometrische Information (105) und Benutzerkonteninformation enthält.

9. Verfahren nach einem der Ansprüche 1, 5 und 6, bei dem die Identifizierungsinformation (120) für das jeweilige Benutzerkonto in einem dem Benutzerkonto zugeordneten digital signierten Zertifikat (130) enthalten ist.

10. Verfahren nach Anspruch 2, weiter mit einem Schritt, bei dem ein Kontenverwalter (110) die digitalisierte biometrische Information (105) überprüft, bevor eine Repräsentation der digitalisierten biometrischen Information im Benutzerkontenspeicher (30) gespeichert wird.

11. Verfahren nach Anspruch 10, bei dem der Schritt der Überprüfung durch den Kontenverwalter während des Anlegens der Benutzerkonten durchgeführt wird.

12. Verfahren nach Anspruch 10, weiter mit einem Schritt, bei dem ein Kontenverwalter (110) die digitalisierte biometrische Information (105) und die Authentifizierungsinformation und die Benutzerkonteninformation digital signiert, bevor die digital signierte Information im Benutzerkontenspeicher (30) gespeichert wird.

13. Verteiltes Computersystem mit einer Pseudonymerkennung, mit:

A) einem Registryspeicher (30) entsprechender Benutzerkonten (33a-33c), wobei die Konten Identifizierungsinformation (120) enthalten, die jeden von mehreren Computerbenutzern eindeutig kennzeichnet;

B) einem gespeicherten Anwendungs-Transaktionsprogramm (35a-35d) mit mindestens zwei Stufen, die zur Ausführung der Stufen getrennte Einleitungsanforderungen benötigen;

C) einer Einrichtung, die auf eine Transaktions-Einleitungsanforderung des ersten Benutzerkontos (33a) eine Stufe (35b, 35c) des Anwendungsprogramms ausführt;

D) einer Einrichtung, die auf eine Gewährung einer Transaktions- Einleitungsanforderung des zweiten Benutzerkontos (33b) eine nächste Stufe (35d, 35a) des Anwendungsprogramms ausführt; und

E) einer Einrichtung zum Vergleichen von Identifikationsinformation des ersten und des zweiten Benutzerkontos (33a, 33b) im Speicher (30) und zum Ausstellen der Gewährung, wenn die verglichenen Identifikationsinformationen nicht übereinstimmen, wodurch angezeigt wird, dass das zweite Benutzerkonto (33b) kein Pseudonym des ersten Benutzerkontos (33a) ist.

14. System nach Anspruch 13, weiter mit einem Kontenverwalter (110) zum digitalen Signieren eines Kontenzertifikats (130), das die Identifikationsinformation (120) für das jeweilige Benutzerkonto enthält.

15. System nach Anspruch 14, bei dem das digital signierte Kontenzertifikat (130) Authentisierungsinformation und digitalisierte biometrische Information (105) und Konteninformation enthält.

16. System nach Anspruch 15, bei dem der Kontenverwalter (110) die digitalisierte biometrische Information (105) überprüft, bevor die digitalisierte biometrische Information im Benutzerkonto (33a-33c) gespeichert wird.

17. System nach Anspruch 13 oder Anspruch 15, bei dem der Kontenverwalter (110) die digitalisierte biometrische Information (105), die Authentifizierungsinformation und die Benutzerkonteninformation digital signiert, bevor die Information im Benutzerkonto (33a-33c) gespeichert wird.

18. System nach Anspruch 13, weiter mit: einer Einrichtung, die auf eine Transaktions-Einleitungsanforderung des zweiten Benutzerkontos (33b) eine nächste Stufe (35d, 35a) des Anwendungstransaktionsprogramms durchführt, um die Authentifizierungsinformation und die digitalisierte biometrische Information (105), die in den Benutzerzertifikaten (130) des ersten und zweiten Benutzerkontos (33a, 33b) im Speicher enthalten sind, zu vergleichen.

19. System nach Anspruch 13, bei dem die auf die erste Anforderung tätig werdende Einrichtung aufweist:

F) eine Einrichtung (44) zum Zuordnen der Benutzeridentifikationsinformation (120) der einen Stufe (35b, 35c) des Anwendungsprogramms;

G) eine Einrichtung zum Überprüfen der ersten Benutzeridentifikationsinformation anhand einer Liste (ACL) von Namen von Konten, um festzustellen, ob die Transaktions-Einleitungsanforderung des ersten Benutzerkontos für eines der auf der Liste erscheinenden Konten erzeugt wurde und daher zum Ausführen der ersten Stufe (35b, 35c) des ausgewählten Transaktionsprogramms berechtigt ist; und

H) eine Einrichtung, die dem ersten Benutzerkonto nur dann erlaubt, die Ausführung der ersten Stufe einzuleiten, wenn es dazu berechtigt ist.

20. System nach Anspruch 13 oder Anspruch 18, bei dem die Einrichtung zum Vergleichen Folgendes aufweist: eine Einrichtung um Beenden der zweiten Anforderung, falls das erste Benutzerkonto das gleiche ist wie das zweite Benutzerkonto (161), das zweite Benutzerkonto keine Identifikationsinformation enthält oder die Identifikationsinformation des zweiten Benutzerkontos die gleiche ist wie die Identifikationsinformation des ersten Benutzerkontos (169).