-
Hintergrund
der Erfindung
-
Die Erfindung betrifft die Verwaltung
kryptographischer Schlüssel
in Datenverarbeitungssystemen. Insbesondere betrifft die Erfindung
einen Mechanismus zum Verbessern der kryptographischen Steuerungstechnik.
-
Der Bedarf an Sicherheit in verteilten
Systemen ist an sich bekannt. Zur Erzielung mancher Sicherheitsaspekte
ist der Einsatz der Kryptographie erforderlich, um die Datenintegrität und Datengeheimhaltung
zu gewährleisten.
-
Nationale Sicherheitsorgane stellen
unterschiedliche Anforderungen an die Arten und Beständigkeiten von
kryptographischen Algorithmen, die zum Schutz von Benutzerdaten
(wenn überhaupt)
verwendet werden. Häufig
wird die Verwendung von strengen kryptographischen Techniken durch
die Sicherheits-Infrastruktur zugelassen (z. B. für eine Schlüssel-Verteilung,
Authentisierung, Zugriffssteuerung), während ein geringerer Schutz
für Benutzerdaten
zugelassen wird. Manchmal werden für Benutzerdaten strenge Integritäts-Algorithmen,
jedoch nur schwache Vertraulichkeits-Algorithmen zugelassen. Es
können
solche Anforderungen entweder durch die Exportbehörden des
Landes, aus denen ein Produkt, das Kryptographie enthält, geliefert
wird, oder durch die nationalen Behörden des Landes, in dem das
Produkt verwendet wird, festgelegt werden.
-
Die Anforderungen, die festlegen,
welche kryptographischen Steuerungen angewendet werden sollen, können in
einer Datei festgelegt werden, die von dem System- Lieferanten geliefert
und die mit einem spezifischen Kunden verknüpft werden (z. B. durch Hashing
bzw. Aufteilungscodieren der Datei unter Verwendung einer Einweg-Funktion verwendet,
die Gebrauch von dem Lizenzschlüssel
und der Kunden-Identität
als Initialisierungs-Vektoren macht). Solche Steuerungen können umfassen:
- – Beschränkungen
in der maximalen Schlüssellänge von
asymmetrischen Chiffren (z. B. 512 Bits maximaler Modulus-Größe für RSA);
- – Schwächung der
symmetrischen Chiffre-Schlüssel
(z. B. durch Aufgeben der Eigenschaft der Maskierung kommerzieller
Daten, wie in US-Patent 5 232 464 an DES-Schlüsseln
vor der Verwendung erläutert);
- – Verwendung
von asymmetrischen Chiffren nur für die Datenintegrität;
- – Beschränkungen
in den zugelassenen Betriebsweisen einer symmetrischen Chiffre (z.
B. durch Verbieten von Triple DES-Betriebsarten)
-
Ein Problem besteht jedoch darin,
dass Anwendungsfälle
diese rigorosen Vorgaben nicht gebrauchen, was zu einer möglichen
Verletzung der nationalen Vorschriften führt.
-
Ein Aufsatz von R. W. Jones mit dem
Titel "Some techniques
for handling encipherment keys",
ICL Technical Journal, 3 (2), 1982, Seiten 175 – 188 beschreibt ein kryptographisches
System, bei dem Informationen (die als Kennung bezeichnet werden)
an einen kryptographischen Schlüssel
angehängt
werden, um zu zeigen, wie der Schlüssel verwendet werden soll.
Das auf diese Weise entstandene Produkt wird als ein "Kennungs-Schlüssel" bezeichnet. Die
Schlüssel
werden in deutlicher Form nur in sicheren, zuverlässigen Modulen gehalten,
und wenn der Schlüssel
außerhalb
der sicheren Module zugänglich
gemacht wird (z. B. für
eine Schlüsselverteilung),
wird er stets zusammen mit den Kennungs-Schlüssel durch eine Schlüssel-Codierungs-Taste
(KEK) chiffriert. Überall,
wo der chiffrierte Schlüssel
verteilt wird, gehen die Kennungsschlüssel mit ihm und können nicht
gelöst
oder modifiziert werden, ausgenommen durch die sicheren Module.
-
Beispielsweise wurde vorgeschlagen,
dass die Kennungsschlüssel
verwendet werden können,
um zu steuern:
- – ob ein Schlüssel verwendet
werden kann, damit kryptographische Operationen an Daten oder an
anderen Schlüsseln
durchgeführt
werden;
- – ob
der Schlüssel
verwendet werden kann, um zu chiffrieren oder zu dechiffrieren oder
beides; und
- – ob
der Schlüssel
verwendet werden kann für
die Integritäts-Versiegelungs-Generierung oder
Verifizierung oder beides.
-
S. M. Matyas "Key Handling with Control Vectors", IBM Systems Journal,
Band 30, Nr. 2, 1. Januar 1991, Seiten 151–174 beschreibt ein kryptographisches
System, bei dem jeder kryptographische Schlüssel einen zugeordneten Steuervektor
hat, der die zugelassenen Verwendungen des Schlüssels festlegt. Der Steuervektor
ist kryptographisch mit dem Schlüssel
bei der Schlüssel-Generierung
gekoppelt. Wie von Matyas ausgeführt,
ist das Verfahren der Steuerung von Vektoren in vielen Fällen ähnlich der
Kennungsschlüssel-Methode,
die in der vorgenannten Druckschrift von R. W. Jones beschrieben
worden ist.
-
Aufgabe vorliegender Erfindung ist,
eine Erweiterung des Kennungsschlüssel-Konzepts vorzuschlagen,
um die Steuerung der Anwendung von kryptographischen Steuervorgaben
zu unterstützen.
-
Kurzbeschreibung
der Erfindung
-
Gemäß der Erfindung weerden eine
kryptographische Unterstützungs-Einrichtung
und ein Verfahren zum Betreiben eines Datenverarbeitungssystems
vorgeschlagen, wie in den beigefügten
Ansprüchen
ausgeführt.
-
Kurzbeschreibung der Zeichnungen
-
1 zeigt
ein Blockschaltbild eines verteilten Datenverarbeitungssystems gemäß der Erfindung;
-
2 zeigt
ein Blockschaltbild, das eine kryptographische Unterstützungseinrichtung
(CSF) näher darstellt;
-
3 ist
ein Flussschaltbild, das die Betriebsweise einer Kundenanwendung
zeigt, wenn es erforderlich ist, eine sichere Kommunikation mit
einer Server-Anwendung
aufzubauen;
-
4 ist
ein Flussschaltbild, das die Arbeitsweise eines Schlüsselverteil-Service
darstellt, wenn es erforderlich ist, einen Basis-Schlüssel zu
liefern;
-
5 ist
ein Flussschaltbild, das die Betriebsweise der CSF zeigt, wenn es
erforderlich ist, einen Dialog-Schlüssel zu generieren;
-
6 ist
ein Flussschaltbild, das die Betriebsweise der Server-Anwendung
zeigt, wenn sie eine Sicherheits-Assoziations-Anfragennachricht
von der Kundenanwendung bekommt;
-
7 ist
ein Flussschaltbild, das die Betriebsweise der CSF darstellt, wenn
sie aufgerufen wird, um Daten unter dem Dialogschlüssel zu
entziffern.
-
Beschreibung
einer Ausführungsform
der Erfindung
-
Eine Ausführungsform der Erfindung wird
nachstehend anhand eines Ausführungsbeispieles
in Verbindung mit den Zeichnungen erläutert.
-
1 zeigt
ein verteiltes Datenverarbeitungssystem 10 mit einer Anzahl
von Anwendungen 11, 12. Es wird angenommen, dass
eine dieser Anwendungen 11 (die als der Kunde bezeichnet
wird), eine sichere Kommunikation mit einer anderen Anwendung 12 aufzubauen
wünscht,
die als Server bezeichnet wird. Das System weist ferner einen Schlüsselverteil-Service
KDS 13 auf, dessen Zweck darin besteht, kryptographische
Schlüssel
an die Anwendungen zu verteilen.
-
Jeder der Anwendungen 11, 12 und
der KDS 13 ist eine entsprechende kryptographische Unterstützungs-Einrichtung
(CSF) 14, 15, 16 zugeordnet. Jede Anwendung 11, 12 hat
ihre eigene Schlüssel-Verschlüsselungs-Taste
(KEK), die in der eigenen CSF sicher gehalten wird. Der KDS hat
eine Schlüssel-Datenbank 17, die
die KEKs aller Anwendungen enthält,
die unter einem Master-Schlüssel
MK verschlüsselt
sind, der nur der CSF 16 des KDS bekannt ist.
-
2 zeigt
eine der CSFs 14, 15, 16 in detailierterer
Form. Die CSF ist ein vertrauensvolles, sicheres Modul und weist
einen Schlüssel-Speicher 21 auf,
in dem Schlüssel
sicher gehalten werden. Jeder im Speicher gehaltene Schlüssel wird
durch eine Kennung identifiziert, die gestattet, dass der Schlüssel durch
die zugeordnete Anwendung oder den KDS in Bezug gesetzt werden kann,
ohne dass ein direkter Zugriff zum Schlüssel selbst möglich ist.
-
Jede CSF weist ferner eine Schlüssel-Management-Funktion 22,
eine Schlüssel-Generier-Funktion 23 und
eine kryptographische Betriebs-Funktion 24 auf. Die Schlüssel-Management-Funktion 22 wird
verwendet, um Schlüssel-Kennungen
zu prüfen
und alle Restriktionen, die diesen Kennungen aufgelegt werden, durchzusetzen.
Die Schlüssel-Generier-Funktion 23 wird
verwendet, um Schlüssel
zu generieren und abzuleiten. Die kryptographische Betriebs-Funktion 24 dient
zum Schutz der Codierung, der Decodierung und der Integrität.
-
Eine derartige CSF ist in einem Aufsatz
von J. Press mit dem Titel "A
New Approach to Cryptographic Facility Design", ICL Technical Journal 8 (3), Mai 1993,
Seiten 492–505
beschrieben.
-
Die kryptographischen Schlüssel können beispielsweise
DES-Schlüssel
sein, wie in dem Dokument FIPS Pub 40, Data Encryption Standard,
National Bureau of Standard (now National Institute of Standards
and Technology), US Handelskammer, 1977 beschrieben.
-
Schlüssel-Kennungs-Format
-
Allen Schlüsseln, die in dem System verwendet
werden, sind eine oder zwei Byte-Kennungen
zugeordnet, die zusammen mit dem Schlüssel gespeichert wird. Das
Schlüssel-Kennungs-Format
ist unten dargestellt. Bit 7 bezeichnet das Bit höchster Bedeutung,
und Bit 0 bezeichnet die niedrigste Bedeutung. Byte
1:
| Bit | Bedeutung,
wenn gesetzt (= 1) |
| 7 | Schlüssel kann
verwendet werden, um Daten zu schützen |
| 6 | Schlüssel kann
verwendet werden, um Schlüssel
zu schützen |
| 5 | Schlüssel kann
verwendet werden, um zu chiffrieren |
| 4 | Schlüssel kann
verwendet werden, um zu dechiffrieren |
| 3 | Schlüssel kann
verwendet werden für
die Integritäts-Versiegelungs-Generierung |
| 2 | Schlüssel kann
verwendet werden für
die Integritäts-Versiegelungs-Verifizierung |
| 1 | reserviert |
| 0 | fortgesetzt
im nächsten
Byte. |
Byte
2:
| Bit | Bedeutung,
wenn gesetzt (= 1) |
| 7 | Schlüssel kann
verwendet werden, um andere Schlüssel
anzuleiten |
| 6 | abgeleitete
Schlüssel
(falls zulässig)
unterliegen kryptographischen Steueringsvorgängen |
| 5 | dieser
Schlüssel
unterliegt den kryptographischen Steuerungs-Vorgängen |
| 4 | reserviert |
| 3 | reserviert |
| 2 | reserviert |
| 1 | reserviert |
| 0 | reserviert |
-
Ein Schlüssel kann mit einer Kennung
versehen werden, die in der Lage ist, sowohl Daten als auch Schlüssel zu
schützen.
Dies geschieht, um Protokolle zu unterstützen, wenn ein einziger Dialog-Schlüssel verwendet
werden kann, um Anfragen nach Schlüsseln zu schützen und
auch Schlüssel
zu schützen,
die von der KDS zurück
gegeben werden.
-
Wenn das Fortsetzungs-Bit nicht in
dem Kennungs-Byte 1 gesetzt ist, wird das Kennungs-Byte 1 das letzte
(und einzige) Kennungs-Byte sein; andernfalls folgt das Kennungs-Byte
2 dem Kennungs-Byte 1.
-
Wie weiter unten noch beschrieben
wird, werden die Schlüssel
und ihre zugeordneten Kennungen miteinander chiffriert, wenn sie
außerhalb
der gesicherten CSF gesendet werden. Damit sind Benutzer oder Benutzervorgänge nicht
in der Lage, die Einstellungen der Schlüssel-Kennungen zu modifizieren.
Wenn die CSF aufgefordert wird, einen Schlüssel zu verwenden, stellt sie
die Schlüssel-Kennungen
in Rechnung, die dem Schlüssel
zugeordnet sind, z. B. um festzustellen, ob sie berechtigt ist,
den Schlüssel
zu verwenden, um andere Schlüssel
daraus abzuleiten, und ob kryptographische Steuer-Vorgänge ausgeführt werden
müssen,
bevor der Schlüssel
verwendet wird.
-
Kundenbetrieb
-
3 zeigt
die Betriebsweise des Kunden 11, wenn er beabsichtigt,
eine sichere Verbindung mit dem Server 12 aufzubauen.
- (Schritt 31) Der Kunde schickt zuerst eine
Anfrage an den KDS und beantragt einen Grundschlüssel (BK), der mit dem Server
geteilt wird. In Abhängigkeit
von dieser Anfrage gibt der KDS zwei Versionen eines Grundschlüssels an
den Kunden zurück;
die erste verschlüsselt
unter der Schlüssel-Codierungs-Taste (KEK)
des Kunden und die zweite verschlüsselt unter der KEK des Servers.
Der Betrieb des KDS in Abhängigkeit
von diesem Anruf wird im einzelnen weiter unten in Verbindung mit 4 beschrieben.
- (Schritt 32) Der Kunde ruft dann seine eigene CSF 14 an
und beauftragt sie, die Version des Basis-Schlüssels BK, der unter der KEK
des Kunden verschlüsselt
ist, zu importieren. In Abhängigkeit
von diesem Anruf prüft
dier CSF die Markierungen der KEK, um sicher zu stellen, dass die
KEK sowohl für
den Schutz als auch für
das Dechiffrieren des Schlüssels
verwendet werden kann. Angenommen, diese Prüfung ist einwandfrei, entschlüsselt die
CSF den Basis-Schlüssel
und speichert den entschlüsselten
Schlüssel
in seinem Schlüssel-Speicher 21.
Die CSF gibt dann eine Kennung an den Schlüssel zurück und ermöglicht dem Kunden, sich später darauf
zu beziehen.
- (Schritt 33) Der Kunde ruft dann seine CSF 14 an und
beantragt, einen Dialog-Schlüssel für die Vertraulichkeit
aufgrund des Basis-Schlüssels
BK zu generieren. Der Kunde gibt dann einen Anfangswert (eine willkürliche Zahl)
ein, die bei der Generierung des Dialog-Schlüssels verwendet wird. In Abhängigkeit
von diesem Anruf benutzt die CSF den Basis-Schlüssel und den eingespeisten
Anfangswert, um einen Dialog-Schlüssel zu
generieren. Die CSF gibt dann eine Kennung an den Dialog-Schlüssel zusammen
mit einem Dialog-Schlüssel-Paket,
das die Informationen enthält,
die ihm eine weitere Anwendung gestattet, um den gleichen Dialog-Schlüssel aus
dem gleichen Basis-Schlüssel
zu gewinnen. Der Betrieb der CSF in Abhängigkeit von einem Anruf zur
Erzielung eines Dialog-Schlüssels
wird in Verbindung mit 5 näher erläutert.
- (Schritt 34) Der Kunde ruft dann seine CSF an und beauftragt
sie, einen Dialog-Schlüssel für die Integrität aus dem
Basis-Schlüssel
BK zu generieren. Die CSF verwendet wiederum den Basis-Schlüssel und
den eingeführten
Anfangswert zur Generierung eines Dialog-Schlüssels und führt eine Kennung an den Schlüssel und
das Dialog-Schlüssel-Paket
zurück,
das die Informationen enthält,
die eine Gleichrangigkeit des Anrufers ermöglicht, um den gleichen Dialog-Schlüssel zu
gewinnen.
- (Schritt 35) Der Kunde konstruiert dann eine sichere Zuordnungs-Anfrage-Nachricht,
die zwei Dialog-Schlüssel-Pakete
enthält,
die durch die CSF zurückgeführt werden, zusammen
mit der Version des Basis-Schlüssels
BK, der unter der KEK des Servers verschlüsselt ist.
- (Schritt 36) Der Kunde ruft dann seine CSF an, die diese Anfrage-Nachricht
unter dem Basis-Schlüssel
auf Integrität
schützt.
Wenn er diesen Anruf empfängt,
prüft die
CSF die Markierungen des Basis-Schlüssels, um zu verifizieren,
dass der Schlüssel
sowohl für
den Datenschutz als auch die Integritäts-Versiegelungs-Generierung
verwendet werden kann. Wenn diese Prüfung einwandfrei ist, verwendet
die CSF die Funktion 23 der kryptographischen Operationen,
um eine Integritäts-Sicherheit
für die
Nachricht zu generieren.
- (Schritt 37) Der Kunde sendet dann die gesicherte Anfrage an
den Server.
-
Wie in Verbindung mit 6 weiter unten beschrieben
wird, führt
er, wenn der Server diese Anfrage-Nachricht für die sichere Zuordnung empfängt, in ähnlicher
Weise den verschlüsselten
Basis-Schlüssel
BK in seine CSF ein und benutzt ihn und die begleitenden Dialog-Schlüssel-Pakete
zur Ableitung des gleichen Dialog-Schlüssels wie der Kunde. Der Kunde
und der Server können
dann die Dialog-Schlüssel
verwenden, um Nachrichten einander in sicherer Weise zuzusenden.
-
Der Kunde und der Server können so
viele Dialog-Schlüssel
wie gewünscht
zur Verwendung zwischen beiden erstellen, ohne dass sie den KDS
weiter konsultieren müssen.
-
Anfrage nach
KDS für
Basis-Schlüssel
-
4 zeigt
die Betriebsweise des KDS, wenn er eine Anfrage von einem Kunden
für einen
Basis-Schlüssel
zur Verwendung mit einem genannten Server aufnimmt.
- (Schritt 41) Der KDS validiert zuerst die Anfrage. Beispielsweise
kann der KDS den Ursprung der Anfrage auf Gültigkeit prüfen, eine Prüfung auf
Wiederholung vorneh men und eine Datenintegrität der Anfrage prüfen. Wenn
die Anfrage ungültig
ist, weist sie der KDS zurück.
- (Schritt 42) Ist die Anfrage gültig, schlägt der KDS den Datenbank-Eintrag
für den
angefragten Server nach. Dieser enthält die KEK des Servers, die
unter dem Master-Schlüssel MK
des KDS verschlüsselt
ist. Wenn der KDS keinen Eintrag für den Server in der Datenbank
finden kann, wird die Anfrage zurückgewiesen.
- (Schritt 43) Vorausgesetzt, dass ein Eintrag gefunden worden
ist, ruft der KDS seine CSF 16 und beauftragt sie, den
verschlüsselten
KEK des Servers abzurufen. In Abhängigkeit von diesem Anruf verschlüsselt die CSF
die verschlüsselte
KEK, wobei der Master-Schlüssel
MK verwendet wird. Die CSF speichert dann den entschlüsselten
Schlüssel
in seinen Sicherheits-Schlüsselspeicher 21 und
gibt eine Kennung an den Schlüssel
zurück.
- (Schritt 44) Der KDS schlägt
dann den Datenbank-Eintrag für
den Kunden nach, um die KEK des Kunden zu ermitteln, die unter dem
Master-Schlüssel
MK des KDS verschlüsselt
ist.
- (Schritt 45) Der KDS ruft dann seine CSF 16 auf und
gibt den Befehl, die verschlüsselte
KEK einzuführen. Wie
vorher entschlüsselt
die CSF die verschlüsselte
KEK unter Verwendung des Master-Schlüssels MK, speichert sie in
dem Sicherheitsschlüssel-Speicher und gibt
eine Kennung an den Schlüssel
zurück.
Der KDS prüft
ferner, ob der Kunde als Teil der Sicherheits-Infrastruktur bekannt
ist.
- (Schritt 46) Der KDS ruft dann seine CSF 16 auf, um
einen Basis-Schlüssel
BK zu generieren, wobei festgelegt wird, dass die Kennungswerte
für den
Basis-Schlüssel
wie folgt eingestellt werden:
- – Datenschutz
- – Generierung/Verifizierung
der Integritätsversiegelung
- – Schlüssel kann
verwendet werden, um andere Schlüssel
abzuleiten
- – abgeleitete
Schlüssel
unterliegen kryptographischen Steuerungsvorgaben (wenn der Kunde
nicht Teil der Infrastruktur ist).
In Abhängigkeit von diesem Anruf generiert
die CSF den gewünschten
Basis-Schlüssel
mit der erforderlichen Kennung.
- (Schritt 47) Der KDS ruft dann seine CSF 16 und beantragt
die Ausführung
des Basis-Schlüssels BK
unter dem Schutz der KEK des Kunden. In Abhängigkeit von diesem Anruf verschlüsselt die
CSF den Basis-Schlüssel-Wert
zusammen mit der Schlüsselkennung
und anderen Steuerinformationen (z. B. der Lebensdauer eines Schlüssels),
wobei der KEK des Kunden verwendet wird. Die CSF führt dann
den geheimen Schlüssel
an den KDS zurück.
- (Schritt 48) Der KDS ruft dann seine CSF 16 auf und
beauftragt sie, den Basis-Schlüssel BK
unter dem Schutz der Server-KEK zu exportieren. In Abhängigkeit
von diesem Anruf verschlüsselt
die CSF den Basis-Schlüssel-Wert
zusammen mit den Schlüssel-Kennungen
und anderen Steuerinformtionen (z. B. den Schlüssel-Lebensdauern), wobei die KEK des Servers
verwendet wird. Die CSF führt
dann den geheimen Schlüssel
in den KDS zurück.
- (Schritt 49) Schließlich
führt der
KDS die beiden verschlüsselten
Versionen des Basis-Schlüssels BK
an den Kunden zurück.
-
Dialog-Schlüssel-Generierung
-
5 zeigt
die Betriebsweise einer CSF, wenn sie einen Anruf empfängt, der
die Generierung eines Dialog-Schlüssels anfragt. Der Anruf umfasst
die Kennung des Basis-Schlüssels BK
und schließt
auch mit ein, dass ein Anfangswert in der Schlüssel-Generierung verwendet wird.
- (Schritt 51) Die CSF greift zunächst den Basis-Schlüssel BK
im Schlüsselspeicher 21 zu
und prüft,
dass dieser Schlüssel
das Bit 7 des Kennungs-Bytes 2 gesetzt hat, wodurch angezeigt wird,
dass dieser Schlüssel
zur Ableitung weiterer Schlüssel
verwendet werden kann. Wenn dieses Kennungsbit nicht gesetzt ist, wird
die Anfrage zurückgewiesen.
- (Schritt 52) Die CSF prüft
dann, ob der Basis-Schlüssel
BK Bit des Kennungs-Bytes 2 gesetzt hat, wodurch angezeigt
wird, dass beliebige abgeleitete Schlüssel kryptographischen Steuerungsvorgaben
unterliegen. Wenn das Kennungs-Bit gesetzt ist, fährt die
CSF mit dem nachstehenden Schritt 53 fort; ist dies nicht der Fall,
geht die CSF auf den Schritt 56 über.
- (Schritt 53) Wenn die Kennung angibt, dass abgeleitete Schlüssel kryptographischen
Steuerungsvorgaben unterliegen, schlägt die CSF die kryptographischen
Steuerungsvorgaben nach, die für
den beabsichtigten Algorithmus und die Verwendung Gültigkeit
haben.
- (Schritt 54) Die CSF erzeugt dann einen dialogen Schlüssel-Wert
durch Aufgeben einer Einweg-Funktion OWF an den Basis-Schlüssel BK
und den Anfangswert. Die CSF wendet die kryptographischen Steuerungsvorgaben
an, um sicher zu stellen, dass der generierte Schlüssel diesen
Vorgaben unterliegt. Wenn der Algorithmus DES ist und der beabsichtigte
Zweck vertraulich ist, gibt die CSF beispielsweise die Commercial
Data Masking Facility, auf die weiter oben hingewiesen worden ist,
an den generierten DES-Schlüssel-Wert,
um einen abgeschwächten
Schlüssel-Wert
zu erzeugen.
- (Schritt 55) Die CSF setzt die Kennwerte des Dialog-Schlüssels wie
folgt:
- – Verschlüsseln/Entschlüsseln (wenn
Vertraulichkeit gefordert wird und kryptographische Steuerungsvorgaben
dies ermöglichen – z. B.
kann RSA für
die Integrität,
jedoch nicht für
die Vertraulichkeit verwendet werden)
- – Integritäts-Generierung/Verifizierung
(wenn die Integrität
gefordert wird und kryptographische Steuerungsvorgaben dies ermöglichen)
- – Schlüssel entsprechend
kryptographischen Steuerungsvorgaben ermöglichen, dass andere Betriebssteuerungen
angewendet werden, z. B. bestimmte verbotene Betriebsweisen einer
Chiffre).
- (Schritt 56) Wenn die Kennung angibt, dass abgeleitete Schlüssel nicht
bestimmten kryptographischen Steuerungsvorgaben unterworfen sind,
generiert die CSF einen Dialog-Schlüssel-Wert, indem die OWF dem
Basis-Schlüssel
BK und dem Anfangs-Wert aufgegeben wird.
- (Schritt 57) Die CSF setzt die Kennungs-Werte des Dialog-Schlüssels wie
folgt:
- – Datenschutz
- – Verschlüsseln/Entschlüsseln (wenn
Vertraulichkeit gefordert wird)
- – Generieren/Verifizieren
der Integrität
(wenn Integrität
gefordert wird).
- (Schritt 58) Die CSF speichert den Dialog-Schlüssel im
Schlüsselspeicher 21 zusammen
mit ihrer Kennung.
- (Schritt 59) Schließlich
führt die
CSF eine Handhabung an den Dialog-Schlüssel zum Anrufer zusammen mit
einem Dialog-Schlüssel-Paket
zurück,
das die Informationen enthält,
die einen mit dem Anrufer Gleichberechtigten ermöglichen, den gleichen Dialog-Schlüssel aus
dem gleichen Basis-Schlüssel
BK zu gewinnen. Dieses Paket unfaßt die Identität des OWF
und des Anfangs-Wertes, die zum Generieren des Basis-Schlüssels verwendet
werden.
-
Server-Betriebsweise
-
6 zeigt
die Betriebsweise des Servers, wenn er die Nachricht über die
Sicherheitszuordnungs-Anfrage-Nachricht von dem Kunden erhält.
- (Schritt 61) Der Server ruft zuerst seine eigene
CSF 15 auf, um die Integrität der Sicherheitsbeziehungs-Anfrage-Nachricht
zu prüfen.
Die CSF prüft
ferner die Kennungen des Basis-Schlüssels BK, um sicher zu stellen,
dass sie für
die Verifizierung des Datenschutzes als auch für die Integritäts-Versiegelung
verwendet werden kann. Wenn diese Prüfung negativ ist, wird die
Anfrage zurückgewiesen.
- (Schritt 62) Vorausgesetzt, dass die Prüfung einwandfrei ist, ruft
der Server dann seine CSF 15 auf und fordert sie auf, die
Version des Basis-Schlüssels
BK, die unter dem Server-KEK verschlüsselt ist, einzuführen. Die
CSF prüft
die Kennungen dieser KEK, um zu verifizieren, dass sie sowohl für den Schlüsselschutz
als auch für
die Entschlüsselung
verwendet werden kann. Nimmt man an, dass diese Prüfung einwandfrei
ist, verschlüsselt
die CSF den Basis-Schlüssel,
speichert ihn und führt
eine Kennung an den Schlüssel
zurück, so
dass ermöglicht
wird, dass der Kunde darauf Bezug nimmt.
- (Schritt 63) Der Server ruft dann seine CSF 15 auf
und beauftragt sie, Dialog-Schlüssel
für die
Vertraulichkeit und die Integrität
aus dem Basis-Schlüssel
BK und den Dialog-Schlüssel-Packungen
zu generieren.
-
Dialog-Schlüssel-Verwendung
-
Nachdem diese Dialog-Schlüssel erstellt
worden sind, können
die Kunden- und Server-Anwendungen ihre
entsprechenden CSFs aufrufen, um diesen Schlüssel zum Verschlüsseln, Entschlüsseln, Integritäts-Versiegelungs-Generieren
und Integritäts-Versiegelungs-Verifizieren
zu verwenden.
-
7 zeigt
die Betriebsweise einer CSF, wenn sie durch eine Anwendung für das Verschlüsseln von Daten
angerufen worden ist. Der Anruf schließt mit ein, dass die zu verschlüsselnden
Daten zusammen mit der Kennung des Dialog-Schlüssels verwendet werden.
- (Schritt 71) Die CSF findet zuerst den Dialog-Schlüssel aus
dem Sicherheits-Schlüsselspeicher 21 auf,
wobei die Kennung zur Ermittlung des Schlüssels verwendet wird.
- (Schritt 72) Die CSF prüft
dann die Schlüssel-Kennungen
des Dialog-Schlüssels,
um zu verifizieren, ob sie zum Schutz der Daten verwendet werden
können
und ob sie zum Verschlüsseln
verwendet werden können. Wenn
der Schlüssel
diese Prüfungen
nicht besteht, wird die Anfrage zurückgewiesen.
- (Schritt 73) Vorausgesetzt, dass die Prüfungen einwandfrei sind, prüft die CSF,
ob das Bit 5 des Kennungs-Bytes 2 gesetzt ist, wodurch angezeigt
wird, dass dieser Schlüssel
der kryptographischen Steuerungsvorgabe unterliegt.
- (Schritt 74) Wenn der Schlüssel
kryptographischen Steuermethoden unterliegt, schlägt die CSF
kryptographische Steuervorgaben nach, die für den beabsichtigten Algorithmus
und die Verwendung gelten und erzwingt diese Vorgaben. Beispielsweise
kann dies umfassen, dass bestimmte Betriebsarten einer Verschlüsselung
verboten sind, z. B. Dreifach-Verschlüsselungsarten.
- (Schritt 75) Schließlich
verschlüsselt
die CSF die Daten und führt
die verschlüsselten
Daten an den Anrufer zurück.
-
Ähnliche
Maßnahmen
werden von der CSF durchgeführt,
um kryptographische Steuerungsvorgaben für das Entschlüsseln, das
Generieren von Integritäts-Versiegelungen
und das Verifizieren von Integritäts-Versiegelungen zu erzwingen.
-
Direkte generierte
Schlüssel
-
Die vorstehende Beschreibung führt aus,
wie die CSFs die Anwendung von kryptographischen Steuerungsvorgaben
auf Dialog-Schlüssel
vornehmen, die von zwei Gleichrangigen aus Basis-Schlüsseln abgeleitet
werden, die von dem Schlüssel-Verteilungs-Service (KDS) generiert
werden. Die CSFs sind ferner nicht in der Lage, die Anwendung von
kryptographischen Steuerungsvorgaben auf Schlüssel zu verstärken, die
di rekt generiert werden (z. B. generiert werden durch Anwendungen,
die verschieden von denen des KDS sind), wie nachstehend beschrieben
wird.
-
Der Standardvorgang einer CSF besteht
darin, kryptographische Steuerungsvorgaben an alle Schlüssel zu
geben, die generiert oder abgeleitet werden, wenn sie nicht durch
den KDS übersteuert
werden. Im Falle von abgeleiteten Schlüsseln steuert die Kennung des
Basis-Schlüssels
(generiert durch den KDS), ob die abgeleiteten Dialog-Schlüssel kryptographischen
Steuerungsvorgaben unterliegen. Im Falle von Schlüsseln, die durch
Anwendungen generiert werden, werden diese kryptographischen Steuerungsvorgaben
unterzogen. In manchen Fällen
kann es erforderlich sein, dass direkte Schlüssel-Generier-Eigenschaften für Anwendungsfälle nicht
verfügbar
sind, so dass die Schlüssel-Ableitung
die einzige Möglichkeit
darstellt.
-
Es ist festzuhalten, dass unter dem
vorbeschriebenen Schema ein abgeleiteter Schlüssel eine solche Kennung erhält, dass
er nicht selbst verwendet werden kann, um andere Schlüssel abzuleiten.
Wenn eine direkte Schlüssel-Generierung
für Anwendungen
nicht verfügbar
ist, können
Schlüssel
somit nur aus einem Basis-Schlüssel
abgeleitet werden, der durch die KDS generiert wird.
-
Der KDS besitzt eine spezielle Version
der Direkt-Schlüssel-Generierungs-Schnittstelle
zur CSF, die es ermöglicht,
dass der KDS die Einstellungen der Schlüssel-Kennungen auf Folgendes
richtet:
- – ob
Schlüssel
von dem Schlüssel
abgeleitet werden können,
- – ob
abgeleitete Schlüssel
kryptographischen Steuerungsvorgaben unterliegen,
- – ob
der Schlüssel
kryptographischen Steuervorgaben unterzogen ist,
- – ob
eine Schlüssel-Kennung
nicht aufgegeben werden soll.
-
Dies ermöglicht dem KDS, Schlüssel zu
erzeugen, die nicht kryptographischen Steuerungsvorgaben zur Verwendung
durch die Sicherheits-Infrastruktur ausgesetzt sind. Dies ermöglicht dem
KDS ferner, Schlüssel
ohne Kennung zur Verwendung bei externen Systemen zu generieren,
z. B. Kerberos, DCE und SESAME, die Schlüssel mit Ken nung nicht unterstützen und
die somit die Schlüssel-Kennungen
fehlerhaft als Teil des Schlüssel-Wertes
interpretieren würden.
-
Im Fall von Kerberos und DCE kann
der KDS auch fordern, dass die CSF kryptographische Steuerungsvorgaben
einem generierten Dialog-Schlüssel
aufgibt, um die private Einstufung von Benutzerdaten zu schwächen, die
zwischen einem Kerberos- oder DCE-Kunden und Server kommunizieren (da
diese den KDS eines exportkontrollierten Produktes benutzen). Dies
trifft nicht zu für
SESAME, da ein Basis-Schlüssel
generiert wird, aus dem Dialog-Schlüssel abgeleitet werden, und
zwar extern zu dem exportkontrollierten Produkt. Der KDS würde somit
eine Abbildung einer Target-Anwendung auf eine Sicherheitssystem-Type
benötigen,
um zu erfahren, ob die Target-Anwendung Schlüssel mit Kennung verstehen
würde.
-
Es sind eine Vielzahl anderer Modifikationen
möglich,
die bei dem vorbeschriebenen System angewendet werden können, ohne
dass vom Wesen der Erfindung abgewichen wird.