-
GEBIET DER ERFINDUNG
-
Die
Erfindung bezieht sich im Allgemeinen auf Datensicherheit und im
Besonderen auf ein Verfahren, System und Speichermedium zur Vermeidung
der Kennwortoffenlegung bei der Anforderung von Attributzertifikaten
Dritter.
-
HINTERGRUND DER ERFINDUNG
-
Attributzertifikate
(Attribute Certificates, ACs) und Zertifikate für öffentliche Schlüssel (Public
Key Certificates, PKCs) dienen zum Schutz vor dem Zugriff auf elektronische
Daten und können
in einer Vielfalt von Anwendungen eingesetzt werden, die eine verteilte
Sicherheit wie beispielsweise Internet-Nachrichten-, IPSec- und
Web-Anwendungen
erfordern. Obwohl diese Zertifikate ähnlich aufgebaut sind, besteht
ein wesentlicher Unterschied zwischen ihnen darin, dass ein AC keinen öffentlichen
Schlüssel
beinhaltet; vielmehr beinhaltet er in der Regel die Identität bzw. den
Subjektnamen eines PKC. Die Aufgabe eines AC besteht darin, eine
Gruppe von Berechtigungsmerkmalen (z. B. Gruppenmitgliedschaft,
Funktion, Sicherheitsstufe usw.) mit Blick auf den AC-Inhaber zu
zertifizieren (d. h., auf sichere Art und Weise mit ihm zu verknüpfen), während ein PKC
einen öffentlichen
Schlüssel
mit dem PKC-Inhaber verknüpft.
Diese Berechtigungsdaten können
entweder in eine PKC-Erweiterung oder in das AC gestellt werden;
allerdings empfiehlt es sich im Allgemeinen nicht, die Berechtigungsdaten
in das PKC zu stellen, da sie üblicherweise
eine kürzere
Lebensdauer aufweisen als der öffentliche
Schlüssel,
der jahrelang gültig
sein kann. Wenn sich die Berechtigungsdaten daher ändern, ist das
PKC nicht mehr gültig.
Wenn der PKC-Ausgebende und das Unternehmen für die Berechtigungsprüfung zwei
unterschiedliche Einheiten darstellen, müsste außerdem der PKC-Ausgebende die
Genehmigung dieses Unternehmens einholen, bevor er die Berechtigungsdaten
in das PKC aufnehmen könnte,
was eine unwirtschaftliche Vorgehensweise wäre.
-
Wenn
auf Grundlage eines AC eine Entscheidung über die Zugriffskontrolle getroffen
wird, kann eine Überprüfungsprozedur
erforderlich sein, um sicherzustellen, dass der betreffende AC-Inhaber
die Einheit ist, die den Zugriff angefordert hat. Diese Überprüfung kann
realisiert werden, indem eine Verknüpfung mit einem PKC hergestellt
wird, der dem AC entspricht, und ein dem PKC zugehöriger privater
Schlüssel
verwendet wird, um die Überprüfung der
Identität
durchzuführen.
1 zeigt
ein Blockschaubild eines X.509-AC
102, der über einen
Inhaber
104 des AC
102 mit einem entsprechenden
X.509-PKC
106 verknüpft
ist. Dabei ist X.509 ein Standard, der auf Empfehlung der International
Telecommunication Union (ITU), einer regierungsübergreifenden Organisation
für die
Entwicklung von Telekommunikationstechnologien, für die Definition
digitaler Zertifikate und Attributzertifikate verwendet wird. In
dem AC
102 wird ein vertrauenswürdiger Pfad
110 hergestellt, indem
anhand einer Prozedur für
die Gültigkeitsprüfung der
Inhaber
104 des AC
102 zu dem zugehörigen PKC
106 zurückverfolgt
wird. Ein Attribut des AC
102 ist das Attribut
108 der Dienstechtheitsüberprüfungsdaten, das
durch folgende ASN.1-Syntax
definiert ist:
-
Das
Attribut 108 der Dienstechtheitsüberprüfungsdaten wird dazu verwendet,
einen Zielsystemnamen (service) mit Echtheitsüberprüfungsdaten wie z. B. die einer
Identität
(ident) und einem Berechtigungsnachweis (authInfo) zu bündeln. Bei
einer herkömmlichen
Anwendung kann die Identität
ein Benutzername und der Berechtigungsnachweis ein Kennwort sein.
Ein Zieldienst/Zielsystem kann die Überprüfung der Identität des AC-Inhabers
vornehmen, sobald es das Zertifikat 102 als Ergebnis eines
wie auch immer gearbeiteten Typs von Sicherheitsprotokoll zwischen
dem Benutzer und dem Zieldienst erhalten hat. Ein derartiges Sicherheitsprotokoll
(z. B. SSL oder sein Nachfolger TLS) legt den Benutzer als Inhaber
des PKC fest. Um die sensiblen Daten bei der Erzeugung des AC zu
schützen,
können
die Berechtigungsnachweisdaten des Benutzers (d. h. SvceAuthInfo)
unter Verwendung des öffentlichen
Schlüssels
des Zieldienstes verschlüsselt
werden. Gemäß den in
RFC3281 genannten Empfehlungen werden die Berechtigungsnachweisdaten
durch den AC-Ausgebende verschlüsselt
und in ein anderes Attribut mit der Bezeichnung encAttrs gestellt,
bevor sie in das AC aufgenommen werden.
-
Neben
den Berechtigungsnachweisdaten enthalten die verschlüsselten
Daten auch den Namen des AC-Ausgebenden und die laufende Nummer
des AC. Diese zusätzlichen
Daten verknüpfen
die Berechtigungsnachweisdaten auf eindeutige Art und Weise mit
dem sie enthaltenden AC. Bei der Überprüfung des AC kann das Zielsystem
somit überprüfen, ob
die Berechtigungsnachweisdaten echt sind und nicht im Rahmen eines Replay-Angriffs
(d. h. eines Angriffs durch Replizieren einer aufgezeichneten Zugangsprozedur)
von einem anderen AC gestohlen wurden.
-
Die
obige Lösung
hat die folgenden beiden Nachteile: (1) Es kann zu einer Offenlegung
des Kennworts kommen, wenn der AC-Ausgebende ein Dritter ist; und (2)
bei einer Änderung
des Kennworts wird das AC unbenutzbar. Mit Blick auf den ersten
Nachteil erzwingt die obige Lösung,
dass AC-Ausgebende und Zieldienst/-system identisch sind. Wenn der
AC-Ausgebende ein Dritter ohne Zugriff auf die Berechtigungsnachweisdatenbank
des Zieldienstes/-systems ist, muss der AC-Anforderer dem AC-Ausgebenden das Klartextkennwort
vorlegen, wenn er das AC anfordert, wodurch das Kennwort möglicherweise
gegenüber
einem nicht vertrauenswürdigen
Dritten offengelegt wird. Die Berechtigungsnachweisdaten können durch
den Anforderer vor der Anforderung des AC nicht vorab verschlüsselt werden,
da normalerweise weder der Anforderer noch das Zielsystem die laufende
Nummer eines noch auszugebenden Zertifikats kennen, während für den AC-Ausgebenden
wiederum keine Notwendigkeit bestehen sollte, das Kennwort zu kennen.
Mit Blick auf den zweiten Nachteil kann das AC bei einer Änderung
des Kennworts für
den Anforderer oder das Zielsystem nicht mehr verwendet werden,
da das Kennwort des Anforderers (in verschlüsselter Form) im AC enthalten
ist. Genauer betrachtet, eine wie auch immer geartete Verwendung
des AC kann nach einer Kennwortänderung
als Einbruchsversuch erscheinen.
-
Die
US-Patentanmeldung Nr. 2002/0144108 A1 beschreibt einen Identitätsüberprüfungsprozess
nach dem Stand der Technik, bei dem eine Hostanwendung innerhalb
eines verteilten Datenverarbeitungssystems eine oder mehrere kontrollierte
Ressourcen unterstützt,
die Identitätsüberprüfungsdaten
empfangen müssen, bevor
sie einem Benutzer den Zugriff auf die kontrollierte Ressource gestatten.
-
ZUSAMMENFASSUNG DER ERFINDUNG
-
Die
oben erwähnten
sowie weitere Nachteile und Unzulänglichkeiten des Stands der
Technik werden mit einem Verfahren, System und Speichermedium behoben
bzw. abgemildert, mit dem ein Besitznachweis zur Einfügung in
ein Attributzertifikat durch eine Einheit für die Attributzertifikatvergabestelle
erzeugt wird, wobei das Attributzertifikat für die Verwendung durch einen
Endnutzer vorgesehen ist. Das Verfahren beinhaltet das Empfangen
einer Vielzahl von Datenfeldern, die einem Zielsystem, der Identität des Endnutzers
und einem Identitätsnachweis
durch den Endnutzer entsprechen, von der Einheit für die Attributzertifikatvergabestelle
als Reaktion auf eine Anforderung durch den Endnutzer. Das Verfahren
beinhaltet weiter das Vorbereiten einer Datenstruktur, die einem
Berechtigungsattribut des Attributzertifikats entspricht, wobei
die Datenstruktur einen Zielsystemnamen, die Identität des Endnutzers
und den Schlüsselbezeichner
des Endnutzers beinhaltet. Das Verfahren beinhaltet das Unterzeichnen
der Datenstruktur unter Verwendung eines privaten Schlüssels, der dem
Zielsystem zugehörig
ist, wodurch sich ein Besitznachweis ergibt, und das Senden des
Besitznachweises an die Einheit für die Attributzertifikatvergabe,
um ihn in das Attributzertifikat aufzunehmen.
-
Weitere
beispielhafte Ausführungsformen
beinhalten ein Computerdatensignal für das Erzeugen eines Besitznachweises
zur Einfügung
in ein Attributzertifikat durch eine die Attributzertifikatvergabestelle,
wobei das Attributzertifikat für
die Verwendung durch einen Endnutzer vorgesehen ist. Das Computerdatensignal
umfasst Code, der so konfiguriert ist, dass er einen Prozessor zur
Ausführung
eines Verfahrens veranlasst. Das Verfahren beinhaltet das Empfangen
einer Vielzahl von Datenfeldern, die einem Zielsystem, der Identität des Endnutzers
und einem Identitätsnachweis
durch den Endnutzer entsprechen, von der Einheit für die Attributzertifikatvergabe
als Reaktion auf eine Anforderung durch den Endnutzer. Das Verfahren
beinhaltet ferner das Vorbereiten einer Datenstruktur, die einem
Berechtigungsattribut des Attributzertifikats entspricht, wobei
die Datenstruktur einen Zielsystemnamen, die Identität des Endnutzers
und den Schlüsselbezeichner
des Endnutzers beinhaltet. Das Verfahren beinhaltet das Unterzeichnen
der Datenstruktur unter Verwendung eines privaten Schlüssels, der
dem Zielsystem zugehörig
ist, wodurch sich ein Besitznachweis ergibt, und das Senden des
Besitznachweises an die Einheit für die Attributzertifikatvergabestelle,
um ihn in das Attributzertifikat aufzunehmen.
-
Weitere
beispielhafte Ausführungsformen
beinhalten ein Speichermedium, das mit maschinenlesbarem Programmcode
codiert ist, um einen Besitznachweis zur Einfügung in ein Attributzertifikat
durch eine Attributzertifikatvergabestelle zu erzeugen, wobei das
Attributzertifikat für
die Verwendung durch einen Endnutzer vorgesehen ist. Der Programmcode
beinhaltet Befehle, mit denen ein Computer zur Ausführung des
Verfahrens veranlasst wird. Das Verfahren beinhaltet das Empfangen
einer Vielzahl von Datenfeldern, die einem Zielsystem, der Identität des Endnutzers
und einem Identitätsnachweis
durch den Benutzer entsprechen, von der Attributzertifikatvergabestelle
als Reaktion auf eine Anforderung durch den Endnutzer. Das Verfahren
beinhaltet ferner das Vorbereiten einer Datenstruktur, die einem
Berechtigungsattribut des Attributzertifikats entspricht, wobei
die Datenstruktur einen Zielsystemnamen, die Identität des Endnutzers
und den Schlüsselbezeichner
des Endnutzers beinhaltet. Das Verfahren beinhaltet das Unterzeichnen
der Datenstruktur unter Verwendung eines privaten Schlüssels, der
dem Zielsystem zugehörig
ist, wodurch sich ein Besitznachweis ergibt, und das Senden des
Besitznachweises an die Attributzertifikatvergabestelle, um ihn
in das Attributzertifikat aufzunehmen.
-
KURZE BESCHREIBUNG DER ZEICHNUNGEN
-
Im
Folgenden werden bevorzugte Ausführungsformen
der vorliegenden Erfindung ausführlich
beschrieben, wobei dies lediglich beispielhaften Charakter haben
und auf die folgenden Zeichnungen Bezug genommen wird:
-
1 zeigt
repräsentative
Zeichnungen eines Attributzertifikats und eines zugehörigen PKI-Zertifikats;
-
2 ist ein Blockschaubild, das die Beziehung
zwischen Einheiten zeigt, die in beispielhaften Ausführungsformen
der Erfindung an der Erzeugung und Verarbeitung eines Attributzertifikats
beteiligt sind;
-
3 ist ein Ablaufdiagramm, das ein Verfahren
für die
Verarbeitung einer AC-Anforderung gemäß einer ersten Ausführungsform
der Erfindung zeigt, bei dem eine Attributvergabestelle als hochgradig
vertrauenswürdig
eingestuft wird und ein Zielsystem verfügbar ist, um das Kennwort zum
Zeitpunkt der AC-Anforderung zu bestätigen;
-
4 ist ein Ablaufdiagramm, das ein Verfahren
für die
Verarbeitung einer Dienstanforderung gemäß der in 3 beschriebenen
Ausführungsform
zeigt;
-
5 ist ein Ablaufdiagramm, das ein Verfahren
für die
Verarbeitung einer AC-Anforderung gemäß einer zweiten Ausführungsform
der Erfindung zeigt, bei dem eine Attributvergabestelle als halb
vertrauenswürdig
eingestuft wird und zum Zeitpunkt der AC-Anforderung kein Zielsystem
verfügbar
ist;
-
6 ist ein Ablaufdiagramm, das ein Verfahren
für die
Verarbeitung einer Dienstanforderung gemäß der in 5 beschriebenen
Ausführungsform
zeigt;
-
7 ist ein Ablaufdiagramm, das ein Verfahren
für das
Auslösen
einer AC-Erweiterung durch ein Zielsystem gemäß der in 5 beschriebenen
Ausführungsform
zeigt; und
-
8 ist ein Ablaufdiagramm, das ein Verfahren
für das
Auslösen
einer asynchronen AC-Erweiterung durch ein Zielsystem gemäß der in 5 beschriebenen Ausführungsform zeigt.
-
AUSFÜHRLICHE BESCHREIBUNG DER BEVORZUGTEN
AUSFÜHRUNGSFORMEN
-
Mit
Blick auf 2 wird zunächst ein
Systemschaubild gezeigt, das die Beziehung zwischen Einheiten darstellt,
die an der Ausgabe eines AC sowie an damit zusammenhängenden
Dienstanforderungen beteiligt sind. Ein Endnutzer-Clientsystem 202 (auch
als „Endnutzer", „Nutzer" oder „Schlüsselinhaber" bezeichnet) verfügt über ein
PKC 106 (1), das von einer (nicht abgebildeten)
Zertifikatvergabestelle (Certificate Authority, CA) ausgegeben wird.
Der Endnutzer 202 fordert von einer Attributzertifikatvergabestelle
(Attribute Certificate Authority, AA) 204 die Vergabe eines
AC 102 (1) an. Der Endnutzer 202 fordert
außerdem
Dienste (Anwendungen, Daten usw.) vom Zielsystem 208 an.
Das hier beschriebene Zielsystem 208 muss weder eine einzelne
Maschine noch eine Gruppe von Maschinen mit einer einzigen Netzwerkschnittstelle
sein. Vielmehr wird davon ausgegangen, dass das Zielsystem 208 über die
Fähigkeit
verfügt,
für einen
Teil eines oder die Gesamtheit eines bedeutenden Teilsatzes von
Endnutzern Berechtigungsnachweise für die Überprüfung der Echtheit nichtöffentlicher
Schlüssel
mit Knoten innerhalb des Systems aus 2 gemeinsam
zu nutzen. Das Zielsystem 208 wird in RFC3281 4.4.1 definiert.
Bei beispielhaften Ausführungsformen
erfolgt die Gültigkeitsprüfung des
AC gemäß den Bestimmungen
aus RFC3281 4.4.1, die durch Bezugnahme in ihrer Gesamtheit als
Bestandteil dieser Patentanmeldung gelten. Das Zielsystem 208 und
die AA 204 können
Teil eines einzigen Unternehmenssystems sein, wobei die AA 204 vom
Zielsystem 208 als hochgradig vertrauenswürdige Einheit eingestuft
wird. Alternativ kann die AA auch ein externes Fremdsystem sein,
das vom Zielsystem 208 als halb vertrauenswürdig eingestuft
wird.
-
Der
Endnutzer 202, die AA 204 und das Zielsystem 208 können über ein
oder mehrere Netzwerke (z. B. das Netzwerk 210) miteinander
Daten austauschen. Das Netzwerk 210 kann eine beliebige
Art eines bekannten Netzwerks sein, uneingeschränkt einschließlich eines
weiträumigen
Netzes (WAN), eines lokalen Netzes (LAN), eines globalen Netzes
(z. B. das Internet), eines virtuellen privaten Netzes (VPN) und
eines Intranet. Das Netzwerk 210 kann unter Verwendung
eines Funknetzwerks oder einer beliebigen anderen, auf dem Fachgebiet
bekannten Art von physischer Netzwerkrealisierung realisiert sein.
Ein Endnutzer 202 kann über mehrere
Netzwerke (z. B. Intranet und Internet) mit dem Zielsystem 208 verbunden
sind, so dass nicht alle Endnutzer über ein und dasselbe Netzwerk
mit dem Zielsystem 208 verbunden sind. Ein oder mehrere
Endnutzer und das Zielsystem 208 können per Funk mit dem Netzwerk 210 verbunden
sein.
-
Die
AA
204 verarbeitet AC-Anforderungen gemäß beispielhaften Ausführungsformen
der Erfindung unter Verwendung eines authInfo-Felds des Berechtigungsattributs
108 aus
1.
Das authInfo-Feld ist – wie in
RFC3281 beschrieben – eine
optionale ACHT-BIT-ZEICHENFOLGE, die das Klartextkennwort eines
Inhabers enthält.
Die beiden oben genannten Nachteile können einzeln und in einigen
Fällen
auch gemeinsam behoben werden, indem die Verwendung des authInfo-Felds
erweitert wird. So kann die ACHT-BIT-ZEICHENFOLGE von authInfo wie
folgt codiert werden:
-
sealedPOP
oder „sealed
proof of possession" (versiegelter
Besitznachweis) ist ein Mechanismus, mit dem das Zielsystem 208 vor
einem Replay-Angriff eines Betrügers
geschützt
wird. Dabei wird das Kennwort (oder ein anderweitiger Identitätsnachweis)
des Anforderers verschlüsselt
oder in eine sealedPOP-Struktur eingebettet. Die sealedPOP-Struktur
beinhaltet auch die Verschlüsselung
des Schlüsselbezeichners
(keyId) der subjectPublicKey-Zeichenfolge (berechnet als Extrakt
des Werts der subjectPublikKey-Zeichenfolge in dem Zertifikat, auf
welches das Inhaberfeld 104 der Zertifikatanforderung 102 verweist)
sowie verschiedene Füllzeichen.
sealedPOP wird vorbereitet, indem mit den folgenden Schritten zunächst eine
clearSealedPOP-Struktur erzeugt wird:
- (1) Setzen
des Kennwortfelds auf das tatsächliche
Kennwort des Endnutzers für
die Anmeldung beim Zielsystem oder auf eine andere Art von Identitätsnachweis,
die vom Zielsystem überprüft werden
kann (z. B. ein „Etikett");
- (2) Suchen des Zertifikats für öffentliche
Schlüssel,
auf das durch die Zertifikatanforderung verwiesen wird;
- (3) Suchen der subjectPublicKey-Zeichenfolge des Zertifikats
für öffentliche
Schlüssel;
- (4) Berechnen des Schlüsselbezeichners
dieser subjectPublicKey-Zeichenfolge als SHA-1-Extrakt des Werts
der subjectPublicKey-Zeichenfolge; und
- (5) Erzeugen eines Stroms von zufälligen Bytes binärer Daten
und Zuweisen dieser Bytes zum Füllzeichenfeld.
-
Die
Syntax der clearSealedPOP-Struktur lautet folgendermaßen:
-
Nachdem
die clearSealedPOP-Struktur vorbereitet wurde, wird die sealedPOP-Struktur
erzeugt, indem clearSealedPOP unter Verwendung des öffentlichen
Schlüssels
des Zielsystems verschlüsselt
wird. Auch hier kann die Verschlüsselung
asymmetrisch erfolgen und so eine sealedPOP-Struktur ergeben. Wenn
sie symmetrisch (d. h. eingebettet) im PRCS-#7- oder im CMS-Format
(Cryptographic Message Syntax, Syntax kryptografischer Meldungen)
erfolgt, so dass der verschlüsselte
symmetrische Schlüssel
nur durch den Host gelesen werden kann, besteht das Ergebnis in
einer longSealedPOP-Struktur. In beiden Fällen wird der versiegelte Besitznachweis
im Rahmen der Zertifizierungsanforderung an die AA 204 gesendet.
Die sealedPOP-Struktur kann dann als Ergebnis der Anforderung, wie
weiter unten ausführlicher
beschrieben, in das AC aufgenommen werden. Diese sealedPOP-, longSealedPOP- und clearSealedPOP-Strukturen
werden in der US-Patentanmeldung Nr. 2003/0009662A1 beschrieben,
die am 09. Januar 2003 unter dem Titel „Password Exposure Elimination
for Digital Signature Coupling With A Host Identity" veröffentlicht
wurde.
-
Die
Codierung der SvcAuthInfo-Struktur wird durch ein Zielsystem unterzeichnet,
um so die obige aCPOPConfirmation-Struktur zu erzeugen, und lautet wie
folgt:
-
Mit
Bezug auf 3 wird nun ein Prozess für die Erzeugung
eines AC beschrieben, wobei die AA 204 hochgradig vertrauenswürdig ist
und das Zielsystem 208 zum Zeitpunkt der AC-Anforderung
für die
Kennwortbestätigung
verfügbar
ist. Der in 3 beschriebene Prozess
geht davon aus, dass die AA 204 Bestandteil eines vertrauenswürdigen Teilsystems
(Trusted Computing Base, TCB) des Zielsystems 208 ist.
Dabei fordern Nutzer des Zielsystems 208 ACs von der AA 204 an,
bevor sie Dienste von dem Zielsystem anfordern. In Schritt 302 empfängt die
AA 204 eine AC-Anforderung von dem Endnutzer-Clientsystem 202.
Der Nutzer überprüft die Identität der AA 204 unter
Verwendung des SSL-Protokolls mit Clientauthentifizierung (oder
eines ähnlichen
Protokolls). Anders ausgedrückt,
der Endnutzer legt ein gültiges
PKC vor. Der Nutzer legt dem Zielsystem außerdem Berechtigungsnachweisdaten,
d. h. das Paar aus Benutzernamen und Kennwort, vor.
-
Wenn
die AC-Anforderung empfangen wurde, bereitet die AA 204 eine
clearSealedPOP-Struktur vor, die das vom Nutzer bereitgestellte
Kennwort und den Schlüsselbezeichner
enthält,
der aus dem PKC des Nutzers für
den öffentlichen
Schlüssel
berechnet wurde. Diese clearSealedPOP-Struktur wird dann entweder
unter Verwendung des öffentlichen
Schlüssels
des Zielsystems 208 asymmetrisch verschlüsselt, um
eine sealedPOP-Struktur
zu erzeugen, oder sie wird unter Verwendung PKCS #7 (Syntax kryptografischer
Meldungen) symmetrisch verschlüsselt
(eingebettet), um in Schritt 304 eine longSealedPOP-Struktur
zu erzeugen. In beiden Fällen
können
die clearSealedPOP-Daten nur durch das Zielsystem 208 wiederhergestellt
werden. Danach leitet die AA 204 in Schritt 306 diese
verschlüsselte
Struktur und den Wert für
den Benutzernamen zur Überprüfung an
das Zielsystem 208 weiter.
-
Wenn
die Daten zur Überprüfung empfangen
wurden, stellt das Zielsystem 208 in Schritt 308 die
clearSealedPOP-Daten direkt (oder indirekt, falls sie eingebettet
wurden) wieder her und verwendet dabei seinen eigenen privaten Schlüssel. So
kann die Wiederherstellung realisiert werden, indem entweder (1)
der verschlüsselte
Text direkt mit dem privaten Schlüssel des Hostsystems entschlüsselt wird,
oder indem (2) – im
Fall einer Einbettung – zunächst der
symmetrische Schlüssel
mit dem privaten Schlüssel
des Hostsystems und anschließend
der verschlüsselte
Text mit dem entschlüsselten
symmetrischen Schlüssel
entschlüsselt
wird. In Schritt 310 wird die Echtheit des Name/Kennwort-Paars
mit der Berechtigungsnachweisdatenbank des Zielsystems verglichen.
Darüber
hinaus vergewissert sich das Zielsystem, dass kein Replay-Angriff
vorliegt, indem es überprüft, ob der
Schlüsselbezeichner
mit demjenigen des öffentlichen
Schlüssels
des Zertifikatsubjekts übereinstimmt.
-
Wenn
die Echtheitsprüfung
keine Übereinstimmung
ergibt, kann in Schritt 312 eine Meldung ausgegeben werden,
die besagt, dass die Daten ungültig
sind, woraufhin die Anforderung in Schritt 314 beendet
wird. Wenn die Echtheitsprüfung
in Schritt 310 erfolgreich ist, bereitet das Zielsystem 208 in
Schritt 316 eine SvceAuthInfo-Struktur vor, die den Namen
des Zielsystems 208 (service), den Wert für den Benutzernamen (ident)
und den Schlüsselbezeichner
(authInfo) enthält.
Die Codierung dieser SvceAuthInfo-Struktur wird vom Zielsystem 208 in
Schritt 318 unter Verwendung seines privaten Schlüssels unterzeichnet,
um so die aCPOPConfirmation-Struktur zu erzeugen. Die Codierung
kann unter Verwendung von DER-Codierungsregeln
(Distinguished Encoding Rules) erfolgen, wobei es sich um einen
Standard für
die plattformunabhängige Kapselung
von Daten handelt. Die DER-Codierung wird häufig für Daten verwendet, die eine
digitale Signatur benötigen,
und ist dem Fachmann hinreichend bekannt. In Schritt 320 wird
die aCPOPConfirmation-Struktur an die AA 204 zurückgegeben,
um in das AC aufgenommen zu werden.
-
Nachdem
die aCPOPConfirmation-Struktur an die AA 204 zurückgegeben
wurde, kopiert diese in Schritt 322 deren Dienst- und Identitätsfelder
in die betreffenden Felder des noch zu erzeugenden SvceAuthInfo-Attributs.
Dabei wird die eigentliche aCPOPConfirmation-Struktur als AUSWAHL-Wert
für secureAuthInfo verwendet,
der nach der DER-Codierung zur ACHT-BIT-ZEICHENFOLGE für das SvceAuthInfo-Attribut
wird. Der Rest des AC wird in Schritt 324 in Übereinstimmung
mit RFC3281 vorbereitet und in Schritt 326 an den Nutzer
ausgegeben. Der Endnutzer 202 kann nun Dienste vom Zielsystem 208 anfordern.
-
Der
Endnutzer 202 fordert in Übereinstimmung mit der Ausführungsform
aus 3 einen Dienst vom Zielsystem 208 an.
Im Folgenden wird der Prozess der Dienstanforderung mit Blick auf 4 beschrieben. Dabei empfängt das
Zielsystem 208 die Dienstanforderung in Schritt 402.
Dieser Schritt beinhaltet die Prüfung der
Identität
des Nutzers gegenüber
dem Zielsystem 208 unter Verwendung von SSL mit Clientauthentifizierung
(oder eines ähnlichen
Protokolls). In diesem Fall muss das PKC mit demjenigen identisch
sein, das bei der AC-Anforderung verwendet wird, bzw. es muss mindestens
denselben öffentlichen
Schlüssel
aufweisen wie das Original. Das Zielsystem 208 führt in Schritt 404 eine
Gültigkeitsprüfung des
AC durch. Bei beispielhaften Ausführungsformen erfolgt die AC-Gültigkeitsprüfung in Übereinstimmung mit RFC3281
5. Wenn das AC in Schritt 406 nicht gültig ist, kann in Schritt 412 eine Fehlermeldung
an den Anforderer ausgegeben werden. Wenn das AC in Schritt 406 gültig ist
und ein SvceAuthInfo-Attribut mit einer secureAuthInfo-aCPOPConfirmation-Struktur
enthält,
führt das
Zielsystem 208 in Schritt 408 eine Signaturprüfung für UnterzeichneteDaten
in der aCPOPConfirmation-Struktur durch und verwendet dabei seinen öffentlichen
Schlüssel.
Wenn die Signatur in Schritt 410 nicht gültig ist,
wird in Schritt 412 eine Fehlermeldung gesendet. Wenn die
Signatur gültig
ist, wird dem Zielsystem 208 bestätigt, dass die aCPOPConfirmation-Daten echt sind.
Danach überprüft das Zielsystem 208 in
Schritt 414, ob der Nutzer tatsächlich die Person ist, die
das AC ursprünglich
angefordert hat. Hierfür
vergleicht sie den Schlüsselbezeichner
aus der aCPOPConfirmation-Struktur mit dem Schlüsselbezeichner, der für den öffentlichen
Schlüssel
des Nutzer-PKC berechnet wurde. Wenn in Schritt 416 keine Übereinstimmung
festgestellt wird (ungültig),
wird in Schritt 412 eine Fehlermeldung ausgegeben. Wenn
die Schlüsselbezeichner
gültig
sind, ist der Prozess der secureAuthInfo-Gültigkeitsprüfung abgeschlossen. Das Zielsystem 208 erzeugt
anhand des Identitätswerts
aus der aCPOPConfirmation-Struktur in Schritt 418 einen Sicherheitskontext
für den
Nutzer (d. h., es meldet den Nutzer an).
-
Aus
den obigen Erläuterungen
wird deutlich, dass das AC bei einer Änderung des Benutzerkennworts für das Zielsystem 208 nicht
unbenutzbar wird, da das Benutzerkennwort nicht im AC gespeichert
ist. Somit vermeidet das Verfahren den oben erwähnten zweiten Nachteil. Allerdings
gilt dies nicht für
den oben genannten ersten Nachteil, da der Anforderer nach wie vor
der AA 204 das Klartextkennwort vorlegen muss. Mit dem im
Folgenden für
die 5 und 6 beschriebenen
Prozess lassen sich dagegen auch die Unzulänglichkeiten des ersten Nachteils
vermeiden.
-
5 beschreibt einen Prozess für die Erzeugung
eines AC, wobei die AA 204 halb vertrauenswürdig und
das Zielsystem 208 zum Zeitpunkt der AC-Anforderung nicht
für die
Kennwortbestätigung
verfügbar
ist. Der in 5 beschriebene Prozess
geht davon aus, dass die AA 204 durch einen Dritten betrieben
wird. Dabei fordern Nutzer des Zielsystems 208 ACs von
der AA 204 an, bevor sie Dienste vom Zielsystem 208 anfordern. Da
die AA 204 nicht zum TCB des Zielsystems 208 gehört, ist
es nicht wünschenswert,
bei der AC-Anforderung das Kennwort des Nutzers an die AA 204 zu
senden. Um zu verhindern, dass das Kennwort an die AA 204 gesendet
wird, erzeugt der Nutzer (nicht die AA 204) entweder die
sealedPOP- oder
die longSealedPOP-Struktur, wie in Schritt 304 aus 3 beschrieben, bevor er in Schritt 504 das
AC anfordert. In Schritt 507 empfängt die AA 204 eine
AC-Anforderung vom Endnutzer-Clientsystem 202. Der Nutzer
weist gegenüber der
AA 204 seine Identität
nach unter Verwendung von SSL mit Clientauthentifizierung (oder
eines ähnlichen Protokolls).
Anders ausgedrückt,
der Nutzer muss ein gültiges
PKC vorlegen. Die sealedPOP- oder longSealedPOP-Struktur wird ebenfalls
in Schritt 507 zusammen mit dem Benutzernamen für das Zielsystem
an die AA 204 übergeben.
-
Nachdem
die AC-Anforderung von dem Nutzer empfangen wurde, erzeugt die AA 204 das
zu erzeugende SvceAuthInfo-Attribut aus den Daten, die in Schritt 508 zur
Verfügung
gestellt wurden. Dabei wird die sealedPOP- oder longSealedPOP-Struktur
als AUSWAHL-Wert für
secureAuthInfo verwendet, der nach der DER-Codierung zur ACHT-BIT-ZEICHENFOLGE
für das
SvceAuthInfo- Attribut
wird. Der Rest des AC wird in Schritt 510 in Übereinstimmung
mit RFC3281 vorbereitet und in Schritt 512 an den Nutzer
ausgegeben.
-
Der
Nutzer fordert gemäß der Ausführungsform
aus 5 Dienste vom Zielsystem 208 an,
wie im Folgenden mit Blick auf den Prozess aus 6 beschrieben
wird. Dabei empfängt
das Zielsystem 208 die Dienstanforderung in Schritt 602.
Dieser Schritt beinhaltet die Überprüfung der
Identität
des Nutzers gegenüber
dem Zielsystem 208 unter Verwendung von SSL mit Clientauthentifizierung
(oder eines ähnlichen
Protokolls). In diesem Fall muss das PKC mit demjenigen identisch
sein, das bei der AC-Anforderung verwendet wird, bzw. es muss mindestens
denselben öffentlichen
Schlüssel
aufweisen wie das Original. Das Zielsystem 208 führt in Schritt 604 eine
Gültigkeitsprüfung des
AC durch. Bei beispielhaften Ausführungsformen erfolgt die AC-Gültigkeitsprüfung in Übereinstimmung
mit RFC3281 5. Wenn die Gültigkeitsprüfung in
Schritt 606 nicht erfolgreich ist, wird eine Fehlermeldung
ausgegeben, und die Sitzung wird in Schritt 614 beendet.
Wenn das AC gültig
ist und ein secureAuthInfo-sealedPOP- oder -longSealedPOP-Struktur
enthält,
wird in Schritt 608 die Struktur entschlüsselt, um
clearSealedPOP und somit auch das Klartextkennwort und den Schlüsselbezeichner
wiederherzustellen. In Schritt 610 wird eine Gültigkeitsprüfung des
Klartextkennworts mit Blick auf das Identitätskennwort durchgeführt. Wenn
dies in Schritt 612 erfolgreich ist, wird der Schlüsselbezeichner
in Schritt 616 aus der clearSealedPOP-Struktur mit dem
Schlüsselbezeichner
verglichen, der für
den öffentlichen Schlüssel des
Nutzer-PKC berechnet wurde, um so sicherzustellen, dass der Nutzer
tatsächlich
die Person ist, die das AC ursprünglich angefordert
hat. Wenn in Schritt 618 eine Übereinstimmung festgestellt
wird, ist der Prozess der secureAuthInfo-Gültigkeitsprüfung abgeschlossen.
Das Zielsystem 208 erzeugt dann in Schritt 620 anhand
des Identitätswerts
aus dem SvceAuthInfo-Attribut einen Sicherheitskontext für den Nutzer
(d. h., es meldet den Nutzer an). Dabei dürfte offensichtlich sein, dass
das oben erwähnte
erste Problem gelöst
ist, da das Kennwort gegenüber
dem Dritten, AA 204, nicht offengelegt wird. Da das AC
jedoch das Kennwort enthält,
bleibt das zweite Problem ungelöst.
Bei einer Änderung
des Benutzerkennworts für
das Zielsystem 208 würde
das AC unbenutzbar.
-
Beide
oben genannten Nachteile lassen sich vermeiden, indem die Merkmale
der oben mit Blick auf die 3 und 5 beschriebenen Prozesse miteinander verbunden
werden. Das folgende Szenario geht davon aus, dass die AA 204 halb
vertrauenswürdig
und das Zielsystem 208 zum Zeitpunkt der AC-Anforderung für die Kennwortbestätigung verfügbar ist.
Der Prozess wird realisiert wie in 3 beschrieben,
mit der Ausnahme, dass der Nutzer (und nicht die AA 204)
die sealedPOP- oder longSealedPOP-Struktur erzeugt, wie in 5 beschrieben wird. Die AA 204 leitet
diese Daten an das Zielsystem 208 zur Überprüfung weiter. Nachdem die Daten
zur Überprüfung empfangen
wurden, folgt das Zielsystem 208 der in 3 dargelegten
Prozedur, um die clearSealedPOP-Struktur wiederherzustellen, die
Echtheit des Paars aus Benutzername und Kennwort zu überprüfen, den
Schlüsselbezeichner
zu überprüfen und
(falls erfolgreich) die aCPOPConfirmation-Struktur zu erzeugen und sie an die
AA 204 zurückzugeben.
Die Erzeugung des AC aus der aCPOPConfirmation-Struktur und die
Verwendung des AC durch den Nutzer stimmen mit der Vorgehensweise
aus 3 bzw. 4 überein.
Dadurch werden beide Probleme gelöst, da das Kennwort gegenüber der
AA 204 nicht offengelegt wird und das AC auch bei einer
Kennwortänderung
gültig
bleibt.
-
Von
der AA 204 ausgegebene ACs können erweitert werden. 7 beschreibt einen Prozess für die Erweiterung
eines AC, der vom Zielsystem 208 bei der Anmeldung ausgelöst wird
und eine Fortsetzung des in den 5 und 6 beschriebenen Prozesses ist. 8 beschreibt einen Prozess für die Erweiterung
eines AC, der vom Zielsystem 208 asynchron ausgelöst wird
und eine Fortsetzung der in den 5 und 6 beschriebenen Prozesse ist.
-
Mit
Blick auf 7 gibt die AA 204 ein
AC aus, das eine sealedPOP- oder longSealedPOP-Struktur enthält und mit
dem sich der Nutzer zu einem späteren
Zeitpunkt anmeldet. Wenn das Zielsystem 208 seinen Sicherheitskontext
für den
Nutzer erzeugt (nachdem die in 6 beschriebene
Gültigkeitsprüfung erfolgreich abgeschlossen
wurde), überprüft es in
Schritt 702, ob es sich um den ersten Anmeldeversuch mit
dem AC handelt. Wenn dies nicht der Fall ist, wird die Sitzung in
Schritt 704 normal fortgesetzt. Wenn es sich um den ersten Anmeldeversuch
handelt, bereitet das Zielsystem 208 in Schritt 706 eine
neue SvceAuthInfo-Struktur vor, die den Namen des Zielsystems 208 (service),
den Wert für
den Benutzernamen (ident) und den Schlüsselbezeichner (authInfo) enthält. Danach
wird die DER-Codierung
dieser SvceAuthInfo-Struktur vom Zielsystem 208 (unter
Verwendung seines privaten Schlüssels)
in Schritt 708 unterzeichnet, um die aCPOPConfirmation-Struktur
zu erzeugen. Diese aCPOPConfirmation-Struktur wird mit Kopien des
PKC und AC in Schritt 710 an die AA 204 gesendet.
-
Die
AA 204 bestätigt
in Schritt 712, dass der Schlüsselbezeichner des PKC mit
demjenigen in aCPOPConfirmation übereinstimmt
und dass das vorhandene AC auf das PKC verweist, bevor sie ein neues
AC ausgibt. Wenn die AA 204 die Nachricht mit diesen drei
Daten empfängt,
kann sie in Schritt 714 ein neues AC ausgeben, dessen AttributeCertInfo
mit folgenden Ausnahmen mit demjenigen des früheren AC übereinstimmt: serialNumber
wird geändert,
attrCertValidityPeriod.notBeforeTime wird auf die aktuelle Zeit
gesetzt (während attrCertValidityPeriod.notAfterTime
gleich bleibt), und SvceAuthInfo wird aktualisiert, um die sealedPOP-
oder longSealedPOP-Struktur durch die aCPOPConfirmation-Struktur
zu ersetzen.
-
Dabei
dürfte
offensichtlich sein, dass dieser Prozess einem Zielsystem 208 ermöglicht,
die als Ergebnis der Ausführungsform
aus 4 ausgegebenen ACs auf diejenigen
ACs umzustellen, die als Ergebnis der Ausführungsform aus 3 ausgegeben
werden und die von Kennwortänderungen
unberührt
bleiben. Das neue AC kann auf verschiedene standardmäßige Arten
an das Subjekt verteilt werden. Um nur einige Möglichkeiten zu nennen, kann
das neue AC im Rahmen einer Sitzung mit dem Zielsystem 208 zurückgegeben
werden, per eMail (verschlüsselt
oder als Klartext) gesendet und in ein Verzeichnis, auf eine FTP-Site,
eine Website usw. gestellt werden.
-
Mit
Blick auf 8 wird nun ein Prozess für die Erweiterung
eines AC beschrieben, die vom Zielsystem 208 asynchron
ausgelöst
wird. Dabei gibt die AA 204 in Schritt 802 ein
AC mit einer sealedPOP- oder longSealedPOP-Struktur aus und sendet
eine Kopie davon mit dem entsprechenden PKC an eine Warteschlange oder
ein Archiv, das dem Zielsystem 208 zugehörig ist.
Wenn das Zielsystem 208 nicht ausgelastet ist, verarbeitet
es in Schritt 804 einen Eintrag aus dieser Warteschlange
bzw. diesem Archiv. Das Zielsystem 208 überprüft in Schritt 806 die
Gültigkeit
des AC und entschlüsselt
in Schritt 808 die secureAuthinfo-sealedPOP- oder -longSealedPOP-Struktur, um die
clearSealedPOP-Struktur und damit das Klartextkennwort und den Schlüsselbezeichner
wiederherzustellen. Wenn in Schritt 810 festgestellt wird,
dass keine clearSealedPOP-Struktur wiederhergestellt wurde, wird
in Schritt 812 keine Aktion durchgeführt.
-
Wenn
in Schritt 810 eine clearSealedPOP-Struktur wiederhergestellt
wurde, wird in Schritt 814 das Klartextkennwort daraufhin überprüft, ob es
das Identitätskennwort
ist, und anschließend
wird in Schritt 816 der Schlüsselbezeichner aus clearSealedPOP
mit dem Schlüsselbezeichner
verglichen, der für
den öffentlichen
Schlüssel
des Nutzer-PKC berechnet wurde, um zu überprüfen, ob der Nutzer tatsächlich die
Person ist, die das AC ursprünglich
angefordert hat. Bei einer Übereinstimmung
bereitet das Zielsystem 208 in Schritt 818 eine
neue SvceAuthInfo-Struktur vor, die den Namen des Zielsystems 208 (service),
den Wert für
den Benutzernamen (ident) und den Schlüsselbezeichner (authInfo) enthält. Die
DER-Codierung dieser SvceAuthInfo-Struktur wird vom Zielsystem 208 (unter
Verwendung seines privaten Schlüssels)
in Schritt 820 unterzeichnet, um die aCPOPConfirmation-Struktur
zu erzeugen. Diese aCPOPConfirmation-Struktur wird mit Kopien des
PKC und AC in Schritt 822 an die AA 204 gesendet.
-
Die
AA 204 bestätigt
in Schritt 824, dass der Schlüsselbezeichner des PKC mit
demjenigen in aCPOPConfirmation übereinstimmt
und dass das vorhandene AC auf das PKC verweist, bevor sie ein neues
AC ausgibt. Wenn die AA 204 die Nachricht mit diesen drei
Daten empfängt,
gibt sie in Schritt 826 ein neues AC aus, dessen AttributeCertInfo
mit folgenden Ausnahmen mit demjenigen des früheren AC übereinstimmt: serialNumber
wird geändert,
attrCertValidityPeriod.notBeforeTime wird auf die aktuelle Zeit
gesetzt (während
attrCertValidityPeriod.notAfterTime gleich bleibt), und SvceAuthInfo
wird aktualisiert, um die sealedPOP- oder longSealedPOP-Struktur
durch die aCPOPConfirmation-Struktur zu ersetzen.
-
Dabei
dürfte
offensichtlich sein, dass dieser Prozess einem Zielsystem ermöglicht,
die als Ergebnis des in 5 beschriebenen
Prozesses ausgegebenen ACs auf ACs umzustellen, die als Ergebnis
des in 3 beschriebenen Prozesses ausgegeben
werden und die von Kennwortänderungen
unberührt
bleiben. Das neue AC kann auf verschiedene standardmäßige Arten
an das Subjekt verteilt werden. Um nur einige Möglichkeiten zu nennen, kann
das neue AC im Rahmen einer Sitzung mit dem Zielsystem 208 zurückgegeben
werden, per eMail (verschlüsselt
oder als Klartext) gesendet und in ein Verzeichnis, auf eine FTP-Site,
eine Website usw. gestellt werden.
-
Dabei
ist zu beachten, dass, indem der Schlüsselbezeichner des AC-Anforderers
in eine beliebige Form des (nun sicheren) authInfo-Felds aufgenommen
wird, die POP-Daten kryptografisch an das PKC des Anforderers gebunden
sind. Daher muss das SvceAuthInfo-Attribut nicht mehr an das AC
gebunden sein, um einen Replay-Angriff zu verhindern. Somit muss
das SvceAuthInfo-Attribut nicht im encAttrs-Attribut enthalten sein,
wenn das AC erzeugt wird.
-
Wie
oben beschrieben, können
die Ausführungsformen
der Erfindung in Form von computergestützten Prozessen und Vorrichtungen
für die
praktische Durchführung
der Erfindung vorliegen. Ausführungsformen
der Erfindung können
auch in Form von Computerprogrammcode mit Befehlen vorliegen, die
auf einem physischen Medium wie beispielsweise Disketten, CD-ROMs,
Festplatten oder einem beliebigen anderen computerlesbaren Speichermedium
enthalten sind, wobei, wenn der Computerprogrammcode in einen Computer
geladen und von ihm ausgeführt
wird, der Computer zu einer Vorrichtung für die praktische Durchführung der
Erfindung wird. Die vorliegende Erfindung kann auch in Form von
Computerprogrammcode vorliegen, wobei dies unabhängig davon ist, ob dieser auf
einem Speichermedium gespeichert ist, in einen Computer geladen
bzw. von einem Computer ausgeführt
wird oder über
ein Übertragungsmedium
wie beispielsweise Elektroleitungen oder -kabel, Lichtwellenleiterkabel
oder mittels elektromagnetischer Strahlung übertragen wird, und wobei, wenn
der Computerprogrammcode in einen Computer geladen und von ihm ausgeführt wird,
der Computer zu einer Vorrichtung für die praktische Durchführung der
Erfindung wird. Bei einer Realisierung mit einem universell einsetzbaren
Mikroprozessor konfigurieren die Segmente des Computerprogrammcodes
den Mikroprozessor so, dass spezifische Logikschaltungen entstehen.