-
Bei
einem kryptographischen Schlüssel,
der aus einem öffentlichen
Schlüssel
und einem privaten Schlüssel
besteht, ist das grundlegende Objekt, das es ermöglicht, dem öffentlichen
Schlüssel
zu vertrauen, ein elektronisches Zertifikat, das von einer Zertifizierungsstelle
ausgegeben wird. Dieses Zertifikat enthält insbesondere den zu zertifizierenden öffentlichen
Schlüssel,
die Identität
des Inhabers des öffentlichen
Schlüssels,
eine Zertifikat-Validitätsdauer,
eine Liste von Schlüsselbenutzungsattributen,
die Benutzungsrechten des Schlüssels, "key usages" genannt, entsprechen
und Parameter wie zum Beispiel einen Mitteilungssignaturschlüssel oder
einen gesicherten Webserverschlüssel
unterstützen,
und eine kryptographische Signatur der obigen Daten, die im Zertifikat
enthalten sind, durch einen öffentlichen
Schlüssel der
Zertifizierungsstelle, die das Zertifikat ausgegeben hat.
-
Das
Vertrauen in den einer Identität
zugeordneten öffentlichen
Schlüssel
läuft auf
die Validität
des Zertifikats hinaus, die insbesondere von der Validität einer "Vertrauenskette" des Zertifikats
C abhängt.
Die "Vertrauenskette" des Zertifikats
C ist eine endliche Folge von N Zertifikaten C1, C2, ..., Cn, Cn
+ l, ..., CN, die von Zertifizierungsstellen AC2, ACn, ...,.ACn +
l, ..., bzw. ACN ausgegeben werden, wobei das erste Zertifikat C1
das zu prüfende
Zertifikat C ist. Die endliche Folge der "Vertrauenskette" endet mit einem Zertifikat CN, das
explizit als "Vertrauenszertifikat" bezeichnet wird.
Ein Zertifikat Cn wird von der Zertifizierungsstelle ACn + l zertifiziert,
die ein Zertifikat Cn + l ausgibt. Im Allgemeinen ist das Vertrauenszertifikat
CN eine Wurzel der Vertrauenskette und bildet ein selbstsigniertes
Zertifikat von einer Zertifizierungsstelle, die der Gemeinschaft
der anderen Zertifizierungsstellen bekannt ist, die sich darauf beziehen
müssen.
Eine Vertrauenskette wird durch die individuelle Validität jedes
der Zertifikate Cn sowie durch die Validität der Verkettung auf der Ebene
jeder Zertifizierungsstelle ACn + l validiert, um zu gewährleisten,
dass die Zertifizierungsstelle ACn + l wirklich das Zertifikat Cn
im Zertifikat Cn + l signiert hat.
-
Die
Schlüsselbenutzungsattribute
einer Zertifizierungsstelle, die im von dieser Stelle ausgegebenen
Zertifikat enthalten sind, spezifizieren insbesondere die genehmigte
Zertifizierungstiefe. Eine Zertifizierungsstelle, die nur Endbenutzer
oder Server zertifizieren kann, hat eine minimale genehmigte Zertifizierungstiefe,
zum Beispiel gleich Null. Ein Endbenutzer hat ein Attribut, das
erwähnt,
dass er nicht das Recht hat, Zertifikate auszugeben. Wenn dieses
Attribut nicht erwähnt
ist, nimmt man standardmäßig an, dass
der Benutzer nicht das Recht hat, Zertifikate auszugeben; in der
Regel hat die genehmigte Zertifizierungstiefe des Zertifikats den
Wert –1.
-
Eine
elektronische Signatur garantiert die Authentizität eines
Dokuments, d.h. authentifiziert sicher einen oder mehrere Signatare,
die die Signatur ausgeführt
haben, und garantiert, dass das Dokument nicht verändert wurde.
Die elektronische Signatur wird oft verwendet, um die Unleugbarkeit
des Dokuments zu garantieren, die darin besteht, sich vor einer
Verleugnung des Dokuments durch den Autor zu schützen.
-
Gemäß einer
anderen, so genannten "Multi-Aktoren"-Technik ("multi-agents") ist die elektronische Signatur eine
Gruppensignatur, die die Anonymität des zur Gruppe gehörenden Signatars
gewährleistet,
indem im Namen der Gruppe unterzeichnet wird.
-
Die
bekannten Formate einer elektronischen Signatur bieten kein Mittel,
eine Erwähnung
einer Signaturdelegation einzufügen.
-
Wenige
elektronische Signatursysteme ermöglichen derzeit die Signaturdelegation.
Insbesondere sieht keines dieser Systeme eine Delegation von zertifizierten
kryptographischen Schlüsseln
vor.
-
Wenn
eine Signaturdelegation in einem elektronischen Signatursystem existiert,
betrifft sie im Allgemeinen einer Delegation von Rechten, mit einem Mittel
zur Verwaltung von Bevollmächtigungen,
die intern vom System durchgeführt
wird, oder in den besten Fällen über ein
allgemeineres Verzeichnis.
-
Zum
Beispiel in einem Arbeitsablauf ("workflow") kann eine Gruppe von "Inhabern" definiert werden,
die das Recht haben, innerhalb des Systems Entscheidungen zu treffen.
Um die Abwesenheiten von Inhabern zu beheben, können einer oder mehrere "Vertreter" jedem der Inhaber
beigeordnet werden.
-
Aufgrund
einer Entscheidung eines Inhabers, zum Beispiel bei einer Aktion
im Arbeitsablauf, wie einer Urlaubserklärung, werden alle oder ein
Teil der Bevollmächtigungen
des Inhabers dem Vertreter während
einer vorbestimmten Delegationsdauer zugeteilt, um keine Betriebsunterbrechung
im Arbeitsablauf zu erzeugen. Die vom Vertreter innerhalb des Arbeitsablaufs
getroffenen Entscheidungen werden im Namen des Inhabers getroffen.
-
Meist
geht die Spur der Delegation verloren, wenn die Delegationsdauer
abgelaufen ist. In den besten Fällen
wird die Delegation wiedergefunden, indem Aufstellungen oder Register
(logs) des Arbeitsablaufs mittels einer komplexen und teuren Suchoperation
durchgesehen werden, vor allem, wenn die Suche lange danach durchgeführt werden
muss.
-
Im
Fall eines Arbeitsablaufs, der eine elektronische Signatur enthält, wobei
das Objekt der "Entscheidung" die elektronische
Signatur eines Dokuments ist, ist in den existierenden Formaten
einer elektronischen Signatur kein Feld "unterzeichnet im Namen von" vorgesehen, das
es ermöglicht,
den Inhaber wiederzufinden, in dessen Namen die Signatur vom Vertreter
ausgeführt
wurde. Sobald das signierte Dokument aus dem Rahmen des Arbeitsablaufs
herausgenommen wird, um zum Beispiel von einem Dritten verarbeitet
oder archiviert zu werden, weist es nur noch die Signatur des Vertreters
auf, ohne eine Spur des Inhabers, in dessen Namen der Vertreter
die Signatur ausgeführt
hat.
-
Da
die Delegierung der Vollmacht nicht in der elektronischen Signatur
enthalten ist, kann sie also auch nicht wiedergefunden werden, wenn
das signierte Dokument seinen Delegationskontext verlassen hat.
-
Die
elektronische Signatur muss aber dauerhaft sein, und mit ihr müssen die
Elemente weiter bestehen, um die Bedingungen wiederzufinden, unter denen
die Signatur ausgeführt
wurde, zum Beispiel die Hinzufügung
der schriftlichen Anmerkung "in
Vertretung" im Fall
einer handschriftlichen Signatur.
-
Außerdem erfordert
die Delegation häufig entweder
für den
Inhaber oder für
den Vertreter oder für
beide ein Eingreifen in das Verwaltungsmittel, das die Delegationen
ermächtigt.
-
Der
Artikel mit dem Titel "Proxy-based
authorization and accounting for distributed systems" von B.C. Neuman,
Proceedings of the International Conference an Distributed Computing
Systems. Pittsburg, 25–28
Mai 1993, Los Alamitos, IEEE COMP. SOC, PRESS, Vol. CONF. 13, Seiten
283–291,
betrifft eine Delegation mittels eines Mandats, das in Form eines
Chips von einem Inhaber an einen Vertreter geliefert wird, um Aktionen
erfüllen,
für die
der Inhaber in Servern berechtigt ist. Das Mandat enthält Einschränkungen
(genehmigte Aktionen) bezüglich der
Vollmachten des Inhabers und kann in Kaskade delegiert werden. Ein
beschränktes
Mandat enthält ein
vom Inhaber signiertes Zertifikat und einen Schlüssel, damit ein Server überprüft, dass
das Mandat tatsächlich
vom Inhaber ausgegeben wurde, und außerdem einen Mandatschlüssel, der
ein Verschlüsselungsschlüssel entsprechend
dem Schlüssel
im Zertifikat ist, der von dem Vertreter verwendet werden wird,
um den Besitz des Mandats zu beweisen. Der Mandatschlüssel kann öffentlich
sein und vom Inhaber erzeugt werden, und das Zertifikat kann das Ablaufdatum
der Delegation enthalten. Der Vertreter schickt das Zertifikat an
den Server und kann den Mandatschlüssel verwenden, um an einer
Authentifizierung teilzunehmen, insbesondere unter Verwendung einer
Zufallszahl des Servers. Ein Genehmigungsserver liefert ein beschränktes Mandat
an den Vertreter. Dieser Artikel schlägt keine Erstellung durch den
Inhaber eines zweiten Zertifikats mit öffentlichen Schlüsseln des
Vertreters und des Inhabers und einem Delegationsattribut vor, die
durch einen privaten Inhaberschlüssel
als Antwort auf eine Neuzertifizierungsanforderung durch den Vertreter signiert
werden.
-
Die
vorliegende Erfindung hat hauptsächlich zum
Ziel, es dem Vertreter zu ermöglichen,
kryptographische Aktionen mit seinem Schlüssel unter der direkten Autorität des Inhabers
auszuführen,
ohne außerdem
auf eine Zertifizierungsstelle zurückzugreifen, und eine Spur
der Delegierung in das Zertifikat einzufügen, das vom Vertreter im Namen
des Inhabers verwendet wird.
-
Um
dieses Ziel zu erreichen, ist ein elektronisches Zertifizierungsverfahren,
um Aktionen eines Inhabers, der ein elektronisches Zertifikat in
einem Inhaberterminal gespeichert hat, an einen Vertreter zu delegieren,
der ein erstes elektronisches Zertifikat in einem Vertreterterminal
gespeichert hat, wobei das Zertifikat des Inhabers und das erste
Zertifikat des Vertreters außerdem
jeweilige öffentliche
Schlüssel und
Zertifikat-Signaturen von jeweiligen Zertifizierungsstellen aufweisen,
dadurch gekennzeichnet, dass es nach einer Delegierungsbeanspruchung
des Vertreters durch den Inhaber die folgenden Schritte aufweist:
- – eine
Erstellung einer Neuzertifizierungsanforderung im Vertreterterminal
und eine Übertragung der
Zertifizierungsanforderung an das Inhaberterminal,
- – eine
Erstellung eines zweiten elektronischen Vertreterzertifikats im
Inhaberterminal als Antwort auf die Neuzertifizierungsanforderung,
und eine Übertragung
des zweiten Zertifikats an das Vertreterterminal, wobei das zweite
Zertifikat Daten umfasst, die der öffentliche Schlüssel des
Inhabers, der öffentliche
Schlüssel
des Vertreters und ein Delegationsattribut sind, und eine Signatur
der Daten mit einem privaten Schlüssel des Inhabers, und
- – im
Vertreterterminal eine Validierung der Signatur im zweiten übertragenen
Vertreterzertifikat, damit das Terminal das zweite Zertifikat für jede Aktion
verwendet, die vom Inhaber an den Vertreter delegiert wird.
-
Die
Erfindung erhebt so den Inhaber auf den Rang einer Zertifizierungsstelle
für den
Vertreter, da die im zweiten Zertifikat enthaltenen Daten und insbesondere
der öffentliche
Vertreterschlüssel
vom Inhaber signiert werden.
-
Die
Spur der Delegation wird durch das Delegationsattribut dargestellt.
Vorzugsweise wird diese Spur durch ein Attribut vervollständigt oder
ersetzt, das eine Befugnis des Inhabers zu delegieren darstellt,
die im Zertifikat des Inhabers enthalten ist, das selbst in den
Daten des zweiten Zertifikats des Vertreters enthalten sein kann.
-
Weitere
Merkmale und Vorteile der vorliegenden Erfindung gehen klarer aus
der folgenden Beschreibung mehrerer bevorzugter Ausführungsformen
der Erfindung unter Bezugnahme auf die entsprechenden beiliegenden
Zeichnungen hervor. Es zeigen:
-
1 ein
schematisches Blockdiagramm eines Telekommunikationssystems mit
einem Inhaberterminal und einem Vertreterterminal und verschiedenen
Servern zur Anwendung des elektronischen Zertifizierungsverfahrens
gemäß der Erfindung;
und
-
2 einen
Algorithmus von Hauptschritten des erfindungsgemäßen elektronischen Zertifizierungsverfahrens.
-
Unter
Bezug auf 1 sind zwei Terminals TET und
TED einem Inhaber-Benutzer T bzw. einem Vertreter-Benutzer D zugeteilt.
Die zwei Terminals sind über
ein Telekommunikationsnetz RT verbunden. Zum Beispiel sind die Terminals
TET und TED Personalcomputer, und das Netz RT ist ein lokales LAN-Netz
vom Typ Ethernet oder drahtloses WAN, oder weist Zugriffsnetze auf,
die über
das Internet verbunden werden. Mindestens eines der Terminals TET
und TED kann ein tragbarer elektronischer Gegenstand wie ein digitaler
persönlicher
Assistent PDA oder ein Laptop sein. Gemäß einem anderen Beispiel ist
mindestens eines der Terminals TET und TED ein Funktelefon, und
das Netz RT weist außerdem
das digitale zellulare Funktelefonienetz auf, von dem das Funktelefon
abhängt.
-
Zu
Anfang ist in jedem Terminal TET, TED ein elektronisches Zertifikat
CT, C1D gespeichert, das den jeweiligen Benutzer T, D identifiziert
und insbesondere einen öffentlichen
Schlüssel
KPUBT, KPUBD des Benutzers T, D, der Inhaber des Zertifikats ist,
die Identität
IDT, IDD, die zum Beispiel den Namen und Vornamen des Benutzers
enthält,
eine Validitätsdauer,
ggf. Attribute ATT, ATD wie die Identität der elektronischen Zertifizierungsstelle
ACT, ACD, die das Zertifikat erzeugt hat, den öffentlichen Schlüssel dieser
Stelle und die Bezeichnung des Algorithmus, der zum Signieren des
Zertifikats dient, usw. enthält.
Das Zertifikat CT, C1D weist ebenfalls eine kryptographische Signatur
SACT, SACD aller vorhergehenden Daten auf, die im Zertifikat CT,
C1D enthalten sind, erstellt von der Zertifizierungsstelle ACT,
ACD, die das Zertifikat ausgegeben hat. Wie in 1 gezeigt,
sind die Zertifizierungsstellen ACT und ACD mit dem Netz RT verbundene
Server, die die Aufgabe haben, die Zertifikate zu signieren, die Zertifikate
in Verzeichnissen zu veröffentlichen
und Listen von widerrufenen Zertifikaten zu erstellen, schwarze
Listen genannt.
-
Jedes
Terminal TET, TED enthält
ebenfalls einen privaten Schlüssel
KPRT, KPRD, der dem öffentlichen
Schlüssel
KPUBT, KPUBD entspricht, um Mitteilungen zu signieren, die mittels
eines vorbestimmten asymmetrischen Algorithmus AA zu übertragen
sind.
-
Zu
Anfang wird angenommen, dass der Inhaber T von der Zertifizierungsstelle
ACT bevollmächtigt
ist, Aktionen an den Vertreter D zu delegieren. Der Inhaber T kennt
den Vertreter D, und folglich hat das Terminal TET des Inhabers
T bereits das erste Zertifikat C1D des Vertreters D gespeichert.
-
Eine
Genehmigung des Inhaber T zu delegieren kann durch ein Schlüsselbenutzungsattribut (key
usage) ATT dargestellt werden, das von der Zertifizierungsstelle
ACT mit einer genehmigten Zertifizierungstiefe gleich 0 und im Inhaberzertifikat
CT enthalten geliefert wird; die Stelle ACT gibt dann eine Zertifizierungspolitik
aus, die mit diesem Typ von Schlüsselbenutzungsattribut
kompatibel ist. Der Inhaber T wird vorzugsweise zu Delegationszwecken vollständig zu
einer Zertifizierungsstelle. Das Delegationszertifikat, das das
Inhaberterminal TET erstellt, wie man weiter unten sehen wird, erfordert
keine spezifischere Kontrolle als die Kontrollen in den anderen Zertifizierungsstellen
bei der Validierung einer Vertrauenskette.
-
In
einer Variante stellt die Inhaber-Zertifizierungsstelle ACT das Recht
des Inhabers zu delegieren sowohl durch ein Schlüsselbenutzungsattribut (key
usage) der Zertifizierungsstelle ACT mit einer genehmigten Zertifizierungstiefe
von 0 als auch durch ein spezifisches Delegationsattribut dar.
-
Eine
elektronische Zertifizierung zum Delegieren der Aktionen des Inhabers
T an den Vertreter D weist erfindungsgemäß Schritte E1 bis E7 auf, wie in 2 gezeigt
ist.
-
Im
Schritt E1 führt
der Benutzer T eine Delegations-Beanspruchung
SLD des Vertreters D entweder direkt bei einer Begegnung der Benutzer
T und D, oder über
eine Mitteilung durch, die vom Terminal TET an das Terminal TED
zum Beispiel in Form einer elektronischen Post (Email) übertragen
wird.
-
Gemäß einer
anderen Variante ist im Terminal TED ein Software-Server SRD installiert,
zum Beispiel ein Webserver HTTP (HyperText Transfer Protocol). Der
Server SRD ist ein Programm, das im Terminal TED als Antwort auf
eine Mitteilung der Delegationsbeanspruchung SLD ausgeführt wird,
die vom Terminal TET übertragen
wird. Der Server SRD erstellt dann eine Neuzertifizierungsanforderung RRC,
wie nachfolgend beschrieben, um sie an das Terminal TET zu übertragen.
In einer Variante ist der Server SRD ein "Client"-Server elektronischer Post, der elektronische
Beanspruchungsmitteilungen SLD filtert, die von berechtigten Inhabern
kommen.
-
Vor
dem Schritt der Delegationsbeanspruchung, unabhängig vom Typ des Servers SRD,
kann dieser entscheiden, das Terminal TET zu authentifizieren, entweder
durch Signatur der Beanspruchungsmitteilung SLD in Form von elektronischer Post,
oder durch Authentifizierung gemäß einem
vorbestimmten Sicherungsprotokoll vom Typ SSL (Secure Sockets Layer)
für einen
Server vom Typ HTTP, oder durch Authentifizierung mit Hilfe eines
Identifikators und eines Passworts, usw.. In der Praxis fordert
ein im Terminal TET installierter Server SRT vorzugsweise eine Authentifizierung
des Servers SRD, d.h. eine Authentifizierung des Vertreters D durch den
Inhaber T, oder ggf. eine gegenseitige Authentifizierung zwischen
den Servern SRD und SRT. Der Software-Server SRT ist vom gleichen
Typ, zum Beispiel HTTP/SSL, wie der Server SRD.
-
Wenn
der die Delegation beanspruchende Inhaber T nicht berechtigt ist,
an den Vertreter D zu delegieren, oder wenn der Vertreter die beanspruchte
Delegation verweigert, wird die Beanspruchung SLD zurückgewiesen,
zum Beispiel durch Übertragung
einer vorbestimmten Zurückweisungsmitteilung vom
Terminal TED zum Terminal TET.
-
Im
Schritt E2 erstellt das Terminal TED eine Neuzertifizierungsanforderung
RRC. Um diese zu erstellen, weist der Schritt E2 insbesondere Unterschritte
E21, E22 und E23 auf.
-
Im
Unterschritt E21 wird das Terminal TED mit einem Applet-Webserver
SA1 verbunden, der von der Zertifizierungsstelle ACT des Inhabers
installiert wird, um ein Java-Applet AP1 zu erfassen, das es dem
Browser im Terminal TED ermöglicht,
die Anforderung RRC zu erstellen. Das Laden des Applets AP1 in das
Terminal TED kann vor dem Schritt E1 erfolgen, wenn das Terminal
TED bereits vor kurzem eine Neuzertifizierungsanforderung erstellt
hat. Das Applet AP1 enthält
insbesondere einen asymmetrischen Algorithmus AA1, an den im Schritt
E22 der öffentliche
Schlüssel
KPUBD als Daten und der private Schlüssel KPRD angewendet werden,
um eine elektronische Signatur SKD des öffentlichen Schlüssels des
Vertreters D zu bestimmen. Dann erstellt das Terminal TED die Neuzertifizierungsanforderung
RRC, indem es im Unterschritt E23 den öffentlichen Schlüssel KPUBD,
dessen vorher erstellte Signatur SKD und ggf. das erste Zertifikat
C1D in sie einführt, das
es dem Inhaber T ermöglicht,
das Vertrauen in den Vertreter D zu überprüfen. Die erstellte Anforderung
RRC wird im Schritt E3 vom Terminal TED an das Terminal TET über das
Netz RT übertragen.
-
Gemäß einer
Variante wird die Neuzertifizierungsanforderung RRC im Schritt E3
vom Terminal TED in Form einer elektronischen Postmitteilung (Email)
an das Terminal TET übermittelt.
-
Nach
der Übertragung
E3 der Neuzertifizierungsanforderung RRC vom Terminal TED zum Terminal
TET über
das Telekommunikationsnetz RT sichert das Terminal TET die Anforderung
RRC, zum Beispiel auf der Festplatte oder einem RAM-Speicher dieser
Festplatte in einem Unterschritt E41 eines Signatur-Validierungsschritts
E4, der Unterschritte E42 bis E46 aufweist.
-
Im
Unterschritt E42 kommuniziert das Terminal TET mit einem zweiten
Applet-Server SA2, um ein Java-Applet AP2 abzurufen, das dazu bestimmt ist,
die Validität
der empfangenen Neuzertifizierungsanforderung RRC zu prüfen, es
sei denn, das Applet AP2 wurde bereits ein für alle Mal im Terminal TET
installiert. Der Applet-Server
SA2 ist ebenfalls unter der Kontrolle der Zertifizierungsstelle
ACT und kann mit dem ersten Applet-Server SA1 zusammenfallen.
-
Dann
prüft in
den Unterschritten E43 bis E45 mittels des geladenen Applets AP2
das Inhaberterminal TET das Format der empfangenen Neuzertifizierungsanforderung
RRC und validiert diese bezüglich der
Signatur SKD. Die Validierung der Anforderung RRC, d.h. der Signatur
SKD, wird durchgeführt,
indem die Signatur SKD als Daten an den im Applet AP2 enthaltenen
Algorithmus AA1 und an den aus der empfangenen Anforderung RRC entnommenen öffentlichen
Schlüssel
KPUBD angewendet wird, um normal einen öffentlichen Schlüssel KPUBD' zu erzeugen, der
mit dem aus der Anforderung RRC entnommenen öffentlichen Schlüssel KPUBD
im Unterschritt E45 verglichen wird. Wenn das Ergebnis der Überprüfung im
Unterschritt E43 oder der Validierung in den Unterschritten E44–E45 fehlerhaft
ist, kann der Inhaber T entscheiden, die laufende Delegation zu verweigern
und zu unterbrechen, oder erneut eine Delegation zu beanspruchen,
indem eine Delegationsbeanspruchung SLD im Schritt E1 ausgegeben wird.
-
Wenn
die Anforderung RRC validiert wird, d.h. im vorliegenden Fall, wenn
der öffentliche Schlüssel KPUBD
im Unterschritt E45 validiert wird, zeigt das Terminal T die Neuzertifizierungsanforderung
RRC im Unterschritt E46 an. Zum Beispiel zeigt das Terminal T insbesondere
das Zertifikat C1D an, das aus der Anforderung RRC entnommen wird, wenn
die Anforderung RRC es enthält,
oder das im Speicher des Terminals TET gelesen wird, damit der Inhaber
T die Validierung der empfangenen Anforderung RRC und die Fortsetzung
der elektronischen Zertifizierung zur Delegation bestätigt, indem
er zum Hauptschritt der Erstellung eines zweiten Vertreterzertifikats
E5 übergeht.
In einer Variante interveniert der Inhaber nicht im Schritt E46,
und die Validierung der Anforderung RRC ist vollständig automatisch
im Terminal TET.
-
Im
Schritt E5 erstellt das Inhaberterminal TET auf der Basis des ersten
Zertifikats C1D ein zweites elektronisches Delegationszertifikat
C2D, das vom Vertreterterminal TED an die Stelle des ersten Zertifikats
C1D zu setzen ist, wenn der Vertreter D im Namen des und für den Inhaber
T handelt.
-
Das
zweite Vertreterzertifikat C2D wird mittels des zweiten Applets
AP2 erstellt und enthält
insbesondere einen öffentlichen
Schlüssel
KPUBT des Inhabers, den öffentlichen
Schlüssel
KPUBD des Vertreters D, die Vertreteridentität IDD, ein Delegationsattribut
ATD vom Typ "Vertreter", oder eine Erwähnung "im Auftrag von" oder "in Vertretung von", vorzugsweise gefolgt
vom Namen des Inhabers T, einer vom Inhaber T festgelegten Delegationsdauer DD,
und anderen Attributen, die notwendig sein können, um den Vertreter D bevollmächtigen
zu können. Alle
im Zertifikat C2D enthaltenen vorhergehenden Daten werden an einen
asymmetrischen Algorithmus AA2 angewendet, der im geladenen Applet
AP2 enthalten ist und dessen Schlüssel aus dem privaten Schlüssel KPRT
des Inhabers T besteht, der dem öffentlichen
Schlüssel
KPUBT entspricht. Der im Unterschritt E5 ausgeführte Algorithmus AA2 liefert
eine Signatur ST des zweiten Zertifikats C2D.
-
Der
Inhaber T verhält
sich während
der Delegationsdauer DD wie eine elektronische Zertifizierungsstelle
für den
Vertreter D. Das Zertifikat C2D wird mittels eines Formulars erstellt,
das auf dem Bildschirm des Terminals TET angezeigt wird, damit der
Benutzer T bestimmte Daten darin einträgt, wie zum Beispiel die Delegationsdauer
DD, eine Identität des
Inhabers wie der Name oder ein Beiname des Inhabers im Delegationsattribut
ATD, usw.
-
In
einer einfachen Variante enthält
das zweite Zertifikat C2D keine besondere Option betreffend die
Attribute, und enthält
insbesondere nicht das Delegationsattribut ATD, da der Inhaber T,
der dieses Zertifikat ausgegeben hat, bereits Besitzer eines Zertifikats
ist, das ihn berechtigt zu delegieren.
-
Gemäß einer
anderen Variante erzeugt ein Zufallsgenerator im Vertreterterminal
TED einen zweiten öffentlichen
Schlüssel
KPUB2D sowie einen zweiten privaten Schlüssel KPR2D, die der Delegation
gewidmet sind und dazu dienen, Mitteilungen nur für vom Inhaber
T an den Vertreter D delegierte Aktionen zu sichern und mit dem
Terminal TED auszutauschen. Wie gestrichelt im Schritt E23 in 2 dargestellt,
ist der zweite öffentliche
Schlüssel
KPUB2D in der Neuzertifizierungsanforderung RRC im Schritt E3 enthalten,
und das Inhaberterminal TET entnimmt aus der gesicherten Neuzertifizierungsanforderung RRC
den öffentlichen
Schlüssel
KPUB2D, um ihn in das zweite Zertifikat C2D einzufügen, das
anstelle des normalen öffentlichen
Schlüssels
KPUBD des Vertreters D zu erstellen ist.
-
Dann überträgt im Schritt
E6 das Applet AP2 im Terminal TET das zweite Zertifikat C2D an das Vertreterterminal
TED über
den Server SRT, das Netz RT und den Server SRD, oder in Form einer elektronischen
Postmitteilung.
-
Im
Vertreterterminal TED weist der Schritt E7 zur Validierung des zweiten
elektronischen Zertifikats C2D Unterschritte E71 bis E76 auf.
-
Im
Unterschritt E71 sichert das Terminal TED das empfangene Zertifikat
C2D zum Beispiel auf seiner Festplatte oder in einem RAM-Speicher.
Im Unterschritt E72 ruft das Terminal TED dann in einem dritten
Applet-Server SA3,
der von der Zertifizierungsstelle ACT abhängt, ein drittes Applet AP3
ab, das dazu bestimmt ist, das empfangene Zertifikat C2D zu validieren,
wenn das Applet nicht bereits in das Terminal TED geladen ist. Der
Server SA3 kann mindestens mit dem Server SA1 vereinigt werden, um
ein Applet AP1 zu laden, das mit dem Applet AP3 im Schritt E21 vereinigt
ist. Gemäß einer
anderen Variante werden die Applet-Server SA1, SA2 und SA3 in einem
einzigen Server fusioniert, der die Applets AP1, AP2 und AP3 enthält.
-
Nach
einer Überprüfung des
Formats des empfangenen Zertifikats C2D im Unterschritt E73 führt das
Terminal TED die Validierung des Zertifikats C2D durch, indem die
in diesem enthaltenen Daten und der öffentliche Schlüssel KPUBT,
der ebenfalls im Applet AP3 enthalten ist, an den asymmetrischen Algorithmus
AA2 angewendet werden, der im Zertifikat C2D identifiziert und im
Applet AP3 abgerufen wird. Die Ausführung des Algorithmus AA2 erzeugt eine
Signatur ST', die
im Unterschritt E75 mit der Signatur ST verglichen wird, die aus
dem empfangenen Zertifikat C2D entnommen wird. Wenn in den Unterschritten
E73 oder E75 die Überprüfung oder
die Validierung nicht zufriedenstellend ist, weist das Terminal
des Vertreters TED das zweite Zertifikat C2D zurück, zum Beispiel, indem es
eine vorbestimmte Zurückweisungsmitteilung
an das Terminal TET überträgt. Im gegenteiligen
Fall speichert das Terminal TED das so validierte Zertifikat C2D
während
der ganzen Dauer der Delegation DD, um das zweite Zertifikat C2D
und insbesondere seinen privaten Schlüssel KPRD oder KPR2D für verschiedene
kryptographische Aktionen zu nutzen, die vom Vertreter D insbesondere
ausgehend vom Vertreterterminal TED im Namen des und für den Inhaber
T ausgeführt
werden.
-
Je
nach dem Träger
des Vertreter-Verbundschlüssels
[KPUBD, KPRD] wird das zweite Zertifikat C2D mehr oder weniger automatisch
in das Vertreterterminal TED integriert. Wenn der Vertreter-Verbundschlüssel ein
Softwareschlüssel
ist, der von einem Browser, oder von einem Werkzeug des Abrufens und
der Übertragung
einer elektronischen Mitteilung, oder von einem Betriebssystem,
oder von einem Software-Server wie dem erwähnten Server SRD, oder von
jeder anderen geeigneten Software, die im Terminal TED installiert
ist, verwaltet wird, wird das Zertifikat C2D von dieser Software
in das Terminal TED integriert, um über dieses zweite Zertifikat
in Übereinstimmung
mit dem existierenden Vertreter-Verbundschlüssel zu verfügen, um
es später
für alle
delegierten Aktionen zu verwenden.
-
Gemäß einer
anderen Variante, wenn der Vertreter-Verbundschlüssel [KPUBD, KPRD] oder allgemeiner
das Vertreterzertifikat C1D in einem herausnehmbaren Hardware-Speicherträger des
Vertreterterminals TED, wie einer Chipkarte oder einem USB-Stick
(token USB (Universal Serial Bus)), gespeichert ist, fordert das
Verwaltungswerkzeug in diesem Träger
selbst die Neuzertifizierung des existierenden öffentlichen Vertreterschlüssels und
befiehlt die Speicherung des zweiten Vertreterzertifikats C2D im
herausnehmbaren Träger
im Schritt E7. Wenn ein zweiter Schlüssel [KPUB2D, KPR2D] im Schritt
E2 erzeugt wird, integriert das Verwaltungswerkzeug des Trägers das
zweite Zertifikat C2D. Die Einführung
des zweiten empfangenen Zertifikats C2D in den herausnehmbaren Hardwareträger ist vorzugsweise
automatisch, ohne Eingreifen des Vertreter-Benutzers D. In einer
Variante kann diese Einführung
des zweiten Zertifikats aber halbautomatisch erfolgen, indem der
Vertreter D durch Anzeige im Terminal TED aufgefordert wird, den
herausnehmbaren Hardwareträger
in das Terminal TED einzuführen, um
dort das Zertifikat C2D zu speichern. Der herausnehmbare Speicherträger ermöglicht es
dem Vertreter, jedes andere Terminal für delegierte Aktionen zu verwenden, das
mit einem entsprechenden Lesegerät
für den
herausnehmbaren Speicherträger
ausgestattet ist.
-
Wenn
der private Schlüssel
KPRD des Vertreters D kompromittiert wurde, d.h. mindestens einem
Dritten bekannt ist, oder entwendet wurde, widerruft der Vertreter
D alle diese auf diesem Schlüssel
beruhenden Zertifikate, einschließlich des Delegationszertifikats
C2D. Um das Zertifikat C2D zu widerrufen, wendet das Terminal TED
sich an einen Widerrufserver, der dem Vertreter D bekannt ist und
der vom Inhaber installiert und mit dem Server ACD der Zertifizierungsstelle
des Vertreters verbunden sein kann, oder wendet sich direkt oder über einen
persönlichen
Server, der dem Delegationswiderruf gewidmet ist, an den Zertifizierungsstellenserver
ACT des Inhabers T.
-
Gemäß noch einer
anderen Variante, beim Erstellen des Delegationszertifikats C2D
im Schritt E5, fügt
das Terminal TE in die Daten des zweiten Zertifikats C2D Informationen
bezüglich
eines Widerrufs des Zertifikats C2D ein, zum Beispiel die Adresse
eines vorbestimmten Widerrufservers.
-
Um
den Aufbau der Vertrauenskette ausgehend vom Delegationszertifikat
C2D zu vereinfachen, fügt
das Vertreterterminal TED das Inhaberzertifikat CT dem Delegationszertifikat
C2D für
jede vom Inhaber T delegierte Aktion bei. Gemäß dieser Variante ist das Zertifikat
CT des Inhabers T ebenfalls in den Daten des zweiten Zertifikats
C2D enthalten, das vom Inhaberterminal TET an das Vertreterterminal
TED im Schritt E6 übertragen
wird, damit das Terminal TED das Inhaberzertifikat CT aus dem gesicherten Zertifikat
C2D entnimmt.
-
Ausgehend
vom Inhaberzertifikat CT wird die Vertrauenskette wie bei einer
nicht vorhandenen Delegation für
eine beliebige Vertrauenskette erstellt und überprüft. Die Überprüfung der Delegations-Vertrauenskette,
d.h. einschließlich
mit dem Delegationszertifikat C2D, bedingt die Überprüfung der Attribute insbesondere
im Inhaberzertifikat CT durch die Zertifizierungsstelle ACT und
im Delegationszertifikat C2D durch das Terminal TET.
-
Gemäß noch einer
anderen Variante werden insbesondere die Anfangsschritte E2, E3
und E4 bezüglich
des Aufbaus und der Übertragung
der Neuzertifizierungsanforderung RRC und der Validierung der elektronischen
Signatur SKD unterdrückt,
um die Ausführungsgeschwindigkeit
der elektronischen Zertifizierung gemäß der Erfindung zu erhöhen. In
dieser Variante beginnt die elektronische Zertifizierung vor dem
Schritt der Zertifikaterstellung E5 durch eine Erzeugung eines privaten
Schlüssels
KPRT des Inhabers T im Terminal TET, damit das Terminal TET im Schritt
E5 die Signatur ST der Daten des Zertifikats C2D mittels des erzeugten
privaten Schlüssels
KPRT erstellt. Die Daten wie der öffentliche Schlüssel KPUBT
des Inhabers und diejenigen KPUBD, ATD, DD, die im ersten Vertreterzertifikat
C1D enthalten sind, wurden vorher im Terminal TET gespeichert. Dann
wird der erzeugte private Schlüssel
KPRT im Wesentlichen parallel mit dem zweiten elektronischen Vertreterzertifikat
C2D im Schritt E6 an das Vertreterterminal TED übertragen; zum Beispiel wird der
private Schlüssel
KPRT im Terminal TET in Abhängigkeit
von einem Passwort verschlüsselt,
das vom Inhaber T verfasst wird, oder von einem Kanal übertragen,
wie eine mündliche Übertragung über das
Telefon zwischen dem Inhaber T und dem Vertreter D, der ein anderer
ist als der Übertragungskanal zwischen
den Terminals TET und TED über
das Netz RT.