-
HINTERGRUND DER ERFINDUNG
-
1. GEBIET DER ERFINDUNG
-
Die
Erfindung betrifft Zertifikate, die zur Identifikation ausgegeben
werden, und insbesondere betrifft sie die Ermittlung der Validität eines
Zertifikats.
-
2. BESCHREIBUNG DES STANDES
DER TECHNIK
-
Üblicherweise
sind gesicherte Tokens physikalisch gesicherte, manipuliersichere
Einrichtungen, die dazu bestimmt sind, digitale Signaturen zu erzeugen,
eine Entschlüsselung
zu leisten oder andere Vorgänge
durchzuführen,
bei denen ein privater Schlüssel
oder ein sicherer symmetrischer Schlüssel verwendet wird. Tokens
können
hardwaremäßig in einen
Computer eingebaut sein oder sie können in mobile Einrichtungen
wie beispielsweise „Smart Cards" und drahtlose Einrichtungen
integriert sein. Die kryptographische Implementierung und das Schlüsselmaterial
sind in einer sicheren Ummantelung eingeschlossen, so dass eine
korrekte Funktion und Verwendung des Schlüssels gewährleistet werden können. Normalerweise
wird der Schlüssel
nur nach dem Vorliegen einer geeigneten PIN oder eines Passwort
verwendet werden. Der Schlüssel
wird generell nur für
genehmigte sichere Operationen verwendet, und der Aufbau des Tokens
ist dergestalt, dass dieser Schlüssel
nicht außerhalb
der sicheren Ummantelung offenbart werden wird und somit nicht kopiert
werden kann. Oftmals enthält
ein gesichertes Token eine Signiermaschine [signing engine] und
einen privaten Schlüssel, α, für den der öffentliche Schlüssel A ist.
Der öffentliche
Schlüssel
wurde von einer Zertifizierungsautorität (CA) zertifiziert, die das Zertifikat
CA ausgegeben hat. Das Token steht mit einer
Anwendung in Kommunikationsverbindung, die von dem Token zur Erzeugung
einer digitalen Signatur, zum Entschlüsseln von Daten oder dergleichen Gebrauch
macht. Die Anwendung übermittelt
eine Anfrage zusammen mit einer PIN oder einem Passwort an die Verschlüsselungsmaschine
in dem Token und die Verschlüsselungsmaschine
führt die
Anfrage unter Verwendung des privaten Schlüssels aus. Die Anfrage kann
dazu dienen, eine Nachricht zu unterzeichnen, eine verschlüsselte Nachricht
oder irgendeine andere Anfrage, die die Verwendung des privaten
Schlüssels
erfordern würde,
zu entschlüsseln.
Für jede
Anfrage, die von einer Anwendung gestellt wird, muss eine CA die
Vali dität
dieser Anfrage beurteilen, und deswegen muss die Validität sowohl auf
der Sende- als auch der Empfangsseite beurteilt werden.
-
Die
Infrastruktur zur Verwaltung und Distribution von öffentlichen
Schlüsseln
(PKI) muss nachgewiesenermaßen
ein sicherer Mechanismus zur sicheren Verteilung von Schlüsseln und
zum sicheren Anhängen
von Attributen an solche Schlüssel
sein. Es ist vorgesehen, eine Identität an einen öffentlichen Schlüssel anzuhängen, so
dass der Halter des entsprechenden privaten Schlüssels als einer mit bestimmter
Identität
bekannt ist. Um diese Aufgabe auszuführen werden Zertifikate ausgegeben,
bei denen es sich um Dokumente handelt, die eine Identität mit einem öffentlichen
Schlüssel
verknüpfen.
Diese Verknüpfung
wird allgemein durch eine digitale Signatur einer Zertifizierungsautorität erzwungen.
Eine CA ist eine zuverlässige
Entität,
der man vertraut, dass sie in sicherer Weise Zertifikate bereitstellt,
die Signaturen auf Individuen und Identitäten übertragen, die dazu in der
Lage sind, deren Identität
zu verifizieren. Eine Gruppe von Mitgliedern, die einer gemeinsamen
CA Vertrauen schenken, bilden eine Infrastruktur zur Verwaltung
und Distribution von öffentlichen
Schlüsseln.
Die Druckschrift WO 98/52163 offenbart ein System mit einer Infrastruktur
zur Verwaltung und Distribution von öffentlichen Schlüsseln, bei dem
alle Operationen mit privaten Schlüsseln (private-key-operations)
auf einer IC-Karte durchgeführt werden.
Wenn ein Mitgliederpaar in einer PKI wünscht, miteinander zu kommunizieren,
müssen
sie die Echtheit des Zertifikats des anderen verifizieren. Die Schwierigkeit
dabei ist, wenn man laufend versucht zu ermitteln, ob ein Zertifikat
gültig
ist, und umgekehrt, wann man ein widerrufenes Zertifikat zurückweisen
muss. Verfahren, die vorgeschlagen wurden, um diese Schwierigkeit
zu überwinden,
sind in verschiedene Kategorien einzuordnen, nämlich kurzlebige Zertifikate,
Online-Status [on-line status] und Zurückweisungslisten [revocation
list].
-
Ausgegebene
kurzlebige Zertifikate sind nur für eine kurze Zeitspanne gültig, beispielsweise
24 Stunden. Diese Zertifikate werden regelmäßig neu herausgegeben, so dass
immer ein aktuelles und gültiges
Zertifikat vorhanden ist. Sich darauf verlassende Parteien müssen die
aktuelle Validität
des Zertifikats nicht verifizieren. Wenn die Sicherheit eines privaten
Schlüssels
gefährdet
ist und dieser Umstand der Zertifizierungsautorität berichtet
wurde, endet das Fenster der Verwundbarkeit dann, wenn das aktuelle
Zertifikat ausläuft
und das Zertifikat nicht neu herausgegeben wird. Kurzlebige Zertifikate
machen es aber erforderlich, dass die Zertifizierungsautorität alle ausstehenden
Zertifikate regelmäßig neu
herausgibt. Dieser Prozess kann rechenmäßig teuer sein und einen automatisierten
Online-Zugang zu dem Schlüssel
zum Signieren des Zertifikats erfordern. Dieser Umstand macht den
Prozess wiederum verletzlicher gegenüber einem Angriff als eine
CA, die ihren Schlüssel
offline und/oder weniger automatisiert verfügbar halten kann. Des Weiteren
haben kurzlebige Zertifikate ein inhärentes Fenster der Verletzbarkeit
von dem Zeitpunkt an, an dem der private Schlüssel festgelegt wurde, bis
zu dem Zeitpunkt, an dem das Zertifikat ausläuft. Außerdem ist das regelmäßige neuerliche
Herausgeben und Verteilen der Zertifikate teuer und schwierig an
größere System anzupassen
und es hat einen einzigen Fehlerpunkt für die gesamte PKI.
-
Ein
Zertifizierungsprozess ist in dem US Patent 5,982,898 von Hsu et
al. beschrieben. Hsu schafft eine sichere Kommunikationsanordnung,
die eine kurze Lebensdauer eines Zertifikats dazu benutzt, Listen,
die ungültig
erklärte
Zertifikate enthalten [certficate revocation lists], zu vermeiden.
-
Ein
anderes Verfahren zum Garantieren der Validität eines Zertifikats besteht
darin, den Online-Status
eines Zertifikates zu jedem Zeitpunkt, an dem das Zertifikat vorgelegt
wird, festzustellen. Bei der Vorlegung eines Zertifikats fordert
die sich darauf verlassende Partei die aktuelle Validität des Zertifikats
von der Zertifizierungsautorität
an. Aus Leistungsgründen
kann eine Implementierung ein Caching umfassen, so dass der Status
eines Zertifikats von der Zertifizierungsautorität nur abgefragt werden kann,
wenn die letzte Anfrage nach dessen Status lang genug vorher erfolgte,
so dass diese als „alt" erachtet werden
kann. Die Online-Überprüfung des Zertifikatsstatus
macht es erforderlich, dass jede sich darauf verlassende Partei
die CA oder deren designierten Vertreter jedes Mal, wenn eine Transaktion durchgeführt wird,
kontaktiert. Sogar wenn für
die Validität
des Zertifikats etwas Caching verfügbar ist, beträgt die Anzahl
der Anfragen ungefähr
1 pro Aktion und vertrauender Partei. Außerdem bedingen einige Systeme
wiederholte Transaktionen mit der gleichen Partei. Des Öfteren tritt
der Fall auf, dass jede Transaktion das erste Mal ist, dass eine
vertrauende Partei mit der zertifizierten Partei für eine Zeitspanne
kommunizierte, sogar in dem Fall, wo jede Partei andauernd in Transaktionen
eingebunden ist. Darüber
hinaus erfordert der Online-Status, dass alle vertrauenden Parteien
die Fähigkeit
haben, die CA zu kontaktieren, wann immer sie es wollen, um ein
Zertifikat zu validieren.
-
Ein
drittes Verfahren, um die Validität von Zertifikaten sicherzustellen,
besteht darin, eine Liste mit Zurückweisungen durchzuschauen.
Eine Liste mit Zurückweisungen
beschreibt ausführlich
Zertifikate, die für
ungültig
erklärt
wurden, beispielsweise wurden sie widerrufen und werden von der
Zertifizierungsautorität
gehalten. Die Liste wird für
vertrauende Parteien bereitgestellt und regelmäßig und/oder wenn neue Zertifikate
zurückgewiesen
sind aktualisiert. Eine vertrau ende Partei überprüft die Zurückweisungsliste, um sicherzustellen,
dass ein Zertifikat nicht auf der Liste auftaucht, bevor ein Zertifikat
als gültig
akzeptiert wird. Die Liste kann in Form einer einfachen Zertifikatsliste
vorliegen oder sie kann irgendeine andere Verfahrensweise umfassen,
um die zurückgewiesenen
Zertifikate mitzuteilen. Zurückweisungslisten
können
in bestimmten Situationen ziemlich groß werden, wenn viele zurückgewiesene
Zertifikate vorhanden sind. Außerdem
muss die Liste regelmäßig neu
ausgegeben und an die vertrauenden Parteien verteilt werden. Überdies
beschreiben Zurückweisungslisten
nur die Validität
eines Zertifikats zu dem Zeitpunkt, an dem sie ausgegeben wurden. Wenn
ein Zertifikat widerrufen wurde, wird die Information bezüglich des
Widerrufs für
die vertrauende Partei solange nicht verfügbar sein, bis das regelmäßige Update
der CRL erfolgt ist. Wenn die CRL vor ihrem regelmäßigen wiederkehrenden
Zeitpunkt aktualisiert wird, muss die vertrauende Partei die CA
kontaktieren, um bestätigt
zu bekommen, dass deren lokale CRL aktuell ist. Dies führt dazu,
dass man die gleichen Leistungscharakteristika wie beim Online-Überprüfen des
Status des Zertifikats erhält.
-
Die
meisten Bewertungen der Gültigkeit
von Zertifikaten von Zertifizierungsautoritäten wie beispielsweise Online-Nachrichten
betreffend den Status eines Zertifikats oder Zertifikatswiderrufslisten tragen
Signaturen von der CA oder irgendeiner Entität, die von der CA autorisiert
ist, um einen Zertifikatsstatus auszugeben. Diese Signatur ist notwendig,
um die Genauigkeit der Information anzuzeigen. Sogar wenn eine Angabe
wie „die
aktuelle CRL hat sich nicht geändert,
es gibt keine nachfolgende Aktualisierung" muss signiert werden. Des Weiteren
müssen
die meisten Statusnachrichten für
jeden Anfordernden signiert sein, um wiederholte Attacken zu verhindern.
Protokolle sind so gestaltet, dass der Anfordernde sicher ist, dass
die Nachricht spezifisch für ihn
signiert wurde und es sich nicht um eine alte Nachricht handelt,
die von einem Angreifer wiedergegeben wird. Dies kann eine sehr
hohe Rechen- und Kommunikationslast für die CA und deren autorisierte
Vertreter erzeugen. Das Ergebnis ist ein System, das nicht besonders
skalierbar ist.
-
Mit
existierenden Verfahren, wie sie oben beschrieben wurden, wird die
Validität
eines Zertifikats durch die vertrauende Partei zum Zeitpunkt des
Vertrauens auf ein Zertifikat festgestellt und ist somit Gegenstand
irgendwelcher Fehlerfenster, die von einer Verzögerung beim Aktualisieren von
Validitätsinformationen
resultieren. Dies kann sowohl zu positiven als auch negativen Fehlern
führen.
In einem Fall, bei dem eine vertrauende Partei eine Nachricht sendet, ermittelt
die vertrauende Partei, dass ein Zertifikat gültig ist, verschlüsselt die
Nachricht und sendet sie. Zu irgendeinem späteren Zeitpunkt wird der private Schlüssel des
Empfängers
kompromittiert und das Zertifikat des Empfängers widerrufen. Alle vorhandenen
verschlüsselten
Nachrichten können
aber weiterhin entschlüsselt
werden, sogar wenn das Zertifikat nicht länger gültig ist. Des Weiteren kann
in dem Fall, bei dem ein Benutzer eine gültige Signatur unter Verwendung
seines privaten Schlüssels
erzeugt, und dann dieser private Schlüssel später kompromittiert wird und
das Zertifikat widerrufen wird, die Signatur nicht länger gültig sein,
sogar wenn sie korrekt und sicher erzeugt wurde. Das Problem beruht
auf dem Umstand, dass die Validität eines Zertifikats die Verwendung
des öffentlichen
Schlüssels
kontrolliert, da durch die vertrauenden Parteien konsultiert wird,
wer ein Zertifikat verwenden darf. Die Validität eines Zertifikats kommuniziert
aber auch die Sicherheit des privaten Schlüssels, so dass ein Zertifikat
widerrufen wird, wenn der Halter des privaten Schlüssels nicht länger mit
der Identität
oder den Privilegien, die in dem Zertifikat kommuniziert werden,
in Verbindung gebracht werden kann.
-
Es
ist eine Aufgabe der vorliegenden Erfindung, zumindest einige der
zuvor genannten Nachteile des Standes der Technik zu umgehen und
zu entschärfen.
-
DARSTELLUNG
DER ERFINDUNG
-
Es
ist somit ein primäres
Ziel der vorliegenden Erfindung, ein System für die Prüfung der Validität der Authentizität eines
Zertifikats zum Zeitpunkt der Benutzung eines privaten Schlüssels einzurichten.
-
Allgemein
ausgedrückt
schafft diese Erfindung ein System zum Erleichtern der Prüfung der
Validität
eines ausgegebenen Zertifikats, und ferner ermöglicht sie es der vertrauenden
Partei ein Zertifikat auszuführen,
wissend, dass das Zertifikat gültig
ist, ohne dass dessen Validität
unabhängig
geprüft
werden muss. Das System umfasst eine kryptographische Maschine,
eine Validierungsmaschine, zumindest ein Interface zu einer Zertifizierungsautorität und eine
unabhängige
Anwendung. Die Anwendung kommuniziert eine Anfrage an die kryptographische Maschine
innerhalb eines gesicherten Tokens zusammen mit einem Personenkennzeichen.
Das gesicherte Token enthält
ferner eine Signiermaschine und einen privaten Schlüssel „α" für einen
bekannten öffentlichen
Schlüssel „A". Die kryptographische
Maschine führt
die Anfrage unter Verwendung des privaten Schlüssels aus. Bei jeder Anfrage
durch die Anwendung, den privaten Schlüssel „α" zu benutzen (zur Erzeugung einer Signatur,
Entschlüsseln
einer Nachricht oder irgendeinem anderen zugelassenen Zweck), wird
die Validierungsmaschine aufgerufen. Die Validierungsmaschine hat
die Fähigkeit,
es zuzulassen oder nicht zuzulassen, dass die angeforderte Operation unter
Verwendung eines privaten Schlüssels
vollständig
abgearbeitet wird. Bei jeder derartigen Anfrage ermittelt die Validierungsmaschine,
ob ein Zertifikat zu diesem Zeitpunkt bzw. aktuell als gültig zu
behandeln ist und arbeitet entsprechend.
-
Eine
Anfrage, wie beispielsweise eine Signatur, wird nur erzeugt (oder
eine Nachricht wird nur entschlüsselt),
wenn das Zertifikat weiterhin gültig
ist. Somit muss eine vertrauende Partei, die den öffentlichen
Schlüssel
des Zertifikats CA benutzt, keine unabhängige Ermittlung
der Gültigkeit
des Zertifikats durchführen.
Im Fall einer Signatur impliziert die Existenz einer signierten
Nachricht, dass das Zertifikat zu dem Zeitpunkt, zu dem die Signatur
erzeugt wurde, gültig
war, und somit, dass eine Signatur als akzeptabel zu behandeln ist.
Diese Feststellung erfordert nicht, dass die vertrauende Partei
die Zertifizierungsautorität
kontaktiert, da die Validierungsmaschine, die mit dem privaten Schlüssel verknüpft ist,
diesen Vorgang ausgeführt
hat. Wenn die vertrauende Partei eine verschlüsselte Nachricht erzeugt, die
für den Halter
des Zertifikats CA bestimmt ist, können die
vertrauende Partei und der Zertifikatshalter gleichfalls auch sicher
sein, dass die Nachricht nur entschlüsselt werden kann, wenn das
Zertifikat zum Zeitpunkt der Entschlüsselung gültig ist.
-
Durch
diese Funktionsweise erhält
man den zusätzlichen
Vorteil, dass die Ermittlung der Validität eines Zertifikats zum Zeitpunkt
der Benutzung des privaten Schlüssels
erfolgt, anstatt zum Zeitpunkt des Zertifikatsverfrauens. Bei der
Verwendung eines Tokens, das eine Validierungsmaschine enthält, kontrolliert
die Validität
eines Zertifikats die Benutzung des privaten Schlüssels und
bindet somit die Bedeutung eines Zertifikatswiderrufs an die Wirkung
des Widerrufs und dies verhindert wiederum die weitere Benutzung
eines zertifizierten privaten Schlüssels.
-
Um
der vertrauenden Partei sicher mitzuteilen, dass für den Empfänger keine
Notwendigkeit besteht, die Validität des Zertifikats zu verifizieren,
wird eine Zertifikatserweiterung, die von der CA signiert ist, angefügt, wenn
die CA ein Zertifikat ausgibt. Wenn eine vertrauende Partei ein
Zertifikat mit dieser Erweiterung verarbeitet, ist sie sich somit
bewusst, dass es nicht notwendig ist, die Validität des Zertifikats
unabhängig
zu überprüfen. Wenn
ein Zertifikat keine solche Erweiterung besitzt, kann nicht von
der Gültigkeit
des Zertifikats ausgegangen werden, ohne dass dessen Validität unabhängig verifiziert
wird.
-
Die
Validierungsmaschine kann ferner feststellen, ob die Benutzung eines
privaten Schlüssels „α" mit einer bestimmten
Verfahrensweise, die mit der Verwendung des privaten Schlüssels ver knüpft ist, vereinbar
ist. Die Verfahrensweise ist von dem Endbenutzer anpassbar. Wenn
das Zertifikat gültig
ist und die Verwendung des Schlüssels
sachgemäß ist, wird
zugelassen, dass der Vorgang unter Verwendung des privaten Schlüssels vollständig ausgeführt wird,
wenn nicht, wird der Vorgang unter Verwendung des privaten Schlüssels beendet.
Die Validierungsmaschine arbeitet in solch einer Weise, dass deren Ermittlung,
ob ein Zertifikat gültig
ist, manipulationssicher und gegen Einwirkung durch irgendeine Partei,
die das Token oder die Kommunikationskanäle des Tokens mit der Außenwelt
kontrolliert, sicher ist. Dies trifft insbesondere auf Kommunikationskanäle mit Parteien
zu, die die Validierungsmaschine bei ihrer Ermittlung, ob das Zertifikat
Gültigkeit
hat, assistieren.
-
KURZE BESCHREIBUNG
DER ZEICHNUNGEN
-
Diese
und weitere Merkmale der bevorzugten Ausführungsformen der Erfindung
werden anhand der nachfolgenden detaillierten Beschreibung, in der
auf die beigefügten
Zeichnungen Bezug genommen wird, deutlich, wobei:
-
1 ein
schematisches Übersichtsschaubild
eines Computersystems ist,
-
2 eine
vergrößerte Ansicht
des gesicherten Tokens der 1 ist,
-
3 eine
weitere detaillierte Ansicht der 2 ist,
-
4 ein
funktionelles Blockdiagramm ist, das das Verfahren zur Herstellung
eines Zertifikats zur Verwendung bei der Validierung einer Anfrage zwischen
einem Paar von Knoten einer Infrastruktur eines öffentlichen Schlüssels in
dem Computersystem der 1 ist, und
-
5 eine
weitere detaillierte Ansicht der 3 ist.
-
BESCHREIBUNG
DER BEVORZUGTEN AUSFÜHRUNGSFORMEN
-
In
den 1 bis 5 ist ein System zur Ermittlung
der Gültigkeit
der Authentizität
eines Zertifikats dargestellt und dieses System ist allgemein mit dem
Bezugszeichen 10 gekennzeichnet.
-
Wie
in der 1 gezeigt, umfasst das System eine Anwendung 14,
die von einem absendenden Korrespondierenden 15 gesteuert
wird, einen empfangenden Korrespondierenden 18 und eine Zertifizierungsautorität (CA) 16,
die durch Kommunikationsverbindungen 19 mit einem gesicherten
Token 12 verbunden ist. Das gesicherte Token 12 enthält ferner,
wie in der 2, gezeigt, eine Validierungsmaschine 20,
ein Zertifikat 22, eine kryptographische Maschine 26 und
einen privaten Schlüssel 24,
die alle in einer sicheren Umgebung 25 gespeichert sind.
-
Das
System 10 ermöglicht
einer Anwendung 14 (die durch dritte Benutzer befehligt
wird), eine Anfrage über
einen Link 19a an das gesicherte Token 12 zu übersenden.
Die Anfrage kann darin bestehen, eine Nachricht zu unterzeichnen,
eine verschlüsselte Nachricht
zu entschlüsseln
oder sie kann irgendeine andere Aktion umfassen, welche die Verwendung
eines privaten Schlüssels
erfordern würde.
Nach Erhalt der Anfrage von der Anwendung 14 kommuniziert das
gesicherte Token 12 über
den Link 19b mit der Zertifizierungsautorität (CA) 16,
um die Validität
des Zertifikats 22 (oder ob die Anfrage erfüllt werden kann)
zu beurteilen. Die Zertifizierungsautorität 16 sendet eine Autorisierung,
mit der der Status des Zertifikats 22 angezeigt wird, an
das gesicherte Token 12 zurück und, wenn das Zertifikat
gültig
ist, ermöglicht diese
es dem Token 12 die Anfrage auszuführen und hängt das Zertifikat 22 an.
Die ausgeführte
Anfrage und das Zertifikat 22 werden entweder an die Anwendung 14 weitergesandt
oder direkt zu dem Endbenutzer 18 übermittelt. Sobald der Benutzer 18 das
Zertifikat 22 empfängt,
kann der Benutzer 18 sicher sein, dass die Zertifizierungsautorität 16 das
Zertifikat 22 zum Zeitpunkt des Beantwortens der Anfrage
validiert hat. Somit besteht für
den Benutzer 18 keine Notwendigkeit, die Validität des Zertifikats
zu authentifizieren.
-
Die 4 zeigt
detaillierter die Weise, mit der eine Signatur unter Verwendung
des Systems 10, das in den 1 und 2 gezeigt
ist, validiert wird. Der Prozess 100 beginnt damit, dass
eine Anwendung 14 auf eine Nachricht, m, hin eine Signatur
bei dem Schritt 102 von dem gesicherten Token 12 anfordert.
Nach Empfangen der Anfrage sendet die Validierungsmaschine 20 innerhalb
des Tokens 12 bei dem Schritt 104 eine Anfrage
an die Zertifizierungsautorität
16, um zu ermitteln, ob das Zertifikat 22 gültig ist,
und kann bei dem Schritt 106 angehängt werden. Wenn das Zertifikat 22 widerrufen
wurde, wird keine Autorisierung ausgegeben und die Anfrage beim
Schritt 108 verweigert. Wenn das Zertifikat 22 aber
gültig
ist, sendet die Zertifizierungsautorität 16 beim Schritt 110 eine
Autorisierung an das gesicherte Token 12. Die Validierungsmaschine 20 erhält die Autorisierung
und ermöglicht
es der kryptographischen Maschine 26 innerhalb des gesicherten
Tokens 12, die ursprüngliche
Anfrage 112 auszuführen,
wobei eine digitale Signatur unter der Verwendung des privaten Schlüssels „α" erzeugt wird. Sobald
die Nachricht m signiert ist, wird das Zertifikat 22 angehängt und
beim Schritt 114 an die Anwendung 14 zurückgesandt.
Die Anwendung 14 sendet wiederum das Zertifikat 22 beim
Schritt 116 zu dem Benutzer 18. Hilfsweise wird
das Zertifikat 22 im Schritt 118 direkt zu dem
Benutzer 18 geschickt. Die Übertragung der Anfrage und
die Rücksendung
der Autorisierung werden in sicherer Weise unter Verwendung von
Protokollen mit öffentlichem
Schlüssel
ausgeführt,
um die Authentizität
der Anfrage sicherzustellen.
-
Die
Validierungsmaschine 20 innerhalb des gesicherten Tokens 12 ist
derart tätig,
dass, sobald sie die Validität
eines Zertifikats feststellt, der Endbenutzer 18 nicht
ebenfalls eine unabhängige
Validierung ausführen
muss. Die Validität
eines Zertifikats steuert die Verwendung des privaten Schlüssels 24 über die
Validierungsmaschine 20 und als solches verknüpft es die
Bedeutung des Widerrufs des Zertifikats mit der Wirkung dieses Widerrufs.
Dies verhindert eine weitere Verwendung eines zertifizierten privaten
Schlüssels,
wenn ein Zertifikat 22 zurückgewiesen wird. Im Falle einer
digitalen Signatur, wie sie in der 4 beschrieben
ist, würde
eine signierte Nachricht auch dann gültig bleiben, nachdem ein Zertifikat 22 widerrufen
wurde, da die Signatur nicht nach dem Zeitpunkt des Widerrufs des
Zertifikats erzeugt worden sein konnte. Im Fall, dass eine Anfrage
darin besteht, eine Nachricht zu entschlüsseln, wenn der private Schlüssel 24 kompromittiert
ist (durch Diebstahl des Tokens), wird das Zertifikat 22 widerrufen und
das gesicherte Token 12 würde damit aufhören, Anfragen
zu akzeptieren, um Nachrichten zu entschlüsseln, was bedeutet, dass irgendwelche
existierenden verschlüsselten
Nachrichten nicht mehr entschlüsselt
werden könnten.
-
In
der bevorzugten Ausführungsform
ist die Fähigkeit,
die es System 10 ermöglicht
zu vermeiden, dass der Benutzer 18 eine unabhängige Validitätsprüfung durchführen muss,
als Attribut des Zertifikats 22 enthalten. Um sicherzustellen,
dass der Benutzer 18 sich bewusst ist, dass die Validität des Zertifikats nicht überprüft werden
muss, ist eine Anzeigeeinrichtung erforderlich. Eine Möglichkeit
wie dies erzielt wird besteht darin, eine Zertifikatserweiterung 28 zu spezifizieren,
wie sie in der 3 gezeigt ist. Diese Zertifikatserweiterung 28 wird
durch die in der 1 gezeigte Zertifizierungsautorität 16 signiert,
wenn ein Zertifikat 22 durch die Zertifizierungsautorität 16 ausgegeben
wird, und sie wird nur angehängt,
wenn die Autorisierung von der CA 16 erhalten wird. Aufgrund dessen
ist sich der Benutzer bewusst, dass keine unabhängige Überprüfung der Validität des Zertifikats 22 erforderlich
ist, wenn der Benutzer 18 ein Zertifikat mit einer Erweiterung 28 verarbeitet.
In einem Fall, wo ein Zertifikat 22 keine Erweiterung besitzt, kann nicht
ohne unabhängige Überprüfung von
dessen Validität
davon ausgegangen werden, dass es gültig ist.
-
In
einer alternativen Ausführungsform
könnte
dieses Attribut aber implizit mit dem Schlüsselpaar verknüpft sein.
Eine implizite Schlüsselpaarverknüpfung erfordert
einen Mechanismus oder eine Vorgehensweise, um eine CA daran zu
hindern, ein Zertifikat an das Schlüsselpaar auszugeben, ohne dass
die CA irgendeine Versicherung hat, dass das gesicherte Token 12,
das den privaten Schlüssel 24 bewahrt,
die Validität
des von der CA ausgegebenen Zertifikats fortlaufend überprüft, und
deshalb die Verwendung des auf diesen Informationen basierenden
privaten Schlüssels
kontrolliert.
-
Bevor
eine CA 16 ein Zertifikat 22 mit einer Erweiterung 28 ausgibt,
die anzeigt, dass der private Schlüssel in der zuvor beschriebenen
Weise kontrolliert wurde, muss die CA ermitteln, ob der private Schlüssel von
einem gesicherten Token 12 gehalten wird, das eine Richtlinie
zur Überprüfung der
Validität zwingend
fordern wird. Es ist aber auch wünschenswert,
es dem Token 12 zu ermöglichen,
ein Schlüsselpaar
zu erzeugen und dieses Schlüsselpaar
zertifiziert zu haben, während
das Token 12 unter der Kontrolle des Endbenutzers steht.
Dies ermöglicht
es dem Endbenutzer, die vollständige
Kontrolle über
die Benutzung des privaten Schlüssels
von dem Moment seiner Erzeugung an sicherzustellen.
-
Um
dem Endbenutzer von dem Token 12 zu der Zertifizierungsautorität 16 sicher
zu kommunizieren, dass ein privater Schlüssel 24 in dem gesicherten
Token 12 gespeichert ist, muss das Token 12 für den Schlüssel „bürgen". In der bevorzugten
Ausführungsform
ist dem Token 12 eine sicherer gesicherter Schlüssel 30 verliehen,
wie es in der 5 dargestellt ist. Das Token 12 verwendet
seinen eigenen sicheren gesicherten Schlüssel 30, um zu attestieren, dass
der private Schlüssel „α" 24, für welchen
eine Zertifizierung angefragt wird, innerhalb des gesicherten Tokens 12 erzeugt
wurde und wiederum, dass die Verwendung des Schlüssels 24 durch die
Validierungsmaschine 20 innerhalb des Tokens 12 gesteuert
wird. In einem Fall können
nur das Token 12 und die CA 16 können den
sicheren gesicherten Schlüssel 30 kennen,
oder es handelt sich um einem Mechanismus mit öffentlichem Schlüssel. Im
Fall eines Mechanismus mit öffentlichem
Schlüssel
besitzt aber das Token einen privaten Schlüssel, der entweder von der
CA programmiert wird oder innerhalb des Tokens dergestalt erzeugt
wird, dass der öffentliche Schlüssel gespeichert
oder zertifiziert wird, bevor das Token zu dem Endbenutzer geliefert
wird. Ungeachtet dessen, der Schlüssel, der das Token authentifiziert,
wird eingerichtet, abgespeichert oder zertifi ziert, bevor das Zertifikat
zu dem Endbenutzer übermittelt
wurde, so dass es bekannt ist, dass das Token nicht unerlaubten Änderungen
unterworfen wurde, und wiederum, dass der Authentifizierungsschlüssel des
Tokens authentisch ist.
-
Die
Beglaubigung durch das gesicherte Token 12 wird vor der Übersendung
an den Endbenutzer in einem sicheren Bereich ausgeführt. Das
gesicherte Token 12 wird aufgefordert, ein Schlüsselpaar zu
erzeugen, das den gesicherten Schlüssel 30 des Tokens
und einen entsprechenden öffentlichen Schlüssel umfasst.
Es speichert den privaten Schlüssel
sicher innerhalb des Tokens, wobei es ihn nur in dem Beglaubigungsvorgang
des Tokens benutzt. Der entsprechende öffentliche Schlüssel wird
von einer CA genommen und zertifiziert. Diese CA kann eine öffentliche
CA, eine von dem Hersteller des Tokens kontrollierte oder irgendeine
andere Autorität
sein. Durch die Ausgabe des Zertifikats attestiert die CA, dass
der private Schlüssel
durch ein Token 12, das das Zertifikat vorvalidiert, kontrolliert
wird. Das beglaubigte Zertifikat wird innerhalb des Tokens 12 abgespeichert,
wie es an der Stelle 32 angezeigt ist. Um diese Beglaubigung
auszuführen,
wird das Token 12 wahrscheinlich physisch innerhalb einer
gesicherten Einrichtung liegen müssen,
damit die CA sicher sein kann, dass sie einen korrekt erhaltenen öffentlichen Schlüssel zertifiziert.
-
Sobald
das Token 12 den gesicherten Schlüssel 30 und ein zugehöriges Zertifikat 32 in
sich abgespeichert hat, wird es an den Benutzer geliefert. Der Endbenutzer 18 fordert
das Token 12 auf, ein Schlüsselpaar für die aktuelle Benutzung zu
erzeugen, was es dann auch macht. Dann fordert der Endbenutzer 18 das
Token 12 auf, ein Zertifikat 22 anzufordern. Das
Token 12 erzeugt eine Zertifikatsanfrage und authentifiziert
diese Anfrage über
seinen Token-Beglaubigungsschlüssel 30.
In diesem Fall agiert das Token 12 als Erstzulassungsagent:
Es signiert die Zertifikatsanforderungsdaten mit seinem gesicherten
Schlüssel 30,
um dessen Validität
und dessen Schaffung innerhalb des Tokens 12 zu attestieren,
dann fügt
es sein eigenes Zertifikat 32 an. Die registrierte Anfrage
kann dann an die CA übermittelt werden.
Nach dem Erhalt dieser Anfrage kann die CA das beglaubigte Zertifikat
des Tokens (enthaltend möglicherweise
ein unabhängiges Überprüfen, ob das
Zertifikat des Tokens immer noch gültig ist) und dessen Signatur
auf die Zertifikatsanforderungsdaten validieren. Wenn der Überprüfungsprozess
erfolgreich verläuft,
gibt die CA ein Zertifikat aus mit dem Wissen, dass die private
Hälfte
des Schlüsselpaars, das
zertifiziert ist, sicher innerhalb eines Tokens 12 gehalten
wird, welches die Validität
des Zertifikats feststellt, bevor der private Schlüssel 24 benutzt
werden kann. Die CA hängt
eine Erweiterung 28 an das Zertifikat 22 an, welche
dem Endbenutzer anzeigt, dass eine vertrauende Partei nicht unabhängig den Widerrufsstatus
des Zertifikats überprüfen muss.
-
Zusätzlich zu
der Validierung des aktuellen Status eines Zertifikats kann die
Validierungsmaschine auch sicherstellen, dass die Benutzung des
privaten Schlüssels
einer bestimmten Verfahrensweise entspricht, bevor zugelassen wird,
dass eine Operation mit einem privaten Schlüssel abläuft. Diese Verfahrensweise
ist an einen spezifischen Endbenutzer einer Gruppe von Benutzern
wie beispielsweise ein Unternehmen anpassbar. Die Verfahrensweise
wird typischerweise in dem Zertifikat abgespeichert; sie kann aber
auch auf irgendeine andere Weise verknüpft werden. Beispielsweise
kann ein bestimmter Schlüssel
zur Verwendung beim Signieren von Nachrichten zugelassen sein und
nicht zur Entschlüsselung.
Komplexe Verfahrensweisen könnten
erzeugt und durchgesetzt werden, eventuell unter der Verwendung
von externen Kommunikationseinrichtungen. Ein gesichertes Token,
das an eine Zertifizierungsautorität eines Unternehmens ausgegeben wird,
könnte
eine Verfahrensweise durchsetzen, die es nur zulassen würde, dass
der private Schlüssel zum
Signieren von Zertifikaten für
Arbeitnehmer dieses Unternehmens verwendet werden kann, die auf irgendeinem
Stammblatt auftauchen oder die von irgendeinem anderen Server freigegeben
wurden. Eine derartige Verfahrensweise würde die Verwendung des Schlüssels, die
Profile der zu signierenden Zertifikate, die Inhalt einiger Felder
dieser Zertifikate und das Validieren von Informationen anderer
Felder in diesen Zertifikaten gegenüber einer externen Datenquelle
kontrollieren. Ähnliche
Verfahrensweisen könnten
in Bezug auf die Verfügbarkeit
von Daten, die unter Verwendung des privaten Schlüssels entschlüsselt werden,
erzeugt werden.
-
Es
gibt eine Vielzahl von Möglichkeiten,
bei denen das Token 12 benutzt werden kann, um festzustellen,
ob ein Zertifikat gültig
ist. Das Token 12 agiert oftmals als vertrauende Partei
und benutzt einen Online-Zertifikatsstatusmechanismus oder eine Zertifikatswiderrufsliste.
Als leistungsfähiger
Mechanismus muss das Token keine CA für jede Verwendung des privaten
Schlüssels
konsultieren. Anstatt dessen nimmt das Token die Information bezüglich der
Gültigkeit
in den Cachespeicher auf und verifiziert diese Informationen periodisch.
Die Zeitspanne, die zwischen der Verifikation von Informationen
verstreicht, kann für
einen Schlüssel
mit extrem hoher Gültigkeit
einmal pro Sekunde sein, sie kann aber auch wahrscheinlicher ein
längeres
Intervall einnehmen. Das Intervall würde in irgendeinem Verhältnis zu
dem Risiko stehen, dass der Schlüssel
gefährdet sein
sollte. Diese Zeitspanne ist von dem Endbenutzer anpassbar.
-
Die
Verwendung einer Validierungsmaschine innerhalb eines Tokens ermöglicht die
Skalierbarkeit des Gesamtsystems. Sie ersetzt viele Clients, die einzeln
den Status eines Zertifikats anfordern, durch eine einzige zentralisierte
Stelle, die derartige Status anfordert. Ferner kann die Validierungsmaschine
die Rechenlast bei einem Provider von Zertifikatsstatus reduzieren,
indem eine symmetrische Kryptographie verwendet wird, um die Rückantworten
betreffend den Status zu verifizieren. In dieser Ausführungsform verwendet
das System ein Protokoll wie SSL, so dass das Token 12 eine
sichere Verbindung mit dem Provider von Zertifikatsstatus aushandelt.
Eine Verbindung besteht aus einer Handshake-Phase, die eine Verschlüsselung
mit einem öffentlichen
Schlüssel
verwendet, um einen gemeinsam benutzten gesicherten Schlüssel, der
beiden Enden der Verbindung bekannt ist, einzuführen. Daraufhin werden einzelne Nachrichten,
die über
die Verbindung gesandt werden, authentifiziert und optional verschlüsselt, wobei Schlüssel verwendet
werden, die von diesem gemeinsam benutzten Geheimnis abgeleitet
sind. Derartige symmetrische Operationen sind effizienter als digitale
Signaturen und Verschlüsselungsoperationen
unter Verwendung eines öffentlichen
Schlüssels, die
erforderlich wären,
um jede Nachricht individuell zu verschlüsseln und zu authentifizieren.
-
Ein
Token gibt typischerweise wiederholt Anfragen betreffend den Status
eines Zertifikats aus und diese Anfragen bringen sowohl bei dem
Token selbst als auch bei der CA eine große Rechenlast mit sich. Diese
Rechenlast kann beträchtlich
reduziert werden, indem eine sichere Verbindung vereinbart wird,
in der der Provider von Zertifikatstatus als ein vertrauenswürdiger Provider
für Informationen
betreffend den Status von Zertifikaten authentifiziert wird. Daraufhin
können
Anfragen betreffend den Status von Zertifikaten und Antworten über die
sichere Verbindung gesendet werden, wobei jede Frage und Antwort
mit dem gemeinsam benutzten sicheren Schlüssel symmetrisch authentifiziert
wird, der in der Handshake-Phase beim Einrichten der sicheren Verbindung
vereinbart wurde. In Protokollen wie beispielsweise SSL können diese
symmetrisch authentifizierten Nachrichten über verschiedene Verbindungen übermittelt
werden, wobei jede ihren Schlüssel von
einem einzigen gemeinsam benutzten Geheimnis, das in einer erstmaligen
Handshake-Phase eingerichtet wurde, ableitet. Diese Benutzung einer
sicheren Verbindung anstatt individueller authentifizierter Nachrichten
erzielt einen Leistungsvorteil, in dem vorteilhaft eine einzige
Operation mit öffentlichem Schlüssel [single
public key operation] (in der Handshake-Phase) in authentifizierende
mehrere oder viele verschiedene Anfragen/Antwortpaare betreffend
den Status von Zertifikaten verwendet wird. Dies geht zu Lasten
solcher Zertifikatsantworten, die nicht länger in solch einer Weise individuell
authentifiziert werden, dass sie dritten Parteien gegenüber zur
Verifikation präsentiert
werden könnten.
-
Um
mit der Zertifizierungsautorität
oder deren designiertem Agenten zu kommunizieren, benötigt das
Token in manchen Fällen
Zugang zu einem externen Netzwerk. In der bevorzugten Ausführungsform
läuft eine
Hilfsanwendung auf dem Computer, der das Token beherbergt (in der
Annahme, dass das Token eine Erweiterungskarte oder irgendeine solche Einrichtung
ist, die keinen direkten Zugang zu Netzwerkeinrichtungen hat). Eine
derartige Hilfsanwendung agiert als Gateway zwischen dem Token und der
bzw. den Dienstleistungen, die sie auf dem Netzwerk, das Daten hin
und her transportiert, benötigt. Der
Endpunkt aller sicheren Kommunikation mit den Providern von Status
von Zertifikaten muss innerhalb der gesicherten Umhüllung des
Tokens liegen; dies bedeutet, dass die Hilfsanwendung als eine Transporteinrichtung
für Daten
zu und von dem Token dient, aber nicht als Endpunkt für Sicherheitsprotokolle
(wie beispielsweise SSL) dienen kann.
-
Die
Verifizierungsmaschine verhindert die Benutzung eines privaten Schlüssels, außer wenn ein
Provider von Status von Zertifikaten kontaktiert werden kann und
eine positive Bestätigung
der aktuellen Gültigkeit
des Zertifikats erhalten wird. Aufgrund dessen ist die Zuverlässigkeit
der Netzwerkverbindungen zwischen dem Token, dessen Hauptcomputer
[hosting computer] und dem Provider für Status von Zertifikaten von
höchster
Wichtigkeit für die
fortlaufende Zuverlässigkeit
und Verfügbarkeit der
Dienstleistung, die durch den privaten Schlüssel des Tokens geboten wird.
Somit ist es von großem Wert,
mehrfache redundante und unabhängige
Mechanismen für
das Token zu haben, um den oder die Provider für Status von Zertifikaten zu
kontaktieren.
-
Die
Zertifikatserweiterung, die die vertrauende Partei darüber informiert,
dass ein privater Schlüssel
mit einer Validierungsmaschine für
Zertifikate geschützt
ist, kann ferner einen Mechanismus enthalten, um der vertrauenden
Partei mitzuteilen, welche Parameter dieser Schutz enthält. Beispielsweise:
- • das
physikalische Schutzlevel des Tokens (beispielsweise FIPS 140-1
Level 1, 2, 3 oder 4)
- • die
Frequenz der Validitätsüberprüfung, die
von der Validierungsmaschine ausgeführt wird (beispielsweise ob
die CA für
jede Transaktion jede Minute, Stunde, Tag oder irgendeine andere
Zeitspanne kontaktiert wird).
- • welche
anderen Verfahrensweisen durch die Validierungsmaschine erzwungen
werden (beispielsweise um die erlaubte Verwendung des Schlüssels herum
oder die Validierung der tatsächlichen
signierten Nachrichten).
-
Zusätzlich zu
der Verweigerung der Benutzung der Signaturmaschine nach der Feststellung, dass
die CA eine derartige Verwendung nicht erlaubt hat, könnte das
Token andere Aktionen wählen,
wie beispielsweise Nullen (Zerstören)
des privaten Schlüssels
oder das Token als nicht benutzbar erachten.
-
Ein
Token, das eine Validierungsmaschine für Zertifikate enthält, schützt gegen
verschiedene Validitätsprobleme,
die in einer sicheren Umgebung periodisch auftreten. So wird eventuell
die Sicherung des Schlüssels
verraten. In einem gesicherten Token ist dies generell mit der physischen
Sicherheit des missbrauchten Tokens oder der Software, die den unsicher
gewordenen Token benutzt, gekoppelt. Beispielsweise kann ein Server,
der ein physisch gesichertes Token enthält, gestohlen werden, wodurch der
Dieb Kontrolle über
das Token erhält.
In einem anderem Beispiel könnte
ein Server, der ein solches Token enthält, von einem Hacker in solch
einer Weise kompromittiert werden, dass die vom Server autorisierten
Benutzer nicht länger
sicher sein können, dass
das Token nur in autorisierter Weise benutzt wurde. In jedem Fall
würde die
Zurückweisung
des dem Token zugewiesenen Zertifikats bewirken, dass die Validierungsmaschine
in dem Token alle weiteren Benutzungen des privaten Schlüssels des
Token stoppt. Eine weitere derartige Benutzung ist der Fall eines
inkorrekt ausgegebenen Zertifikats. Beispielsweise gibt eine CA
ein Zertifikat aus und findet dann, dass die Papiere, die zur Identifizierung
des Anfordernden des Zertifikats benutzt wurden, gefälscht waren.
In diesem Fall widerruft die CA das Zertifikat, das ausgegeben wurde,
und das Token stoppt jedwede weitere Verwendung des zertifizierten
privaten Schlüssels.
-
In ähnlicher
Weise wird auch ein Widerruf benutzt, um laufende Validierungen
zu managen. Beispielsweise wenn ein Zertifikat, das an eine Partei unter
bestimmten Konditionen oder Bedingungen ausgegeben wurde, die zu
einem späteren
Zeitpunkt ungültig
wurden, wenn der Empfänger
des Zertifikats die Aufrechterhaltungsgebühr nicht zahlte. In solch einem
Fall widerruft die CA ihr Zertifikat und stoppt die weitere Benutzung
des Schlüssels
durch das Token.
-
Der
wesentliche Nutzen eines Token, das eine Verifizierungsmaschine
enthält,
besteht darin, dass keine Notwendigkeit mehr für eine vertrauende Partei besteht,
den Widerruf unabhängig
zu überprüfen. Dies
ist in Situationen von besonderem Nutzen, in denen eine Gruppe von
vertrauenden Parteien entstanden ist, die einen Widerruf nicht überprüfen, wie es
beispielsweise bei Internet-Webbrowsern der Fall ist, die das SSL-Protokoll
implementiert haben. Die meisten dieser Browser werden keine Überprüfung mit
einer Zertifizierungsautorität
durchführen,
um zu ermitteln, ob ein Zertifikat widerrufen wurde. Sollte in solch
einem Fall ein Zertifikat aus irgendeinem Grund widerrufen worden
sein, so wird ein solcher Widerruf keinen praktischen Effekt für Clients
haben, die Einrichtungen nach dem Stand der Technik benutzen, welche
einen Widerruf nicht prüfen.
Wenn man aber ein Token benutzt, das eine Verifizierungsmaschine enthält, wird
die Wirkung des Widerrufs an einer einzigen Stelle beurteilt werden.
Die Benutzung des privaten Schlüssels,
der einem zertifizierten öffentlichen Schlüssel entspricht,
basiert auf der anhaltenden Gültigkeit
des Zertifikats. Das Ergebnis besteht darin, dass es die Notwendigkeit
für vertrauende
Parteien eliminiert, die aktuelle Validität zu verifizieren und wiederum
die Sicherheit eines Systems erhöht,
in welchem viele solcher Clients die Validität eines Zertifikats überprüfen.
-
Des
Weiteren schützt
die Durchsetzung zusätzlicher
Verfahrensweisen in Bezug auf die Benutzung des Schlüssels die
Zertifizierungsautorität
gegen böswilligen
oder unabsichtlichen Missbrauch des Schlüssels. Beispielsweise könnte eine
Verfahrensweise bestimmte Aspekte der Zertifikatsausgabe durch eine
untergeordnete Zertifizierungsautorität erzwingen. Somit hat die übergeordnete
Zertifizierungsautorität
das Vertrauen, dass die angemessene Verwendung der untergeordneten
Zertifizierungsautorität
an der Stelle der Benutzung des privaten Schlüssels technologisch erzwungen
wird, anstatt dass auf juristische Vereinbarungen oder komplexe Validierungsprozeduren
durch die vertrauende Partei vertraut wird.
-
Ein
Token, das eine Validierungsmaschine für Zertifikate enthält, ist
dazu in der Lage, eine Anzahl privater Schlüssel mit deren entsprechenden Zertifikaten
zu managen. Das Token kontaktiert eine Anzahl verschiedener Zertifizierungsautoritäten, um die
Validität
dieser verschiedenen Zertifikate zu ermitteln, und die Benutzung
der zugehörigen
privaten Schlüssel
zu kontrollieren. Allgemein ist es nicht zweckmäßig, mehrere Zertifikate zu
haben, die den öffentlichen
Schlüssel
eines bestimmten Schlüsselpaars
zertifizieren. Solch ein Umstand würde typischerweise erfordern,
dass das Token feststellt, dass all diese Zertifikate fortlaufend
gültig
sind, um die Benutzung des privaten Schlüssels zu validieren. Das Einbeziehen
einer Validierungsmaschine in ein Token ermöglicht aber, dass das System
nur die Validität des
Zertifikats verifizieren muss, das in einem bestimmten Fall benutzt
wird.
-
Obwohl
die Erfindung unter Bezugnahme auf bestimmte spezifische Ausführungsformen
beschrieben wurde, sind für
Fachleute verschiedene Modifikationen der Erfindung offensichtlich,
ohne den Schutzbereich der Erfindung, wie er in den beigefügten Ansprüchen umrissen
wird, zu verlassen.