DE69731714T2

DE69731714T2 - Dynamische Dienstklassen für eine internationale kryptographische Struktur

Info

Publication number: DE69731714T2
Application number: DE69731714T
Authority: DE
Inventors: Helmut Fieres; Roger Merckling; Keith Klemba
Original assignee: CHEYENNE PROPERTY TRUST SAN FR; CHEYENNE PROPERTY TRUST SAN FRANCISCO
Current assignee: CHEYENNE PROPERTY TRUST SAN FR; CHEYENNE PROPERTY TRUST SAN FRANCISCO
Priority date: 1996-11-12
Filing date: 1997-09-10
Publication date: 2005-11-03
Anticipated expiration: 2017-09-11
Also published as: DE69731714D1; JPH10313309A; US5740248A; EP0843249A1; US5841870A; EP0843249B1

Description

Hintergrund der Erfindung
Technisches Gebiet
Die Erfindung bezieht sich auf Kryptographie. Insbesondere bezieht sich die Erfindung auf dynamische Dienstklassen für die Verwendung mit einer internationalen Kryptographiegrundstruktur.
Beschreibung des Stands der Technik
Kunden von großen Computersystemen sind typischerweise multinationale Konzerne, die firmenweite computerbasierte Lösungen kaufen möchten. Die verteilte Natur solcher Organisationen erfordert es, dass dieselben öffentliche internationale Kommunikationsdienste verwenden, um Daten innerhalb ihrer Organisation zu transportieren. Selbstverständlich sind sie besorgt um die Sicherheit ihrer Kommunikation und möchten moderne Ende-zu-Ende-Kryptographiemöglichkeiten verwenden, um Geheimhaltung und Datenintegrität sicherzustellen.
Die Verwendung von Kryptographie in der Kommunikation wird durch nationale Richtlinien bzw. Taktik bestimmt und leider unterscheiden sich die nationalen Richtlinien bezüglich dieser Verwendung. Jede nationale Richtlinie wird unabhängig entwickelt, im allgemeinen mit einem nationaleren Schwerpunkt anstatt internationalen Überlegungen. Es gibt Standardgruppen, die versuchen, einen gemeinsamen kryptographischen Algorithmus zu entwickeln, der für eine internationale Kryptographie geeignet ist. Das Thema der internationalen Kryptographiestandards ist jedoch kein technisches Problem, sondern ein politisches Thema, dem die nationale Souveränität zugrunde liegt. Als solches ist es unrealistisch zu erwarten, dass die unterschiedlichen nationalen Kryptographierichtlinien durch einen technischen Standardisierungsprozess aufeinander abgestimmt werden.
Das Thema nationaler Interessen bei der Kryptographie ist von besonderem Belang für Firmen, die Informationstechnologieprodukte auf der Basis eines offenen Standards für einen weltweiten Markt herstellen. Der Markt erwartet, dass diese Produkte sicher sind. Immer mehr Verbraucher dieser Produkte sind jedoch selbst multinational und fordern von den Herstellern, dass sie ihnen dabei helfen, die internationalen Kryptographieprobleme zu lösen, die ihre weltweite Informationstechnologieentwicklung hemmen. Die anhaltenden ungelösten Unterschiede und Exportbeschränkungen bei nationalen Kryptographierichtlinien haben einen nachteiligen Effekt auf das Wachstum des internationalen Marktes für sichere offene Rechenprodukte. Somit wäre es hilfreich, eine internationale Grundstruktur zu schaffen, die globale Informationstechnologieprodukte liefert, die gemeinsame Sicherheitselemente aufweisen, während sie gleichzeitig die unabhängige Entwicklung nationaler Kryptographierichtlinien respektieren.
Die Nationen haben Gründe zum Einführen von Richtlinien, die die Kryptographie regeln. Häufig haben diese Gründe mit dem Vollzug von Gesetzen und nationalen Sicherheitsthemen zu tun. Innerhalb jedes Landes kann es zwischen der Regierung und dem Volk Debatten über die Richtigkeit und Annehmbarkeit dieser Richtlinien geben. Anstatt sich an diesen Debatten zu beteiligen oder zu versuchen, deren Ergebnis vorherzusagen, ist es praktischer, das souveräne Recht jeder Nation, eine unabhängige Richtlinie festzulegen, die die Kryptographie in der Kommunikation regelt, zu akzeptieren.
Richtlinien, die die nationale Kryptographie regeln, drücken nicht nur den Willen des Volkes und der Regierung aus, sondern umfassen auch bestimmte Technologien, die Krypto graphie ermöglichen. Die Wahl der Technologie ist sicherlich ein Bereich, wo die Standardisierung eine Rolle spielen kann. Wie es früher angemerkt wurde, ist dies jedoch nicht lediglich ein technisches Problem, so dass zum Beispiel die Auswahl gemeinsamer kryptographischer Technologien allein die Unterschiede bei den nationalen Richtlinien nicht lösen kann. Folglich wäre es nützlich, eine gemeinsame akzeptierte Kryptographiegrundstruktur zu schaffen, bei der unabhängige Technologie und Richtlinienauswahlen auf eine Weise getroffen werden können, die nach wie vor eine internationale Kryptographiekommunikation ermöglicht, die mit diesen Richtlinien übereinstimmt.
Eine Vier-Teil-Technologiegrundstruktur, die eine internationale Kryptographie unterstützt, die eine nationale Flagkarte, eine kryptographische Einheit, ein Hostsystem und einen Netzwerksicherheitsserver umfasst, ist offenbart in K. Klemba, R. Merckling, International Crytpography Framework in einer mitanhängigen U.S.-Patentanmeldung mit der Seriennummer 08/401,588, die am 8. März 1995 eingereicht wurde. Drei dieser vier Dienstelemente haben eine im wesentlichen hierarchische Beziehung. Die nationale Flagkarte (NFC = National Flag Card) ist in der kryptographischen Einheit (CU = Cryptographic Unit) installiert, die wiederum in einem Hostsystem (HS) installiert ist. Kryptographische Funktionen auf dem Hostsystem können nicht ohne eine kryptographische Einheit ausgeführt werden, die selbst das Vorliegen einer gültigen nationalen Flagkarte erfordert, bevor die Dienste derselben verfügbar sind. Das vierte Dienstelement, ein Netzwerksicherheitsserver (NSS = Network Security Server), kann einen Bereich von unterschiedlichen Sicherheitsdiensten liefern, einschließlich der Verifizierung der anderen drei Dienstelemente.
Die Internationale Kryptoghaphiegrundstruktur (ICF; ICF = International cryptography framework) unterstützt den Entwurf, die Implementierung und Betriebselemente jeder und aller nationalen Richtlinien, während der Entwurf, die Entwicklung und der Betrieb der unabhängigen Sicherheitsrichtlinien vereinheitlicht wird. Die Grundstruktur gibt daher den Dienstelementen der nationalen Sicherheitsrichtlinien eine Standardform, wo solche Dienstelemente Dinge wie Hardwareformfaktoren, Kommunikationsprotokolle und Online- und Offline-Datendefinitionen umfassen.
Kritisch für die Implementierung der Grundstruktur ist die Bereitstellung einer grundlegenden Technologie, die die Herstellung der verschiedenen Dienstelemente ermöglicht. Obwohl verschiedene Implementationen der Dienstelemente innerhalb der Fähigkeiten eines Fachmanns auf diesem Gebiet liegen, gibt es einen Bedarf an spezifischen Verbesserungen des Stands der Technik, falls das volle Potential der Grundstruktur realisiert werden soll. Beispielsweise wäre es vorteilhaft, einen sicheren Mechanismus zum Herstellen verschiedener Dienstklassen und Verfahren in Verbindung mit der Verwendung von Kryptographie und anderen Merkmalen der Grundstruktur zu liefern.
Bransted M. u. a.: „The Role of Trust in Protected Mail", IEEE Computer Society Symposium on Research in Computer Security and Privacy, 7. Mai 1990, Seiten 210 bis 215, bezieht sich auf ein vertrauenswürdiges Betriebssystem zum Schützen einer Tmail und die kryptographischen Module, die beim Übertragen der Tmail beteiligt sind. Eine Zertifizierungsautorität zum Erzeugen von Zertifikaten ist vorgesehen. Die Zertifizierungsautorität erzeugt und unterzeichnet Öffentlicher-Schlüssel-Zertifikate für lokale Schlüsselverwalter und registrierte Benutzer, wobei der Lokale-Schlüssel-Verwalter ein Programm ist, das die kryptographischen Informationen über den spezifischen Host und die lokalen Benutzer verwaltet. Das Zertifikat wird validiert durch Erzeugen einer Signatur, die aus einem Hash der Benutzerinformationen besteht, die mit dem privaten Schlüssel der Zertifizierungsautorität verschlüsselt sind. Die Öffentlicher-Schlüssel-Zertifikate werden an einen Empfänger gesendet, wobei die Validierung der digitalen Signatur durch den Empfänger, die dem Öffentlicher-Schlüssel-Zertifikat zugeordnet ist, eine Gewissheit liefert, dass das Zertifikat authentisch ist und die Informationen in demselben nicht manipuliert wurden.
Die US-A-4,649,510 bezieht sich auf Verfahren und Vorrichtungen für die Schutzsteuerung von Computerprogrammen. Insbesondere bezieht sich dieses Dokument auf das Modifizieren eines gültigen Programms zum Liefern eines ausgestatteten Programms und eines entsprechenden Wiederherstellungsprogramms. Eines oder beide derselben sind gemäß Bestätigungsdaten modifiziert. Das ausgestattete Programm, die Bestätigungsdaten und die Wiederherstellungsprogrammdaten werden dann über getrennte kommerzielle Kanäle an eine ausgestattete Computerinstallation geliefert.
Die EP-A-0 828 208 wurde nach dem Prioritätsdatum der vorliegenden Anmeldung veröffentlicht und bezieht sich auf Anwendungszertifizierung für eine internationale Kryptographiegrundstruktur. Dieses Dokument sagt nichts aus über eine Struktur einer Dienstklasse, die ein Verfahrensfeld und ein Beschränkungsfeld umfasst.
Es ist die Aufgabe der vorliegenden Erfindung, einen sicheren Mechanismus zum Einrichten verschiedener Dienstklassen und Verfahren in Verbindung mit der Verwendung von Kryptographie und anderen Merkmalen einer internationalen Kryptographiegrundstruktur zu schaffen.
Diese Aufgabe wird durch eine Vorrichtung gemäß Anspruch 1 gelöst.
Die internationale Kryptographiegrundstruktur ermöglicht es Herstellern, verschiedene nationale Gesetze zu erfüllen, die die Verteilung kryptographischer Fähigkeiten bestimmen. Insbesondere macht es eine solche Grundstruktur möglich, weltweite kryptographische Fähigkeiten in allen Typen von Informationsverarbeitungsgeräten (z. B. Druckern, Palmtops) zu versenden. Innerhalb der Grundstruktur enthält eine kryptographische Einheit mehrere kryptographische Verfahren (z. B. DES, RSA, MD5).
Die Erfindung hierin bezieht sich hauptsächlich auf die Anwendungszertifizierungsaspekte der Grundstruktur. Es ist eine Grundanforderung einer IC F, dass eine Anwendung, die von den ICF-Dienstelementen kryptographische Dienste anfordert, durch eine Form von Zertifikat identifiziert wird, zum Schutz gegen den Missbrauch eines gewährten Kryptographiepegels. Die gewährten Kryptographiepegel werden über Sicherheitstaktiken beschrieben und als Dienstklassen ausgedrückt.
Die kryptographische Einheit, eines der ICF-Kernelemente, kann verwendet werden, um mehrere Zertifizierungsschemata für Anwendungsobjekte zu erstellen. Die Erfindung liefert verschiedene Verfahren, die die Stärke der Bindung zwischen einem Anwendungscodebild und den ausgegebenen Zertifikaten in dem Kontext der ICF-Elemente bestimmen. Ein Schlüsselelement bezüglich der Ausübung der kryptographischen Funktion bezieht sich auf die speziellen Anforderungen für die Vertrauensbeziehung, die eine Autorität für die kryptographische Einheit spezifiziert. Beispielsweise muss jede Funktion, die durch die kryptographische Einheit ausgeübt wird, durch die zugeordnete Dienstklasse steuerbar sein, die die Sicherheitstaktik darstellt. Das Berührungspunktkonzept, das in diesem Dokument für sowohl die Anwendungs- als auch die Firmwareelemente in der kryptographischen Einheit erörtert wird, spielt eine Schlüsselrolle beim Ausüben von Steuerung über die Funktionsfähigkeit dieser Module.
Eine weitere fundamentale Anforderung der ICF-Architektur ist, dass der Anwendung die Integrität der kryptographischen Einheit zugesichert wird, von der dieselbe Dienste empfängt. Somit liefert die Erfindung auch Verfahren, die eine Bestimmung erlauben, ob eine kryptographische Einheit ersetzt oder beschädigt wurde oder nicht.
Kurze Beschreibung der Zeichnungen
1 ist ein Blockdiagramm einer internationalen Kryptographiegrundstruktur, die eine nationale Flagkarte, eine kryptographische Einheit, ein Hostsystem und einen Netzwerksicherheitsserver umfasst;
2 ist ein schematisches Blockdiagramm, das zusätzliche Verwaltungselemente der ICF gemäß der Erfindung einführt;
3 ist eine schematische Blockdarstellung der ICF und der Zertifizierungsanforderungen gemäß der Erfindung;
4 ist ein Blockdiagramm, das die Beziehung der Verwaltungselemente der ICF, d. h. ADA und SDA, gemäß der Erfindung zeigt;
5 ist eine Darstellung der Dienstklassenstruktur gemäß der Erfindung;
6 ist ein schematisches Blockdiagramm, das das COS-Pegelkonzept gemäß der Erfindung darstellt;
7 ist ein schematisches Blockdiagramm, das Schlüsselelemente in dem Verwaltungsprozess gemäß der Erfindung darstellt;
8 ist eine Softwarearchitekturübersicht der ICF-Softwareumgebung gemäß der Erfindung;
9 stellt die Verfahren dar, die verfügbar sind, um Zertifikate zu dem Dienstanbieter zu leiten, der verantwortlich ist für das Ausführen der angeforderten Funktionen gemäß der Erfindung;
10 ist ein schematisches Blockdiagramm, das eine beispielhafte Architektur der CU gemäß der Erfindung darstellt;
11 ist ein schematisches Blockdiagramm der Firmware der kryptographischen Einheit gemäß der Erfindung;
12 ist ein schematisches Blockdiagramm, das das Konzept einer virtuellen CPU gemäß der Erfindung darstellt;
13 ist ein schematisches Blockdiagramm, das den Softwarekomponentenzertifizierungsprozess während der Installationsstufe gemäß der Erfindung darstellt;
14 ist ein schematisches Blockdiagramm, das den Softwarekomponentenzertifizierungsprozess während der Ausführungsstufe gemäß der Erfindung darstellt;
15 stellt Softwarepegelberührungspunkte gemäß der Erfindung dar;
16 stellt die Befehlspegelberührungspunkte gemäß der Erfindung dar;
17 ist ein schematisches Blockdiagramm, das die Herstellungsstufe gemäß der Erfindung darstellt;
18 ist ein schematisches Blockdiagramm, das die Installationsstufe gemäß der Erfindung darstellt;
19 ist ein schematisches Blockdiagramm der Ausführungsstufe gemäß der Erfindung;
20 stellt das Prinzip der Dienstklassen, Berührungspunkte und Umschläge gemäß der Erfindung dar;
21 stellt die Speicherhierarchie bezüglich der Softwareberührungspunktauflösung gemäß der Erfindung dar;
22 zeigt einen Hostsystemprozessor, der Befehle von dem Speichercodebild einer Anwendung abruft, die strukturierte Befehlspegelberührungspunkte aufweist, die gemäß der Erfindung installiert sind; und
23 ist ein schematisches Blockdiagramm, das Befehlspegelberührungspunktunterstützung in dem Hostsystemprozessor gemäß der Erfindung darstellt.
Detaillierte Beschreibung der Erfindung
Nationale Kryptographierichtlinien schwanken oft nach Industriesegment, politischem Klima und/oder Mitteilungsfunktion. Dies macht es schwierig, eine einheitliche Richtlinie bzw. Taktik für alle Industrien für alle Zeiten zuzuweisen. Folglich ist die Flexibilität einer kryptographischen Grundstruktur, die eine nationale Flagkarte, d. h. Richtlinie, umfasst, sehr attraktiv. Die Erfindung bezieht sich daher hauptsächlich auf das Lösen von Problemen im Zusammenhang mit internationaler Kryptographie. Die Erfindung ist jedoch an viele andere Anwendungen angepasst und für dieselben beabsichtigt.
Die Erfindung befindet sich vorzugsweise in dem Kontext einer internationalen Kryptographiegrundstruktur, die vier Dienstelemente aufweist, wobei jedes einen anderen Diensttyp anbietet. 1 ist ein Blockdiagramm der internationalen Kryptographiegrundstruktur (ICF; ICF = international cryptography framework) 10, die eine nationale Flagkarte (die hierin auch als eine „Taktikkarte" (PC; PC = policy card) und als eine „Taktik" bezeichnet wird) 12, eine kryptographische Einheit 14, ein Hostsystem 16 und einen Netzwerksicherheitsserver 18. Es sollte klar sein, dass verschiedene dieser ICF-Elemente in einer gemeinsamen Umgebung kombiniert werden können, z. B. können sich die kryptographische Einheit und die Taktikkarte in dem Hostsystem befinden. Beispielsweise können die kryptographische Einheit, die Taktikkarte und das Hostsystem eine einzelne integrierte Schaltung umfassen, z. B. in einem Drucker.
Hostsystem (HS). Das System oder die Einheit, die eine kryptographische Einheit (CU) enthält. Dieses Element der ICF unterstützt eine Anwendungsprogrammierschnittstelle zu einer CU. Es unterstützt auch Anwendungen, die sicherheitsbewusst sind und die die CU verwenden. Diese Anwendungen sind während der Laufzeit fest mit der CU verbunden.
Kryptographische Einheit (CU). Das System oder die Einheit, die die kryptographischen Funktionen enthält. Diese Funktionen sind ruhend und können durch das HS nicht verwendet werden, bis sie durch eine PC aktiviert werden. Die kryptographischen Funktionen, die in der CU enthalten sind, werden durch Geschäftsnachfrage bestimmt. Die CU ist gegen Eingriffe gesichert, um alles Verschlüsselungsmaterial, das darin gespeichert sein kann, zu schützen. Es ist die Verantwortung der CU, Kontakt mit einer PC beizubehalten. Wenn sie dies nicht tut, führt dies zum Verfall der Funktionalität der CU.
Taktikkarte (PC). Das System oder die Einheit, die Kryptographieverwendungstaktiken enthält. Insbesondere enthält dieses Element der ICF Parameter, die die Verwendung der Kryptographie in einer oder mehreren CUs regeln, die dieser PC bekannt sind. Ferner ist dieses Element verantwortlich für das Ansprechen auf die CU-Heartbeat-Parolen (Heartbeat-Challenge).
Taktikkarten können entweder in physikalischer oder virtueller Form implementiert werden. Eine physikalische Taktikkarte erfordert Hardwareunterstützung in der CU, die dann die PC in einer Heartbeat-Beziehung in Eingriff nimmt. Hardwareberührungspunkte, das Verfahren zum Deaktivieren der kryptographischen Hardwarefunktionen (siehe Klemba u. a., Cryptographic Unit Touch Point Logic, U.S.-Patentanmeldung Seriennummer 08/685,076, eingereicht 23. Juli 1996), müssen für eine physikalische Taktikkarte implementiert werden. Eine virtuelle Taktikkarte (VPC) arbeitet in Verbindung mit einer Hardware- oder einer Firmwareimplementierung der Berührungspunkttechniken. In dem VPC-Szenario umfasst die Taktikverteilung den Netzwerksicherheitsserver.
Netzwerksicherheitsserver (NSS). Das System oder die Einheit, die als vertrauenswürdige dritte Partei wirkt, um Netzwerksicherheitsdienste an HSs, CUs und PCs zu liefern. Diese Dienste können Taktikverbesserungen, Taktikverteilung, Einheitsverifizierung, Einstellungen an Autorisierungen und Schlüsselverwaltungsdienste umfassen.
ICF-Verwaltungsgrundstruktur. An der Peripherie der Kernelemente der ICF befinden sich die Hersteller der kryptographischen Ausrüstung und die Domainautoritäten, die die Taktikdefinition und Geltendmachung durch die Grundstruktur implementieren. 2 ist ein schematisches Blockdiagramm, das diese zusätzlichen Verwaltungselemente der ICF einführt.
Es gibt vier Grundelemente in der Verwaltungsgrundstruktur. Dies sind die Sicherheitsdomainautorität 20, die Anwendungsdomainautorität 22, die Hostsystemelemente 16 und der Netzwerksicherheitsserver 18.
Die folgenden Definitionen gelten bezüglich der Erörterung hierin:
Hersteller. Der Hersteller ist der tatsächliche Erzeuger der kryptographischen Ausrüstung. Der Hersteller teilt Informationen mit der Sicherheitsdomainautorität über jeden Satz von hergestellten CUs.
Sicherheitsdomainautorität. Die Sicherheitsdomainautorität (SDA) ist die Institution, die die Sicherheitstaktiken definiert, die die Domain regeln. Sicherheitstaktiken werden anderen Grundstrukturelementen über Dienstklassen (COS) präsentiert. Die Kenntnis der Herstellungsinformationen ermöglicht die Erzeugung von Dienstklassen, die sich auf einen deterministischen Satz von CUs beziehen.
Anwendungsdomainautorität. Die Anwendungsdomainautorität (ADA) wirkt als die Autorität, die Zertifikate für die Anwendung erzeugt. Das Zertifikat enthält die gewährten Dienstklassen für die Anwendung, wie sie durch die SDA gewährt wurden.
Netzwerksicherheitsserver. Der Netzwerksicherheitsserver (NSS) wirkt als vertrauenswürdige Onlineautorität, die Taktikaktivierung für eine bestimmte CU verwaltet.
Hostsystem/Anwendung/CU. Das Hostsystem, auf dem die Anwendungen installiert sind und auf dem die CU-Dienste verwendet werden, bilden die Ausführungselemente, die durch die Grundstruktur gesteuert werden sollen.
Die beiden Domainautoritäten sind auf der Oberseite von 2 gezeigt. Die Sicherheitsdomainautorität (SDA) ist verantwortlich zum Gewähren eines Satzes von Dienstklassen 26 an die Anwendungsdomainautorität. Die SDA ist auch verantwortlich für das Ausgeben von Taktikkarten, die die COS-Informationen und die Berührungspunktdaten für die CU enthalten. Die SDA stellt diese Informationen auf Anforderung von der Stelle her, die die CU in ein Hostsystem installiert.
Die Anwendungsdomainautorität (ADA) empfängt die COS-Elemente, die durch die SDA gewährt werden. Dieselbe hat die Verantwortung zum Ausgeben von Anwendungszertifikaten 28 an Anwendungen 29, die zu ihrer Domain gehören. Ein Anwendungszertifikat enthält eine Anwendungs-ID und die COS, die durch die ADA gewährt wird.
Anwendungen empfangen ein Zertifikat von der ADA, das der CU präsentiert werden muss, um den gewünschten COS-Pegel zu empfangen. Auf das Empfangen der Anforderungen hin verwendet die CU das Zertifikat zum Bestimmen, ob die Anwendung das Recht hat, auf die angeforderte kryptographische Funktion zuzugreifen. Falls die COS, die über das Anwendungszertifikat angefordert wurde, mit der COS übereinstimmt, die der ADA durch die SDA gewährt wurde und in der Taktikkarte gespeichert ist, wird die Anforderung gehandhabt, andernfalls wird dieselbe nicht gehandhabt.
Die Berührungspunktdaten sind die Informationen, die auf der Taktikkarte 12 gespeichert sind und die die kryptographische Hardware für die definierte Dienstklasse aktivieren. Diese Informationen werden regelmäßig durch die CU neu berechnet und durch die Taktikkarte validiert. Jede Fehlübereinstimmung bewirkt, dass die kryptographische Fähigkeit der CU verfällt.
Der Netzwerksicherheitsserver 18 (NSS) wirkt als Onlineinstrument für Taktikverhandlung und Änderungen an den Taktikinformationen, die auf der Taktikkarte gespeichert sind. Das Hinzufügen einer Dienstklasse zu dem Satz von Diensten erfordert normalerweise das Ausgeben einer neuen Taktikkarte, die die geänderten Informationen enthält. Alternativ führt der NSS die Aktualisierung der Taktikkarte für die SDA durch.
Der NSS spielt auch die Rolle der Verteilung von virtuellen Taktikkarten (VPC). VPC-Implementierungen müssen den NSS an definierten Punkten kontaktieren, z. B. Systemstart, um COS-Informationen wiederzugewinnen. Es gibt COS-Attribute, die genau definieren, wann eine CU den NSS kontaktieren muss.
Grundlegende ICF-Architekturannahmen. Die ICF-Architektur beruht auf einigen sehr grundlegenden Annahmen über die Kernelemente. Dieselben sind wie folgt:
Zertifizierung. Alle Softwareelemente, egal ob sie Firmwarekomponenten sind, die in die CU installiert sind, oder Anwendungen, die die Dienste verwenden, die durch die CU exportiert werden, werden durch ein Zertifikat geschützt. Jede Operation, z. B. das Herunterladen von Firmwaremodulen oder einer Anwendung für einen bestimmten Dienstpegel, umfasst die Validierung dieses Zertifikats.
Somit ist eine Technik, die durch die Erfindung zum Verbessern der Sicherheit in der Grundstruktur vorteilhaft ausgenutzt wird, das Erfordern der Zertifizierung an bestimmten Punkten. Die Verwendung von Zertifikaten im allgemeinen ist bekannt. Siehe beispielsweise die ITU-T-Empfehlung X.509 (1993).
Das X509(93)-Zertifikat-Format ist wie folgt:
Zwei Variationen der bestehenden X509(93)-Spezifikationen sind in Verbindung mit der Erfindung von Interesse:

• Die Bemühungen, die eindeutigen Identifizierer über Domains zu treiben, auf der Basis der hierarchischen Art der Autoritätsverbindung, beispielsweise in dem Prozess des Validierens eines Zertifikats oder einer Richtlinie wie mit Bezug auf Constructing X509(93) certificate UniqueIdentifiers from specific certification system semantics, Dept of Computer Architecture – Universitat of Politectnica de Catalunya Barcelonia (Okt. 94) (auch eine EWOS-Referenz EWOS/EGSEC/94/183); und Working Draft for extensions to X509/ISO/IEC 9594-8 certificate definitions (Juli 94) (auch eine EWOS-Referenz EWOS/EGSEC/94/168). Taktik-IDs sind registriert durch Gemeinschaftsinteressengruppen, wie z. B. NSA und SCSSI; oder durch private Organisationen, wie z. B. die Software Publisher's Association (Vereinigung der Softwareveröffentlicher) oder die Microsoft Corporation aus Redmond, Washington.
• Die paaridentifizierten Taktiken und Autoritätsbeschränkungen, wie sie erwähnt werden in Working Draft for extensions to X509/ISO/IEC 9594-8 certificate definitions (Juli 94) (auch eine EWOS-Referenz EWOS/EGSEC/94/168) sind gut geeignet für Kreuzzertifizierung kompatibler Taktiken zwischen Regierungen. Beispielsweise können die lokalen Domainrichtlinien, die die hierin beschriebene Dienstklasse ausdrücklich unterstützt, sobald sie in dem Erweiterungsfeld erwähnt wird, auch mit anderen Taktiken verwendbar sein oder nicht und daher die Erkennung von kompatiblen Taktiken ermöglichen. Eine Anwendung dieses Aspekts eines Zertifikats ist die Internetrichtlinienzertifi zierungsautorität, die unter Verwendung dieses Schemas eine private Organisationsrichtlinie kreuzzertifizieren könnte.

Erweiterungen für die Taktiken- oder Zertifizierungssystemsemantik finden sich in dem Uniqueld-Feld, das vorgeschlagen wird von Constructing X509(93) certificate UniqueIdentifiers from specific certification system semantics, Dept of Computer Architecture – Universitat of Politectnica de Catalunya Barcelonia (Okt. 94) (auch eine EWOS-Referenz EWOS/EGSEC/94/183). Die Zertifikatserweiterungsfelder, die als Taktikfeld oder Autoritätsbeschränkungsfeld bezeichnet werden, wie sie definiert sind in Working Draft for extensions to X509/ISO/IEC 9594-8 certificate definitions (Juli 94) (auch eine EWOS-Referenz EWOS/EGSEC/94/168) würden die zweite Anforderung erfüllen.
Liefern kryptographischer Funktionen. Ein System, das das physikalische Taktikkartenschema implementiert, erfordert, dass die CU Hardwareberührungspunkte implementiert. Die CU liefert dem HS keine kryptographischen Funktionen, ohne in Kontakt mit einer PC zu treten und denselben beizubehalten. Ein System, das das virtuelle PC-Schema implementiert, erfordert das Vorliegen eines NSS. Es muss zumindest einen anfänglichen Kontakt zwischen dem NSS und der CU geben, um die VPC zu verteilen. Es kann auch erforderlich sein, dass die CU den NSS auf regelmäßiger Basis kontaktiert, die durch COS-Attribute bestimmt werden, die den Taktiklebensdauerzyklus beschreiben.
Trennung. Unter keinen Umständen können Taktikelemente auf Benutzerdaten, die in der CU verarbeitet werden, zugreifen, unabhängig davon, ob die Taktikkarte eine physikalische oder die virtuelle Taktikkarte ist. Gleichartig dazu sollte das Hostsystem unter keinen Umständen Zugriff auf die Daten haben, die sich auf Taktikelemente beziehen, wie z. B. Berührungspunktdateninformationen.
Steuerung. Die CU oder die CUs, die durch eine bestimmte PC oder VPC gesteuert werden, ist deterministisch, d. h. jedes Ereignis, jeder Vorgang und jede Entscheidung der CU ist die unvermeintliche Konsequenz von vorhergehenden Ereignissen, die unabhängig von der PC sind.
ICF-Grundvertrauensanforderungen. 3 ist eine schematische Blockdarstellung der ICF- und Zertifizierungsanforderungen. Die ICF-Umgebung hängt von einem Verfahren zum Validieren ab, dass eine Anwendung 29 einen bestimmten Kryptographiepegel rechtmäßig ausführt, wie er durch die Anwendungsdomainautorität in der Form eines Zertifikats gewährt wurde, das die gültige Dienstklasse enthält. Eine enge Bindung der Anwendung an dieses Zertifikat ist daher ein wichtiges Element der ICF. Der Prozess des Herstellens dieses Vertrauens wird in diesem Dokument als Anwendungszertifizierung bezeichnet.
Anwendungszertifizierung beschreibt zwei Hauptelemente des Herstellens von Vertrauen zwischen der Anwendung 29 und der kryptographischen Einheit 14.
Der erste Teil bezieht sich auf den Prozess des Analysierens eines Datenstücks zum Bestimmen, dass dasselbe nicht manipuliert wurde. Im allgemeinen sind zwei Hauptobjektklassen von Interesse. Die erste Klasse bezieht sich auf das Subjekt der Programmbildzertifizierung. Die zweite Klasse verallgemeinert den Prozess und legt das Konzept an eine Vielzahl von Datenobjekten an. Die Charakteristika der CU, nämlich eine gegen Eingriffe gesicherte funktionale Einheit, ermöglichen den Aufbau allgemeiner Zertifizierungsverfahren von beliebigen Datenobjekten.
Aus einer Anwendungsperspektive muss der Anwendung die Identität der CU sichergestellt werden. Der Prozess des Herstellens dieser Art von Vertrauen wird in diesem Dokument als CU-Validierung bezeichnet. CU-Validierung bezieht sich auf den Prozess des Vergewisserns der Anwendung, dass die CU nicht manipuliert wurde, d. h. nicht durch eine verfälschte CU ersetzt wurde. Nach dem Prozess der CU-Validierung kann die Anwendung annehmen, dass die korrekte CU die angeforderten kryptographischen Dienste durchführt.
Zertifizierung von Codebildern. Für kritische Anwendungen gibt es seit langem einen Bedarf zu Validieren, dass eine Anwendung nicht manipuliert wurde. Das Durchführen dieser Validierung umfasst normalerweise ein vertrauenswürdiges Ladeteilsystem. Ein vertrauenswürdiges Ladeteilsystem ist der Teil des Betriebssystems, der für das Laden eines Programmbilds in den Systemspeicherplatz verantwortlich ist, und während es dies tut, zu Validieren, dass die Anwendung nicht manipuliert wurde. Mechanismen, wie z. B. eine Prüfsumme über das Programmbild, werden für diesen Zweck häufig verwendet. Falls bei solchen Anwendungen die Prüfsumme nicht mit der Prüfsumme übereinstimmt, die durch das Ladeteilsystem zum Anwendungsinstallationszeitpunkt gespeichert wird, versagt das Laden und das Programmbild wird nicht geladen.
Ein vertrauenswürdiges Ladeteilsystem kann nicht unabhängig von einer Beziehung zu dem Betriebssystem existieren. Das Vertrauen des Laders, zu validieren, dass die Anwendung nicht manipuliert wurde, impliziert, dass das Betriebssystem dem Lader vertraut. Ein vertrauenswürdiger Betriebskern, der zum Systembootzeitpunkt validiert wird, normalerweise durch ein Hardwarestück, bildet den Kern der Vertrauenshierarchie, auf der die Anwendung läuft.
Eine CU umfasst auch Firmwareelemente 27 (siehe 2), die die CU-Laufzeit, kryptographische Dienstmodule und potentielle Benutzerpegeldienstmodule implementieren, die Sicherheitsprotokolle oder andere Benutzerpegelfunktionen implementieren. Die Anforderungen, die für die Anwendungszertifizierung gelten, gelten auch für die Firmware. Somit werden Firmwaremodule, die in die CU geladen werden, von einem Firmwarezertifikat 25 begleitet (2).
Zertifizierung allgemeiner Objekte. Das Validieren eines Codebilds zum Bestimmen der ordnungsgemäßen Verwendung eines Zertifikats kann verallgemeinert werden auf das Validieren jedes Objekts, das durch ein Zertifikat geregelt wird. Beispielsweise könnte ein Internet-Applet, wie sie für World-Wide-Web-Anwendungen durch die Java-Programmiersprache geliefert werden, auch das hierin beschriebene Schema ausnutzen. Jedes Objekt, das verwendet oder zugegriffen werden soll, könnte von einem Zertifikat begleitet werden. Der Validierungsschritt ist sehr ähnlich zu den Schritten, die durch ein vertrauenswürdiges Ladeteilsystem für Codebilder durchgeführt werden.
CU-Validierung. CU-Validierung beschreibt den Prozess des Sicherstellens, dass die Anwendung, die kryptographische Dienste anfordert, über die Identität der CU versichert wird. Es gibt mehrere Verfahren, die diese Aufgabe erreichen können, z. B.:

• Herausfordern der CU. Bei diesen Verfahren gibt die Anwendung ein Rätsel an die CU aus, das nur die CU lösen kann. Die Tatsache, dass die CU das Rätsel lösen konnte, ist Beweis der Identität der CU.
• Die CU bereitet die Anwendung zum Funktionieren vor. Bei diesem Lösungsansatz wird die Anwendung in verwürfelter Form an das Zielsystem geliefert. Beispielsweise könnte das binäre Bild verschlüsselt sein. Nur die CU, die den korrekten Entschlüsselungsschlüssel hat, kann die Anwendung entwürfeln, und somit ist dieselbe eine gültige CU.

Das zweite Verfahren hat zusätzliche Anwendbarkeit für Softwareurheberrechtsschemata. Das Senden der Anwendung in verschlüsselter Form an die Zielseite und das Verschlüsseln des Programms durch die CU offenbart nicht nur, dass die CU eine gültige CU ist, sondern ermöglicht es auch dem Soft warehersteller, eine Anwendung auszusenden, die auf diese bestimmte CU, d. h. dieses bestimmte Hostsystem, zugeschnitten ist. Sobald das Anwendungsbild verschlüsselt ist, ist es jedoch in Klartext verfügbar und kann mit wenig oder keinem Aufwand zu anderen Systemen kopiert werden.
Die ICF-Gründung ermöglicht ein Verfahren, das als Softwarepegelberührungspunkte bezeichnet wird und das sowohl die CU-Validierungsaspekte der Erfindung als auch die Urheberrechtsschutzschemata adressiert. Das Konzept von Softwarepegelberührungspunkten wird nachfolgend näher erläutert.
ICF-Verwaltungskonzepte. Das ICF-Modell implementiert ein Taktikschema, in dem die Anwendung eine Dienstklasse anfordert, die schließlich den Kryptographiepegel definiert, der in der Anwendung erlaubt ist. Es folgt eine Erörterung der Konzepte der Taktik und Dienstklasse und wie die Verwaltungselemente SDA, ADA und NSS bei der Definition und Verteilung von Taktiken zusammenspielen.
Taktiken und Dienstklasse. 4 ist ein Blockdiagramm, das die Beziehung der Verwaltungselemente der ICF, d. h. ADA und SDA, darstellt. Die ICF ist eine richtliniengetriebene Implementierung von Kryptographie. Eine Richtlinie ist die formale Definition des Dienstpegels, der in Form von Dienstklassen gewährt wird. Beispielsweise kann ansprechend auf eine Geschäftsanforderung, einen starken Kryptographiepegel für eine Email-Anwendung zu haben, eine Sicherheitsdomainautorität die Dienstklasse „DES 128 bit" erzeugen. ADAs, die diesen starken Kryptographiepegel anfragen, bekommen die COS, die definiert ist, um diese Richtlinie zu implementieren.
Die Sicherheitsdomainautorität, die in der ICF-Verwaltungsgrundstruktur definiert ist, ist das Element, das Dienstklassen von Taktiken erzeugt, die definiert sind, um die Sicherheitsinteressen und Anforderungen der Autori täten zu erfüllen. Eine COS hat eine eindeutige Identifizierung, d. h. eine Seriennummer, die durch diese Autorität nicht wiederverwendet werden darf und die bei einer Funktion der Kreuzzertifizierung semantisch von andern SDAs verstanden werden muss.
Eine COS 26, die an die ADA 22 geliefert wird, ermöglicht es der ADA, Anwendungszertifikate für eine Anwendung auszustellen, die die COS enthält. Dies bildet einen Weg der Zugriffssteuerung. Eine Anwendung muss ein Zertifikat haben zum Zugreifen auf das Verfahren, das durch die COS identifiziert ist, z. B. eine kryptographische Operation bei einer bestimmten Stärke.
Der andere Weg der Steuerung in der ICF-Architektur ist der Weg der Existenz. Die definierte COS muss an die CU weitergeleitet werden, um diesen Dienst bei einer Ziel-CU zu aktivieren. Selbst wenn der Zugriffsweg einen gültigen Zugriff anzeigt, müssen die Verfahren, die durch die COS gekennzeichnet sind, in einem aktuellen Zustand sein, damit die Anforderung ausgeführt wird. Falls beispielsweise die COS auf der physikalischen Taktikkarte gespeichert ist und diese Taktikkarte von der CU entfernt wird, bestehen die zugeordneten Verfahren nicht mehr, d. h. dieselben arbeiten nicht.
Die Steuerung des Zugriffs und die Steuerung der Existenz eines Verfahrens sind fundamental für die ICF-Architektur und beide sollten bei jeder Implementierung immer vorliegen. Die Entfernung der COS von dem Existenzweg führt zu einem nicht funktionierenden Verfahren, unabhängig von dem Zugriffswegbewertungsergebnis.
Taktikaktivierung. Taktikaktivierung beschreibt die Reihenfolge von Ereignissen, die für eine CU stattfinden müssen, um Dienste anzubieten, wie es durch die Dienstklassen definiert ist. Bevor eine Anwendung über das Anwendungszertifikat nach einer COS fragen kann, muss die CU für diese bestimmte COS aktiviert sein. Die ICF ist einmalig in dem Konzept der Taktikgesteuerten Aktivierung von Kryptographie.
Abhängig von der Implementierung muss die kryptographische Einheit in Verbindung mit einer Taktikkarte sein, damit die COS von der Taktikkarte heruntergeladen wird. Das VPC-Szenario erfordert eine Netzwerkverbindung zu dem NSS zum Herunterladen der COS zu der CU. Obwohl diese Lösungen technisch mehr oder wenig gleich sind, haben dieselben eine starke Implikation für das Vertrauensmodell der gesamten Grundstruktur. Eine Lösung auf der Basis einer physikalischen Taktikkarte erfordert, dass die CU Berührungspunkte in Hardware implementiert. Der Hauptgrund dafür ist die Abtrennung der Steuerung in dem Fall der physikalischen Taktikkarten. Eine physikalische Taktikkarte ist nicht notwendigerweise mit der Domainautoritätsumgebung verbunden und weniger Steuerung über die Taktiken ist möglich, sobald dieselbe ausgegeben wurde. Um dies auszugleichen, werden Hardwareberührungspunkte in deterministische Positionen in der Hardware platziert, so dass eine Taktikkarte, die die Berührungsdaten enthält, geladen werden kann, aber nicht von der Implementierung entfernt werden kann ohne einen Verfall der gesteuerten Anwendung.
Eine Firmwareimplementierung des Berührungspunktkonzepts arbeitet auf eine sehr viel dynamischere Weise bezüglich der Position und Installation dieser Berührungspunkte, weil die tatsächliche Firmware, die geladen werden soll, nicht a priori bekannt ist und somit mehr Raum für den Angreifer liefert. Um dies auszugleichen, liegt ein Onlineelement in der Form des NSS vor, das eine dynamischere Steuerung der firmwarebasierten Berührungspunktimplementierung ermöglicht.
Dienstklassen. 5 ist eine Darstellung der Dienstklassenstruktur. Eine Dienstklasse (COS) beschreibt Taktiken.
Wie es oben erörtert wurde, wird eine Taktik in eine oder mehrere COS-Strukturen übersetzt.
Dienstklassen sind eine Struktur, die durch die ausgebende SDA 20 unterzeichnet wird. Eine COS enthält auch die Berührungspunktdaten, die notwendig sind, um die Berührungspunktmechanismen in der CU zu steuern.

• Das Verfahrensfeld 51 beschreibt das tatsächliche Verfahren, für das die Dienstklasse steht. Beispiele sind kryptographische Algorithmusidentifizierer, aber auch jedes andere definierte Verfahren, wie z. B. Prozeduren für die Installation von Komponenten oder Ausführungsrechte für eine Operation, die der COS zugeordnet ist.
• Das Beschränkungsfeld 52 beschreibt Attribute des Verfahrens. Beispiele sind die Attribute, die die Verwendung dieser Dienstklasse regeln, z. B. die Stärke des Verschlüsselungsmaterials, das für den Algorithmus verwendet wird, die Zeitdauer, die diese COS gültig ist, oder die Anzahl von Malen, die dieselbe verwendet werden kann. Das Berührungspunktdatenfeld beschreibt die Berührungspunktinformationen, die von der CU benötigt werden, um für diese COS aktiviert zu werden.

Dienstklassen können verschachtelt sein, d. h. eine COS kann als Verfahrensteil andere Dienstklassen enthalten. Einige Dienstklassen, insbesondere die nichtkryptographischen Dienstklassen, können eventuell keine Berührungspunktdaten enthalten.
Allen COS-Strukturen gemeinsam ist auch das Konzept einer Verfallstaktik. Eine COS kann für eine unbegrenzte Lebensdauer für gültig erklärt werden, oder dieselbe kann in der Lebensdauer begrenzt sein. Beispiele einer begrenzten Lebensdauer sind eine Verbindung der COS-Lebensdauer mit der Lebensdauer des Betriebssystems, des Anwendungsfalls oder des Kontextes, der in der CU hergestellt ist. Der Neubeginn des Betriebssystems oder der Anwendung oder das Schließen des CU-Kontextes würden die COS als abgelaufen und ungültig markieren. Eine Interaktion mit dem NSS zum Aktivieren der COS wäre dann notwendig.
Andere Ereignisse, die die Lebensdauer einer COS begrenzen, sind Zähler, z. B. die Anzahl von Operationen, die von dieser COS erlaubt sind, oder sogar eine einzelne Operation, die durch diese COS geregelt wird. Die letztere ist ein sehr starkes Werkzeug zum Erzeugen von Dienstklassen für genau eine Interaktion, wie es z. B. für finanzielle Transaktionen sinnvoll wäre.
Ein Teil der CU implementiert die Verfallsfunktionalität, in der Dienstklassen gemäß ihrer Verfallsrichtlinie verarbeitet werden. Wenn die Taktik bestimmt, dass es notwendig ist, die COS zu deaktivieren, hört jede zugeordnete Funktionalität auf, zu existieren. Die ICF-CU ist einmalig darin, dass dieselbe kryptographische Dienste anbietet, die durch eine Dienstklasse mit Beschränkungen, die ablaufen, getrieben werden.
Eine spezielle vordefinierte Dienstklasse, COS0, wird verwendet, um die COS-Verfallsfunktionalität zu schützen. Weil die COS0 selbst einer Verfallsrichtlinie unterworfen ist, kann bewirkt werden, dass die COS-Verarbeitung aufhört zu existieren, womit die gesamte CU für jede Art von Dienst beschrieben wird. In diesem Fall wäre eine Neuaktivierung von dem NSS erforderlich.
Dienstklassenpegel. Dienstklassen sind nicht nur durch das Objekt organisiert, das dieselben beschreiben, sondern auch durch den Validierungspegel, den eine Implementierung durchführt, bevor der Dienstpegel gewährt wird, der durch die COS beschrieben wird. Das bevorzugte Ausführungsbeispiel der ICF definiert sechs Gültigkeitspegel für eine COS. Während sich die Pegel erhöhen, wird eine engere Validierung (und daher Steuerung) über den Dienst, der gewährt werden soll, erreicht.
6 ist ein schematisches Blockdiagramm, das das COS-Pegelkonzept darstellt. Die ICF implementiert mehrere COS-Validierungspegel. Diese COS-Validierungspegel sind nur Beispiele. Es ist klar, dass andere Validierungspegel und Kombinationen derselben beim Anwenden der Erfindung hierin vorgesehen sein können. Dieselben sind mit COS-Pegel 0 bis 5 bezeichnet. Während sich der Pegel erhöht, erhöht sich die Menge an Validierung. 6 umfasst einen Kreis 61 im Gegenuhrzeigersinn, der die Elemente zeigt, die in der Validierung enthalten sind. Bei dem niedrigsten zertifizierten Pegel wird nur der SDA-Ursprung der COS validiert; während bei dem höchsten zertifizierten Pegel eine Onlineverbindung und Autorisierung des NSS für jede Operation erforderlich ist.

• COS-Pegel 0. Der COS-Pegel 0 ist Anwendungen zugewiesen, denen kein Zertifikat zugewiesen ist. Trotzdem ist an diesem Pegel ein minimaler Schutzpegel vorgesehen, weil die COS durch die SDA unterzeichnet ist, die die COS ausgegeben hat. Dieser Pegel ist hauptsächlich für Anwendungen beabsichtigt, die nicht geändert werden können, um ein Zertifikat zu der CU weiterzuleiten.
• COS-Pegel 1. Der COS-Pegel 1 validiert die COS-ID, während dieselbe durch das Anwendungszertifikat verfügbar gemacht wird, das durch die SDA unterzeichnet wird.
• COS-Pegel 2. Der COS-Pegel 2 fügt dem COS-Pegel 1 die Validierung des Anwendungszertifikats hinzu. Es ist erforderlich, dass das Zertifikat durch die ADA ausgegeben wird, die die SDA nach der COS gefragt hat, die durch die COS-ID identifiziert ist.
• COS-Pegel 3. Der COS-Pegel 3 fügt dem COS-Pegel 2 die Validierung der Anwendungs-ID hinzu, die durch die ADA ausgegeben wurde.
• COS-Pegel 4. Der COS-Pegel 4 fügt dem COS-Pegel 3 die Interaktion mit dem NSS hinzu, um die COS zu validieren, die durch die Anwendung angefordert wird.
• COS-Pegel 5. Der COS-Pegel 5 verstärkt den COS-Pegel 4 weiter durch Interagieren mit dem NSS bei jeder kryptographischen Operation, die durch die Anwendung angefordert wird.
• COS-Pegel 6. Der COS-Pegel 6 fügt die Anforderung eines Token hinzu, wie z. B. einer Smartcard, für jede oder mehrere der Interagieraktionen, die für die COS-Pegel 1 bis 5 oben aufgeführt wurden.

Informationsfluss. 7 ist ein schematisches Blockdiagramm, das Schlüsselelemente in dem Verwaltungsprozess darstellt. Solche Elemente umfassen das Anwendungszertifikat 28, die Dienstklasse 24, 26 und die Domainautoritäten, die dieselben verwalten. 7 umfasst sowohl eine Ansicht dieser Elemente hoher Ebene als auch ihren Fluss (wie es durch die Linien und Pfeile in der Figur gezeigt ist).
ICF-Softwareumgebung. 8 ist eine Softwarearchitekturübersicht der ICF-Softwareumgebung. Die ICF-Softwarearchitektur beschreibt die Schichten von Bibliotheken und Systemelementen, die benötigt werden, um die ICF-Elemente auf einem bestimmten Hostsystem zu implementieren. Die folgende Erörterung liefert eine Übersicht über die Hauptsoftwarearchitekturelemente:

• Anwendungen. Die Anwendungsschicht 81 ist der Bereich von benutzergeschriebenen Anwendungen und Bibliotheken, die kryptographische Dienste benötigen. Eine Anwendung kann sich dieser Dienste bewusst sein oder nicht. In dem Fall, in dem die Anwendung bewusst ist, bietet die nachfolgende Teilsystemschicht 82 einen Satz von Programmierschnittstellen für die Anwendung. Kryptographisch unbewusste Anwendungen geben selbst keine Anrufe aus, das darunter liegende Teilsystem führt diese Aufrufe für die Anwendung aus.
• Teilsystembibliotheken und Schnittstellen. Dies sind Teilsysteme, die kryptographische Funktionen für bewusste und unbewusste Anwendungen unterstützen. Diese Teilsysteme liefern auch APIs an die Anwendungen. Die meisten erwähnenswerten APIs umfassen die Microsoft CAPI für die Microsoft-Welt und die X/Open-GSS-API und GCS-API für die Unix-Welt. Teilsystembibliotheken organisieren sich typischerweise selbst in Anwendungsprogrammierschnittstellen und, abgeschirmt durch das Betriebssystem, ein kryptographisches Dienstanbietermodul. Die Teilsystembibliotheken können die Sicherheits-APIs auch vollständig vor der Anwendung verstecken. Dies ermöglicht es bestehenden Anwendungen, die Lösung zu nutzen, ohne modifiziert zu werden. Ein Beispiel ist die Integration der Sicherheitsmerkmale in Transportpegelsoftwareteilsysteme. Andere Elemente dieser Schicht können APIs liefern, zum Zugreifen auf die CU-sichere Speicherungs- und Ausführungseinrichtungen. Beispielsweise könnte eine Datenbank-API, wie z. B. die ODBC-Schnittstelle, zusammen mit einem Datenverwaltermodul in der CU angeboten werden, um eine gegen Eingriffe gesicherte Datenbank zu liefern.
• Betriebssysteme und Treiber. Das Betriebssystem 83 führt zwei Hauptaufgaben durch. Eine ist das Isolieren der Teilsystemprogrammierschnittstellen von den Kryptographiedienstanbietern. Die andere Aufgabe ist das Liefern der notwendigen Hardwaresteuerung durch einen Satz von Treibern 84, die mit der kryptographischen Hardware in Form von Hardwaretreibern eine Schnittstelle bilden.
• Kryptographische-Einheit-Teilsystem. Diese Schicht enthält die Hardwareimplementierungs- und Firmwareelemente der kryptographischen Funktionen 85. Die Hardware ist typischerweise in mehreren Formfaktoren vorgesehen, wie z. B. einer PCI-Karte oder einer PCMCIA-Karte, zum Unterbringen der unterschiedlichen Hardwareplattformen und Leistungsfähigkeitsanforderungen. Die Firmware ist ein Satz von Bibliotheken, die eine Mikrobetriebskernlaufzeit, die ICF-Funktionalität und auch benutzerherunterladbare Softwaremodule implementieren, die für eine bestimmte Anwendungsprogrammierschnittstelle erforderlich sind.
• Verwaltung. Das Verwaltungselement 86 ist verantwortlich für das Liefern einer Verwaltungsgrundstruktur der gesamten Lösung. Dies umfasst beispielsweise Middleware-Komponenten für Verwaltungsfunktionen, wie z. B. Zertifikatsverwaltung, Anwendungsdienstklassenverwaltung und Herunterladen von anwendungsspezifischen Erweiterungen der CU.

Die Schlüsselelemente sind in zwei Gruppen unterteilt:
Hostsystemsoftware und Kryptographische-Einheit-Firmware. Zwischen den beiden Hauptblöcken ist die Definition eines Befehlssatzes, der verwendet wird, um Anforderungen von dem Hostsystem zu der kryptographischen Einheit zu kommunizieren und umgekehrt. Jedes der Hauptelemente ist nachfolgend näher beschrieben.
Hostsystemsoftware. Die Hostsystemsoftware besteht aus Anwendungspegelprogrammierschnittstellen, Systempegeltreibern und Hilfsprogrammen, die beim Konfigurieren und Verwalten des Teilsystems helfen. Dieser Abschnitt kann unter schiedlich aussehen, abhängig von der ausgewählten Zielplattform und den Schnittstellen.
Teilsystembibliotheken. Eine Anwendung verwendet die kryptographische Einheit durch eine oder viele APIs. APIs können bereits existieren, neue werden als „Standards" vorgeschlagen, noch andere müssen entwickelt werden, um die vollen Fähigkeiten der kryptographischen Einheit zu nutzen. Ein Beispiel wäre die Fähigkeit, Code dynamisch in eine vertrauenswürdige Umgebung herunterzuladen und auszuführen.
Die kryptographische Einheit arbeitet in Verbindung mit einem großen Bereich von Programmierschnittstellen. APIs können auch vor der Anwendung versteckt werden, in Form der Teilsystembibliotheken oder Middleware-Schichten, die die kryptographischen Operationen maskieren.
Hosttreiber. Das Hostsystem muss die kryptographische Einheit in die Betriebsumgebung integrieren. Von einer Softwareperspektive aus umfasst dies die Gerätetreiber und jede Konfigurationssoftware, die benötigt wird, um die Taktikkarte zu installieren, zu konfigurieren und zu verwalten.
Verwaltungshilfsprogramme. Hilfsprogrammsoftware ist verantwortlich für die Installation, Verwaltung und Konfiguration des Kryptographische-Einheit-Teilsystems. Dieselbe ist auch notwendig, um Hilfsprogramme zum Entwickeln von Dienstmodulen und Hilfsprogramme zum Herunterladen dieser Module in die kryptographische Einheit bereitzustellen.
Kryptographische-Einheit-Befehlssatz. Die Hostsystemsoftware kommuniziert durch einen Satz von Anforderungen mit der kryptographischen Einheit. Beispiele für Anforderungen sind das Herunterladen einer Dienstbibliothek oder die Verschlüsselung eines Datenpuffers. Zum Unterstützen mehrerer Plattformen mit der gleichen kryptographischen Einheit sollte der Befehlssatz gleich sein und für alle Zielplatt formen das gleiche Format haben. Der Hauptvorteil ist eine einzige Implementierung der Kryptographische-Einheit-Softwareschichten.
Der Befehlssatz selbst kann in Hauptkategorien unterteilt werden. Die erste Kategorie bietet Befehle, die auf die verfügbare Funktionalität der kryptographischen Einheit abbilden, wie z. B. die Ausführung eines Hash-Algorithmus. Die zweite Kategorie bezieht sich auf Befehle zwischen der Hostsoftware und der Dienstschichtsoftware in der Einheit. Der Inhalt dieser Befehle ist für die Firmware überwiegend unbekannt und dieselben werden zu der entsprechenden Dienstschicht geleitet.
ICF-Anwendungsprogrammierschnittstellen. Die ICF führt das Konzept der taktikgetriebenen Kryptographie ein. Anwendungsprogrammierschnittstellen ermöglichen es, die gewünschten Dienste auf der Basis des Anwendungszertifikats auszuwählen, das durch die ADA gewährt wird. Dies steht im Gegensatz zu den derzeit verfügbaren kryptographischen Programmierschnittstellen. Die meisten der aktuellen kryptographischen APIs sind um das Konzept eines kryptographischen Kontexts gebaut. Anwendungen stellen diesen Kontext her, bevor dieselben irgendeinen kryptographischen Dienst verwenden können. Keine Verbindung wird hergestellt zwischen der Anwendung und der Dienstklasse, die durch die CU angeboten wird. Beispielsweise bietet die Microsoft Crypto-API eine Programmierschnittstelle, die es dem Benutzer ermöglicht, den Typ des kryptographischen Dienstanbieters (CSP) auszuwählen und das Softwaremodul in das System zu laden. Danach kann eine Anwendung Aufrufe an den CSP durchführen und seine Dienste verwenden. Es gibt jedoch keine Verfahren zum Unterscheiden kryptographischer Funktionen auf der Basis dessen, was die Anwendung tut.
9 stellt die Verfahren dar, die verfügbar sind, um Zertifikate 90 zu dem Dienstanbieter 91 weiterzuleiten, der verantwortlich ist für das Ausführen der angeforderten Funktionen. Es gibt mehrere Verfahren zum Verfügbarmachen des Zertifikats für die kryptographische Einheit, z. B.:

• Zertifikat bei jedem Aufruf weitergeleitet. Das Zertifikat kann bei jedem Aufruf zu dem CSP weitergeleitet werden. Dieses Schema ermöglicht eine Anwendung, die mehr als ein Zertifikat oder die Aufgabe, die zu erfüllen ist, weiterleiten kann. Falls es beispielsweise einer Anwendung erlaubt ist, eine starke Verschlüsselung für Finanztransaktionen zu verwenden und gleichzeitig eine weniger starke Verschlüsselung für Email-Funktionalität, kann diese Anwendung den Kryptographiepegel durch Weiterleiten des entsprechenden Zertifikats dynamisch auswählen.
• Zertifikat zum Initialisationszeitpunkt weitergeleitet. Das Zertifikat kann auch weitergeleitet werden, wenn die Verbindung zu dem CSP hergestellt wird. Eine Anwendung, die mehrere Zertifikate verwendet, könnte mehrere Kontexte einrichten, einen für jedes Zertifikat, und den geeigneten in den kryptographischen Funktionsaufrufen verwenden.
• Zertifikat implizit verfügbar. Das Zertifikat ist transparent für die Anwendung und für die kryptographischen Schichten verfügbar. Beispielsweise leitet die Anwendung ihren Namen weiter, der verwendet wird, um in ein Register zu indexieren, das die Zertifikate für diese Anwendung enthält.

Alle diese Verfahren beruhen auf der Annahme, dass es eine enge Verbindung zwischen der Anwendung und dem Zertifikat gibt. Dieses Konzept wird in diesem Dokument als Anwendungszertifizierung bezeichnet. Wie es nachfolgend erörtert wird, spielt die CU eine wesentliche Rolle beim Herstellen dieser engen Verbindung.
ICF-Kryptographische-Einheit. Im Kern der ICF-Grundstruktur ist die CU. Eine Implementierung der CU liefert einen Satz von Diensten an das Hostsystem. Diese Dienste umfassen kryptographische Funktionen, aber auch andere Funktionen, wie z. B. das Speichern empfindlicher Informationen, die die eingriffssicheren Charakteristika der CU ausnutzen. Die folgenden drei breiten Dienstkategorien werden durch die CU angeboten:

• Kryptographische Funktionen. Der Hauptzweck der CU ist das Liefern kryptographischer Funktionen. Die Einheit umfasst Hardware und Software zum Ausführen der definierten kryptographischen Algorithmen. Dieselbe umfasst auch Hardware und Software, die eine bestimmte kryptographische Taktik geltend machen.
• Sichere Speicherung. Die sichere Speicherung ermöglicht es der CU, Informationen auf sichere Weise in der CU zu speichern. Diese Einrichtung wird hauptsächlich für die Speicherung von Schlüsselmaterial in der CU verwendet. Im Verlauf der Zeit können Anwendungs- und Teilsystemschichten diese Einrichtung ebenfalls nutzen, durch Speichern von anderem nichtsicherheitsverwandten Material in der CU.
• Sichere Ausführung. Die CU ermöglicht die Ausführung von Code in der sicheren und gegen Eingriffe gesicherten Umgebung dieser Einheit. Anwendungen und Teilsystemschichten können diese Einrichtung nutzen, um einen Teil ihrer Funktionalität, wie z. B. Sicherheitsprotokollhandhabungseinrichtungen, in dieser sicheren Umgebung zu implementieren.

ICF-Kryptographieeinheit-Hardware. 10 ist ein schematisches Blockdiagramm, das eine beispielhafte Architektur der CU darstellt. 10 bezieht sich nicht auf eine bestimmte physikalische Implementierung, sondern zeigt statt dessen die Hauptelemente, die in der CU benötigt werden, um die drei breiten Kategorien der Funktionalität zu implementieren, die oben angedeutet sind. Es gibt mehrere Komponenten, die die CU bilden:

• Zentrale Verarbeitungseinheit. Die CPU 101 ist das Herz der Einheit, die allen Informationsfluss steuert. Module, die für eine sichere Ausführung heruntergeladen werden, werden durch die CPU ausgeführt.
• Speicherelemente. Die CU 14 benötigt mehrere Speicherelemente. Der Flash-Speicher 102 ist der Speicherplatz für Programme und nichtflüchtige Daten, die in der CU gespeichert sind. Der ROM-Speicher 103 nimmt den Urladungscode auf, der auf die Rücksetzung der CU hin ausführt. Der RAM-Speicher 104 hält die flüchtigen Daten der CU.
• Kryptographische ASIC 105 und Zufallszahlengenerator 106. Diese beiden Elemente führen die Grundoperationen für die kryptographischen Funktionen durch, die durch die CU angeboten werden. Für Implementierungen, die Berührungspunkte in Hardware liefern, findet sich in diesen Elementen eine ICF-Berührungspunktlogik zum Aktivieren dieser Funktionen bei dem Vorliegen einer Taktikkarte.
• Buslogik. Die Buslogik 107 verbindet die Einheit schnittstellenmäßig mit verschiedenen anderen Schnittstellen zu dem Hostsystem. Zwei Kanäle treten zu dem Hostsystem 108 aus. Der erste Kanal, d. h. der Steuerkanal, wird für Befehle und Statusmitteilungen zwischen dem aufrufenden System und der CU verwendet. Der Datenkanal führt die tatsächliche Datenübertragung aus.

ICF-Kryptographische-Einheit-Firmware. 11 ist ein schematisches Blockdiagramm der Kryptographische-Einheit-Firmware. Die CU-Firmware 27 ist die Software, die sich in der kryptographischen Einheit 14 befindet. Es gibt ein Kernlaufzeitmodul 113, das den Gesamtbetrieb der Einheit steuert, Betriebskerndienstschichten 112, die Sicherheitstaktiken implementieren und den Zugriff zu den kryptographischen Funktionen steuern, und Dienstbibliotheksmodule 111, die eng mit den Hostsystemanwendungen interagieren, um anwendungsspezifische Sicherheitsdienste und Taktiken zu implementieren.
Die Firmwarekomponenten können entlang einer scharfen Linie geteilt werden, die als Vertrauensgrenze 115 bezeichnet wird. Unter der Vertrauensgrenze befinden sich die CU-Kernlaufzeit und die tatsächliche Hardware. Über der Vertrauensgrenze befinden sich die CU-Laufzeit, die den gesamten Chip verwaltet, und Dienstmodule oberer Ebene.
CU-Kernlaufzeit. Die CU-Kernlaufzeit implementiert die Dienste unterer Ebene, die die darunter liegende Hardware abschirmen. Dieselbe bietet auch den Unterstützungsschichten Dienste zum Verwalten der Ressourcen an, die durch die CU angeboten werden, z. B. Speicherobjekte für Codemodulspeicherung. Die CU-Kernlaufzeit ist verantwortlich für die COS-Verarbeitung. Jede Operation, die durch die oberen Schichten angefordert wird, wird von einem COS-Identifizierer begleitet. Die COS-Verfallsrichtlinie wird unter dieser Grenze implementiert. Der CU-Kernlaufzeitschutz beruht auf den folgenden Schlüsselmechanismen:

• ROM-Code. Aller CU-Kernlaufzeitcode ist in ROM-Speicherung implementiert. Da er von der vor Eingriffen gesicherten Art der CU profitiert, kann dieser Code nicht manipuliert oder umgangen werden. Der ROM wird in den CU-Prozessoradressraum abgebildet, um die Rücksetz- und Hardwareunterbrechungsvektoren zu bedecken, so dass jeder Rücksetzversuch erzwingt, dass die Ausführung innerhalb der ROM-Codegrenzen erfolgt. Der ROM-Code verläuft auf dem höchsten Privilegpegel des CU-Prozessors.
• Schutzarchitektur. Es ist erforderlich, dass der CU-Prozessor zumindest zwei Privilegpegel implementiert. Auf Speicherobjekte, die dem höheren Privilegpegel zugewiesen sind, kann nicht durch Code zugegriffen werden, der bei einem niedrigerem Privilegpegel läuft. Diese Grenze wird durch die CU-Prozessorhardware geltend gemacht und kann unter keinen Umständen umgangen werden.
• Permanenter Speicher. Die CU-Kernlaufzeit erfordert eine bestimmte Menge an nichtflüchtigem Speicher, der dem höchsten Privilegpegel zugewiesen ist, der nur für den ROM-Code zugreifbar ist. Diese Speicherung wird für die COS-Verarbeitung und die Berührungspunktverarbeitung verwendet, wie es nachfolgend näher beschrieben ist.

Aller Code, der oberhalb der Vertrauensgrenze eingeführt wird, ist Berührungspunktverarbeitung unterworfen. Das Konzept der Berührungspunktverarbeitung wird nachfolgend näher erörtert. Es ist wichtig, anzumerken, dass Code darüber aufhört, zu arbeiten, falls die Berührungspunktpositionen während der Ausführung dieses Codes nicht durch die Kernlaufzeit aufgelöst werden.
CU-Laufzeitdienste. Die CU-Laufzeitdienste liefern die elementaren Betriebssystemfunktionen, die benötigt werden, um die Karte zu verwalten und zu organisieren. Sie befinden sich direkt auf der CU-Kernlaufzeit. Diese Laufzeit kann als Mikrobetriebskern angesehen werden, der bei einem hohen Ausführungsprivilegpegel läuft. Dieser Betriebskern ist der einzige Ort, der die kryptographischen Funktionen treibt, die für die Dienstmodule höherer Ebene verfügbar sind. Die folgenden Grundfähigkeiten sollten verfügbar sein:

• Sicheres Laden. Aufgrund der Art der Einheit müssen einige Softwaremodule, die in die CU geladen werden, validiert werden, bevor dieselben geladen und ausgeführt werden können. Zum Ladezeitpunkt lädt der Lader das Codebild und, falls erforderlich, validiert die Signatur dieser Module. Der sichere Lader ist Teil des Betriebskerncodes und Teil der CU-Kernlaufzeit. Der Betriebskerncode selbst wird durch das CU-Kernlaufzeitmodul geladen und validiert.
• Speicherverwaltung. Der Speicherverwalter des Mikrobetriebskerns ist verantwortlich für die Zuweisung und Freigabe des Hauptspeichers. Speicher kann bei den unterschiedlichen Ringpegeln zugewiesen werden, um einen Schutz zwischen den Speicherbereichen sicherzustellen.
• Aufgabenstellung. Die Aufgabenhandhabungseinrichtung liefert die Grundmechanismen zum Ausführen mehrerer Betriebsteilprozesse. Ankommende Anforderungen können den Beginn einer neuen Aufgabe auslösen oder werden einfach in eine Warteschlange gestellt, um eine bestehende Aufgabe zu erfüllen.
• Interne Mitteilungsmöglichkeit. Falls gewünscht wird, dass die geladenen Module miteinander kommunizieren müssen, muss eine Grundform von Kommunikation zwischen den Aufgaben bereitgestellt werden.
• Crypto Paging. Crypto Paging ermöglicht es dem Speicherverwalter, Speicher außerhalb der Grenze der kryptographischen Einheit zuzuweisen und Seiten in verschlüsselter Form zu speichern. Diese Einrichtung wird benötigt, falls die Speichermenge, die in der Einheit benötigt wird, das überschreitet, was verfügbar ist.
• Zugriff zu internen Ressourcen. Auf die meisten anderen Komponenten, wie z. B. die kryptographische Hardware auf dem Chip, wird durch Routinen zugegriffen, die Teil des Mikrobetriebskerns sind.
• Externe Schnittstellen. Die kryptographische Einheit bildet durch diese Komponente eine Schnittstelle mit dem Hostsystem, die der Eintrittspunkt für externe Anforderungen ist. Die Anforderungen werden gemäß dem definierten Befehlssatz weitergeleitet, decodiert und zu der geeigneten Einheit für die Ausführung weitergeleitet. Diese Schicht kann von der Art der Hostsystembusarchitektur abhängig sein.

CU-Dienste. Dieser Satz von Bibliotheken läuft bei dem am wenigsten privilegierten Schutzpegel. Dieser Pegel nimmt Bibliotheken auf, die Dienste für eine bestimmte Programmierschnittstelle implementieren könnten, wie z. B. die ICF Envelope APIs, kryptographische APIs, wie z. B. die Microsoft Crypto API oder die X/Open GCS API, oder nach Bedarf alle anderen APIs, die benötigt werden, um eine Abstraktion für sichere Speicherung, sichere Ausführung oder Herunterlademöglichkeiten zu bieten. Befehle, die zwischen dem Hostsystem und dieser Schicht ausgetauscht werden, werden durch den Implementierer dieser Schicht definiert.
Die Dienstbibliothekschichten bieten auch die Möglichkeit, es einer Anwendung zu erlauben, einen Teil von sich selbst in einer sicheren und vertrauenswürdigen Umgebung auszuführen. Diese Einrichtung könnte verwendet werden, um Urheberrechtschemata zu implementieren, oder spezielle Funktionalität, wie z. B. Risikobewertungsmodule für finanzielle Anwendungen. Die Programmierschnittstellen sind anwendungsabhängig. Der Hostsystemtreiber leitet Informationen zwischen der Anwendung und den Dienstbibliotheken als Mitteilungen weiter.
Konzept der virtuellen CPU. 12 ist ein schematisches Blockdiagramm, das das Konzept einer virtuellen CPU darstellt. Eine weitere Möglichkeit zum Betrachten der oben erörterten Firmwarestruktur ist das Kombinieren der Firmware niedriger Ebene, die sich in der CU-Kernlaufzeit befindet, und der darunter liegenden Hardware in eine virtuelle CPU, die unter den Beschränkungen ausgeführt wird, die durch diese Kombination implementiert sind.
Die ICF CPU kann als Prozessor gesehen werden, der in der Lage ist, Befehle unter der Steuerung einer Taktik auszuführen. Ein Teil dieser ICF CPU bezieht sich auf die COS-Bewertung und den resultierenden Berührungspunktauflösungsprozess. Das Betrachten der Kombination der Firmware- und Hardwareelemente als verbundene Einheit ermöglicht eine bessere Beschreibung des Vertrauensmodells und die Bewertung einer Hardware/Firmware-Kombination mit demselben. Sobald diese Komponente validiert ist, muss die Analyse jedes Moduls, das darüber geladen und ausgeführt wird, nicht mit aller Interaktion niedrigerer Ebene um Berührungspunkte und Speicherschutz gemischt bewertet werden.
Jede physikalische Prozessormodell/ROM-Kombination, die den oben dargestellten Schutzmechanismus implementieren kann, ist daher in der Lage, als virtuelle CPU konfiguriert zu werden, wie es durch die ICF-CU-Architektur erforderlich sein kann. Jedes Modul, das für eine solche ICF CPU geschrieben ist, kann auf jeder ICF CPU laufen, die die starken Sicherheitsanforderungen erfüllt.
Softwarekomponentenzertifizierungsprozess. Softwarekomponentenzertifizierung ist der Prozess des Sicherstellens, dass es eine enge Verbindung zwischen dem Anwendungsbild und dem Anwendungszertifikat gibt, das durch die ADA ausgegeben wird. Derselbe umfasst auch Firmwarekomponenten und Firmwarezertifikate, die durch die SDA ausgegeben werden.
Der Prozess der Softwarekomponentenzertifizierung kann in zwei einzelnen Stufen beschrieben werden. Es gibt die Installationsstufe und die Ausführungsstufe. Jedes Mal, wenn im folgenden Text der Begriff Anwendung verwendet wird, soll er auch die Firmwarekomponenten umfassen. Es folgt eine kurze Beschreibung der Zertifizierungsprozessstufen.

• Installationsstufe. Die Installationsstufe beschreibt die Schritte, die notwendig sind, um der CU die Anwendung und das begleitende Zertifikat vorzustellen.
• Ausführungsstufe. Die Validierungsstufe beschreibt die Schritte, die durchgeführt werden, um die Identität der Anwendung zu validieren auf der Basis des Zertifikats, das zusammen mit der Validierungsanforderung weitergeleitet wird. Nach der erfolgreichen Validierung tritt die Anwendung in die Ausführungsstufe ein. Zu jedem Zeitpunkt während dieser Stufe kann die CU eine Validierungsanforderung ausgeben, um den Anspruch der Anwendung erneut zu validieren.

Installationsstufe. 13 ist ein schematisches Blockdiagramm, das den Softwarekomponentenzertifizierungsprozess während der Installationsstufe zeigt. Zertifizierte Anwendungen werden an der Anwendungsinstallationsstufe in das Hostsystem eingeführt. Eine zertifizierte Anwendung besteht aus dem Anwendungsbild 29, d. h. der Codedatei, und dem Zertifikat 28, das durch die Anwendungsdomainautorität ausgegeben wird. Das Ergebnis der Installationsstufe ist ein Anwendungsberechtigungsnachweis 130, der eindeutig die Anwendung, die CU und die gültigen Dienstklassen bezeichnet. Das Ergebnis wird hierin als Anwendungsberechtigungsnachweis bezeichnet.
Der Zweck des Installationsprozesses ist es, die Anwendung 29 der CU 14 vorzustellen. Ein spezielles Hilfsprogramm, das Installierprogramm 135, wird aufgerufen, um die notwendige Arbeit auszuführen. Die Hauptaufgabe dieses Hilfsprogramms ist das Weiterleiten einer Referenz an das Programmbild und des Anwendungszertifikats an die CU. Auf das Empfangen der Anforderung für die Installation hin verwen det die CU ihre Hostsystemspeicherzugriffsfähigkeiten zum Berechnen eines Hash-Werts von dem Programmbild.
Das Anwendungszertifikat enthält neben anderen Informationen die Anwendungs-ID 137 und die Dienstklasse 136, die für diese Anwendung definiert ist. Unter Verwendung dieser beiden Informationselemente erzeugt die CU einen Berechtigungsnachweis, der die Anwendung identifiziert, z. B. durch einen Namen, den Hash-Wert des Anwendungsbildes und der Dienstklasse, die für die Anwendung definiert ist.
Der Berechtigungsnachweis wird dann durch die CU unterzeichnet 138 und in einem lokalen nichtflüchtigen Speicher in der CU gespeichert. Falls gewünscht, könnte der Berechtigungsnachweis auch zu einem externen Bereich exportiert werden. Weil die Berechtigungsnachweise nur für die CU sinnvoll sind, die dieselben erzeugt hat, muss nur sichergestellt werden, dass die Berechtigungsnachweise nicht manipuliert wurden, während dieselben außerhalb der CU-Grenzen waren.
Ausführungsstufe. 14 ist ein schematisches Blockdiagramm, das den Softwarekomponentenzertifizierungsprozess während der Ausführungsstufe zeigt. In der Ausführungsstufe wird eine Anwendung 29 durch das Betriebssystem in das Speichersystem geladen und beginnt die Ausführung. An einem Punkt in der Anwendungsausführung fordert die Anwendung kryptographische Dienste an. Normalerweise ist es der erste Schritt, einen Kontext mit der CU herzustellen. Eine Anwendung leitet das Anwendungszertifikat 28, das durch die ADA ausgegeben wurde, an die CU 14, wenn dieselbe eine logische Assoziation herstellt, z. B. einen kryptographischen Kontext.
Auf das Empfangen der Anforderung zum Herstellen einer Assoziation hin validiert die CU die Identität der Anwendung auf der Basis des weitergeleiteten Zertifikats. Durch die Betriebssystemkomponenten hat die CU Zugriff zu dem Anwendungsbild und ist daher in der Lage, die Signatur der Anwendung zu berechnen. Beispielsweise kann unter Verwendung der DMA-Fähigkeit und der Kenntnis des Speicheradressbereichs der Anwendung in dem Speichersystem die CU einen Hash-Wert berechnen.
Nach dem Validieren der Korrektheit des Zertifikats verwendet die CU das Zertifikat zum Lokalisieren des Anwendungsberechtigungsnachweises 130, der dem Zertifikat entspricht. Der Berechtigungsnachweis enthält neben anderen Informationen die berechnete Signatur 138 des Anwendungsbildes von dem Installationsprozess, der in dem vorhergehenden Teilabschnitt beschrieben wurde. Falls die Werte übereinstimmen, können zwei wichtige Tatsachen abgeleitet werden. Zunächst wird die Identität der Anwendung hergestellt, weil die berechnete Signatur über diesem Bild mit der berechneten Signatur zum Installationszeitpunkt übereinstimmt. Zweitens wurde die Anwendung seit der Installationsstufe nicht manipuliert.
Nach diesem anfänglichen Validierungsschritt kann die Anwendung Aufrufe an die CU ausgeben, die kryptographische Operationen anfordern. Zu jedem späteren Zeitpunkt kann die CU entscheiden, diesen Validierungsprozess erneut auszuführen. Die Optionen reichen von Validieren auf einer regelmäßigen Basis zum Validieren auf jede Anforderung hin.
Aus der Perspektive eines Betriebssystems sind keine Änderungen an dem Lader und dem Betriebssystem erforderlich, um dieses Schema zu implementieren. Die einzigen benötigen Anforderungen ist die Fähigkeit, auf das Speicherbild eines Objekts zuzugreifen. Implementierungen können jedoch entscheiden, die CU zur Anwendungsladezeit aufzurufen, um den Validierungsschritt durchzuführen.
Zertifizierung von Firmwarekomponenten. Firmwarezertifizierung unterscheidet sich nicht wesentlich von der Anwendungspegelzertifizierung. Beide haben das Ziel gemeinsam, eine enge Verbindung zwischen dem Zertifikat und dem Softwareobjekt herzustellen. Ein Unterschied, der zu sehen ist, ist, dass die Firmwareobjekte der niedrigeren Ebene durch die SDA und nicht durch die ADA zertifiziert werden. Firmwareobjekte höherer Ebene, z. B. benutzergeschriebene Protokollmodule, die zu der CU heruntergeladen werden, werden durch die ADA zertifiziert.
Ein weiterer Unterschied ist, dass jedes Firmwaremodul, das in die CU heruntergeladen wird, egal ob ein benutzergeschriebenes Modul hoher Ebene oder ein verkäufergeliefertes Modul niedriger Ebene, dem Berührungspunktprozess unterworfen ist. Dieser Prozess ist optional für Anwendungsobjekte außerhalb der CU-Grenze. Das Berührungspunktkonzept wird nachfolgend näher beschrieben.
Zertifizierung allgemeiner Objekte. Das Schema, das in dem vorhergehenden Teilabschnitt beschrieben wurde, kann ohne weiteres ausgedehnt werden, um nicht nur Codebilder, sondern auch jede Art von Datenobjekt abzudecken, das das dargestellte Validierungsverfahren verwenden könnte. Beispielsweise könnten das Betriebssystem selbst, Teilsystembibliotheken und statische Konfigurationsinformationen durch dieses Schema vor unbefugten Modifikationen oder Austausch geschützt werden.
Softwarepegelberührungspunkte. 15 stellt Softwarepegelberührungspunkte dar. ICF-Softwarepegelberührungspunkte sind Datenbereiche, die für den Host oder die CU-Systemumgebung nicht verwendbar sind, bis sie vorverarbeitet wurden. Ein Beispiel eines Softwareberührungspunkts ist das von Befehlssequenzen in einem Codebild, die auf eine Weise transformiert wurden, dass die Befehlsabrufeinheit des Prozessors dieselben nicht erfolgreich decodieren kann. Gleichartig dazu könnte es Datenbereiche geben, die auf eine Weise geändert wurden, dass die ursprünglichen Daten nicht zugreifbar sind.
Ein Softwareberührungspunkt ist durch eine Anfangsadresse in dem Adressbereich 150 des Objekts 151 und die Länge des Berührungspunkts gekennzeichnet. Es gibt mehrere Klassen von Softwareberührungspunkten. Datenpegelberührungspunkte beschreiben einen Bereich in einem Datenobjekt. Keine weiteren Informationen über den Berührungspunkt werden über diesen Berührungspunkt in dem Datenobjekt aufgezeichnet. Ein getrennter Datenbereich beschreibt diese Berührungspunkte außerhalb des Datenobjekts.
Befehlspegelberührungspunkte beschreiben Berührungspunkte in einem Befehlsstrom. Es gibt zwei Unterklassen. Die erste Unterklasse beschreibt Befehlspegelberührungspunkte, die ähnlich sind wie ihre Datenpegelgegenspieler. In diesem Fall wird ein Bereich in dem Befehlsstrom durch die Berührungspunktinformationen ersetzt. Die zweite Unterklasse beschreibt Befehlspegelberührungspunkte, die eine Struktur haben. Ein strukturierter Berührungspunkt beginnt und endet mit einem speziellen Befehl, der den Berührungspunktbereich begrenzt. Alle diese Berührungspunkttypen sind nachfolgend näher beschrieben.
Befehlspegelberührungspunkte. 16 stellt Befehlspegelberührungspunkte dar. Es gibt zwei Typen von Befehlspegelberührungspunkten. Der erste Typ 160 implementiert einen Befehlspegelberührungspunkt als einen Datenbereich in dem Befehlsstrom, der durch eine verwürfelte Version ersetzt wurde. Über den Berührungspunkt an der Position selbst sind keine weiteren Informationen erhältlich. Der zweite Typ 161 implementiert den Berührungspunkt mit einem bestimmten Befehl am Anfang und einem Befehl am Ende des Berührungspunktbereichs. Um die beiden Berührungspunktbereiche zu unterscheiden, wird der erste Typ von Berührungspunkt hierin als unstrukturierter Berührungspunkt bezeichnet, während der zweite Berührungspunkttyp hierin als strukturierter Berührungspunkt bezeichnet wird.
Mechanismen zum Implementieren von Befehlspegelberührungspunkten. Diese Erörterung bezieht sich auf die Implementierungsaspekte von Softwarepegelberührungspunkten. Abhängig von dem verwendeten Prozessor und der verfügbaren Hardwareunterstützung können Berührungspunkte auf eine Vielzahl von Weisen implementiert werden. Die folgenden Aspekte sind allen Implementierungen gemeinsam.

• Auflösen des Berührungspunkts. Das Auflösen eines Berührungspunkts kann auf verschiedene Weisen durchgeführt werden. Beispielsweise könnte ein tp_start- und tp_end-Befehl einen Berührungspunktbereich begrenzen. Die Informationen dazwischen sind die Berührungspunktdaten, die zu der ursprünglichen Befehlssequenz umgewandelt werden sollen. Im Fall eines Befehlspegelberührungspunkts sind die Daten dazwischen Befehle. Der Begrenzungsbefehl könnte eine Unterbrechung an die CU bewirken, um den Berührungspunktbereich aufzulösen und in Position zu bringen, nachdem die Befehlssequenz ausgeführt wurde. Dadurch wird sichergestellt, dass mit der Ausnahme von Betriebssystemausnahmen kein anderer Code ausgeführt werden kann, der Zugriff zu dem Berührungspunktbereich haben könnte. Alternativ könnte man diese Berührungspunktdecodierfunktion in der Befehlsabrufeinheit einer CPU implementieren. Ein Taktikregister könnte den notwendigen Decodierschlüssel für diese Anwendung an dem Kontextschalter speichern. Vorteile dieses Lösungsansatzes umfassen die Transparenz des TP, kombiniert mit dem Vorteil, dass der Code für ein anderes System unbenutzbar gemacht wird. Diese Alternative wird näher erörtert in Verbindung mit der nachfolgenden Erörterung der Hostsystemunterstützung für Softwarepegelberührungspunkte. Das Auflösen eines Berührungspunkts kann auf eine Weise durchgeführt werden, dass der mit einem Berührungs punkt versehene Bereich einen Mechanismus zum Sicherstellen verwendet, dass nur der Empfänger, d. h. derjenige, der den Berührungspunkt permanent entfernen kann, der korrekte Empfänger für dieses Berührungspunktobjekt ist. Das Auflösen eines Berührungspunkts kann auch auf eine Weise durchgeführt werden, dass der Berührungspunkt in Position bleibt und nur für die Dauer der Verwendung des Berührungspunktbereichs auflöst wird. Dieser Lösungsansatz wird verwendet, um die Existenzkriterien von Verfahren in der CU zu implementieren. Es ist wesentlich, die Berührungspunktbereiche permanent in Position zu lassen.
• Auswählen, was mit einem Berührungspunkt zu versehen ist. Ein Berührungspunkt ersetzt eine Sequenz von Befehlen. Die Implementierung muss ein Ausführungsobjekt liefern, in dem die ursprünglichen Befehle ausgeführt werden sollen. Die Sequenz von Befehlen sollte automatisch ausgeführt werden. Die Sequenz von Befehlen selbst muss bestimmte Kriterien erfüllen. Beispielsweise erfordern Zweige außerhalb eines oder in einen Berührungsbereich hinein wesentliche Unterstützung von dem Prozessor zum Erfassen, wenn sich jemand innerhalb eines Berührungspunktbereichs befindet. Zum Stärken des Mechanismus ist es jedoch sinnvoll, diese Alternative zu verfolgen. In einem Codeobjekt können sehr wenige oder viele Berührungspunktbereiche sein. Von dem Satz möglicher Berührungspunkte kann eine Implementierung bei der Laufzeit einen zufälligen Satz von Positionen auswählen, die mit einem Berührungspunkt zu versehen sind. Um das Berührungspunktkonzept weiter zu stärken, kann der Satz dynamisch modifiziert werden, d. h. Berührungspunkte werden zufällig zu dem Satz hinzugefügt und von demselben entfernt. Dies verhindert einen Angriff, bei dem man die Berührungspunktbereiche lokalisieren könn te und im Verlauf der Zeit die ursprüngliche Befehlssequenz bestimmen könnte.
• Erfassen eines Berührungspunkts. Das Erfassen eines Bereichs der mit einem Berührungspunkt versehen ist, erfordert einen Mechanismus, der es dem Prozessor erlaubt, den Anfang und das Ende eines solchen Bereichs zu erfassen. Für Berührungspunktbereiche, die Zweige enthalten, muss jede Position mit einer solchen Anzeige geflaggt werden. Die Programmunterbrechungsfähigkeiten des Prozessors können verwendet werden, um jeden dieser Mechanismen zu implementieren. Die Auswahl reicht vom Verwenden eines Softwareunterbrechungsbefehls über illegale Operationscodes zum Erzwingen einer Ausführung zu speziell zugewiesenen Befehlen, wie z. B. der oben erwähnte tp_start- und tp_end-Befehl.

Datenpegelberührungspunkte. Wie bei dem unstrukturierten Befehlspegelberührungspunkt kann jede Art von konstanten Daten durch dieses Schema geschützt werden. Falls der Prozessor einen Datenunterbrechungspunktmechanismus unterstützt, können diese Bereiche während der Ausführung lokalisiert werden und auf ähnliche Weise aufgelöst werden wie die Befehlspegelberührungspunkte.
CU-Validierungsprozess. Anwendungen müssen über die Korrektheit der CU versichert werden. Das Ziel ist es, das Szenario zu vermeiden, bei dem jemand die Anwendungsanforderungen zu einer anderen kryptographischen Funktion umleitet. Der CU-Validierungsprozess beschreibt die Schritte, die durchgeführt werden, um der Anwendung die Identität der CU zu versichern. Der Validierungsprozess, der in diesem Kapitel beschrieben wird, verwendet die Softwarepegelberührungspunkte als verwendetes Hauptkonzept. CU-Validierung kann in drei einzelnen Stufen beschrieben werden:

• Herstellungsstufe. Die Herstellungsstufe beschreibt die Schritte, die auf Seiten des Anwendungsherstellers durchgeführt werden müssen, um eine Anwendung zu erzeugen, in die die Softwarepegelberührungspunktinformationen eingebaut sind.
• Installationsstufe. Die Installationsstufe beschreibt die Schritte, die notwendig sind, um die Anwendung und das begleitende Zertifikat der CU vorzustellen. Abhängig von der Art der Installation können die Softwarepegelberührungspunkte an dieser Stufe entfernt werden oder intakt in dem Anwendungsbild belassen werden, um zum Ausführungszeitpunkt aufgelöst zu werden.
• Ausführungsstufe. Die Validierungsstufe beschreibt die Schritte, die durchgeführt werden, um die Identität der Anwendung auf der Basis des Zertifikats zu validieren, das zusammen mit der Validierungsanforderung weitergeleitet wird. Nach der erfolgreichen Validierung tritt die Anwendung in die Ausführungsstufe ein. Zu jedem Zeitpunkt während dieser Stufe kann die CU eine Validierungsanforderung ausgeben, um den Anspruch der Anwendung neu zu validieren. Zusätzlich zu diesen Anwendungszertifizierungsschritten müssen die Softwarepegelberührungspunkte, die in der Anwendung installiert sind, entfernt oder dynamisch transformiert werden, wenn dieselben durch den Hostsystemprozessor angetroffen werden. Dies ist nur der Fall, falls dieselben nicht während der Installationsstufe entfernt wurden.

Der nachfolgend skizzierte CU-Validierungsprozess ermöglicht zusätzliche Vorteile, die über das Hauptziel der CU-Validierung hinaus gehen. Aus der Perspektive eines Softwareherstellers werden Probleme bezüglich des Urheberrechtsschutzes in einer Netzwerkwelt zunehmend kritisch. Ein Softwarehersteller würde daher gern die Gewissheit haben, dass die Software, die zu einem Kunden gesendet wird, nicht auf ein anderes System kopiert wird. Der Bereich von Anforderungen kann vom Sicherstellen reichen, dass die Software nur auf eine gültige Gruppe von adressierten Systemen geladen wird, bis zum kundenspezifischen Anpassen der Software für genau ein System.
Herstellungsstufe. 17 ist ein schematisches Blockdiagramm, das die Herstellungsstufe zeigt. In der Herstellungsstufe wird die Anwendung 29a durch den Anwendungshersteller 170 hergestellt. Das Ziel ist das Aufbauen einer Anwendung, die für die bestimmte Gruppe von Zielsystemen oder ein einzelnes Zielsystem genau angepasst werden kann. Das Zielsystem wird durch die CU identifiziert, die in dasselbe installiert ist.
Der Anwendungshersteller entwickelt zunächst die Anwendung. Dies ist die ausführbare Version der Anwendung für die Zielhostsystemplattform. Bevor die Anwendung zu dem Zielhostsystem versendet werden kann, installiert der Anpassungsschritt 171 die Softwarepegelberührungspunkte. Nach der Installation kann die Anwendung 29 versandt werden. Die in 17 gezeigte Anpassungskomponente ist verantwortlich für das Installieren der Berührungspunkte in dem Anwendungsbild.
Die ADA 22 ist die Domainautorität, in der sich der Anwendungshersteller befindet. Der ADA wird durch die SDA 20 eine Dienstklasse gewährt, die die Funktion definiert, die verwendet wird, um die Berührungspunkte in das Anwendungsbild zu installieren.
Ein Punkt der Berührungspunktinstallation ist das Herstellen einer Liste der Position und Länge der Berührungspunktbereiche in dem Codebild. In dem Fall von unstrukturierten Befehlspegelberührungspunkten werden diese Informationen benötigt, um die Berührungspunkte zu lokalisieren. Für strukturierte Befehlspegelberührungspunkte sind diese Informationen nicht unbedingt notwendig. Es gibt auch Überlegungen, die sich darauf beziehen, wo genau ein Berüh rungspunkt platziert werden könnte und was die Länge einer solchen Sequenz sein sollte.
Für unstrukturierte Berührungspunkte ist die Frage, wo genau in dem Codebild dieselben platziert sind, nicht von wesentlicher Bedeutung. Technisch gesehen können dieselben in jeden Bereich des Bildes platziert werden. Für strukturierte Berührungspunkte gibt es mehr Beschränkungen. Beschränkungen umfassen, dass Berührungspunkte beispielsweise keine Prozedurgrenzen kreuzen sollten oder mehr als einen Grundbefehlsblock überlagern sollten. Die Beschränkungen hängen von der Art der Hardwarepegelunterstützung für strukturierte Berührungspunkte ab. Einige dieser Aspekte sind irgendwo anders hierin erörtert.
Am Ende der Herstellungsstufe gibt es ein Anwendungsbild, das mit Softwarepegelberührungspunkten 172 vergrößert ist. Die Berührungspunkte wurden auf rechtmäßige Weise in das Bild gesetzt, weil der COS, die die Operation in der CU für die angepasste Komponente aktiviert, dieses Recht gewährt wurde durch Zertifizierung von der SDA zu der Anwendungshersteller-ADA. Dieser Prozess umfasst bisher keine Informationen über das Zielsystem. Jede Installation, die die Fähigkeiten hat, den Berührungspunktinformationsinstallationsprozess umzukehren, kann eine funktionierende Anwendung ableiten.
Ein weiteres detailliertes Zuschneiden des Zielsystems erfordert zusätzliches Wissen über dieses System. Weil dies eine stärkere Abhängigkeit zwischen dem Hersteller und dem Zielempfänger einführt, ist auf der Verwaltungsseite ein stärkerer Einsatz notwendig.
Installationsstufe. 18 ist ein schematisches Blockdiagramm, das die Installationsstufe zeigt. Die Installationsstufe beschreibt die Schritte, die an der Zielstelle durchgeführt werden, d. h. das Hostsystem und eine spezifische CU 14 sind notwendig, um die Anwendung 29 für die Verwendung auf diesem System vorzubereiten. Erneut gibt es mehrere Ziele. Das erste Ziel ist das Sicherstellen, dass einer Anwendung die Integrität der CU versichert wird. Diese Versicherung wird erreicht durch die Tatsache, dass nur eine CU, der die notwendige COS zum Verarbeiten des Anwendungsbildes gewährt wurde, in der Lage ist, dieses Bild erfolgreich in ein benutzbares umzuwandeln. Das zweite Ziel ist es, sicherzustellen, dass, sobald eine Anwendung auf dem Zielsystem installiert ist, dieselbe nur durch dieses System verwendet werden kann und nicht auf ein anderes System kopiert werden kann.
Die Installierkomponente 180 ist verantwortlich für das Installieren der Anwendung in das Zielsystem. Als Teil des Installierprozesses wird der Berechtigungsnachweis 28 der Anwendung erzeugt, der die COS 26 beschreibt, die für die Anwendung verfügbar ist. Die Einzelheiten dieses Prozesses sind nachfolgend näher beschrieben. Der andere Teil des Installierprozesses führt die Schritte durch, die notwendig sind, um zu beweisen, dass dies eine gültige CU ist, und um ein Anwendungsbild aufzubauen, das nicht anderweitig verwendet werden kann als in Kombination mit der CU, die durch den Installierprozess verwendet wurde.
Die SDA 20 gewährt der ADA 22 den Satz der COS 26. Die ADA gewährt der Anwendung Rechte an einem Satz von COS. Die Taktikkarte 12 enthält die gültige COS für die ADA und die COS für die Installationseinrichtung, wie sie der ADA des Anwendungsherstellers gewährt wurde. Die Installationskomponente kann daher nur die Berührungspunkte in dem Anwendungsbild verarbeiten, falls ihr COS gewährt wurde, um dies zu tun.
Berührungspunkte können theoretisch an der Installationsstufe entfernt werden. Das Entfernen derselben von dem Anwendungsbild an dieser Stufe hat jedoch zwei Konsequenzen. Zunächst hat die Anwendung nur eine Zeitversicherung, dass die CU zum Installationszeitpunkt eine gültige CU ist.
Nach der Entfernung von Berührungspunkten könnte zusammen mit einer anderen Taktikkarte eine andere CU installiert werden, oder umgangen werden, wenn die Anwendung kryptographische Dienste erfordert. Zweitens ist die Anwendung ohne Berührungspunkte im Klartext und kann auf jedes andere System kopiert und ausgeführt werden. Um diese Szenarien zu verhindern, sollte der Berührungspunkt so spät wie möglich in dem Ausführungszyklus entfernt werden.
Ausführungsstufe. 19 ist ein schematisches Blockdiagramm der Ausführungsstufe. In der Ausführungsstufe läuft die Anwendung auf dem Hostsystem. Der Betriebssystemlader 190 transformiert die Anwendungsbilddatei in das ausführbare Speicherbild. Ein Teil des Prozesses bezieht sich auf die Anforderung, zu validieren, dass die Anwendung seit dem Installationszeitpunkt nicht manipuliert wurde, und rechtmäßig eine bestimmte Dienstklasse anfordert. Die Schritte, die durchgeführt werden, um dies sicherzustellen, wurden oben in Verbindung mit der Erörterung von Anwendungszertifizierung beschrieben. Für den CU-Validierungsabschnitt sind zusätzliche Schritte erforderlich.
Zum Anwendungsladezeitpunkt müssen zwei Hauptziele adressiert werden. Das erste Ziel ist das Validieren der CU. Diese Aufgabe wird erfüllt, falls die CU in der Lage ist, die Softwareberührungspunkte von der Anwendung aufzulösen. Falls die CU beispielsweise in der Lage ist, die ursprüngliche Signatur der Anwendung ohne die Berührungspunkte zu berechnen, beweist dies, dass dieselbe dieselben erfolgreich entfernen kann und ist daher eine gültige CU, weil ihr die COS gewährt wurde, diese Operation durchzuführen. Das zweite Ziel ist das Auflösen der Berührungspunkte. Die CU ist verantwortlich für das Entfernen der Berührungspunkte, bevor der Anwendungsabschnitt, der dieselben enthält, ausgeführt wird.
Der einfachste Fall ist es, wenn die CU die Berührungspunkte von dem Anwendungscodebild entfernt. Das Dateibild des Programms würde nach wie vor die Berührungspunkte enthalten und nutzlos bleiben, falls es auf ein anderes System kopiert wird. Der Speicherabschnitt ist jedoch im Klartext und könnte kopiert werden, falls ein böswilliger Benutzer ein Kopierprogramm schreiben würde, das das Dateibild von dem Speicherbild aufbaut. Eine solche Aufgabe erfordert gewisse Fähigkeiten und Kenntnis des darunter liegenden Betriebssystems, ist aber nicht unmöglich.
Ein weiterer Lösungsansatz ist es, die Berührungspunkte in Position zu lassen und dieselben aufzulösen, wenn sie angetroffen werden. Dieser Lösungsansatz verlässt sich auf Hardwareunterstützung zum Erfassen der Berührungspunkte. Dies wird in Verbindung mit der Erörterung für Hardwareunterstützung für Softwarepegelberührungspunkte hierin näher beschrieben.
Zuschneiden zu einer einmaligen CU. Der bisher beschriebene Prozess stellt keine enge Beziehung zwischen der Softwarekomponente des Softwareherstellers und dem Zielsystem dar, das durch die CU identifiziert wird, die in dasselbe installiert ist. Der Vorteil der eher lockeren Kopplung ermöglicht es dem Hersteller, eine Anwendung herzustellen, die auf jedem System installiert werden kann, das die Fähigkeit hat, die Berührungspunkte zu verarbeiten, die in der Anwendung installiert sind. Kein weiteres Wissen über das Zielsystem ist erforderlich.
Falls eine engere Verbindung gewünscht wird, muss der Anwendungshersteller die Anwendungskomponente auf die Zielsystem-CU zuschneiden. Dies könnte beispielsweise durchgeführt werden durch Erzeugen einer einmaligen COS, die von der ADA des Herstellers und der SDA gemeinschaftlich verwendet wird. Die SDA installiert die einmalige COS auf der Taktikkarte, wenn dieselbe für die Zielsystem-CU zugeschnitten ist, und verwendet diese COS gemeinschaftlich mit der ADA des Anwendungsherstellers. Nur das Installationshilfsprogramm auf dem Zielsystem, dem diese eindeutige COS gewährt wird, kann die Software erfolgreich auf dem Zielsystem installieren.
Firmwareberührungspunktunterstützung in der kryptographischen Einheit. 20 stellt das Prinzip von Dienstklassen, Berührungspunkten und Umschlägen dar. Firmwarepegelberührungspunkte sind Berührungspunkte, die in ein Firmwaremodul installiert sind, das sich in der CU befindet. Als solche müssen dieselben durch die oben beschriebene ICF-CPU gesteuert werden. Es gibt drei Grundfunktionalitätsblöcke, die die ICF-CPU liefern muss, um Firmwarepegelberührungspunkte handzuhaben.
Firmwareberührungspunktverarbeiten umfasst drei Grundkomponenten, falls die ICF CPU:
Der erste Block ist die Umschlagshandhabung 200. Taktikaktivierung, d. h. der Prozess des Sendens der geeigneten Informationen an die CU zum Aktivieren einer bestimmten Dienstklasse, wird zwischen dem NSS und der ICF CPU über Umschläge 201 kommuniziert, wie sie in der ICF-Architektur beschrieben sind. Bevor irgendeine weitere Verarbeitung dieser Umschläge stattfindet, muss der Ursprung und die Validität derselben verifiziert werden.
Der validierte und authentifizierte Inhalt des Umschlags wird zu der zweiten Komponente weitergeleitet, die die COS-Maschine 202 ist. Die COS-Maschine kann als Herz der Verwaltung der Dienstklasse gesehen werden, die auf dieser CU installiert ist. Jede Anforderung für einen Dienst, der einer COS zugeordnet ist, wird an diese Maschine gerichtet und für Zugriffssteuerung zu dieser Ressource bewertet.
Außerdem behält die COS-Maschine auch eine Heartbeatfunktion bei, die eine Implementierung von COS-Verfall ermöglicht. Die COS-Maschine analysiert jede gespeicherte COS regelmäßig und verifiziert, dass die Randbedingungen für diese COS noch wahr sind. Die Randbedingungen werden ebenfalls für jede Anforderung bewertet, falls das COS-Attribut dies spezifiziert. Eine COS, die beispielsweise spezifiziert, dass nur eine bestimmte Anzahl von Operationen erlaubt sind, ruft den Maschinenbewertungsmechanismus bei jeder Anforderung auf und dekrementiert einen Zähler.
Die dritte Grundkomponente ist TP-Auflösung 203. Der TP-Auflösungsblock ist verantwortlich für das Handhaben der Auflösung von Berührungspunkten 204, während dieselben durch die ausführende Firmware angetroffen werden. Durch einen der früher skizzierten Mechanismen wird die Ausführungssteuerung zu dieser Komponente übertragen und die Befehle, die durch den Berührungspunkt maskiert sind, werden in der Vertrauensgrenze 205 ausgeführt, die durch die ICF-CPU hergestellt wird. Sobald die COS-Maschine bestimmt, dass eine COS nicht mehr zugreifbar ist, wird die COS als ungültig markiert und der TP-Auflösungsprozess funktioniert für diese COS nicht. Als Folge kann die Firmware nicht mehr verwendet werden.
Hostsystemhardwareunterstützung für SW-Berührungspunkte. 21 stellt die Speicherhierarchie bezüglich der Softwareberührungspunktauflösung dar. Softwarepegelberührungspunkte können Hardwareunterstützung von der Hostsystem-CPU ausnutzen. Ein Schlüsselaspekt dieses Ausführungsbeispiels der Erfindung bringt den Auflösungsprozess von Berührungspunkten näher zu den Hostsystemprozessorausführungselementen. Durch Bewegen des Auflösungsprozesses näher zu dem Prozessor 210, z. B. dem Cacheteilsystem 211, sind keine Berührungspunktbereiche im Klartext in dem Hauptspeichersystem 212 oder den Speicherelementen 213 bei einem niedrigeren Pegel in der Speicherhierarchie.
Bei diesem Ausführungsbeispiel der Erfindung gibt es zwei Hauptlösungsansätze zum Auflösen von Softwarepegelberührungspunkten. Bei dem ersten Lösungsansatz erzeugt der Hostprozessor eine Ausnahme auf die Erfassung eines Softwareberührungspunkts hin, was die CU aufruft, den Software berührungspunkt aufzulösen. Der zweite Lösungsansatz ist relativ ähnlich, außer dass es die Hostsystemverarbeitungselemente für die tatsächlichen Operationen verwendet. Beide Lösungsansätze können ferner gemäß strukturierten gegenüber unstrukturierten Softwareberührungspunkt unterteilt werden.
Der Softwareunterbrechung-zu-CU-Lösungsansatz für strukturierte Befehlspegelberührungspunkte. 22 zeigt einen Hostsystemprozessor, der Befehle von dem Speichercodebild 221 einer Anwendung abruft, in die strukturierte Befehlspegelberührungspunkte 222 installiert sind. Bei dem Programmunterbrechung-zu-CU-Lösungsansatz erhebt der Hostsystemprozessor 223 eine Ausnahme, wenn er auf einen Berührungspunktstartbefehl trifft. Die Ausnahmehandhabungseinrichtung ruft die CU-Komponente auf, den Berührungspunkt zu entfernen und die Berührungspunktdaten mit ausführbaren Befehlen zu ersetzen. Der Hostsystemprozessor fährt dann fort, die Anwendung auszuführen. Auf das Erfassen des Berührungspunktendebefehls hin erlebt der Hostsystemprozessor erneut eine Programmunterbrechung und die CU kann das Speicherbild zurück zu dem Berührungspunktzustand transformieren.
Der Hostsystemprozessor verwendet den tp_start-Befehl zum Erheben einer Ausnahme, die bewirkt, dass die CU aufgerufen wird. Der CU wird dann die Kenntnis des Speicheradressbereichs und der Speicherposition des Berührungspunkts übertragen, um den Berührungspunktkörper in eine Befehlssequenz umzuwandeln, die durch den Hostsystemprozessor ausgeführt werden kann. Die Steuerung kehrt dann zu dem Hostsystemprozessor zurück. Sobald der Berührungspunkt auf diese Weise übersetzt wurde, könnten andere Anwendungsfälle potentiell auf den Berührungspunktbereich zugreifen. Es ist daher wichtig, die Berührungspunkte als kritischen Abschnitt zu implementieren, in dem kein Anwendungskontextschalten erlaubt ist. Auf das Ende der Berührungspunktbefehlssequenz hin bewirkt der tp_end-Befehl eine Programmunterbrechung der CU, die es der CU ermöglicht, die Berührungspunktdaten zurück zu dem ursprünglichen Zustand umzukehren.
Verwendung von Hostsystemprozessorelementen für strukturierte Befehlspegelberührungspunkte. 23 ist ein schematisches Blockdiagramm, das Befehlspegelberührungspunktunterstützung in dem Hostsystemprozessor darstellt. Dieser zweite Lösungsansatz nimmt an, dass der Hostsystemprozessor 223 eine eingebaute Logikkomponente 230 aufweist, die es ihm ermöglicht, den Berührungspunkt während dem Befehlsabrufen zu decodieren. Auf das Antreffen eines Berührungspunktstartbefehls hin übersetzt der Hostsystemprozessor die Berührungspunktdaten in dem Cache 224 des Prozessors und setzt die Ausführung fort. Keine Speicherbildänderung findet statt. Auf das Antreffen des Berührungspunktendbefehls hin wird die Cachezeile 225 gelöscht oder für zukünftige Verwendung belassen. Um dieses Schema zu unterstützen, ist es erforderlich, dass sich Berührungspunkte auf einer Cachegrenze ausrichten, die ein Mehrfaches der Cachezeilengröße sein sollte.
Auf das Erfassen eines tp_start-Befehls durch die Hostsystemprozessorbefehlsabrufeinheit hin ruft das Hostsystem zuerst eine oder mehrere Cachezeilen ab, die den Berührungspunkt enthalten, und wandelt dieselben dann um unter Verwendung des Schlüssels, der an einem Hostsystemprozessorsteuerregister 226 gespeichert ist. Jede Anwendung kann einen unterschiedlichen tp_reg-Wert zum Auflösen des Berührungspunktbereichs haben. Der tp_reg-Wert ist Teil der COS-TP, die verwendet wurde, um die Anwendung in dem Hostsystem zu installieren. Das Laden des tp_reg-Steuerregisters im Zusammenhang am Kontextschalter umfasst die CU als Hüter der Informationen. Der key_reg-Wert könnte auch zu einem Teil des Anwendungskontextzustands gemacht werden, so dass derselbe während einem Kontextumschalten geladen werden kann, ohne die CU aufzurufen.
Lösungsansätze für nichtstrukturierte Befehlspegelberührungspunkte und Datenpegelberührungspunkte. Sowohl unstrukturierte Befehlspegelberührungspunkte als auch Daten pegelberührungspunkte sind durch die Abwesenheit von Metainformationen über die Berührungspunkte an der Berührungspunktposition selbst gekennzeichnet. Der Lösungsansatz für diese Klasse von Softwareberührungspunkten kann in zwei Schritte unterteilt werden. Der erste Schritt bezieht sich auf die Erfassung dieser Berührungspunkte, der zweite Schritt löst dieselben auf, bevor der Hostsystemprozessor auf diesen Bereich zugreift.
Um einen Berührungspunktbereich zu erfassen, müssen Mechanismen sowohl in der Softwareumgebung als auch der Hardware positioniert werden, um die Informationen über die Position der Berührungspunkte an die Hostsystemverarbeitungselemente auszubreiten. Falls beispielsweise die Granularität der Berührungspunktbereiche gewählt ist, auf einer Seitengröße des virtuellen Speichersystems des Hostsystems zu sein, könnten die Informationen über die Berührungspunktposition durch die Seitentabellen und Übersetzungspuffer zu dem Hostsystemprozessor kommuniziert werden.
Während der Adressübersetzung kann der Hostprozessor erfassen, ob der Adressbereich, der übersetzt werden soll, Softwareberührungspunkte enthält oder nicht. Wenn die Cachezeile für die Ausführung oder Zugriff von einer Berührungspunktseite durch den Hostsystemprozessor geladen wird, wird der Berührungspunktbereich in dem Cacheteilsystem aufgelöst, wie es oben beschrieben ist. Ähnliche Techniken werden angewendet, wenn die aufgelösten Berührungspunktbereiche in den Cachezeilen gehalten werden und in dem Hauptspeicher nicht zugreifbar sind, oder die Plattenbilder der Objekte, die dieselben enthalten. Nur-Lese-Cache-Zeilen werden einfach jedes Mal gelöscht, wenn dieselben nicht mehr benötigt werden. Modifizierte Cachezeilen müssen zurücktransformiert werden, bevor dieselben zurück in das Hauptspeichersystem geschrieben werden.
Obwohl die Erfindung hierin mit Bezugnahme auf das bevorzugte Ausführungsbeispiel beschrieben ist, wird ein Fach mann auf diesem Gebiet ohne weiteres erkennen, dass andere Anwendungen für diejenigen, die hierin beschrieben sind, eingesetzt werden können, ohne von dem Schutzbereich der vorliegenden Erfindung abzuweichen. Folglich soll die Erfindung nur durch die angehängten Ansprüche begrenzt sein.

Claims

Eine Vorrichtung zum Validieren, dass eine Anwendung (29) eine bestimmte Dienstklasse (26) rechtmäßig ausführt, wobei die Vorrichtung folgende Merkmale umfasst: eine Anwendungsdomainautorität (22) zum Gewähren eines Autoritätspegels in der Form eines Zertifikats (28), das gültige Dienstklassen enthält; eine Einrichtung, um entweder Dienstklassen mit einer Sicherheitsdomainautorität zu erzeugen oder Dienstklassen mit der Anwendungsdomainautorität zu definieren, wobei die Dienstklassen durch die Sicherheitsdomainautorität validiert werden, die Richtlinien definiert hat, um die Sicherheitsinteressen und -anforderungen der Sicherheitsdomainautorität zu erfüllen; eine Einrichtung (14) zum engen Binden der Anwendung an das Zertifikat; ein vertrauenswürdiges Ladeteilsystem (12) zum Durchführen einer Anwendungsvalidierung; eine Einrichtung (14) zum Laden eines Programmbildes in einen Systemspeicherplatz, und während dies durchgeführt wird, Validieren, dass diese Anwendung nicht manipuliert wurde, wobei die Dienstklasse eine eindeutige Identifikation aufweist, die durch die Sicherheitsdomainautorität nicht wiederverwendet wird, wobei die Dienstklasse ein Verfahrensfeld (51) umfasst, das ein tatsächliches Verfahren beschreibt, für das die Dienstklasse steht, wobei die Dienstklasse ein Beschränkungsfeld (52) enthält, das Attribute des Verfahrens beschreibt, das in dem Verfahrensfeld beschrieben ist, wobei die Attribute die Verwendung der Dienstklasse regeln, und wobei eine Anwendung ein Zertifikat aufweisen muss, um auf ein Verfahren zuzugreifen, das durch die Dienstklasse identifiziert wird.
Die Vorrichtung gemäß Anspruch 1, die ferner folgende Merkmale umfasst: eine kryptographische Einheit (14); und eine Einrichtung (12) zum Herstellen von Vertrauen zwischen der Anwendung und der kryptographischen Einheit, wobei der Anwendung versichert wird, dass die kryptographische Einheit nicht manipuliert wurde.
Die Vorrichtung gemäß Anspruch 1 oder 2, bei der das vertrauenswürdige Ladeteilsystem ferner folgendes Merkmal umfasst: eine Einrichtung (27) zum Verwenden einer Prüfsumme über ein Programmbild; wobei die Ladung ausfällt und das Programmbild nicht geladen wird, falls die Prüfsumme nicht mit einer Prüfsumme übereinstimmt, die durch ein Laderteilsystem bei der Anwendungsinstallationszeit gespeichert wurde.
Die Vorrichtung gemäß einem der Ansprüche 1 bis 3, die ferner folgendes Merkmal umfasst: eine Einrichtung (27) zum Validieren jedes Objekts, das durch ein Zertifikat geregelt wird.
Die Vorrichtung gemäß Anspruch 2, die ferner folgendes Merkmal umfasst: eine Einrichtung (27) zum Herausfordern der kryptographischen Einheit.
Die Vorrichtung gemäß Anspruch 2, bei der die Anwendung in verwürfelter Form an ein Zielsystem gesendet wird; wobei die Vorrichtung ferner folgendes Merkmal umfasst: eine Einrichtung (30) zum Vorbereiten der Anwendung zum Wirken mit der kryptographischen Einheit; wobei nur eine kryptographische Einheit, die einen korrekten Verschlüsselungsschlüssel aufweist, die Anwendung entwürfeln kann.
Die Vorrichtung gemäß einem der Ansprüche 1 bis 6, die ferner folgendes Merkmal umfasst: eine Einrichtung zum Liefern einer Dienstklasse von der Sicherheitsdomainautorität (20) an die Anwendungsdomainautorität (22), um es der Anwendungsdomainautorität zu ermöglichen, Anwendungszertifikate (28) für eine Anwendung auszugeben, die die Dienstklasse enthält; wobei ein Weg der Zugriffssteuerung gebildet wird.
Die Vorrichtung gemäß Anspruch 2, die ferner folgendes Merkmal umfasst: eine Einrichtung (28) zum Ausbreiten einer Dienstklasse an die kryptographische Einheit, um die Dienstklasse an einer kryptographischen Zieleinheit freizugeben; wobei Verfahren, die durch die Dienstklasse markiert sind, in einem aktuellen Zustand sein müssen, damit eine Anforderung ausgeführt werden kann.
Die Vorrichtung gemäß einem der Ansprüche 1 bis 7, bei der sowohl die Steuerung des Zugriffs und die Steuerung der Existenz eines Verfahrens immer vorliegen muss, um ein Verfahren, das durch die Anwendung definiert ist, in einem funktionierenden Zustand zu halten.
Die Vorrichtung gemäß Anspruch 2, die ferner folgendes Merkmal umfasst: eine Taktik (12) zum Aktivieren der kryptographischen Einheit, bevor einer Anwendung über das Anwendungszertifikat eine Dienstklasse gewährt werden kann.
Die Vorrichtung gemäß Anspruch 10, bei der die kryptographische Einheit (14) in Kommunikation mit einer Taktik (12) sein muss, damit die Dienstklasse heruntergeladen werden kann.
Die Vorrichtung gemäß Anspruch 2, die ferner folgendes Merkmal umfasst: eine virtuelle Taktik (12), die eine Netzwerkverbindung mit einem Netzwerksicherheitsserver (18) erfordert, um die virtuelle Taktik an die kryptographische Einheit (14) zu verteilen.
Die Vorrichtung gemäß einem der Ansprüche 1 bis 11, die ferner folgendes Merkmal umfasst: eine physikalische Taktik (12), die es erfordert, dass die kryptographische Einheit (14) Berührungspunkte in Hardware implementiert; wobei die Berührungspunkte in deterministische Positionen in der Hardware plaziert werden; und wobei eine Taktik, die Berührungspunktdaten enthält, geladen werden kann, aber nicht ohne einen Zerfall der Funktion der Anwendung von der kryptographischen Einheit entfernt werden kann.
Die Vorrichtung gemäß einem der Ansprüche 1 bis 13, bei der die Dienstklasse Berührungspunktdaten enthält, die notwendig sind, um Berührungspunkte in der kryptographischen Einheit zu steuern.
Die Vorrichtung gemäß einem der Ansprüche 1 bis 14, bei der das Intervall, für das eine Dienstklasse als gültig erklärt werden kann, ein ungebundenes sein kann oder durch vorbestimmte Kriterien beschränkt sein kann.
Die Vorrichtung gemäß einem der Ansprüche 1 bis 15, bei der die Dienstklasse ferner folgendes Merkmal umfasst: eine spezielle vordefinierte Dienstklasse, die verwendet wird, um die Dienstklassenzerfallfunktionalität zu sichern.
Die Vorrichtung gemäß einem der Ansprüche 1 bis 16, bei der die Dienstklassen nicht nur durch ein Objekt organisiert sind, das dieselben beschreiben, sondern auch durch einen Validierungspegel oder einen Satz von Beschränkungen, den eine Implementierung durchführt, bevor ein Dienstpegel gewährt wird, der durch die Dienstklasse beschrieben wird.
Die Vorrichtung gemäß einem der Ansprüche 1 bis 17, bei der eine engere Validierung und Steuerung über einen Dienst, der gewährt werden soll, auf der Basis des Validierungspegels oder des Satzes von Beschränkungen erreicht wird.
Die Vorrichtung gemäß einem der Ansprüche 1 bis 18, die ferner folgendes Merkmal umfasst: einen Dienstklassenpegel, der die Dienstklassen-ID validiert, wenn dieselbe durch ein Anwendungszertifikat verfügbar gemacht wird und durch eine Sicherheitsdomainautorität unterzeichnet wurde.
Die Vorrichtung gemäß einem der Ansprüche 1 bis 19, die ferner folgendes Merkmal umfasst: einen Dienstklassenpegel, der die Validierung des Anwendungszertifikats erfordert, wobei das Zertifikat durch die Anwendungsdomainautorität ausgestellt werden muss, das die Dienstklasse angefordert hat, die durch die Dienstklassen-ID von der Sicherheitsdomainautorität identifiziert ist.
Die Vorrichtung gemäß einem der Ansprüche 1 bis 20, die ferner folgendes Merkmal umfasst: einen Dienstklassenpegel, der die Validierung der Anwendungs-ID erfordert, die durch die Anwendungsdomainautorität ausgegeben wird.
Die Vorrichtung gemäß einem der Ansprüche 1 bis 21, die ferner folgendes Merkmal umfasst: einen Dienstklassenpegel, der eine Interaktion mit einem nationalen Sicherheitsserver erfordert, um die Dienstklasse zu validieren, die durch die Anwendung angefordert wird.
Die Vorrichtung gemäß einem der Ansprüche 1 bis 22, die ferner folgendes Merkmal umfasst: einen Dienstklassenpegel, der mit dem nationalen Sicherheitsserver an jeder Operation interagiert, die durch die Anwendung angefordert wird.
Die Vorrichtung gemäß einem der Ansprüche 1 bis 23, die ferner folgendes Merkmal umfasst: einen Dienstklassenpegel, der ein Token (50) für jede oder jede Kombination von Validierungen und Interaktionen erfordert.
Die Vorrichtung gemäß einem der Ansprüche 1 bis 24, bei der die Dienstklassenpegel allein oder in Kombination vorgesehen sein können.