-
Gebiet der
Erfindung
-
Die
vorliegende Erfindung bezieht sich auf Verbesserungen bei der Sicherheitsarchitektur
von Computerplattformen und insbesondere, obwohl nicht ausschließlich, auf
Verbesserungen bei taktikbasierter Sicherheitsverwaltung bei der
gemeinsamen Datensicherheitsarchitektur (CDSA; CDSA = Common Data
Security Architecture).
-
Hintergrund
der Erfindung
-
Mit
der weiten Annahme des Internets und des World Wide Web ist es für Benutzer
sehr viel leichter geworden, unter Verwendung von gemeinsamen Gatewayschnittstellen
(CGIs; CGIs = Common Gateway Interfaces) oder Servlets über das
Internet auf verschiedene Ressourcen zuzugreifen, wie z. B. Dokumente,
Verzeichnisse, Datenbanken, Webseiten und Dienste. Dadurch sind
einige schwerwiegende Sicherheitsprobleme aufgetreten, die sich
auf den Zugriff von Daten auf einzelnen Rechenressourcen beziehen,
wie z. B. Authentifizierung von Benutzern, Integritätsprüfung von
Benutzerplattformen, Geheimhaltung und Sicherheit von Daten und
Autorisierung zum Zugreifen auf Daten.
-
Bekannte
herkömmliche
Sicherheitssysteme umfassen Cryptographic API (CryptoAPI) von Microsoft,
das vom Internet Explorer 3.x oder darüber und Windows NT 4.0 abhängt, und
die bekannte Java Cryptography Extension (JCE) von Sun Microsystems
ist gleichermaßen
plattformabhängig
und basiert auf einer Java-Plattform. Jedes dieser herkömmlichen
Sicherheitssysteme hängt
von einem proprietären
Betriebssystem oder einer solchen Plattform ab. Die bekannte Common
Data Security Architecture (CDSA) von Intel kann über einen
großen
Bereich von Computerplattformen und Betriebssystemen angewendet
werden. Die Common Data Security Architecture liefert eine flexible
und ausdehnbare Grundstruktur, die es Software und Hardware, die
durch unabhängige
Verkäufer
erzeugt wird, ermöglicht,
zusätzliche
Sicherheitsdienste in einer Computerplattformumgebung zu liefern.
Die Common Data Security Architecture ist ein offener und von der
Industrie akzeptierter Standard, der Interoperabilität zwischen
Plattformen, Plattformunabhängigkeit
und einen umfassenden Satz von Sicherheitsdiensten unterstützt. Seit
die Open Group ihre erste Spezifikation im Dezember 1997 angenommen
hat, wurde CDSA weit verbreitet unterstützt. CDSA ist beschrieben in
dem Dokument „Intel
Security Program", veröffentlicht
von der Intel Corporation am 1. Juli 1998. Mit Bezugnahme auf 1 hierin
hat die herkömmliche
CDSA-Version 2.0
die folgenden vier Schichten:
- – eine Anwendungsschicht 100
- – eine
Mehrschicht-Dienste-Schicht 101 mit einem Satz von Sicherheitsdienstprotokollen,
einem Sprachschnittstellenadapter und Werkzeugen
- – eine
Gemeinsamer-Sicherheitsdiensteverwalter- (CSSM-) Schicht 102
- – eine
Zusatzsicherheitsmodulschicht 103, die eine Einrichtung
für eine
Mehrzahl von Zusatzsicherheitsmodulen aufweist, wie z. B. kryptographische
Dienstanbieter- (CSP-; CSP = Cryptographic Service Provider) Module,
Zertifikatsbibliotheks- (CL-; CL = Certificate Library) Module,
Vertrauenstaktik- (TP-; TP = Trust Policy) Module, Autorisierungsberechnungs-
(AC-; AC = Authorization Computation) Module und Datenspeicherbibliotheks-
(DL-; DL = Data Storage Library) Module.
-
Die
Anwendungsschicht 100 hat einen Satz von Sicherheitsanwendungen,
die in der Schicht enthalten sind; die Mehrschicht-Dienste-Schicht 101 umfasst
typischerweise einen Satz von Sicherheitsdienstprotokollen, wie
z. B. HTTPS, S/MIME, SSL oder SET; die CSSM-Schicht 102 enthält einen
Satz von Verwaltungsmodulen 104–109, einen Satz von Integritätsdiensten
zum Prüfen
der Integrität
von Modulen, einen Verwalter von Sicherheitskontexten für Sicherheitsdienste
und einen Satz von Schnittstellen 110–115; und die Zusatzsicherheitsmodulschicht 103 hat
einen Satz von benutzerkonfigurierbaren Sicherheitsdienstmodulen 116–121,
die proprietär
und verkäuferspezifisch
sein können
und auf die durch die CSSM über
die Schnittstellen 110–115 in
der CSSM-Schicht 102 zugegriffen
werden kann.
-
Die
Sicherheitsdiensteverwaltungsmodule 104–109 umfassen einen
Kryptographiedienstanbieterverwalter 104, einen Vertrauenstaktikmodulverwalter 105;
einen Autorisierungsberechnungsmodulverwalter 106; einen
Zertifikatsbibliotheksmodulverwalter 107; einen Datenspeicherbibliotheksmodulverwalter 108;
und einen Wahlmodulverwalter 109.
-
Eine
Begrenzung der bekannten Common Data Security Architecture tritt
auf, wo ein Satz von Vertrauenstaktiken in eine Computerplattform
implementiert werden soll. Vertrauen in eine Computerplattform ist
ein besonders wichtiges Thema, wo Computerplattformen für elektronischen
Handel verwendet werden und Elemente wie z. B. Kreditkartennummern,
automatische Handelsprogramme und allgemeine kommerzielle Transaktionen
handhaben. Vertrauenstaktiken umfassen einen Satz von Regeln, die
von einer Computerplattform befolgt werden, um einen Vertrauenspegel
in die Integrität
einer Computerplattform zu bestimmen, die ein Benutzer der Computerplattform
und/oder anderen Computerplattformen, die mit der Computerplattform
interagieren, haben kann. Beispielsweise muss ein Benutzer oder eine
dritte Rechenentität,
die mit einer ersten Rechenentität
interagieren, einen Grad an Vertrauen haben, dass die erste Rechenentität nicht
durch einen Virus verfälscht
wurde oder nicht beschädigt wurde,
so dass die Computerplattform nicht vertrauenswürdig ist.
-
In
der bekannten Common Data Security Architecture können Vertrauenstaktiken
durch die Bereitstellung eines Vertrauenstaktikdienstmoduls 117 implementiert
werden. Diese sind jedoch proprietär und verkäuferspezifisch. Jeder andere
Verkäufer
liefert sein eigenes Vertrauenstaktikmodul 117, das mit einer
Semantik geschrieben ist, die für
diesen Verkäufer
spezifisch ist. Die Semantik eines bekannten Vertrauenstaktikmoduls
ist durch den Modulentwickler vollständig fest codiert. Die Vertrauenstaktikmodulbenutzer
müssen
die Semantik verstehen, die von dem verkäuferspezifischen Vertrauenstaktikmodul 117 verwendet
wird, so dass für
jedes Vertrauenstaktikmodul 117 eine Modifikation des Vertrauenstaktikmoduls
durchgeführt
werden muss, aufgrund der unterschiedlichen Semantik, die zwischen
unterschiedlichen Verkäufern
verwendet wird. Sobald ein Vertrauenstaktikmodul 117 herausgegeben
wird, sind Benutzer nicht in der Lage, neue Vertrauenstaktiken hinzuzufügen oder
bestehende zu modifizieren, ohne die verkäuferspezifische Semantik zu
verwenden. Aus der Perspektive des Benutzers ist dies nicht ideal,
da der Benutzer eventuell seine eigene spezifische Vertrauenstaktiken
in seinen Anwendungsbereichen geltend machen möchte, anstatt den Taktiken,
die durch den Verkäufer
geliefert und fest codiert werden. Die Sicherheitsinfrastruktur,
die durch die herkömmliche
CDSA geliefert wird, ist weder vollständig allgemein noch flexibel
für Sicherheit und/oder
Vertrauensverwaltung.
-
Bei
der herkömmlichen
CDSA-Sicherheitsarchitektur wird für jedes Vertrauenstaktikmodul
die Semantik eines Satzes von Vertrauenstaktiken durch einen einzelnen
Entwickler bestimmt. Unterschiedliche herkömmliche Vertrauenstaktikmodule,
die von unterschiedlichen Entwicklern geschrieben werden, haben
unterschiedliche Sätze
von Semantik. Ein Benutzer möchte
eventuell die Vertrauenstaktiken ändern, damit dieselben besser
zu der Geschäftsorganisation des
Benutzers passen. Weil das Vertrauenstaktikmodul eine nicht-allgemeine
Semantik verwendet, muss der Benutzer zu dem Entwickler gehen, der
das Vertrauenstaktikmodul geschrieben hat, damit diese Änderungen
unter Verwendung des herkömmlichen
Sicherheitssystems durchgeführt
werden.
-
Das
Dokument „Accessing
the Intel Random Number Generator with CDSA", das von der Intel Corporation am 1.
Januar 1999 veröffentlicht
wurde, beschreibt ein Zusatzsicherheitsmodul, das eine Schnittstelle
zu einem externen Zufallszahlengenerator aufweist.
-
Zusammenfassung
der Erfindung
-
Es
ist eine Aufgabe der vorliegenden Erfindung, eine verbesserte Common
Data Security Architecture (CDSA) zu schaffen, die das Problem der Vertrauens-
und Sicherheitstaktikverwaltung und das Problem der Verwendung unterschiedlicher
Semantiksätze überwindet,
die in unterschiedlichen verkäuferspezifischen
Vertrauenstaktiken für
eine Computerplattform verwendet und fest codiert werden.
-
Es
ist eine zweite Aufgabe der vorliegenden Erfindung, eine Sicherheitsarchitektur
zu schaffen, bei der einzelne Benutzer ihre eigenen Taktiken spezifizieren
können,
die in den individuellen Anwendungsbereichen des Benutzers geltend
gemacht werden sollen.
-
Es
ist eine dritte Aufgabe der vorliegenden Erfindung, eine verbesserte
Sicherheitsarchitektur zu liefern, bei der einzelne Benutzer ihre
eigenen Taktiken spezifizieren können,
die geltend gemacht werden sollen, innerhalb jeder Schicht der CDSA-Sicherheitsarchitektur.
-
Es
ist eine weitere Aufgabe der vorliegenden Erfindung, eine Architektur
zu schaffen, die es Benutzern ermöglicht, unter Verwendung von
Werkzeugen, die durch die Architektur geliefert werden, ihre eigenen
Taktiken zu definieren.
-
Gemäß einem
Aspekt der vorliegenden Erfindung ist eine Computerplattform vorgesehen,
die zumindest einen Datenprozessor und zumindest eine Speichereinrichtung
umfasst, wobei die Plattform eine Architektur aufweist, die folgende
Merkmale umfasst:
eine Anwendungsschicht zum Aufnehmen einer Mehrzahl
von Benutzersicherheitsanwendungen;
eine Mehrschicht-Dienste-Schicht,
die unter der Anwendungsschicht liegt, zum Aufnehmen einer Mehrzahl
von Sicherheitsdienstprotokollen;
eine gemeinsame Sicherheitsdiensteverwalter- (CSSM-)
Schicht, die unter der Mehrschicht-Dienste-Schicht liegt und eine
Mehrzahl von Sicherheitsdiensteverwaltungseinrichtungen, einen Satz
von Integritätsdiensten,
einen Verwalter von Sicherheitskontexten und eine Mehrzahl von Schnittstellen
zum Bilden einer Schnittstelle mit Zusatzsicherheitsmodulen umfasst;
und
eine Zusatzsicherheitsmodulschicht, die unter der gemeinsamen
Sicherheitsdiensteverwaltungsschicht liegt, die konfiguriert ist,
um eine Mehrzahl von Zusatzsicherheitsmodulen anzunehmen, die einen
Satz von Standardsicherheitsdiensten implementieren;
dadurch
gekennzeichnet, dass die Plattform folgende Merkmale umfasst:
eine
allgemeine Vertrauenstaktikbibliothek in der Zusatzsicherheitsmodulschicht,
die einen Satz von Standardvertrauenstaktikanwendungsschnittstellen (APIs;
API = Applicaton Programming Interface) unterstützt;
eine Vertrauenstaktikbeschreibungsdatei,
die einen Satz von domainspezifisichen Vertrauenstaktiken enthält, die
in
einer Taktiksprache geschrieben sind, die für die Architektur
gemeinsam ist; und
einen Taktikinterpretierer in der gemeinsamen
Sicherheitsdiensteverwalter- (CSSM-) Schicht, wobei der Taktikinterpretierer
durch eine oder mehrere APIs in der allgemeinen Vertrauenstaktikbibliothek
arbeitet, um einen Satz von Taktiken zu interpretieren, die in der
Taktikbeschreibungsdatei enthalten sind.
-
Vorzugsweise
ist zumindest eine der Mehrzahl der Dienstverwaltungseinrichtungen
mit einer entsprechenden Taktikbeschreibungsdatei (PDF) versehen,
die die Taktiken bestimmt, mit denen die zumindest eine Sicherheitsdiensteverwaltungseinrichtung
arbeitet.
-
Vorzugsweise
ist zumindest eines der Mehrzahl von Zusatzsicherheitsdienstmodulen
mit einer entsprechenden jeweiligen Taktikbeschreibungsdatei (PDF)
versehen, die die Taktik bestimmt, mit der das zumindest eine Zusatzsicherheitsdienstmodul
arbeitet.
-
Vorzugsweise
ist die Architektur dadurch gekennzeichnet, dass dieselbe ferner
einen Satz von Taktik- und Modellverfassungswerkzeugen umfasst, die
es einem Benützer
ermöglichen,
eine Taktikbeschreibungsdatei zu erzeugen, die einen Satz von benutzerspezifizierten
Taktiken zum Steuern der Computerplattform implementiert.
-
Die
Taktikbeschreibungssprache umfasst vorzugsweise eine bekannte PROLOG-Sprache.
-
Vorzugsweise
umfasst der Taktikinterpretierer eine PROLOG-Inferenzmaschine.
-
Die
Sicherheitsdiensteverwaltungsschicht ist mit ihrer eigenen Taktikbeschreibungsdatei
zum Implementieren von Taktiken in dieser Schicht versehen.
-
Die
Anwendungsschicht kann mit einer Anwendungsschichttaktikbeschreibungsdatei
versehen sein, zum Bestimmen von Taktiken, die in die Anwendungsschicht
implementiert werden sollen.
-
Die
Mehrschicht-Dienste-Schicht kann mit einer Mehrschicht-Dienste-Taktikbeschreibungsdatei
versehen sein, zum Bestimmen von Taktiken, die von der Mehrschicht-Dienste-Schicht
befolgt werden.
-
Kurze Beschreibung
der Zeichnungen
-
Für ein besseres
Verständnis
der Erfindung und zum Zeigen, wie dieselbe ausgeführt werden kann,
werden nun beispielhaft spezifische Ausführungsbeispiele, Verfahren
und Prozesse gemäß der vorliegenden
Erfindung mit Bezugnahme auf die beiliegenden Zeichnungen beschrieben.
-
1 stellt
schematisch die herkömmliche 4-Schicht-Common-Data-Security-Architecture-Version
2.0 dar;
-
2 stellt
schematisch eine verbesserte Common Data Security Architecture gemäß einer ersten
spezifischen Prototypimplementierung der vorliegenden Erfindung
dar;
-
3 stellt
schematisch ein Beispiel einer Autorisierungstaktik dar, die in
einer Vertrauenstaktikbeschreibungsdatei beschrieben ist, die durch
einen Benutzer erzeugt wird, für
den Anhang an die Common Data Security Architecture gemäß der spezifischen
Implementierung der vorliegenden Erfindung;
-
4 stellt
schematisch ein Datenflussdiagramm für die Verwendung der verbesserten
Common Data Security Architecture von 2 hierin
dar; und
-
5 stellt
schematisch eine zweite verbesserte Common Data Security Architecture
gemäß einem
zweiten spezifischen Ausführungsbeispiel
der vorliegenden Erfindung dar.
-
Detaillierte
Beschreibung des besten Modus zum Ausführen der Erfindung
-
Nachfolgend
wird beispielhaft der beste Modus beschrieben, der von den Erfindern
zum Ausführen
der Erfindung in Betracht gezogen wird. Bei der folgenden Beschreibung
sind zahlreiche spezifische Einzelheiten aufgeführt, um ein gründliches
Verständnis
der vorliegenden Erfindung zu liefern. In anderen Fällen wurden
gut bekannte Verfahren und Strukturen nicht näher beschrieben, um die vorliegende
Erfindung nicht unnötig
zu behindern.
-
Mit
Bezugnahme auf 2 hierin ist schematisch eine
Sicherheitsarchitektur gemäß einer
ersten spezifischen Prototypimplementierung der vorliegenden Erfindung
dargestellt. Die Sicherheitsarchitektur basiert auf einer Verbesserung
der bekannten Common Data Security Architecture Version 1.2,
und der Verwendung des bekannten Netscape Directory Servers, Version 4.0,
die beide mit einem Hewlett Packard HP-UX 11.0 Betriebssystem
kompatibel sind. Die Sicherheitsarchitektur umfasst eine Anwendungsschicht 200,
in der ein Satz von Sicherheitsanwendungen enthalten ist; eine Mehrschicht-Dienste-Schicht 201,
die einen Satz von Sicherheitsdienstprotokollen umfasst, die folgendes
umfassen können:
HTTPS, S/MIME, SSL oder SET; einen Sprachschnittstellenadapter,
Werkzeuge 400 für
Taktik- und Modellverfassung oder dergleichen; eine gemeinsame Sicherheitsdiensteverwalter-
(CSSM-) Schicht 202, die folgen des enthält: einen Satz von Sicherheitsverwaltungsmodulen 203–208,
einen Satz von Integritätsdiensten
zum Prüfen
der Integrität
von Modulen, einen Verwalter von Sicherheitskontexten für Sicherheitsdienste,
einen Taktikinterpretierer 224, der einen Satz von Schnittstellen 209–214;
eine Zusatzsicherheitsdienstemodulschicht 215, die einen Satz
von benutzerkonfigurierbaren Sicherheitsdienstemodulen 216–221 umfasst,
der proprietär
und verkäuferspezifisch
sein kann, und einen Satz von Standard-APIs enthält, und der mit der CSSM über die Schnittstellen 209–214 kommuniziert.
In der gemeinsamen Sicherheitsdiensteverwaltungs- (CSSM-) Schicht 202 gibt
es eine Anwendungsprogrammierschnittstelle (API) zum Bilden einer
Schnittstelle zwischen der Anwendungsschicht 200 und der CSSM-Schicht 202.
-
Die
Sicherheitsverwaltungsmodule umfassen einen kryptographischen Dienstanbieter-
(CSP-) Verwalter 203, einen Vertrauenstaktik- (TP-) Modulverwalter 204,
einen Autorisierungsberechnungs- (AC-) Modulverwalter 205,
einen Zertifikatsbibliotheks- (CL-) Modulverwalter 206,
einen Datenspeicherbibliotheks- (TL-) Modulverwalter 207 und
einen Wahlmodulverwalter 208.
-
Die
Sicherheitsarchitektur umfasst in der Zusatzsicherheitsmodulschicht 215 eine
allgemeine Vertrauenstaktikbibliothek 217, die durch die
Vertrauenstaktikschnittstelle 210 kommuniziert und auf
der Basis der Taktiken arbeitet, die in einer Vertrauenstaktikbeschreibungsdatei 223 beschrieben
sind. Der Taktikinterpretierer 224 kommuniziert mit einer allgemeinen
Vertrauenstaktikbibliothek 217.
-
Die
externe Vertrauenstaktikbeschreibungsdatei 223 ist für eine Anwendungsdomain
spezifisch und kann durch einen Benutzer unter Verwendung von Taktik-
und Modellverfassungswerkzeugen 400 erzeugt werden. Die
Semantik jeder Benutzervertrauenstaktik ist vollständig durch
die externe Vertrauenstaktikbeschreibungsdatei 223 dieses
Benutzers definiert.
-
Die
Kombination der allgemeinen Vertrauenstaktikbibliothek 217 und
einer spezifischen Vertrauenstaktikbeschreibungsdatei 223 ersetzt
das herkömmliche
Vertrauenstaktikmodul 117 in der bekannten Common Data
Security Architecture. Weil die Vertrauenstaktikbibliothek 217 allgemein
ist, kann die herkömmliche
Vertrauenstaktikbibliothek 117, die nicht allgemein und
für einen
herkömmlichen
Vertrauenstaktikmodulentwickler spezifisch ist, durch die Vertrauenstaktikbeschreibungsdatei 223 ersetzt
werden.
-
Die
allgemeine Vertrauenstaktikbibliothek 217 liefert einen
Satz von Modulverwaltungsdiensten für den Anhang/die Trennung der
Vertrauenstaktikbeschreibungsdatei 223 an/von dem CSSM.
Nachdem eine Vertrauenstaktikbeschreibungsdatei 223 auf
einem System erzeugt wurde, kann dieselbe durch die gemeinsame Sicherheitsdiensteverwalter-
(CSSM-) Schicht 202 angehängt werden und wird durch einen Satz
von Vertrauenstaktikdiensten verwendet, die durch die allgemeine
Vertrauenstaktikbibliothek 217 in der Zusatzsicherheitsmodulschicht 215 vorgesehen
sind.
-
Taktiken,
die in der Vertrauenstaktikbeschreibungsdatei 223 enthalten
sind, werden durch einen Taktikinterpretierer 224 implementiert,
der eine Inferenzmaschine umfasst. Die Inferenzmaschine kann beurteilen,
ob eine Taktikaussage wahr oder falsch ist. In jeder API der allgemeinen
Vertrauenstaktikbibliothek 217 wird ein Aufruf an den Taktikinterpretierer 224 durchgeführt, um
zu sehen, ob die API eine bestimmte Funktion durchführen kann,
jedes Mal, wenn eine solche Funktion versucht wird. Für jede bestimmte
API der allgemeinen Vertrauenstaktikbibliothek 217 gibt
es eine zugeordnete Vertrauenstaktik in der Benutzervertrauenstaktikbeschreibungsdatei 223.
Dies wird durch den Taktikinterpretierer 224 jedes Mal
interpretiert, wenn versucht wird, eine Operation auszuführen. Falls
es beispielsweise erforderlich ist, ein Zertifikat aufzuheben, würde die
relevante API in der allgemeinen Vertrauenstaktikbibliothek 217,
die zum Aufheben eines Zertifikats verwendet wird, vor dem Implementieren
dieser Aufhebung einen verfahrensorientierten Aufruf zu dem Taktikinterpretierer 224 durchführen, der
dann die Taktiken in der Vertrauenstaktikbeschreibungsdatei 223 interpretieren
würde,
um zu sehen, ob dem Aufheber vertraut werden kann, das Zertifikat
aufzuheben. Die Vertrauenstaktikbeschreibungsdatei 223 kann
erfordern, dass der Benutzer ein digitales Zertifikat hat, das durch
eine vertrauenswürdige
Zertifikatsautorität (CA)
erteilt wurde, z. B. Baltimore, Entrust oder ähnliches, bevor dieselbe dem
Benutzer vertraut, ein bestimmtes Zertifikat aufzuheben. Falls ein
Benutzer ein digitales Zertifikat hat, das durch Baltimore zertifiziert
wurde und Baltimore eine vertrauenswürdige CA ist, dann wird dem
Benutzer vertraut, ein Zertifikat aufzuheben.
-
Eine
Vertrauenstaktik kann sein, „falls
ein Benutzer ein digitales Zertifikat hat, das durch zumindest zwei
vertrauenswürdige
Zertifikatsautoritäten (CAs)
kreuzzertifiziert wurde, dann kann einem Benutzer vertraut werden,
die Zertifikate aufzuheben". Ein
anderer Benutzer kann eine andere Vertrauenstaktik wie folgt implementieren, „falls
der Benutzer ein digitales Zertifikat hat, das von einer der vertrauenswürdigen CAs
zertifiziert ist, dann wird dem Benutzer vertraut, die Zertifikate
aufzuheben". Diese beiden
Vertrauenstaktiken können
durch zwei unterschiedliche Benutzer implementiert werden unter Verwendung
der gleichen Architektur gemäß dem besten
Modus hierin, indem jeder Benutzer unterschiedliche Vertrauenstaktikbeschreibungsdateien 223 hat,
aber die den gleichen Taktikinterpretierer 224 und eine
allgemeine Vertrauenstaktikbibliothek 217 verwendet, die
durch die hierin beschriebene Architektur geliefert wird.
-
Bei
dem besten Modus hierin werden der Taktikinterpretierer 224 und
die allgemeine Vertrauenstaktikbibliothek 217 einmal entwickelt
und alle Änderungen
an den Vertrauenstaktiken des Benutzers werden durch die Änderungen
eines Benutzers an seiner Vertrauenstaktikbeschreibungsdatei 223 durchgeführt, unter
Verwendung der Taktik- und Modellverfassungswerkzeuge 400.
-
Die
Taktikbeschreibungssprache definiert eine Sprache zum Einstellen
von Sicherheitstaktiken. Bekannte herkömmliche Sicherheitstaktikbeschreibungssprachen
sind für
einen Nichtprogrammierer entweder zu spezifisch oder zu kompliziert
zu verwenden. Es gibt ein Problem beim Entwerfen einer Sprache,
die sowohl einfach als auch ausdrucksvoll ist. Herkömmliche
Programmiersprachen können
in der allgemeinen Vertrauenstaktikbibliothek 217 verwendet
werden, aber die Taktikbeschreibungssprache muss zumindest einige
der folgenden Merkmale haben.
- – Die Taktikbeschreibungssprache
ist leicht zu verwenden, so dass das Schreiben einer Taktik so leicht
sein sollte wie das Beschreiben, was die Taktik ist.
- – Die
Sprache sollte eine gute Programmierbarkeit haben.
- – Die
Sprache sollte sehr einfach und dennoch ausdrucksvoll genug sein,
um das Schreiben einer Vielzahl von Taktiken zu unterstützen.
- – Die
Sprache sollte in der Lage sein, sowohl Sicherheitstaktiken als
auch domainspezifische Vertrauenstaktiken zu spezifizieren.
- – Die
Sprache sollte das Schreiben eines Satzes von Taktikvorlagen unterstützen. Taktikvorlagen umfassen
voreingestellte Taktiken, die prägnanter sind
als konkret dargestellte Taktiken. Die Sprache sollte das Unterstützen von
Taktiken mit Variablen unterstützen.
- – Die
Sprache sollte das Merkmal der Vernünftigkeit haben. Beispielsweise
muss das Beantworten der Frage „wird dem Benutzer vertraut,
eine Operation einer Res source durchzuführen" erörtert werden,
falls eine Vertrauensbeziehung von einem Satz von Vertrauenstaktiken
abgeleitet werden kann, die in der Vertrauenstaktikbeschreibungsdatei
gespeichert sind. Ferner erfordert das Prüfen nach Taktikkonflikten ein
Element der Erörterung,
das durch die Taktikbeschreibungssprache unterstützt wird.
- – Die
Sprache sollte für
Verfeinerung geeignet sein. Weil die Taktikentwicklung ein Prozess
des Umwandelns einer Taktikbeschreibung hoher Ebene zu einem maschinenverständlichen
Code ist, sollte die Unterstützung
einer inkrementalen Taktikprototypbildung und Verfeinerung ein Merkmal
der Taktikbeschreibungssprache sein.
- – Die
Sprache sollte einen einheitlichen Mechanismus haben. Taktiken,
Beglaubigungen und Vertrauensbeziehungen sollten auf einheitliche Weise
dargestellt und verarbeitet werden, anstatt getrennt bearbeitet
zu werden.
-
In
dem besten Modus hierin wird die herkömmliche Programmiersprache
PROLOG (PROgramming in LOGic) für
die Taktikbeschreibungssprache verwendet. PROLOG ist geeignet für die Verwendung
als Sprache zum Spezifizieren von Sicherheitstaktiken aufgrund ihrer
folgenden Charakteristika.
- – PROLOG ist erklärend. Eine
Regel in PROLOG definiert eine Beziehung zwischen mehreren Objekten.
Eine Sicherheitstaktik kann als Regel in PROLOG beschrieben werden.
Ferner ist das Spezifizieren einer Vertrauenstaktik in PROLOG beinahe
so einfach wie das Beschreiben, wie die Vertrauensbeziehung ist.
- – In
PROLOG können
Regeln Variablen enthalten, so dass die PROLOG-Sprache das Schreiben
von Taktikvorlagen unterstützt.
- – PROLOG
ist in der Lage, von einem Satz von Regeln zu erörtern, der sowohl Taktikbewertung als
auch Taktikkonflikterfassung unterstützt.
- – Datenstrukturen
in PROLOG sind einheitlich ausgedrückte Strukturen. Daher könne alle
Sicherheitsobjekte auf einheitliche Weise dargestellt werden und
somit ihre Verarbeitung vereinfachen.
- – PROLOG
ist eine produktive Modelliersprache, die sowohl inkrementales Taktikschreiben
als auch Taktikverfeinerung unterstützt.
- – PROLOG
liefert auch eine verfahrensorientierte Interpretation, so dass
Aktionen durchgeführt
werden können,
wenn sie notwendig sind.
- – PROLOG
basiert auf Hornklauseln, die ein Teilsatz der Logik erster Ordnung
(FOL; FOL = First Order Logic) sind, die eine solide mathematische Grundlage
für allgemeines
Taktikübereinstimmungsprüfen liefert.
-
Bei
einer Prototypimplementierung des besten Modus auf der Basis von
HP-UX 11.0 ist die PROLOG-Sprache als Endtaktikdarstellungssprache
angenommen und eine gemeinschaftlich verwendete Bibliothek wird
erzeugt, um als ein Taktikinterpretierer zu wirken. Es wurde beobachtet,
dass das Schreiben von domainspezifischen Taktiken ein System und
einen Geschäftsprozess
einer Organisation unter Verwendung der Modellverfassungswerkzeuge 400 modellieren
muss.
-
Innerhalb
von Anwendungen ruft ein Benutzer zunächst eine gemeinsamer Sicherheitsdienste-Verwalter-
(CSSM-) Anwendungsprogrammierschnittstelle (API) auf und fragt dann
den gemeinsamen Sicherheitsdiensteverwalter, sich an die allgemeine
Vertrauenstaktikbibliothek 217 anzuhängen, was während der CSSM-Initialisierung
durchgeführt werden
kann. Die allgemeine Vertrauenstaktikbibliothek 217 unterstützt eine
PassThrough-API, die eine Anfrage auf der Basis eines Satzes von
Taktiken bewerten kann. Bei Funktionen, die jede der APIs eines Standardvertrauenstaktikmoduls 117 definieren,
wird die PassThrough-Funktion als erstes aufgerufen, um die Taktiken
geltend zu machen, die der bestimmten API zugeordnet sind. Auf diese
Weise sind sowohl die Zusatzsicherheitsmodule als auch der gemeinsame
Sicherheitsdiensteverwalter (CSSM) in der Lage, ihre eigenen Sicherheitstaktiken
geltend zu machen, durch Aufrufen der allgemeinen Vertrauenstaktikbibliothek-PassThrough-API.
Dies ist ein wesentlicher Vorteil im Vergleich zu der herkömmlichen
Common Data Security Architecture (CDSA-) Grundstruktur.
-
Nachfolgend
wird ein Beispiel einer Taktik beschrieben, die in der Form einer
PROLOG-Aussage in der Vertrauenstaktikbeschreibungsdatei 223 eines
Benutzers gespeichert ist.
-
Mit
Bezugnahme auf 3 hierin ist ein Beispiel einer
Autorisierungstaktik definiert, dass ein Bankkontoinhaber (U) einen
Betrag P Pfund Sterling von seinem Konto A zu einem anderen Bankkonto
B übertragen
kann, falls der Betrag P geringer als 10.000 Pfund ist und geringer
als der aktuelle Stand des Kontos A. Bei der in 3 gezeigten
Regel sind das Konto Nummer A, das Konto Nummer B, der Betrag P
und der Stand (Balance) des Kontos A logische Variablen, die nur
in der beschriebenen Regel gültig
sind.
-
Bei
dem Beispiel von 3 wird ein Verfahren verwendet,
um externe Informationen über
ein Bankkonto wiederzugewinnen. Falls die Aussage
Balance_of_Account
(Balance, A)
(Kontostand (Stand, A)
als wahr bewertet
wird, wird die logische Variable Balance vereinheitlicht auf den
echten Stand des Bankkontos A. Ferner wird angenommen, dass die
Beziehung Owner_of_Account (Inhaber_des_Kontos) (U, A) auch in einem
Modell definiert wurde.
-
Wenn
ein Benutzer Geld zwischen seinen beiden Bankkonten A, B übertragen
möchte,
kann dies durchgeführt
werden, falls die obige Taktik als wahr bewertet wird. Andernfalls
wird dem Benutzer nicht vertraut, das Geld zu übertragen.
-
Bei
dem obigen Beispiel wird die Taktik, wie sie in 3 dargestellt
ist, in einer Vertrauenstaktikbeschreibungsdatei 223 gespeichert,
die durch einen Dienstanbieter erzeugt wird, und durch den Taktikinterpretierer 224 interpretiert.
Die allgemeine Vertrauenstaktikbibliothek 217 führt die
Funktion des Anhangs/der Entfernung der Vertrauenstaktikbeschreibungsdatei 223 an/von
dem CSSM durch.
-
Mit
Bezugnahme auf 4 ist schematisch ein Mechanismus
für die
Geltendmachung von Taktiken in der Architektur gemäß dem besten
Modus der vorliegenden Erfindung dargestellt. Um die Architektur
zu nutzen, muss ein Benutzer einen Satz von Vertrauenstaktiken in
einer Vertrauenstaktikbeschreibungsdatei 223 liefern, die
durch den Benutzer geliefert wird. Die allgemeine Vertrauenstaktikbibliothek 217 ist
vorbestimmt und wird einmal für
die Zusatzsicherheitsdienstschicht 215 erzeugt. Dies vereinfacht die
Entwicklung der herkömmlichen
Vertrauenstaktikmodule 117. In der Mehrschicht-Dienste-Schicht 501 ist
ein Satz von Taktik- und Modellverfassungswerkzeugen 400 vorgesehen,
der es dem Benutzer ermöglicht,
die Vertrauenstaktikbeschreibungsdatei (TPDF) zu entwickeln. Die
allgemeine Vertrauenstaktikbibliothek 217 ist getrennt
von dem Taktikinterpretierer 224. Die Semantik einer Vertrauenstaktik
ist vollständig
definiert durch die entsprechende Vertrauenstaktikbeschreibungsdatei 223,
die durch den Benutzer unter Verwendung der Taktik- und Modellverfassungswerkzeuge 400 erzeugt
wird. Weil die Vertrauenstaktikbeschreibungsdatei 223 unter
Verwendung einer allgemeinen Taktikbeschreibungssprache erzeugt
wurde, ist die Vertrauenstaktikbeschreibungsdatei bereits in einem
allgemeinen Format, das für
die Architektur verständlich
ist und zu einer anderen Computerplattform der gleichen Architektur übertragen
werden kann. Wie es in 4 dargestellt ist, können Taktiken
auch von einer Datenspeichervorrichtung 401 wiedergewonnen
werden, auf die dieselben vorgeschrieben sein können.
-
Mit
Bezugnahme auf 5 ist schematisch eine zweite
spezifische Implementierung gemäß der vorliegenden
Erfindung dargestellt. Die Architektur der zweiten spezifischen
Implementierung basiert auf dem, wie es vorher mit Bezugnahme auf
die erste spezifische Implementierung beschrieben wurde. Die Architektur
umfasst eine Anwendungsschicht 500, eine Mehrschicht-Dienste-Schicht 501,
eine gemeinsame Sicherheitsdiensteverwalter- (CSSM-) Schicht 502 und
eine Zusatzsicherheitsdienstmodulschicht 503. In der Anwendungsschicht 500 sind
eine Mehrzahl von Sicherheitsanwendungen 504 vorgesehen und
eine Anwendungstaktikbeschreibungsdatei 540, die einen
Satz von benutzerspezifizierten Taktiken enthält, die an die Anwendungsdomain
anwendbar sind. Bei der Mehrschicht-Dienste-Schicht 501 sind eine
Mehrzahl von Mehrschicht-Diensten 505 vorgesehen, wie sie
hierin oben beschrieben sind, und außerdem eine Mehrschicht-Dienste-Taktikbeschreibungsdatei 506,
die einen Satz von Taktiken enthält, die
auf die Dienste anwendbar sind, die in der Mehrschicht-Dienste-Schicht 501 enthalten
sind. In der gemeinsame Sicherheitsdiensteverwalter- (CSSM-) Schicht 502 sind
ein Satz von Verwaltungsmodulen, ein Satz von Integritätsdiensten,
ein Sicherheitskontextverwalter, ein Taktikinterpretierer 510,
Werkzeuge für
Taktik- und Modellverfassung oder dergleichen, Schnittstellen 521–526, über die
CSSM mit Zusatzsicherheitsmodulen 527–532 kommuniziert,
wie es hierin oben beschrieben ist, und eine CSSM-Taktikbeschreibungsdatei 520 vorgesehen,
die Taktiken umfasst, die auf den Betrieb der CSSM-Schicht 502 anwendbar
sind. In den Zusatzsicherheitsmodulen 503 sind CSP-Module 527,
eine allgemeine Vertrauenstaktikbibliothek 528 und ein
oder mehrere Vertrauenstaktikbeschreibungsdateien 534,
AC- Module 529,
CL-Module 530, DL-Module 531 und Wahlmodule 532 vorgesehen,
für die
Bereitstellung neuer Dienste, die durch einen Benutzer gewählt und
spezifiziert werden können.
Ferner können
Zusatzsicherheitsmodule 527, 529–532 auch
durch ihre jeweiligen Taktikbeschreibungsdateien 535–539 erweitert
werden.
-
Die
Verwaltungsmodule umfassen einen Kryptographiedienstanbieter- (CSP-)
Verwalter 507 und außerdem
eine CSP-Verwaltertaktikbeschreibungsdatei 508,
die Taktiken enthält,
die auf den CSP-Verwalter anwendbar sind; einen Vertrauenstaktik-
(TP-) Modulverwalter 509 und außerdem eine TP-Verwaltertaktikbeschreibungsdatei 511,
die Taktiken enthält,
die auf den TP-Verwalter anwendbar sind, einen Autorisierungsberechnungs-
(AC-) Modulverwalter 512 und außerdem eine AC-Verwaltertaktikbeschreibungsdatei 513,
die einen Satz von Taktiken enthält,
die auf den AC-Modulverwalter
anwendbar sind; einen Zertifikatsbibliotheks- (CL-) Modulverwalter 514 und
außerdem
eine CL-Verwaltertaktikbeschreibungsdatei 515,
die Taktiken enthält, die
auf den CL-Modulverwalter anwendbar sind; einen Datenspeicherungsbibliotheks-
(DL-) Modulverwalter 516 und außerdem eine DL-Verwaltertaktikbeschreibungsdatei 517,
die Taktiken enthält,
die auf den DL-Modulverwalter anwendbar sind; einen Wahlmodulverwalter 518 und
außerdem
eine Wahlmodulverwaltertaktikbeschreibungsdatei 519, die
Taktiken enthält,
die auf die Verwaltung der Wahlmodule anwendbar ist.
-
Sicherheitstaktiken
jeder Schicht in der Architektur werden durch einzelne Taktikbeschreibungsdateien
implementiert, die durch einen Benutzer oder einen Verkäufer definiert
sein können.
-
Jeder
Modulverwalter in der gemeinsamen Sicherheitsdiensteverwalter- (CSSM-)
Schicht 502 kann daher seinen eigenen Satz von Taktiken
haben, die vom Modulverwalterentwickler definiert sein können unter
Verwendung von Werkzeugen, wie sie hierin mit Bezugnahme auf 2 beschrieben
sind, in einer Sprache, die für
die Architektur üblich
ist. Auf jeder Ebene hat der Benutzer Steuerung über die Sicherheitstaktiken,
die in jeder Schicht angewendet werden, durch Einstellen der Taktiken
in dieser Schicht unter Verwendung des Werkzeugsatzes, der in der
Architektur vorgesehen ist. Außerdem
kann ein Benutzer innerhalb einzelner Zusatzsicherheitsmodule selbst,
beispielsweise der Datenspeicherungsbibliothek 531, auch
eine spezifische Taktikbeschreibungsdatei 538 erzeugen,
zum Steuern von Zugriff auf die Daten in einem Datenspeicher 533.
Eine beispielhafte Taktik kann wie folgt sein: „Einem Benutzer einer Anwendung
ist es nicht erlaubt, private Schlüsseldaten in eine Datenspeicherung
auf der Basis eines lokalen Dateisystems zu speichern". Diese Taktik kann
in einer Taktikbeschreibungsdatei 538 gespeichert sein,
die in der Datenspeicheungsbibliothek 531 zugeordnet ist.
Eine weitere Taktik kann sein: „Falls ein Benutzer auf Taktikdaten
zugreifen möchte, die
in einer Datenspeichervorrichtung gespeichert sind, muss der Benutzer
sich selbst der Datenspeichervorrichtung authentifizieren".
-
Jede
Taktikbeschreibungsdatei wird durch den Einzeltaktikinterpretierer 510 interpretiert,
der in der gemeinsamen Sicherheitsdiensteverwalter- (CSSM-) Schicht 502 vorgesehen
ist. Außerdem
hat die CSSM-Schicht selbst eine Taktikbeschreibungsdatei 520,
wodurch ein Benutzer Taktiken beschreiben kann, mit denen der CSSM
arbeitet, unter Verwendung des gemeinsamen Werkzeugsatzes, der in der
Mehrschicht-Dienste-Schicht 501 vorgesehen ist, wie es
hierin mit Bezugnahme auf 2 beschrieben ist.
Beispielsweise kann der CSSM seine eigene Taktik, die in einer CSSM-spezifischen Taktikbeschreibungsdatei 520 gespeichert
ist, wie folgt implementieren: „Der CSSM kann sich selbst
nur an Sicherheitsmodule anhängen,
die durch die Modulentwickler unterzeichnet wurden, die digitale
Zertifikate haben, die durch den CSSM-Verkäufer ausgestellt wurden".
-
Es
ist sowohl eine dynamische Verbindungsbibliothek (DLL) auf Windows
NT 4.0 vorgesehen, als auch eine gemeinschaftlich verwendete Bibliothek auf
dem HP-UX 11.0 des Taktikinterpretierers 510,
so dass der gemeinsame Sicherheitsdiensteverwalter und alle Zusatzsicherheitsmodule
ihre eigenen Taktiken geltend machen können durch direktes Aufrufen des
Taktikinterpretierers anstatt durch Aufrufen der allgemeinen Vertrauenstaktikbibliothek-PassThrough-API.
Ein Vorteil dieser Lösung
ist ihre hohe Effizienz. Zusätzlich
kann es sein, dass es keinen Bedarf an einem Vertrauenstaktikmodulverwalter 509 gibt,
weil die allgemeine Vertrauenstaktikbibliothek 528 Teil
der gemeinsamen Sicherheitsdiensteverwalterschicht 502 werden
kann. Aus der Perspektive des Benutzers und für ursprüngliche herkömmliche
CDSA-Anwendungen sollte die Schnittstelle jedoch rückwärtskompatibel
sein. Daher ist es sinnvoll, die CDSA sowohl mit einer gemeinschaftlich
verwendeten Bibliothek als auch einem Zusatzsicherheitsmodul der
allgemeinen Vertrauenstaktikbibliothek 528 zu versehen.
-
Verschiedene
Schnittstellen in der gemeinsamen Sicherheitsdiensteverwalterschicht,
in dem Kryptographiedienstanbietermodul, dem Zertifikatsbibliotheksmodul
und dem Datenspeicherbibliotheksmodul können taktikbasiert sein. Beispiele
derselben sind wie folgt:
- – Kryptographiedienstanbieter
(CSP): private Schlüsselspeicherung
in einem CSP kann eine Taktik geltend machen, dass der CSP Schlüsselmaterial
nicht offenbart, außer
dies wurde kryptographisch geschützt.
- – Eine
verzeichnisbasierte Datenspeicherungsbibliothek (DL): zum Wiedergewinnen
von Sicherheitstaktiken, die in dem Verzeichnis gespeichert sind,
müssen
Benutzer authentifiziert sein durch den Verzeichnisserver unter
Verwendung ihrer Berechtigungsnachweise.
- – Gemeinsame
Sicherheitsdiensteverwalter- (CSSM-) Schicht: bevor der CSSM sich
an ein Kryptographiedienstanbieter- (CSP-) Modul anhängt, muss
dasselbe die Signaturen auf dem CSP-Modul verifizieren.
-
Das
Wahlmodul 532 ist für
eine zukünftige Wahlverwendung
reserviert. Das Wahlmodul kann für den
Einbau eines Schlüsselwiedergewinnungsmoduls
oder eines Benutzerauthentifizierungsmoduls verwendet werden.
-
Die
Integritätsdienste
in der CSSM-Schicht 502 prüfen die Integrität jedes
Zusatzmoduls und des CSSM selbst. Jedes der Zusatzsicherheitsmodule 527–532 muss
auf der Basis ihrer Signaturen verifiziert werden, die durch Modulentwickler
unterzeichnet sind. Jedes Modul hat ein digitales Zertifikat, das durch
seinen Entwickler unterzeichnet wurde und in das Modul aufgenommen
wurde, wobei der CSSM-Verkäufer dem
Zertifikat vertraut.
-
Neben
dem Bereitstellen von Integritätsdiensten
liefert der CSSM auch Sicherheitskontextverwaltung. Wo beispielsweise
unterschiedliche Algorithmen verwendet werden, um Daten zu unterzeichnen
und/oder zu verschlüsseln,
was auf einer Element-um-Element-Basis erreicht werden kann, wobei
Datenelemente unterschiedliche Sicherheitskontexte für Datenunterzeichnung
und/oder Datenverschlüsselung
verwenden, die durch den CSP durchgeführt wird. Ein Benutzer kann
unterschiedliche CSPs verwenden, die von unterschiedlichen Herstellern
stammen können.
-
Eine
weitere Funktion der CSSM-Schicht ist Modulverwaltung. Module können an
den CSSM angehängt
oder von demselben gelöst
werden, was durch die CSSM-Schicht verwaltet wird. Taktiken, die das
Anhängen
und Entfernen von Modulen regeln, können in der CSSM-Taktikbeschreibungsdatei 520 von
einem CSSM-Verkäufer
spezifiziert sein. Die Mehrschicht-Dienste-Schicht kann auch ihre Taktikbeschreibungsdatei 506 umfassen,
die die Sicherheitsdienstprotokolle, Sprachen schnittstellenadapter
für Sprachen,
wie z. B. Java und C++, und Werkzeuge regelt.
-
Ebenso
wie Taktiken, die an die Anwendungsschicht 500, die Mehrschicht-Dienste-Schicht 501 und
die CSSM-Schicht 502, angelegt werden, können Benutzer
ihre eigenen Sicherheits- und
Vertrauenstaktiken an der Zusatzsicherheitsmodulschicht 503 definieren,
durch Aufnehmen einzelner benutzergeschriebener Taktikbeschreibungsdateien in
jedes der Kryptographiedienstanbieter- (CSP-) Module 527,
das Autorisierungsberechnungs- (AC-) Modul 529, das Zertifikatsbibliotheks-(CL-) Modul 530,
die Datenspeicherbibliotheks- (DL-) Module 531 und die
Wahldienstmodule 532.
-
Der
Benutzer kann seine eigenen Vertrauenstaktiken in der Benutzertaktikbeschreibungsdatei definieren.
Die Vertrauenstaktikbeschreibungsdatei 534 speichert Taktiken,
die einen Satz von domainspezifischen Vertrauenstaktiken beschreiben,
die bestimmen, ob einem Benutzer vertraut werden kann, um bestimmte
Operationen durchzuführen.
Beispielsweise das Zulassen eines Benutzers zu einer finanziellen
Transaktion. In dem besten Modus können unterschiedliche Benutzer
unter Verwendung der gleichen allgemeinen Vertrauenstaktikbibliothek 528 jeweils
ihre eigene Vertrauenstaktikbeschreibungsdateien 534 spezifizieren
und ihre eigenen Vertrauenstaktiken beschreiben.
-
Ein
Beispiel einer Taktik, die in der CSP-Taktikbeschreibungsdatei 535 in
einem CSP-Modul 527 gespeichert ist, kann wie folgt sein: „Der private Schlüssel eines
Benutzers darf nie dem CSSM oder dem Rest der Sicherheitsarchitektur
einer Computerplattform gezeigt werden, außer er wurde kryptographisch
geschützt".