DE602005003631T2

DE602005003631T2 - Ausschluss der Passwortaufdeckung bei Attributzertifikatausgabe

Info

Publication number: DE602005003631T2
Application number: DE602005003631T
Authority: DE
Inventors: Messaoud Benantar; Thomas Gindin; James Sweeny
Original assignee: International Business Machines Corp
Current assignee: International Business Machines Corp
Priority date: 2004-10-28
Filing date: 2005-10-21
Publication date: 2008-11-13
Anticipated expiration: 2025-10-22
Also published as: ATE380370T1; CN1767427A; TW200633459A; US7543147B2; CN100581098C; TWI390937B; EP1653387B1; EP1653387A1; DE602005003631D1; US20060095760A1

Description

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.

Claims

Verfahren für die Erzeugung eines Besitznachweises zur Einfügung in ein Attributzertifikat (102) durch eine Einheit (204) für die Attributzertifikatvergabe, wobei das Attributzertifikat für die Verwendung durch einen Endnutzer (202) vorgesehen ist, dadurch gekennzeichnet, dass das Verfahren die folgenden Schritte umfasst: Empfangen (302) einer Vielzahl von Datenfeldern, die einem Zielsystem, der Identität des Endnutzers und einem Identitätsnachweis durch den Benutzer entsprechen, von der Einheit für die Attributzertifikatvergabe (204) als Reaktion auf eine Anforderung durch den Endnutzer; Vorbereiten (304) 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; Unterzeichnen (318) der Datenstruktur unter Verwendung eines privaten Schlüssels, der dem Zielsystem zugehörig ist, wodurch sich ein Besitznachweis ergibt; und Senden (320) des Besitznachweises an die Einheit für die Attributzertifikatvergaben, um ihn in das Attributzertifikat aufzunehmen.
Verfahren nach Anspruch 1, das weiter Folgendes umfasst: Überprüfen der Vielzahl von Datenfeldern vor der Vorbereitung der Datenstruktur.
Verfahren nach Anspruch 1, wobei die Datenstruktur vorbereitet wird, indem das Berechtigungsdatenfeld des Attributzertifikats anhand einer ACHT-BIT-ZEICHENFOLGE, die dem Berechtigungsdatenfeld entspricht, erweitert wird.
Verfahren nach Anspruch 1, wobei der Identitätsnachweis durch den Endnutzer verschlüsselt wird, wobei die Einheit für die Attributzertifikatvergabe nicht Teil einer vertrauenswürdigen Sicherheitsplattform ist, die dem Zielsystem zugehörig ist, wobei der Endnutzer den Identitätsnachweis zum Zeitpunkt der Anforderung verschlüsselt.
Verfahren nach Anspruch 1, wobei der Identitätsnachweis durch die Einheit für die Attributzertifikatvergabe verschlüsselt wird, wobei die Einheit für die Attributzertifikatvergabe Teil einer vertrauenswürdigen Sicherheitsplattform ist, die dem Zielsystem zugehörig ist, wobei die Einheit für die Attributzertifikatvergabe den Identitätsnachweis zum Zeitpunkt der Anforderung verschlüsselt.
Verfahren nach Anspruch 1, das ferner das Erweitern eines Attributzertifikats umfasst, wobei das Erweitern durch das Zielsystem veranlasst wird, wenn sich der Endnutzer bei dem Zielsystem anmeldet.
Verfahren nach Anspruch 1, das ferner das Erweitern eines Attributzertifikats umfasst, wobei das Erweitern durch das Zielsystem asynchron veranlasst wird, wenn eine Kopie eines Attributzertifikats ausgewählt wird, die in einer dem Zielsystem zugehörigen Warteschlange gespeichert ist.
Mittel für das Erzeugen eines Besitznachweises zur Einfügung in ein Attributzertifikat (102) durch eine Einheit für die Attributzertifikatvergabe (204), wobei das Attributzertifikat für die Verwendung durch einen Endnutzer vorgesehen ist, dadurch gekennzeichnet, das das Mittel Folgendes umfasst: ein Mittel für das Empfangen (302) 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; ein Mittel für das Vorbereiten (304) 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; ein Mittel für das Unterzeichnen (318) der Datenstruktur unter Verwendung eines privaten Schlüssels, der dem Zielsystem zugehörig ist, wodurch sich ein Besitznachweis ergibt; und ein Mittel für das Senden (320) des Besitznachweises an die Einheit für die Attributzertifikatvergabe, um ihn in das Attributzertifikat aufzunehmen.
Computerprogrammelement, das Computerprogrammcode umfasst, um – wenn es in ein Computersystem geladen und ausgeführt wird – den Computer zur Durchführung der Schritte eines Verfahrens zu veranlassen, wie es in einem beliebigen der Ansprüche 1 bis 7 geltend gemacht wird.