-
Die
vorliegende Anmeldung bezieht sich auf Vorrichtungen und Systeme
zum Zugreifen von einer Vorrichtung auf zumindest einen ersten Rechner
eines Rechnerverbundes, z. B. auf einen Rechner in einem Rechner-Grid.
-
In
verteilten IT-Infrastrukturen (IT – Informationstechnologie),
wie sie z. B. im Grid-Computing, im Cloud-Computing oder auch in
Service-Orientierten Architekturen (SOA) vorkommen, spielt eine
sichere Authentifizierung von Nutzern an diesen verteilten IT-Ressourcen,
wie beispielsweise Rechnern, Speicher-Systemen, Software-Diensten,
z. B. Web-Diensten oder Grid-Diensten/WSRF-Web-Diensten (WSRF – Web
Service Resource Framework = Web Dienst Ressourcen Umgebung), oder
Daten eine herausragende Rolle. Um eine möglichst hohe
Sicherheit zu haben, dass der Nutzer, der auf die sowohl räumlich
als auch bezüglich ihrer administrativen Domänen
verteilten Ressourcen und Dienste zugreifen möchte, auch
der ist, der er vorgibt zu sein, wird daher der Einsatz von PKI-basierten
Authentifizierungs- und Autorisierungsmechanismen angestrebt (PKI – Public
Key Infrastructure = Öffentlicher-Schlüssel-Infrastruktur).
In den gängigen Grid-Middleware Systemen ist die Verwendung
von X509-Zertifikaten zur Nutzerauthentifizierung sogar unumgänglich.
Ein großes Problem der PKI-basierten Authentifizierung
von Nutzern ist, dass der Nutzer dazu zunächst ein entsprechendes
Zertifikat besitzen muss. Darüber hinaus muss er sich in
den Umgang mit PKI-Zertifikaten einarbeiten, was erfahrungsgemäß sehr
viele Nutzer überfordert. Der Registrierungsprozess, um
ein Zertifikat zu erhalten, ist ferner in aller Regel sehr kompliziert.
-
Aufgabe
der Ausführungsbeispiele der vorliegenden Erfindung ist
es daher, die zertifikatsbasierte Anmeldung an einer verteilten
IT-Infrastruktur bzw. an IT-Diensten so einfach wie möglich
zu gestalten, beispielsweise von der Registrierung bis zur täglichen
Nutzung.
-
Zusammenfassung
-
Ein
Ausführungsbeispiel der vorliegenden Erfindung schafft
ein Verfahren zum Zugreifen von einer Vorrichtung auf zumindest
einen ersten Rechner eines Rechnerverbundes, um zumindest Teilaufgaben
eines Anwendungsprogramms auf dem ersten Rechner des Rechnerverbundes
durchzuführen, wobei das Zugreifen auf den ersten Rechner
eine Authentifizierung mittels öffentlich zugänglicher
Authentifizierungsinformationen über eine von der Vorrichtung
unabhängige Zugangsvorrichtung voraussetzt, mit den folgenden
Schritten. Bereitstellen des Anwendungsprogramms auf der Vorrichtung,
wobei das Anwendungsprogramm fest eingebettete Authentifizierungsinformationen
aufweist, die das Anwendungsprogramm gegenüber der Zugangsvorrichtung authentifizieren.
Authentifizieren des Anwendungsprogramms gegenüber der
Zugangsvorrichtung mittels der fest eingebetteten Authentifizierungsinformationen.
Authentifizieren der Zugangsvorrichtung gegenüber dem ersten
Rechner mittels der öffentlich zugänglichen Authentifizierungsinformationen
der Zugangsvorrichtung, die von einer Zertifizierungsstelle zertifiziert
ist, der der erste Rechner vertraut.
-
Ein
weiteres Ausführungsbeispiel der vorliegenden Erfindung
schafft ein System zum Zugreifen von einer Vorrichtung auf zumindest
einen ersten Rechner eines Rechnerverbundes, um zumindest Teilaufgaben
eines Anwendungsprogramms auf dem ersten Rechner des Rechnerverbundes
durchzuführen, wobei das Zugreifen auf den ersten Rechner eine
Authentifizierung mittels öffentlich zugänglicher Authentifizierungsinformationen über
eine von der Vorrichtung unabhängige Zugangsvorrichtung
voraussetzt; wobei das Anwendungsprogramm fest eingebettete Authentifizierungsinformationen
aufweist, die das Anwendungsprogramm gegenüber der Zugangsvorrichtung
authentifizieren, und das Anwendungsprogramm auf der Vorrichtung
bereitgestellt wird; wobei das Anwendungsprogramm und die Zugangsvorrichtung
ausgebildet sind, um das Anwendungsprogramm gegenüber der
Zugangsvorrichtung mittels der fest eingebetteten Authentifizierungsinformationen
zu authentifizieren; und wobei die Zugangsvorrichtung und der erste
Rechner ausgebildet sind, um die Zugangsvorrichtung gegenüber
dem zumindest einen Rechner mittels öffentlich zugänglicher
Authentifizierungsinformationen der Zugangsvorrichtung zu authentifizieren,
die von einer Zertifizierungsstelle zertifiziert sind, der der erste
Rechner vertraut.
-
Indem
die notwendigen privaten Schlüssel und Zertifikate für
die Authentifizierung gegenüber dem Zugangsrechner schon
in dem Anwendungsprogramm fest eingebettet sind, und das Anwendungsprogramm
sich nur gegenüber dem zwischengeschalteten Zugangsrechner
authentifizieren muss, und der dazwischen geschaltete Zugangsrechner
die Authentifizierung gegenüber dem Rechner des Rechnerverbundes
mittels eigener Authentifizierungsinformationen übernimmt,
wird der Zugang bzw. der Zugriff für den Anwender auf Rechner
des Rechnerverbundes erleichtert.
-
Kurzbeschreibung der Figuren
-
Ausführungsbeispiele
der vorliegenden Erfindung werden nachfolgend unter Bezugnahme auf beiliegende
Zeichnungen näher erläutert.
-
1 zeigt
ein Flussdiagramm eines Verfahrens zum Zugreifen von einer Vorrichtung
auf zumindest einen ersten Rechner eines Rechnerverbundes.
-
2 zeigt
ein Blockdiagramms eines Ausführungsbeispiels eines Systems
zum Zugreifen von einer Vorrichtung auf zumindest einen ersten Rechners
eines Rechnerverbundes.
-
3A zeigt
ein Flussdiagramm eines Ausführungsbeispiels der gegenseitigen
Authentifizierung der Vorrichtung und der Zugangsvorrichtung.
-
3B zeigt
ein Flussdiagramm eines Ausführungsbeispiels der gegenseitigen
Authentifizierung der Zugangsvorrichtung und des ersten Rechners.
-
4A/B zeigen ein Flussdiagramm eines weiteren
Ausführungsbeispiels eines Verfahrens zum Zugreifen von
einer Vorrichtung auf zumindest einen ersten Rechner eines Rechnerverbundes.
-
Dabei
werden in der vorliegenden Beschreibung für Objekte und
Funktionseinheiten, die gleiche oder ähnliche funktionelle
Eigenschaften aufweisen, gleiche Bezugszeichen verwendet.
-
Detaillierte Beschreibung
-
Bevor
auf die einzelnen Ausführungsbeispiele eingegangen wird,
werden zuvor, zum besseren Verständnis, Begriffe der verteilten
Rechnerarchitekturen, wie beispielsweise des Grid-Computing, der Authentifizierung
bzw. der Kryptographie im Allgemeinen, sowie ein beispielhafter
Prozess von einer Nutzerregistrierung bis zur Nutzung eines Grid-Dienstes,
der auch als Grid-Anwendung oder Grid Service bezeichnet wird, beschrieben.
-
Mehrere
Rechner werden häufig zu einem Rechnerverbund, allgemein
auch als Rechner-Cluster oder Computer-Cluster bezeichnet, zusammengefasst,
um beispielsweise die Rechenkapazität oder die Verfügbarkeit
gegenüber einem einzelnen Rechner zu erhöhen.
Die Rechner können beispielsweise handelsübliche
Computer, Hochleistungsrechner bzw. Super-Computer oder andere Rechner,
zum Beispiel für spezielle Anwendungen entwickelte Rechner
bzw. Computer sein. Aufgrund der Verteilung der Kapazitäten
auf mehrere Rechner wird dies auch als ”verteiltes Rechnen” bezeichnet.
Dabei können verschiedenste Architekturen, also Rechnerverbundarchitekturen,
Anwendung finden, z. B. Cloud-Computing oder Grid-Computing. Bei
dem Cloud-Computing (Cloud = Wolke) sind die Anwendungen und Daten
für die einzelnen Nutzer nicht mehr auf dem lokalen Rechner
des Nutzers installiert, sondern in einem Rechnerverbund, dessen
Architektur der Nutzer selbst nicht kennen muss, und daher diesem
als ”Wolke” erscheint. Grid-Computing (Grid =
Gitter) unterscheidet sich von typischen Computerclustern in der
wesentlich loseren Kopplung, der Heterogenität und der
geographischen Zerstreuung der Computer. Grids werden häufig
von einer bestimmten Interessengruppe, auch als Community bezeichnet,
betrieben und die technische Infrastruktur, die das Grid bildet,
so optimiert, dass eine bestimmte Klasse von Anwendungen, die in
der Community besonders oft eingesetzt wird, optimal läuft.
Des Weiteren nutzen Grids typischerweise standardisierte Programmbibliotheken
und Middleware. Dabei sind die einzelnen Rechner, die das Grid bilden,
häufig verschiedenen Administrationsdomänen zugeordnet und
kommunizieren beispielsweise über das öffentliche
Internet miteinander. Im Gegensatz zu Rechnern, die beispielsweise
einer Administrationsdomäne zugeordnet sind, und die beispielsweise über
ein nicht-öffentliches bzw. nur einer geschlossenen Gruppe
von Rechnern und Anwendern zugängliches Intranet miteinander
kommunizieren, ist bei Rechner-Grids eine gegenseitige Authentifizierung,
also einer Überprüfung der Identität,
der einzelnen Rechner und ihrer Nutzer gegenüber den anderen
Rechnern und Diensten des Rechner-Grids notwendig, um einen unerlaubten
Zugriff auf die einzelnen Rechner, Dienste und Daten des Rechner-Grids
zu verhindern.
-
Als
Authentifizierung wird allgemein der Vorgang der Überprüfung,
auch als Verifikation bezeichnet, und der Bestätigung einer
behaupteten Identität, beispielsweise einer Person oder
eines Objekts, wie beispielsweise eines Rechners, bezeichnet. Davon zu
unterscheiden ist die Authentisierung, dem Vorgang des Nachweises
der eigenen Identität.
-
Üblicherweise
wird zwischen den zwei Begriffen Authentifizierung und Authentisierung
jedoch nicht unterschieden und allgemein nur von der „Authentifizierung” gesprochen.
Daher werden auch im Folgenden diese Begriffe allgemein unter dem
Begriff Authentifizierung subsumiert, es sei denn, in der Beschreibung
wird explizit zwischen diesen Begriffen unterschieden. Die Authentifizierung
im engeren wie im weiteren Sinne wird im Englischen auch als „Authentication”,
die Authentisierung auch als „Identification” (Identifikation)
und die Authentifizierung im engeren Sinne auch als „Verification” (Verifikation)
bezeichnet.
-
Nachdem
die Authentifizierung abgeschlossen ist, erfolgt auf Basis der Identität
des Nutzers (diese wird bei der Authentifizierung überprüft)
und einer lokalen Policy, die die Zugriffsrechte definiert und auch
als Regelwerk oder Zugriffsregeln bezeichnet werden kann, im Anschluss
daran eine Autorisierung. Wobei im Falle einer positiven Autorisierung
(im Nachgang an eine positive Authentifizierung) ein Zugriff gemäß der
Policy erlaubt wird, und im Falle einer negativen Autorisierung
(trotz einer vorherigen positiven Authentifizierung) kein Zugriff
erlaubt wird. Letzteres kann beispielsweise der Fall sein, wenn
der Zugreifende seine begrenzte Zugriffszeit schon aufgebraucht
hat oder wenn er zwar grundsätzlich Nutzungsrechte auf
den Ressourcen aber nicht für die im speziellen angefragten
Anwendungen und Daten hat.
-
Die
Authentifizierung der Rechner eines Rechnerverbundes kann beispielsweise
mithilfe eines asymmetrischen Kryptosystems, dass auf der Verwendung
von so genannten privaten Schlüsseln, öffentlichen
Schlüsseln und Zertifikaten basiert, erfolgen. Systeme
bzw. Infrastrukturen für derartige asymmetrische Kryptosysteme
werden auch als Public-Key-Infrastrukturen (PKI) bezeichnet. Dabei
wird für jeden Teilnehmer bzw. Rechner der Public-Key-Infrastruktur
ein Schlüsselpaar bestehend aus einem privaten Schlüssel
und einem öffentlichen Schlüssel erstellt. Der
private Schlüssel ist nur dem Inhaber bzw. Teilnehmer oder
Rechner des Inhabers bzw. Teilnehmers bekannt, daher der Begriff „privat”, während
der öffentliche Schlüssel allen anderen Teilnehmern
zugänglich bzw. bekannt ist, daher der Begriff „öffentlich”.
-
Will
sich ein erster Teilnehmer bzw. erster Rechner gegenüber
einem zweiten Teilnehmer bzw. zweiten Rechner authentifizieren,
sendet der erste Teilnehmer bzw. Inhaber des privaten Schlüssels eine
Signatur, die basierend auf dem privaten Schlüssel und
eines Signaturerzeugungsalgorithmus beispielsweise auf dem Rechner
des Inhabers erzeugt wird. Die Verwendung der Signatur vermeidet,
dass der private Schlüssel selbst aus dem Bereich des Inhabers
gelangt, somit andere in Besitz des Schlüssels gelangen
könnten, und sich dann mit Hilfe dieses privaten Schlüssels
fälschlicherweise als der Inhaber ausgeben zu könnten,
dies wird auch als Identitätsraub bezeichnet. In anderen
Worten, die Erzeugung der Signatur ermöglicht, dass der
private Schlüssel den ersten Rechner nicht verlässt.
Der Empfänger der Signatur, also der zweite Teilnehmer oder
zweite Rechner, gegenüber dem sich der Inhaber des privaten
Schlüssels authentifizieren bzw. identifizieren möchte, überprüft
die Echtheit der Signatur mittels des zugehörigen öffentlichen
Schlüssels, also dem öffentlichen Schlüssel
der im Rahmen des Schlüsselpaars dem privaten Schlüssel
zugeordnet ist, und einem Signaturüberprüfungsalgorithmus. Ist
die Überprüfung positiv, oder in anderen Worten, ergibt
die Überprüfung mittels des Signaturüberprüfungsalgorithmus
und des öffentlichen Schlüssels, dass die Signatur
mit dem dem öffentlichen Schlüssel zugeordneten
privaten Schlüssel erzeugt wurde, ist die Identitätsüberprüfung
also positiv verlaufen, genehmigt bzw. erlaubt der zweite Rechner
bzw. Teilnehmer den Zugriff des ersten Teilnehmers bzw. Rechners
auf den zweiten Rechner, sofern dies den Zugriffsregeln des Betreibers
des zweiten Rechners entspricht. Im Folgenden wird, um Wiederholungen zu
vermeiden, davon ausgegangen, dass, soweit sich aus dem Kontext
nicht etwas anderes ergibt, nach einer positiven Authentifizierung
auch eine positive Autorisierung erfolgt.
-
Das
Erzeugen und Senden der Signatur durch den ersten Teilnehmer bzw.
ersten Rechner kann auch als Authentisierung bezeichnet werden, das Überprüfen
durch den zweiten Teilnehmer bzw. den zweiten Rechner als Authentifizierung
im engeren Sinne, und das gewähren des Zugriffs auf den zweiten
Rechner als Autorisierung.
-
Da
der öffentliche Schlüssel der Öffentlichkeit
zugänglich ist, z. B. über das Internet, kann
er auch manipuliert werden, z. B. in betrügerischer Absicht
gefälscht werden. Um sicherzustellen, dass es sich bei
dem öffentlichen Schlüssel des ersten Teilnehmers
bzw. Rechners tatsächlich um den Schlüssel desselben
handelt und nicht um eine Fälschung, werden so genannte
Zertifikate bzw. digitale Zertifikate verwendet. Derartige Zertifikate
dienen dazu, die Authentizität, also Echtheit, eines öffentlichen Schlüssels
bestätigen. Das Zertifikat ist selbst durch eine Signatur
bzw. digitale Signatur geschützt, deren Echtheit mit dem öffentlichen
Schlüssel des Ausstellers des Zertifikates geprüft
werden kann. Um die Authentizität des Ausstellerschlüssels
zu prüfen, wird wiederum ein digitales Zertifikat benötigt.
Auf diese Weise lässt sich eine Kette von digitalen Zertifikaten aufbauen,
die jeweils die Authentizität des öffentlichen
Schlüssels bestätigen, mit dem das vorhergehende
Zertifikat geprüft werden kann. Eine solche Kette von Zertifikaten
wird Validierungspfad oder Zertifizierungspfad genannt. Auf die
Echtheit des letzten Zertifikates und des durch diesen zertifizierten Schlüssels
müssen sich die Kommunikationspartner aber ohne ein weiteres
Zertifikat verlassen können, also vertrauen können.
-
Die
Zertifizierungsstelle wird auch als „Aussteller” des öffentlichen
Schlüssels bzw. Zertifikats bezeichnet. Derjenige, der
den privaten Schlüssel besitzt und auf den der zu dem privaten
Schlüssel zugehörige Öffentliche Schlüssel
bzw. das entsprechenden Zertifikat ausgestellt wurde, wird auch
als „Inhaber” oder „Nutzer” dieses
Schlüsselpaars bzw. des entsprechenden Zertifikats bezeichnet.
Dabei sind die Begriffe Aussteller, Inhaber und Nutzer nicht auf
Personen beschränkt, sondern umfassen auch entsprechende
Infrastrukturen und Anwendungsprogramme, die diese Funktionen wahrnehmen.
-
In
dem vorliegenden Fall kann der zweite Teilnehmer bzw. zweite Rechner
die Authentizität des öffentlichen Schlüssels
des ersten Teilnehmers bzw. ersten Rechners mittels eines ebenfalls öffentlich
zugänglichen Zertifikats des Ausstellers, dem der zweite
Teilnehmer bzw. Rechner vertraut, überprüfen. Derartige
Zertifikate können beispielsweise in dem Format X509 vorliegen,
in dem der öffentliche Schlüssel des ersten Teilnehmers
bzw. ersten Rechners sowie weitere Informationen bezüglich
des ersten Teilnehmers bzw. ersten Rechners und eine Signatur des
Ausstellers enthalten sind. Der X509-Standard definiert
weitere Sub-Formate, wie z. B. PKCS12 oder PEM (Privacy Enhanced
Mail), in denen die Schlüssel und Zertifikate vorliegen
bzw. gespeichert und/oder ausgetauscht werden können.
-
Gemäß der
Spezifikation RFC2828 ist ein Zertifikat für
ein PKI-System ein digitales Zertifikat, dass den Öffentlichen
Schlüssel des Inhabers desselben, der auch als „Owner” bezeichnet
wird, Informationen über die Identität des Inhabers
sowie eine Signatur der Zertifizierungstelle aufweist, die für
die Echtheit des Zertifikat bürgt. Dabei sind der Öffentliche
Schlüssel und die Informationen über die Identität
des Inhabers mittels eines privaten Schlüssels der Zertifizierungsstelle
fälschungssicher verschlüsselt, so dass das PKI-Zertifikat
ohne weitere Schutzmechanismen öffentlich zugänglich
gemacht werden kann, z. B. auf einem öffentlichen Server.
-
Üblicherweise
erfolgt im Gegenzug, nach erfolgreicher Authentifizierung des ersten
Teilnehmers bzw. ersten Rechners durch den zweiten Teilnehmer bzw.
zweiten Rechner, eine entsprechende Authentifizierung des zweiten
Teilnehmers bzw. zweiten Rechners gegenüber dem ersten
Teilnehmer bzw. ersten Rechner. Dabei wird ein zweites Schlüsselpaar,
dass auf den zweiten Teilnehmer bzw. zweiten Rechner ausgestellt
ist, verwendet, wobei das Schlüsselpaar einen zweiten privaten
Schlüssel und einem zweiten öffentlichen Schlüssel
aufweist. Der zweite Teilnehmer bzw. zweite Rechner sendet also eine
Signatur, die basierend auf dem privaten Schlüssel des
zweiten Teilnehmers bzw. Rechners und einem Signaturerzeugungsalgorithmus
erzeugt wird, an den ersten Teilnehmer bzw. ersten Rechner, der die
Echtheit mittels eines Signaturüberprüfungsalgorithmus
und dem zweiten öffentlichen Schlüssel überprüft.
Erst wenn beide Teilnehmer beziehungsweise beide Rechner sich gegenseitig
erfolgreich authentifiziert haben, erfolgt der weitere Verbindungsaufbau für
die Übertragung von Daten, oder allgemein von Informationen,
bzw. wird ggf. gegenseitig der Zugriff auf den jeweils anderen Rechner
zugelassen. Der erste Teilnehmer bzw. erster Rechner kann, wie zuvor
für den zweiten Teilnehmer bzw. zweiten Rechner beschrieben,
die Authentizität des zweiten öffentlichen Schlüssels,
der dem zweiten Teilnehmer bzw. dem zweiten Rechner zugeordnet ist, über
ein zweites Zertifikat, das beispielsweise von demselben Aussteller
ausgestellt wurde, überprüfen.
-
Da
ein Zertifikat sowohl die Signatur des Ausstellers bzw. der Zertifizierungsstelle
als auch den öffentlichen Schlüssel, den es zertifiziert,
enthält, kann auch davon gesprochen werden, dass die Überprüfung
der Signatur mittels des Zertifikates (für den entsprechenden öffentlichen
Schlüssel) durchgeführt wird.
-
Die
gegenseitige Authentifizierung wird auch als „Handshake” bezeichnet.
-
Im
Folgenden wird ein beispielhafter Prozess von einer Nutzerregistrierung
bis zur Nutzung eines Grid-Dienstes bzw. einer Grid-Anwendung beschrieben.
-
Der
Nutzer muss zunächst die für ihn zuständige
Zertifizierungsstelle, im Englischen auch als Certification Authority
(CA) bezeichnet, sowie die nächstgelegene zu dieser Zertifizierungsstelle
gehörige Registrierungsstelle, im Englischen auch als Registration
Authority (RA) bezeichnet, ermitteln (Schritt A).
-
Dazu
muss der Nutzer entweder persönlich bei der für
ihn zuständigen Zertifizierungsstelle bzw. Registrierungsstelle
erscheinen und sich auf geeignete Weise ausweisen, z. B. mit einem
Personalausweis oder Reisepass, oder sich über das Postident-Verfahren
der Deutschen Post gegenüber der Zertifizierungsstelle
identifizieren (Schritt B).
-
Ferner
muss der Nutzer einen Zertifikatsantrag stellen (Schritt C). Dies
kann der Nutzer beispielsweise über ein Webportal vornehmen,
wobei der private Schlüssel dabei in dem Webbrowser des Nutzers
auf dessen Rechner erzeugt wird (Schritt C1). Diese Variante ist
relativ komfortabel. Alternativ kann ein Nutzer einen Zertifikatsantrag über
eine Kommandozeile oder spezielle Werkzeuge, auch als Tools bezeichnet,
erstellen (Schritt C2). Beides erfordert jedoch spezielles technisches
Know-How oder die Installation von Software. Dabei wird der private Schlüssel
als Datei direkt auf dem Rechner des Nutzers erzeugt. Gleichzeitig
wird eine weitere Datei erzeugt, die an die zuständige
Zertifizierungsstelle, z. B. per E-Mail, gesendet wird.
-
Daraufhin
erhält der Nutzer von der Zertifizierungsstelle den passenden öffentlichen
Schlüssel zu dem auf seinem Rechner erzeugten privaten
Schlüssel und muss diese zusammenführen. Dies
kann er durch Import des öffentlichen Schlüssels
in denselben Browser, mit dem der private Schlüssel erzeugt wurde
(Schritt D1), oder, alternativ, durch Ablegen des öffentlichen
Schlüssels in dem Dateisystem auf dem Nutzerrechner (Schritt
D2) durchführen.
-
Ferner
ist eine Konvertierung von Zertifikaten notwendig (Schritt E). Dabei
wird für die Verwendung von einem Rechner-Grid das Schlüsselpaar aus
privatem und öffentlichem Schlüssel in dem PEM-Format
(PEM = Privacy Enhanced Mail) benötigt, das zwei einzelne
Dateien vorsieht. In dem Browser entsteht jedoch eine Datei im PKCS12-Format, die
zudem erst aus dem Browser exportiert werden muss. Die Konvertierung
ist ohne eine geeignete Unterstützung von Software-Werkzeugen
bzw. Software-Tools in Windowssystemen nicht möglich. Unter Linux
ist die detaillierte Kenntnis, beispielsweise des Kommandozeilenwerkzeugs
bzw. Kommandozeilentools OpenSSL (SSL – Secure Socket Layer)
erforderlich (Schritt 5A). Für die Verwendung
an Web-Clients bzw. Web-basierten Programmen wird das Schlüsselpaar
in dem PKCS12-Format benötigt und muss nach der Konvertierung,
siehe Schritt E1, in den Browser des Nutzers importiert werden (Schritt E2).
Des Weiteren muss das Zertifikat (das konvertierte Zertifikat) im
passenden Format in den jeweiligen Client bzw. das Anwendungsprogramm
importiert werden (Schritt F). Dabei gibt es in der Regel die folgenden
vier Arten von Clients: Den Kommandozeilen Client, die Desktop-Anwendung,
die Rich-Client Plattform und den Webbrowser bzw. das Webportal.
-
Für
den Kommandozeilen Client ist die Installation einer geeigneten
Middleware erforderlich. Dies ist ein Prozess, der bei den gängigen
Middleware-Systemen selbst Experten überfordern kann. Verwendet
wird typischerweise das PEM-Format.
-
Bei
den Desktop-Anwendungen ist der Import durch Angabe eines Dateipfades
in der Anwendung vergleichsweise einfach. Verwendet wird auch hier
in der Regel das PEM-Format.
-
Entsprechendes
gilt auch für Rich-Client Plattformen. Für die
Nutzung mittels Webbrowser bzw. Webportal muss in jedem Fall das
Schlüsselpaar in dem PKCS12-Format in den Browser importiert
sein, um sich an dem Webportal anmelden zu können.
-
Bei
der Authentifizierung gegenüber Rechner-Grids werden sog.
Proxys verwendet. Dies sind kurzlebige Schlüsselpaare,
die vom Schlüsselpaar des Nutzers auf seinem Rechner abgeleitet
bzw. erzeugt werden. Ein Proxy ist eine einzelne Datei, die als
Derivat des Original-Schlüsselpaars gekennzeichnet ist
und in der Regel mit einer deutlich kürzeren Lebensdauer
versehen wird, da mit ihnen ansonsten dieselben Rechte verbunden
sind, wie mit den Original-Schlüsselpaaren des Nutzers.
Die Proxys bilden somit ein von einem Originalschlüsselpaar (privater
und öffentlicher Schlüssel) abgeleitetes sogenanntes
qualitativ identisches Schlüsselpaar, das verwendet werden
kann, um mit denselben Signaturerzeugungsalgorithmen wie für
das Originalschlüsselpaar bzw. für den privaten
Originalschlüssel eine Signatur zu erzeugen, und um mit
denselben Signaturüberprüfungsalgorithmen wie
für das Originalschlüsselpaar die Echtheit der
Signatur zu überprüfen. Entsprechend wird basierend
auf dem Originalzertifikat für das Originalschlüsselpaar
ein Proxy-Zertifikat abgeleitet, das den abgeleiteten öffentlichen Schlüssel
des Proxy, die Informationen über die Identität
des Inhabers des Originalschlüssels, die Signatur der Zertifizierungsstelle,
die das Zertifikat für den öffentlichen Originalschlüssel
ausgestellt hat, und eine zweite Signatur aufweist, wobei die zweite
Signatur mittels des privaten Schlüssels des Inhabers des
Originalschlüsselpaares erzeugt wird, um die Echtheit des
Ursprungs des Proxys zu bestätigen bzw. überprüfen
zu können. Die Lebensdauer der Proxys kann, je nach Tool,
bei der Erzeugung des Proxys eingestellt werden oder nimmt einen
voreingestellten Wert ein, sie kann jedoch die Lebensdauer des Originalschlüsselpaars
nicht überschreiten.
-
Im
Folgenden wird die Erzeugung der Proxys für die vier zuvor
beschriebenen Arten von Clients beschrieben.
-
Im
Falle des Kommandozeilen Clients erfolgt die Authentifizierung an
dem ersten Grid-Rechner mit Hilfe des Original-Schlüsselpaars.
Das Proxy wird mit der Grid-Aufgaben-Anfrage, auch als Grid Job
Anfrage bzw. Service Request bezeichnet, mit gesendet. Jeder Service,
der eine weitere Kommunikation im Auftrag des Nutzers mit einem
weiteren Grid Rechner bzw. Grid Service bzw. einer weiteren Grid
Ressource des Grids durchführt, leitet dazu ein weiteres
Proxy ab. Die Lebensdauer von Proxys kann dabei die Lebensdauer
des Schlüsselpaars oder Proxys von dem sie abgeleitet werden,
nicht überschreiten. Im Grid wird bei von Proxys abgeleiteten
Proxys immer die maximal mögliche Lebensdauer verwendet.
-
Im
Falle der Desktop-Anwendungen und der Rich Client Plattformen wird,
wie für den Kommandozeilen Client beschrieben, verfahren.
-
Im
Falle von Webbrowsern bzw. Webportalen ist ein Zwischenschritt erforderlich,
da die Erzeugung des Proxys auf dem Nutzerrechner erfolgen muss
und des Vorteil des Webportal-Szenarios gegenüber den anderen
drei Client-Arten darin liegt, dass keine weitere Software installiert
werden muss. In dem Zwischenschritt kann über ein Java
Webstart Werkzeug bzw. Java Webstart Tool oder ein geeignetes Applet
ein Proxy des Original-Schlüsselpaars mit mittlerer Lebensdauer,
in der Regel eine Woche, auf dem Nutzerrechner erzeugt werden. Das
Proxy wird dann üblicherweise an einen in dem Rechner Grid befindlichen
MyProxy Server übertragen und dort gespeichert. Der Zugriff
auf die Proxys im MyProxy Server wird in frei wählbaren
Kombinationen von Benutzername und Passwort geschützt.
Dieser MyProxy Server ist einerseits vom Internet aus immer zugänglich
und andererseits auch von allen Grid Ressourcen, wie beispielsweise
dem Webportal. Anschließend kann über eine Funktion
im Webportal das eigentliche für die Nutzung im Grid vorgesehene
Proxy vom Proxy im MyProxy Server abgeleitet bzw. erzeugt werden.
Dieses bereits zweimal abgeleitete Proxy wird dann vom Portal Client
für die Authentifizierung beim nächsten Dienst
genutzt. Gegebenenfalls wird dabei ein von diesem Proxy abgeleitetes Proxy
weitergegeben, um weitere Kommunikation mit anderen Grid Services
im Auftrag des Nutzers zu ermöglichen. Der Zwischenschritt über
den MyProxy Server ist nicht zwingend, aber üblich, da
auf diese Weise durch einen Click in dem Portal ein neues Proxy,
z. B. ein Proxy zweiten Grades, von dem MyProxy Server bezogen werden
kann, ohne nochmals auf den Nutzerrechner zugreifen zu müssen.
-
Dabei
muss der Nutzer bei der Erzeugung des ersten Proxys darauf achten,
dass die Lebensdauer des Proxys einerseits möglichst kurz
ist, da er für die Lebensdauer des Proxys praktisch seine
Identität aus der Hand gibt. Andererseits muss die Lebensdauer
lang genug sein, um alle Aktivitäten im Grid, den sog.
Grid Job bzw. Grid-Auftrag, ausführen zu können,
bevor das Proxy abläuft.
-
Der
Vorteil des Proxy Konstrukts bzw. der Verwendung von Proxys ist,
dass jegliche Nutzung von Grid Ressourcen, Grid Diensten und Daten
im Grid direkt unter der Identität des eigentlichen Nutzers
erfolgt. Somit ist auch eine direkte Zuordnung von Accounting-Daten
an den Nutzer möglich.
-
Die
Probleme bei den zuvor beschriebenen Verfahren liegen beispielsweise
bei der Konvertierung und dem Import des persönlichen Schlüsselpaars
in den jeweiligen Client, aber auch bei der Erstellung von Zertifikatsanträgen,
vor allem bei Verfahren unter Verwendung von Kommandozeilenwerkzeugen
oder spezieller Software für (s. Schritt C2), aber auch
in geringerem Umfang bei Anträgen mittels Webbrowsern (s.
Schritt C1). Darüber hinaus ergeben sich Probleme bei der
Klärung der Zuständigkeiten von Zertifizierungsstellen
bzw. Registrierungsstellen und dem Finden der passenden Zertifizierungsstellen
und Registrierungsstellen, der Logistik der persönlichen
Identifizierung gegenüber den Zertifizierungsstellen bzw.
Registrierungsstellen und dem richtigen Setzen der Proxylebensdauer,
die auch als Credential Lebensdauer bezeichnet wird.
-
1 zeigt
ein Flussdiagramm eines Ausführungsbeispiels eines Verfahrens
zum Zugreifen von einer Vorrichtung auf zumindest einen ersten Rechner
eines Rechnerverbundes, um zumindest Teilaufgaben eines Anwendungsprogramms
auf dem ersten Rechner des Rechnerverbundes durchzuführen,
wobei das Zugreifen auf den ersten Rechner einer Authentifizierung
mittels öffentlich zugänglicher Authentifizierungsinformationen über
eine von der Vorrichtung unabhängige Zugangsvorrichtung
voraussetzt. Dabei weist das Verfahren die folgenden Schritte auf.
-
Bereitstellen 110 des
Anmeldungsprogramms auf der Vorrichtung, wobei das Anmeldungsprogramm
fest eingebettete Authentifizierungsinformationen aufweist, die
das Anwendungsprogramm gegenüber der Zugangsvorrichtung
authentifizieren.
-
Authentifizieren 120 des
Anwendungsprogramms gegenüber der Zugangsvorrichtung mittels der
fest eingebetteten Authentifizierungsinformationen.
-
Authentifizieren 130 der
Zugangsvorrichtung gegenüber dem ersten Rechner mittels
der öffentlich zugänglichen Authentifizierungsinformationen
der Zugangsvorrichtung, die von einer Zertifizierungsstelle zertifiziert
ist, der der erste Rechner vertraut.
-
Derartige
Anwendungsprogramme können beispielsweise Programme zur
Simulation von Druckgussverfahren oder der Lokalisierung von Ölvorkommen
in tiefen Gesteinsschichten sein. Die dafür benötigten
Rechenleistungen übersteigen typischerweise die Kapazitäten
einzelner Rechner, auch einzelner Hochleistungsrechner, so dass
die Berechnungen zumindest teilweise von dem Anwendungsprogramm
bzw. dem Rechner, auf dem es installiert ist, auf einem Rechnerverbund,
z. B. ein Rechner-Grid, verteilt werden. Dabei greift das Anmeldungsprogramm
bzw. die Vorrichtung, auf der das Anwendungsprogramm vorliegt, auf
einzelne Rechner des Rechnerverbundes zu, beispielsweise indem es
so genannte Aufträge bzw. Jobs zur Durchführung bestimmter
Berechnungen an die Rechner des Rechnerverbundes sendet. Vor einem
derartigen Zugriff erfolgt jedoch zunächst eine Authentifizierung
gegenüber den Rechnern des Rechnerverbundes, und nur bei
positiver Authentifizierung ermöglichen die Rechner den
Zugriff auf dieselben, bzw. bearbeiten einen von dem Anwendungsprogramm
bzw. der Vorrichtung gesendeten Auftrag.
-
Der
Zugriff bzw. die Authentifizierung gegenüber den Rechnern
des Rechnerverbundes wird gemäß Ausführungsbeispielen
der vorliegenden Erfindung dadurch erleichtert, dass eine Zugangsvorrichtung,
z. B. eines Dienstleisters, die Authentifizierung gegenüber
den Rechnern des Rechnerverbundes durchführt, und der Nutzer
sich nur gegenüber der Zugangsvorrichtung des Dienstleisters
authentifiziert. Die Authentifizierung gegenüber der Zugangsvorrichtung
wird ferner dadurch erleichtert, dass der Dienstleister dem Nutzer
bzw. dem Anwender ein entsprechendes Anwendungsprogramm zur Verfügung
stellt, das die für die Authentifizierung gegenüber
der Zugangsvorrichtung notwendigen Authentifizierungsinformationen
schon in fest eingebetteter Form enthält. Der Nutzer benötigt
damit keine speziellen Kenntnisse oder Werkzeuge, um beispielsweise einen
privaten Schlüssel lokal zu erzeugen, und den zugehörigen öffentlichen
Schlüssel bzw. das zugehörige öffentliche
Zertifikat, zum Beispiel in das Anwendungsprogramm, zu importieren
und gegebenenfalls zu konvertieren, um es überhaupt importieren
zu können. Die von dem Dienstleister bereitgestellten Anwendungsprogramme
können beispielsweise Clients zu den zuvor erwähnten
Simulationsprogrammen für Druckgussverfahren oder für
die Lokalisierung von Erdölvorkommen in tiefen Gesteinsschichten
sein. Für die Rechner des Rechnerverbundes bzw. den Rechnerverbund
selbst sind nur geringe Änderungen, wenn überhaupt,
notwendig, da die Zugangsvorrichtung sich gegenüber den
Rechnern des Rechnerverbundes auf herkömmliche Weise authentifiziert,
beispielsweise mittels eines Schlüsselpaares und eines
Zertifikates einer PKI-Infrastruktur bzw. einer unabhängigen
Zertifizierungsstelle, der die Rechner des Rechnerverbundes aber
auch die Zugangsvorrichtung bzw. der Dienstleister vertrauen.
-
Der
Dienstleister kann entsprechende Anwendungsprogramme einer Vielzahl
von Anwendern anbieten, um einen vereinfachten Zugang zu einem Rechnerverbund
oder mehreren verschiedenen Rechnerverbunden zu ermöglichen.
Dazu enthält jedes Anwendungsprogramm ein anderes Schlüsselpaar,
dass sich von den Schlüsselpaaren der anderen Anwendungsprogramme
unterscheidet. Zur Unterscheidung vergibt der Dienstleister jedem
Nutzer bzw. jedem Anwendungsprogramm eine unterschiedliche Identifikationskennung,
die allgemein auch als Identifizierungsinformation bezeichnet werden
kann, und die bei dem Zugriff auf die Rechner des Rechnerverbundes
bzw. mit den Aufträgen an die Rechner des Rechnerverbundes
von der Zugangsvorrichtung mitgegeben wird. Dabei kann die Identifizierungsinformation
eine Klartextinformation über den Kunden bzw. Anwender
enthalten oder ein Kundenpseudonym sein, z. B. eine Kundennummer, um
einen pseudonymen Zugriff zu ermöglichen, so dass also
nur der Dienstleister in der Lage ist, die Identität des
Anwenders zurückzuverfolgen.
-
Nach
erfolgreicher gegenseitiger Authentifizierung greift das Anwendungsprogramm 212 auf den
ersten Rechner zu, indem es eine Anforderung bzw. einen entsprechenden
Auftrag zur Durchführung der zumindest einen Teilaufgabe
des Anwendungsprogramms an die Zugangsvorrichtung 220 sendet,
und diese eine zweite Anforderung bzw. einen zweiten Auftrag zur
Durchführung an den ersten Rechner 230 sendet,
die identisch zu der ersten ist oder zumindest ähnlich,
und beispielsweise die Identifizierungsinformation des Anwendungsprogramms als
Job-Parameter bzw. Auftrags-Parameter enthält. In derartigen
Ausführungsbeispielen leitet die Zugangsvorrichtung 220 die
Anforderung des Anwendungsprogramms 212 also nicht einfach
weiter, sondern erzeugt eine neue Anforderung, und authentifiziert
sich zuvor mittels der eigenen externen Schlüssel bzw.
Zertifikate gegenüber dem ersten Rechner. Dabei entspricht
der zweite Auftrag dem ersten, von dem Anwendungsprogramm selbst
gesendeten Auftrag, zumindest insofern, als dadurch die Durchführung
der zumindest einen Teilaufgabe durch den ersten Rechner initiiert
wird.
-
Das
Verfahren zum Zugreifen von einer Vorrichtung 210 auf zumindest
einen ersten Rechner 230 eines Rechnerverbundes kann daher
auch als Verfahren zum indirekten Zugreifen von einer Vorrichtung 210 auf
zumindest einen ersten Rechner 230 eines Rechnerverbundes über
eine Zugangsvorrichtung bezeichnet werden. Dabei umfasst das Zugreifen
auf den ersten Rechner beispielsweise ein Senden einer ersten Anforderung
von dem Anwendungsprogramm an die Zugangsvorrichtung 220,
und ein Senden einer zweiten Anforderung der Zugangsvorrichtung 220 an
den ersten Rechner 230, um die Durchführung der
durch die erste Anforderung definierten Teilaufgabe des Anwendungsprogramms durch
den ersten Rechner zu initiieren bzw. allgemein die durch die erste
Anforderung definierte Teilaufgabe des Anwendungsprogramms durch
den ersten Rechner durchzuführen.
-
2 zeigt
ein Blockdiagramm eines Ausführungsbeispiels eines Systems
zum Zugreifen von einer Vorrichtung auf zumindest einen ersten Rechner
eines Rechnerverbundes. Das System weist einen Vorrichtung 210,
eine Zugangsvorrichtung 220, einen ersten Rechner 230 eines
Rechnerverbundes, einen zweiten Rechner 240 des Rechnerverbundes und
einen dritten Rechner 250 des Rechnerverbundes sowie eine
Zertifizierungsstelle 260 und eine weitere Zertifizierungsstelle 270 auf.
Auf der Vorrichtung 210 ist ein Anwendungsprogramm 212 bereitgestellt, das
fest eingebettete Authentifizierungsinformationen 214 aufweist.
-
Dabei
bedeutet das Merkmal, dass die Authentifizierungsinformationen in
dem Anwendungsprogramm fest eingebettet sind, dass das Anwendungsprogramm
weder Schnittstellen für das Importieren oder Exportieren
dieser Authentifizierungsinformationen aufweist, noch Schnittstellen
oder Optionen, beispielsweise über in dem Anwendungsprogramm
implementierte Befehle, diese Authentifizierungsinformationen anzusehen
oder zu verändern. In anderen Worten, die fest eingebetteten
Authentifizierungsinformationen sind weder dem Nutzer des Anwendungsprogramms
noch Dritten über das Anwendungsprogramm zugänglich.
-
Die
Vorrichtung ist beispielsweise ein Computer, ein Notebook oder eine
andere Vorrichtung, die einen Speicher aufweist, um das Anwendungsprogramm
einschließlich der fest eingebetteten Authentifizierungsinformationen
in dem selben Speicher zu speichern, und einen Prozessor, um das
Anwendungsprogramm 212 auf der Vorrichtung 210 auszuführen.
Die fest eingebetteten Authentifizierungsinformationen werden zur
Unterscheidung von anderen Authentifizierungsinformationen im Folgenden auch
als erste Authentifizierungsinformationen bezeichnet. Die Vorrichtung 210 kann
ferner Einrichtungen zur Eingabe von Informationen, wie z. B. eine Tastatur
und/oder eine Maus aufweisen, und ferner Einrichtungen zur Anzeige
von Informationen, z. B. einen Bildschirm, damit der Nutzer bzw.
Anwender das Anwendungsprogramm installieren, starten und/oder steuern
kann, und Statusinformationen und Ergebnisse des Anwendungsprogramms
betrachten kann.
-
Die
Zugangsvorrichtung 220 ist beispielsweise ein Server und
wird beispielsweise durch einen Dienstleister betrieben.
-
Die
Vorrichtung 210 und die Zugangsvorrichtung 220 sind über
eine erste Kommunikationsverbindung 216, z. B. eine Internetverbindung,
miteinander verbunden.
-
Der
erste Rechner 230, der zweite Rechner 240 und
der dritte Rechner 250 stellen symbolisch Rechner eines
Rechnerverbundes dar, wobei der Rechnerverbund zwei oder mehr Rechner
aufweisen kann, die über Kommunikationsverbindungen miteinander
verbunden sind. Der Rechnerverbund kann beispielsweise ein Rechner-Grid,
eine Rechner-Cloud oder ein anderer Verbund von Rechnern sein, wobei
der erste Rechner 230 im Falle eines Rechner-Grids auch
als erster Grid-Rechner, der zweite Rechner 240 auch als
zweiter Grid-Rechner 240 und der dritte Rechner 250 auch
als dritter Grid-Rechner 250 bezeichnet werden kann.
-
In 2 ist
die Zugangsvorrichtung 220 über eine zweite Kommunikationsverbindung 226 mit
dem ersten Rechner 230 verbunden, der zweite Rechner über
eine dritte Kommunikationsverbindung 236 mit dem zweiten
Rechner 240, über eine vierte Kommunikationsverbindung 238 mit
dem dritten Rechner 250, und der zweite Rechner 240 über
eine fünfte Kommunikationsverbindung 246 mit dem
dritten Rechner 250 verbunden. Die zweite, dritte, vierte
und fünfte Kommunikationsverbindung kann beispielsweise
eine zweite, dritte, vierte und fünfte Internetverbindung
sein.
-
Die
Zugangsvorrichtung 220 kann einen Speicher aufweisen, indem
die Zugangsvorrichtung 220 zweite Authentifizierungsinformationen 224 und dritte
Authentifizierungsinformationen 284 speichert. Ferner kann
der erste Rechner 230 einen Speicher aufweisen, in dem
der erste Rechner vierte Authentifizierungsinformationen 234 speichert,
der zweite Rechner 240 einen Speicher aufweisen, indem
der zweite Rechner 240 fünfte Authentifizierungsinformationen 244 speichert
und der dritte Rechner 250 einen Speicher aufweisen, in
dem der dritte Rechner sechste Authentifizierungsinformationen 254 speichert.
-
In
dem Ausführungsbeispiel gemäß 2 sind
ferner die Zugangsvorrichtung 220, der erste Rechner 230 und
der zweite Rechner 240 und der dritte Rechner 250 über
Kommunikationsverbindungen 229, 239, 249 mit
der Zertifizierungsstelle 260 verbunden, die Kommunikationsverbindung
für den dritten Rechner 250 ist in 2 nicht
gezeigt, wobei die Kommunikationsverbindungen beispielsweise Internetverbindungen
sein können.
-
Die
Kommunikationsverbindungen zwischen der Zertifizierungsstelle und
der Zugangsvorrichtung 220 und den Rechnern des Rechnerverbundes
ermöglichen, dass die Zugangsvorrichtung und die Rechner
Zertifikate der Zugangsvorrichtung bzw. anderer Rechner beziehen
können, um sich gegenseitig authentifizieren zu können.
Diese Kommunikationsverbindungen sind optional. Beispielsweise können
die Zugangsvorrichtung 220 und die Rechner 230 bis 250 ausgebildet
sein, sich die Zertifikate zuvor von der Zertifizierungsstelle 260 zu
verschaffen und zu speichern, und die Authentifizierung mittels der
gespeicherten Zertifikate offline, d. h. ohne Verbindung zu der
Zertifizierungsstelle durchzuführen. Bei Ausführungsbeispielen,
die zusätzlich mittels Zertifikatssperrlisten, die von
der Zertifizierungsstelle 260 bereit gestellt werden, bei
jeder Authentifizierung überprüfen, ob Zertifikate
gesperrt sind, wird jedoch zumindest für diese Überprüfung
eine Verbindung zu der Zertifizierungsstelle hergestellt, diese
Prüfung wird daher auch als online-Überprüfung
bezeichnet.
-
In
einem weiteren Ausführungsbeispiel kann die Zugangsvorrichtung 220 beispielsweise über
eine sechste Kommunikationsverbindung 227 direkt mit dem
zweiten Rechner 240 verbunden sein und über eine
siebte Kommunikationsverbindung 228 mit dem dritten Rechner 250,
wobei diese Kommunikationsverbindungen beispielsweise Internetverbindungen sein
können.
-
Die
weitere oder zweite Zertifizierungsstelle 270 ist ausgebildet,
um Zertifikate für die Authentifizierung zwischen der Vorrichtung 210 und
der Zugangsvorrichtung 220 bereit zu stellen.
-
Dabei
bezeichnet die Zertifizierungsstelle 260 oder erste Zertifizierungsstelle 260 im
weiteren Sinne allgemein die Instanz, die dafür verantwortlich ist,
die Echtheit der Informationen des Inhabers sowie die Echtheit der
von ihr ausgestellten Zertifikate zu gewährleisten (als
Grundlage für das Vertrauen in die Zertifizierungsstelle
bzw. deren Zertifikate) bzw. die entsprechende Infrastruktur, und
im engeren Sinne einen Server oder ähnliche Infrastruktur
der Instanz Zertifizierungsstelle 260, auf dem die von
der Zertifizierungsstelle ausgestellten Zertifikate gespeichert
sind, und gegebenenfalls auch die Zertifikatssperrlisten.
-
Dabei
bezeichnet die Zertifizierungsstelle 270 oder zweite Zertifizierungsstelle 270 im
weiteren Sinne allgemein die Instanz, also z. B. den Dienstleister,
die das Anwendungsprogramm 212 mit der fest eingebetteten
Authentifizierungsinformation 214 und die Infrastruktur
für die Anmeldung des Nutzers bis zur tatsächlichen
Nutzung der Rechnerverbunddienste bereitstellt, bzw. die entsprechenden
Infrastruktur selbst, und im engeren Sinne einen Server oder ähnliche
Infrastruktur der Instanz Dienstleister 270, auf dem die
von dem Dienstleister und für die einzelnen Anwendungsprogramme 212 ausgestellten
Zertifikate und gegebenenfalls auch das für die Zugangsvorrichtung 220 ausgestellte
Zertifikat gespeichert sind, des Weiteren gegebenenfalls auch Zertifikatssperrlisten.
Die Zertifizierungsstelle 270 kann optional oder vorübergehend
mit der Vorrichtung über eine Kommunikationsverbindung 272 verbunden
sein, um beispielsweise das Anwendungsprogramm 212 auf
die Vorrichtung 210 zu laden, und mit der Zugangsvorrichtung über
Kommunikationsverbindung 274 verbunden sein, um dieser
beispielsweise die Zertifikate für neue Anwendungsprogramme
und/oder die Zugriffsrechte der Anwendungsprogramme bereit zu stellen.
-
Im
Folgenden wird ein Ausführungsbeispiel des Verfahrens und
des Systems zum Zugreifen von der Vorrichtung 210 auf zumindest
einen ersten Rechner 230 des Rechnerverbundes beschrieben.
-
Wie
zuvor erläutert kann das Anwendungsprogramm beispielsweise
ein Programm zur Simulation von Druckgussverfahren sein, die sehr
rechenintensiv ist. Die Rechenkapazität herkömmlicher
Computer ist meist nicht ausreichend, so dass beispielsweise auch
auf Rechner eines Rechnerverbundes zugegriffen wird, die Teile der
Berechnungen durchführen und die Ergebnisse der Berechnungen
an das Anwendungsprogramm zurückliefern. Die Berechnungen
des Rechnerverbunds sowie ggf. eigene Berechnungen werden von dem
Anwendungsprogramm zusammengeführt und dem Nutzer des Anwendungsprogramms
bereitgestellt, beispielsweise über den Bildschirm angezeigt
oder als Datei auf der Vorrichtung 210 gespeichert.
-
Wird
das Anwendungsprogramm gestartet, z. B. durch den Nutzer, so authentifiziert
sich das Anwendungsprogramm gegenüber der Zugangsvorrichtung
mittels der fest eingebetteten ersten Authentifizierungsinformationen 214 sobald
das Programm im Verlauf der Durchführung des Anwendungsprogramms
einen Zugriff auf den ersten Rechner des Rechnerverbundes (oder
jeden anderen Rechner des Rechnerverbundes) vorsieht.
-
Die
ersten Authentifizierungsinformationen 214 weisen dazu
einen ersten privaten Schlüssel auf, der dem Anwendungsprogramm
zugeordnet ist. Das Anwendungsprogramm 212 erzeugt basierend
auf dem ersten privaten Schlüssel, der nur dem Anwendungsprogramm
bekannt ist, mittels eines ersten Signaturerzeugungsalgorithmus
eine erste Signatur, die das Anwendungsprogramm über die
erste Kommunikationsverbindung 216 an den Zugangsrechner 220 sendet.
Die Zugangsvorrichtung 220 überprüft die
Echtheit der Signatur und damit die Identität des Anwendungsprogramms,
anhand eines ersten Signaturüberprüfungsalgorithmus
und einem ersten Zertifikat, das dem Anwendungsprogramm zugeordnet ist.
Das erste Zertifikat ist beispielsweise in dem Speicher der Zugangsvorrichtung
als Teil der zweiten Authentifizierungsinformationen 224 gespeichert.
-
Bei
positiver Authentifizierung des Anmeldungsprogramms durch die Zugangsvorrichtung 220, erzeugt
die Zugangsvorrichtung 220 eine zweite Signatur, wobei
die Zugangsvorrichtung 220 die zweite Signatur basierend
auf einem zweiten privaten Schlüssel, der der Zugangsvorrichtung
zugeordnet ist, mittels des zweiten Signalalgorithmus erzeugt. Der
zweite private Schlüssel ist nur der Zugangsvorrichtung
bekannt und ist Teil der zweiten Authentifizierungsinformation 224.
-
Die
zweite Signatur wird von der Zugangsvorrichtung 220 über
die Kommunikationsverbindung 216 an die Vorrichtung 210 gesendet.
Die Vorrichtung 210 authentifiziert die Zugangsvorrichtung 220 mittels
eines zweiten Überprüfungsalgorithmus, basierend
auf der zweiten Signatur und eines der Zugangsvorrichtung bzw. dem
zweiten privaten Schlüssel zugeordneten zweiten Zertifikat.
Das zweite Zertifikat ist Teil der fest eingebetteten bzw. ersten
Authentifizierungsinformation 214.
-
Ist
auch diese Überprüfung der Identität,
also die Authentifizierung der Zugangsvorrichtung gegenüber
der Vorrichtung positiv verlaufen, haben sich also beide, die Vorrichtung
und die Zugangsvorrichtung gegenseitig authentifiziert, kann beispielsweise ein
Sicherheitsschlüssel zwischen der Vorrichtung 210 und
der Zugangsvorrichtung 220 vereinbart werden, um die folgende
Kommunikation zwischen der Vorrichtung und der Zugangsvorrichtung
zu verschlüsseln. Dabei können die Vorrichtung 210 und die
Zugangsvorrichtung 22 ausgebildet sein, symmetrische und/oder
asymmetrische Verschlüsselungsalgorithmen zu verwenden.
-
Ferner
erfolgt neben der Authentifizierung (im engeren Sinne) der Vorrichtung 210 durch
die Zugangsvorrichtung 220 eine Autorisierung der Vorrichtung 210 bzw.
des Anwendungsprogramms 212, bei der überprüft
wird, welche Zugriffsrechte des Anwendungsprogramms 212 hat,
zum Beispiel in welchem Umfang das Anwendungsprogramm über
die Zugangsvorrichtung auf die Rechner des Rechnerverbundes zugreifen
darf. Ist die Authentifizierung der Vorrichtung positiv verlaufen
und ist der Zugriff des Anwendungsprogramms 212 auf die
Zugangsvorrichtung 220 bzw. den ersten Rechner 230 autorisiert, das
heißt berechtigt, so initiiert die Zugangsvorrichtung 220 eine
gegenseitige Authentifizierung mit dem ersten Rechner 230,
um nach positiver gegenseitiger Authentifizierung den Zugriff auf
den ersten Rechner 230 durchzuführen bzw. eine
Dienstanfrage, auch als Job Request bezeichnet, an den ersten Rechner 230 zu
senden.
-
Für
die Authentifizierung gegenüber dem ersten Rechner 230 erzeugt
die Zugangsvorrichtung 220 eine dritte Signatur und sendet
diese über die Kommunikationsverbindung 226 an
den ersten Rechner 230. Die Zugangsvorrichtung 220 ist
ausgebildet, die dritte Signatur, basierend auf einem dritten privaten
Schlüssel, der der Zugangsvorrichtung 220 zugeordnet
ist, und Teil einer dritten Authentifizierungsinformation 284 ist,
gemäß einem dritten Signaturalgorithmus zu erzeugen.
-
Der
erste Rechner 230 ist ausgebildet, die Zugangsvorrichtung 220 mittels
der dritten Signatur zu authentifizieren, indem er diese mittels
eines dritten Überprüfungsalgorithmus, basierend
auf der dritten Signatur und einem dritten Zertifikat, das der Zugangsvorrichtung 220 zugeordnet
ist, überprüft.
-
Bei
erfolgreicher Authentifizierung der Zugangsvorrichtung 220 durch
den ersten Rechner 230, erzeugt der erste Rechner 230 im
Gegenzug eine vierte Signatur und sendet diese über die
Kommunikationsverbindung 226 an die Zugangsvorrichtung 220.
Der erste Rechner 230 ist ausgebildet, die vierte Signatur,
basierend auf einem vierten Signaturerzeugungsalgorithmus und einem
vierten privaten Schlüssel, der dem ersten Rechner zugeordnet
ist, zu erzeugen. Der vierte private Schlüssel ist Teil
der vierten Authentifizierungsinformation 234.
-
Die
Zugangsvorrichtung 220 ist ausgebildet, mittels eines vierten
Signaturüberprüfungsalgorithmus die Echtheit der
vierten Signatur, basierend auf der vierten Signatur und einem vierten
Zertifikat zu überprüfen. Das vierte Zertifikat
ist Teil der dritten Authentifizierungsinformation 284.
-
Das
dritte Zertifikat ist ein von der Zertifizierungsstelle 260 ausgestelltes
Zertifikat, der der erste Rechner 230 vertraut. Das dritte
Zertifikat wird jedoch nicht nur für die Authentifizierung
der Zugangsvorrichtung durch den ersten Rechner verwendet, sondern
kann auch für die Authentifizierung der Zugangsvorrichtung
durch den zweiten Rechner 240, den dritten Rechner 250,
oder durch andere Dritte verwendet werden, sofern diese der Zertifizierungsstelle 260 vertrauen.
Wie zuvor erläutert, ist das dritte Zertifikat und damit
auch der entsprechende dritte öffentliche Schlüssel,
der dem dritten privaten Schlüssel zugeordnet ist, öffentlich
zugänglich. Das dritte Zertifikat kann damit auch als öffentliches
Zertifikat bezeichnet werden. Gleiches gilt beispielsweise für das
vierte Zertifikat, das dem ersten Rechner 230 zugeordnet
ist, und durch die Zertifizierungsstelle 260 zertifiziert
ist, der auch die Zugangsvorrichtung 220 bzw. der Dienstleister
vertraut. Auch das vierte Zertifikat und damit auch der entsprechende
vierte öffentliche Schlüssel, der dem vierten
privaten Schlüssel zugeordnet ist, ist öffentlich
zugänglich, und kann somit als öffentliches Zertifikat
bezeichnet werden.
-
Im
Gegensatz dazu werden das erste Zertifikat und das zweite Zertifikat
nur für die gegenseitige Authentifizierung des Anwendungsprogramms 212 und
der Zugangsvorrichtung 220 verwendet, nicht jedoch für
die Authentifizierung gegenüber anderen Dritten. Das erste
Zertifikat, und typischerweise auch das zweite Zertifikat, werden
der Öffentlichkeit nicht zugänglich gemacht, so
dass das erste Zertifikat und das zweite Zertifikat auch als private
Zertifikate oder als Zertifikate für die Verwendung in
einer geschlossenen Gruppe bezeichnet werden können.
-
In
anderen Worten, wie in 2 dargestellt (siehe gestrichelte
Linie), bestehen zwei verschiedene Bereiche oder Domänen,
der erste Bereich 202 und der zweite Bereich 204.
Der erste Bereich weist die Vorrichtung 210, die Zugangsvorrichtung 220 und die
zweite Zertifizierungsstelle 270 auf bzw. wird durch diese
gebildet. Innerhalb dieses Bereichs werden für die Authentifizierung
beispielsweise nur Zertifikate verwendet, die von der zweiten Zertifizierungsstelle
ausgestellt wurden, und denen auch nur die Zertifizierungsstelle
bzw. die Zugangsvorrichtung und die Anwendungsprogramme bzw. Vorrichtungen vertrauen
müssen. Diese bilden, wie zuvor beschrieben, eine geschlossene
Gruppe. Die zweite Zertifizierungsstelle kann daher auch als interne
Zertifizierungsstelle 270 bezeichnet werden und die Schlüsselpaare,
Signaturen und Zertifikate, die innerhalb der geschlossenen Gruppe
verwendet werden auch als interne Schlüsselpaare, interne
Signaturen und interne Zertifikate. Ferner kann die interne Zertifizierungsstelle
auch als abhängige Zertifizierungsstelle 270 bezeichnet
werden, da sowohl sie als auch die Zugangsvorrichtung 220 von
derselben Instanz bzw. dem selben Dienstleister bereit gestellt
werden.
-
Entsprechend
bilden die Zugangsvorrichtung 220, die Rechner 230 bis 250 und
die erste Zertifizierungsstelle 260 das externe Gebiet,
und kann die erste Zertifizierungsstelle 260 aus Sicht
der geschlossenen Gruppe auch als externe Zertifizierungsstelle 260 bezeichnet
werden und die Schlüsselpaare, Signaturen und Zertifikate,
die außerhalb der geschlossenen Gruppe verwendet werden,
auch als externe Schlüsselpaare, externe Signaturen und
externe Zertifikate.
-
In
anderen Worten, die Zugangsvorrichtung bildet die Schnittstelle
zwischen dem ersten oder internen Gebiet 202 und dem zweiten
oder externen Gebiet 204 und verwendet interne Schlüsselpaare, Signaturen
und Zertifikate für die Authentifizierung innerhalb des
internen Gebiets und externe Schlüsselpaare, Signaturen
und Zertifikate für die Authentifizierung außerhalb
des internen Gebiets bzw. in dem externen Gebiet.
-
Haben
beide positiv die Identität des jeweils anderen überprüft,
sich also gegenseitig positiv authentifiziert, kann beispielsweise
ein Sicherheitsschlüssel zwischen der Zugangsvorrichtung 220 und dem
ersten Rechner 230 vereinbart werden, um die folgende Kommunikation
zwischen der Zugangsvorrichtung 220 und dem ersten Rechner 230 zu
verschlüsseln, wie dies schon zuvor für die Vorrichtung 210 und
die Zugangsvorrichtung 220 beschrieben wurde. Dabei verwenden
die Zugangsvorrichtung 220 und der erste Rechner 230,
für den Fall, dass sie denselben Verschlüsselungsalgorithmus
wie die Vorrichtung 210 und die Zugangsvorrichtung 220 verwenden,
typischerweise einen anderen Schlüssel oder anderen Verschlüsselungsparameter.
Die Zugangsvorrichtung 220 und der erste Rechner 230 können
jedoch auch einen anderen Verschlüsselungsalgorithmus als
die Vorrichtung 210 und die Zugangsvorrichtung 220 verwenden.
-
Der
erste Rechner 230 kann ausgebildet sein, bei Bedarf, zur
Durchführung des Auftrags des Anwendungsprogramms einen
oder mehrere weitere Rechner des Rechnerverbunds einzubinden, z.
B. den zweiten Rechner 240. Dazu sendet der erste Rechner 230 selbst
wiederum einen Auftrag an den zweiten Rechner. Da der zweite Rechner 240 aber wiederum
zu einer anderen Administrationsdomäne als der erste Rechner 230 gehört,
wird zuvor eine Authentifikation durchgeführt.
-
Dabei
wird die Zugangsvorrichtung 220 gegenüber dem
zweiten Rechner 240 authentifiziert. Dafür erzeugt
die Zugangsvorrichtung 220 ein erstes Proxy und sendet
dieses über die Kommunikationsverbindung 226 an
den ersten Rechner 230. Das Proxy kann beispielsweise mit
dem Auftrag von der Zugangsvorrichtung 220 an den ersten
Rechner 230 gesendet werden. Die Zugangsvorrichtung 220 ist
ausgebildet, das erste Proxy basierend auf dem dritten privaten
Schlüssel und gemäß einem Proxyerzeugungsalgorithmus
zu erzeugen. Der erste Rechner 230 wiederum sendet eine
fünfte Signatur über die Kommunikationsverbindung 236 an
den zweiten Rechner 240, wobei der erste Rechner 230 ausgebildet
ist, die fünfte Signatur basierend auf dem Proxy mittels
eines fünften Signaturerzeugungsalgorithmus zu erzeugen.
-
Der
zweite Rechner 240 ist ausgebildet, die Zugangsvorrichtung 220 mittels
der fünften Signatur zu authentifizieren, indem er diese
mittels eines fünften Signaturüberprüfungsalgorithmus,
und dem dritten Zertifikat, das der Zugangsvorrichtung 220 zugeordnet
ist, überprüft. Der erste Rechner fungiert also als
ein Art Stellvertreter der Zugangsvorrichtung und wird nicht notwendigerweise
selbst authentifiziert. Eine zusätzliche Authentifizierung
des ersten Rechners 230 gegenüber dem zweiten
Rechner 240 basierend auf dessen Schlüssel und
Zertifikat ist optional möglich, um die Sicherheit weiter
zu erhöhen.
-
Bei
erfolgreicher Authentifizierung des ersten Rechners 230 (bzw.
der durch ihn verwendeten Identität der Zugangsvorrichtung)
durch den zweiten Rechner 240, erzeugt der zweite Rechner 240 im
Gegenzug eine sechste Signatur und sendet diese über die
Kommunikationsverbindung 236 an den ersten Rechner 230.
Der zweite Rechner 240 ist ausgebildet, die sechste Signatur,
basierend auf einem sechstem Signaturerzeugungsalgorithmus und einem
fünften privaten Schlüssel, der dem zweiten Rechner
zugeordnet ist, zu erzeugen. Der fünfte private Schlüssel
ist Teil der fünften Authentifizierungsinformation 244.
-
Der
erste Rechner 230 ist ausgebildet, mittels eines sechsten
Signaturüberprüfungsalgorithmus die Echtheit der
sechsten Signatur, basierend auf der sechsten Signatur und einem
fünften Zertifikat zu überprüfen. Das
fünfte Zertifikat ist Teil der vierten Authentifizierungsinformation 234.
-
Das
fünfte Zertifikat ist ein von der Zertifizierungsstelle 260,
der der erste Rechner 230 vertraut, für den zweiten
Rechner 240 ausgestelltes öffentliches Zertifikat,
das auch zur Authentifizierung des zweiten Rechners 240 durch
andere Rechner verwendet wird.
-
Haben
beide, der erste Rechner 230 und der zweite Rechner 240,
jeweils positiv die Identität des jeweils anderen bzw.
der Zugangsvorrichtung überprüft, sich also gegenseitig
positiv authentifiziert, kann wiederum ein Sicherheitsschlüssel
zwischen dem ersten Rechner und dem zweiten Rechner 240 vereinbart
werden, um die folgende Kommunikation zwischen beiden zu verschlüsseln,
wie dies schon zuvor beschrieben wurde.
-
Nach
der gegenseitigen Authentifizierung sendet der erste Rechner 230 den
Auftrag an den zweiten Rechner 240. In anderen Worten,
das Anwendungsprogramm 212 greift über die Zugangsvorrichtung 210 und
den ersten Rechner 220 auf den zweiten Rechner 230 zu,
um zumindest Teilaufgaben des Anwendungsprogramms auf dem zweiten
Rechner durchzuführen, wie dies analog in Bezug auf 1 beschrieben
wurde. Mit dem Auftrag kann der erste Rechner 230 ein zweites
Proxy an den zweiten Rechner senden, damit sich dieser – ähnlich
wie zuvor der erste Rechner gegenüber dem zweiten Rechner – gegenüber
anderen Rechnern des Rechnerverbundes, z. B. dem dritten Rechner 250 als
Stellvertreter der Zugangsvorrichtung bzw. im Namen der Zugangsvorrichtung
authentifizieren kann. Der zweite Rechner ist ausgebildet, das zweite
Proxy basierend auf dem ersten Proxy und einem Proxyerzeugungsalgorithmus
zu erzeugen.
-
Derart
kann das Anwendungsprogramm kaskadenartig auf weitere Rechner des
Rechnerverbundes zugreifen, um weitere Teilaufgaben durch diese durchführen
zu lassen.
-
Die
Zugangsvorrichtung kann jedoch auch ausgebildet sein, auf weitere
Rechner, z. B den zweiten 240 oder dritten Rechner 250 des
Rechnerverbunds direkt zuzugreifen, wobei bei dem direkten Zugriff
jeweils eine Signatur basierend auf dem dritten privaten Schlüssel
und gemäß dem dritten Signaturerzeugungsalgorithmus
erzeugt wird, und die Authentifizierung durch die Rechner mittels
des dritten Signaturüberprüfungsalgorithmus und
dem dritten öffentlichen Zertifikat durchführen.
-
Des
weiteren, kann die Zugangsvorrichtung ausgebildet sein, auch diesen
Rechnern ein von dem privaten Schlüssel abgeleiteten Proxy
mitzuschicken, so dass der zweite oder dritte Rechner sich mit deren Hilfe
gegenüber anderen Rechnern des Rechnerverbundes authentifizieren
können.
-
In
weiteren Ausführungsbeispielen können der erste
und zweite Signaturerzeugungsalgorithmus identisch sein, und entsprechend
auch der erste und der zweite Signaturüberprüfungsalgorithmus.
Ferner können der dritte, vierte, fünfte und sechste
Signaturerzeugungsalgorithmus identisch sein, und entsprechend auch
der dritte, vierte, fünfte und sechste Signaturüberprüfungsalgorithmus.
Außerdem können alle Signaturerzeugungsalgorithmen
identisch sein, und entsprechend auch alle Signaturüberprüfungsalgorithmen.
-
Unabhängig
davon, weist die erste Authentifizierungsinformation 214 zumindest
den ersten privaten Schlüssel auf, der dem Nutzer bzw.
Anwendungsprogramm zugeordnet ist. Ferner kann die erste Authentifizierungsinformation 214 den
zweiten öffentlichen Schlüssel bzw. das zweite
interne Zertifikat aufweisen, das dem zweiten privaten Schlüssel,
der der Zugangsvorrichtung zugeordnet ist, zugeordnet ist. Dabei
ist der zweite öffentliche Schlüssel optional und
ist nur dann erforderlich, wenn sich die Vorrichtung bzw. das Anwendungsprogramm
und die Zugangsvorrichtung gegenseitig authentifizieren. Authentifiziert
sich nur die Vorrichtung bzw. das Anwendungsprogramm gegenüber
der Zugangsvorrichtung, so ist nur der erste, fest eingebettete
private Schlüssel notwendig.
-
Die
zweite Authentifizierungsinformation 224 weist zumindest
den ersten öffentlichen Schlüssel bzw. das erste
interne Zertifikat auf. Optional auch den zweiten privaten Schlüssel.
-
Die
dritte Authentifizierungsinformation 284 weist zumindest
den dritten privaten Schlüssel auf, und kann ferner öffentliche
Schlüssel bzw. öffentliche Zertifikate, also externe
Zertifikate, aufweisen, um Rechner des Rechnerverbundes oder andere
Rechner zu authentifizieren, also z. B. das vierte und fünfte öffentliche
Zertifikat aufweisen, um den ersten Rechner und den zweiten Rechner
zu authentifizieren.
-
Die
vierte Authentifizierungsinformation 234 weist zumindest
den vierten privaten Schlüssel auf, und kann ferner öffentliche
Zertifikate, also externe Zertifikate, aufweisen, um die Zugangsvorrichtung, Rechner
des Rechnerverbundes oder andere Rechner zu authentifizieren, also
z. B. das dritte und fünfte öffentliche Zertifikat
aufweisen, um die Zugangsvorrichtung und den zweiten Rechner zu
authentifizieren.
-
Die
fünfte Authentifizierungsinformation 244 weist
zumindest den fünften privaten Schlüssel auf, und
kann ferner öffentliche Zertifikate, also externe Zertifikate,
aufweisen, um die Zugangsvorrichtung, Rechner des Rechnerverbundes
oder andere Rechner zu authentifizieren, also z. B. das dritte und
vierte öffentliche Zertifikat aufweisen, um die Zugangsvorrichtung
und den ersten Rechner zu authentifizieren.
-
Die
Erläuterungen zu dem Ausführungsbeispiel des Systems
gemäß 2 gelten entsprechend für
das Verfahren. Entsprechend weist der Abschnitt der gegenseitigen
Authentifizierung der Vorrichtung 210 und der Zugangsvorrichtung 220 gemäß einem
Ausführungsbeispiel folgende Schritte auf, siehe 3A.
-
Erzeugen 302 einer
ersten Signatur durch das Anwendungsprogramm, wobei die erste Signatur basierend
auf dem ersten privaten Schlüssel, der dem Anwendungsprogramm
zugeordnet ist, gemäß einem ersten Signaturalgorithmus
erzeugt wird.
-
Senden 304 der
ersten Signatur von dem Anwendungsprogramm an die Zugangsvorrichtung.
-
Authentifizieren 306 des
Anwendungsprogramms durch die Zugangsvorrichtung mittels eines ersten Überprüfungsalgorithmus
und basierend auf der ersten Signatur und dem ersten Zertifikat.
-
Bei
positiver Authentifizierung des Anwendungsprogramms durch die Zugangsvorrichtung,
Erzeugen 308 einer zweiten Signatur durch die Zugangsvorrichtung,
wobei die zweite Signatur basierend auf einem zweiten privaten Schlüssel,
der der Zugangsvorrichtung zugeordnet ist, mittels eines zweiten
Signaturalgorithmus erzeugt wird.
-
Senden 310 der
zweiten Signatur von der Zugangsvorrichtung an die Vorrichtung.
-
Authentifizieren 312 der
Zugangsvorrichtung durch die Vorrichtung mittels eines zweiten Überprüfungsalgorithmus,
basierend auf der zweiten Signatur und eines der Zugangsvorrichtung
zugeordneten zweiten Zertifikats.
-
Der
Abschnitt der gegenseitigen Authentifizierung der Zugangsvorrichtung 220 und
des ersten Rechners 230 weist daher gemäß einem
Ausführungsbeispiel folgende Schritte auf, siehe 3B.
-
Erzeugen 322 einer
dritten Signatur durch die Zugangsvorrichtung 220 und getriggert
durch das Anwendungsprogramm (bzw. den zugehörigen Client 210),
wobei die dritte Signatur basierend auf dem dritten privaten Schlüssel,
der der Zugangvorrichtung zugeordnet ist, gemäß einem
dritten Signaturerzeugungsalgorithmus erzeugt wird.
-
Senden 324 der
dritten Signatur von der Zugangsvorrichtung an den ersten Rechner.
-
Authentifizieren 326 der
Zugangsvorrichtung durch den ersten Rechner mittels eines dritten
Signaturüberprüfungsalgorithmus und basierend
auf der dritten Signatur und dem dritten Zertifikat.
-
Bei
positiver Authentifizierung der Zugangsvorrichtung durch den ersten
Rechner, Erzeugen 328 einer vierten Signatur durch den
ersten Rechner, wobei die vierte Signatur basierend auf einem vierten privaten
Schlüssel, der dem ersten Rechner zugeordnet ist, mittels
eines vierten Signaturalgorithmus erzeugt wird.
-
Senden 330 der
vierten Signatur von dem ersten Rechner an die Zugangsvorrichtung.
-
Authentifizieren 340 des
ersten Rechners durch die Zugangsvorrichtung mittels eines vierten Überprüfungsalgorithmus,
basierend auf der vierten Signatur und eines der Zugangsvorrichtung
zugeordneten vierten Zertifikats.
-
In
einem Ausführungsbeispiel, bei dem der Rechnerverbund ein
Rechner-Grid ist, kann die Zugangsvorrichtung 220 auch
als Grid-Gateway bezeichnet werden und der Dienstleister auch als Grid-Gateway
Service Provider.
-
In
einem weiteren Ausführungsbeispiel kann die Zugangsvorrichtung 220 ausgebildet
sein, für die Authentifizierung gegenüber dem
ersten Rechner 230 (oder anderen Rechnern) eine dritte
Signatur, die das dritte bzw. externe Zertifikat der Zugangsvorrichtung 220 aufweist,
mittels eines abgewandelten dritten Signaturerzeugungsalgorithmus
zu erzeugen. Der erste Rechner kann dabei ausgebildet sein, diese
dritte Signatur mit dem dritten Zertifikat mittels eines abgewandelten
dritten Signaturüberprüfungsalgorithmus und einem
externen Zertifikat der externen Zertifizierungsstelle zu überprüfen,
wobei die Zertifizierungsstelle sich dieses Zertifikat beispielsweise selbst
ausgestellt hat. Dieses eigene Zertifikat der Zertifizierungsstelle
kann beispielsweise als Teil der vierten Authentifizierungsinformation
in dem ersten Rechner 230 gespeichert sein. Die Zugangsvorrichtung
und der erste Rechner können ferner ausgebildet sein, die
Authentifizierung des ersten Rechners gegenüber der Zugangsvorrichtung
analog durchzuführen, indem der erste Rechner eine vierte
Signatur sendet, die das vierte externe Zertifikat aufweist, und die
Zugangsvorrichtung diese vierte Signatur mittels des Zertifikats
der externen Zertifizierungsstelle überprüft.
Die anderen Rechner des zweiten Bereichs können entsprechend
ausgebildet sein. Die Authentifizierung über Proxys kann
ebenfalls analog zu dem beschriebenen Beispiel erfolgen Dies hat
den Vorteil, dass, im Gegensatz zu dem zuvor beschriebenen Ausführungsbeispiel,
bei dem die Zugangsvorrichtung bzw. die Rechner die verschiedenen öffentlichen
bzw. externen Zertifikate der anderen Rechner bzw. der Zugangsvorrichtung
speichern, lediglich ein fremdes Zertifikat, nämlich das
Zertifikat der Zertifizierungsstelle 260, benötigt
bzw. gespeichert wird.
-
In
einem weiteren Ausführungsbeispiel kann auch in der ersten
Domäne 202 die Authentifizierung über
eine Signatur erfolgen, in der das interne Zertifikat des Anwendungsprogramms
bzw. das interne Zertifikat der Zugangsvorrichtung enthalten ist,
und die Zugangsvorrichtung bzw. das Anwendungsprogramm als Empfänger
der Signatur diese mittels einem internen Zertifikat der internen
Zertifizierungsstelle überprüfen, das sich die
interne Zertifizierungsstelle 270 selbst ausgestellt hat.
-
Ausführungsbeispiele
der vorliegenden Erfindung lösen die zuvor beschriebenen
Probleme durch die folgenden Merkmale. Zum einen wird ein Dienstleister
als Mittler zwischen dem Endnutzer der Grid Anwendungen und Services
einerseits und den Anbietern von Grid Ressourcen, Anwendungen, Diensten
und Daten andererseits, eingeführt. Dieser Dienstleister
betreibt einen Grid Gateway Service, der mit Hilfe eines auf den
Dienstleister ausgestellten Service-Zertifikats Zugriff auf alle
Ressourcen, Anwendungen, Services und Daten im Grid hat, die er seinen
Kunden nach außen zur Verfügung stellt.
-
Die
ganze Komplexität der Authentifizierung und Autorisierung
wird also vom Endkunden auf den Dienstleister übertragen.
Um einen ähnlichen hohen Sicherheitsstandard bei der Authentifizierung
und Autorisierung des Nutzers gegenüber dem Dienstleister
zu erreichen, wie dies innerhalb des Grids der Fall ist, kann der
Dienstleister auch gegenüber dem Endnutzer eine PKI-basierte
Authentifizierung und Autorisierung implementieren. Dazu erfolgt
der Zugriff des Kunden auf den Grid Gateway Service über ein
Anwendungsprogramm, das als Service-Client für den Grid
Gateway Service fungiert und über ein fest eingebautes
Schlüsselpaar (PKI Zertifikat) verfugt, mit dem der Nutzer
niemals direkt in Berührung kommt. Somit wird zum einen
die Authentifizierung für den Nutzer erleichtert, zum anderen
wird durch das feste Einbetten verhindert oder zumindest erschwert,
dass das fest eingebaute Schlüsselpaar in dem Anwendungsprogramm
selbst manipuliert wird oder aus dem Anwendungsprogramm exportiert
wird, um dieses missbräuchlich in anderen Anwendungen zu
verwenden.
-
So
kann auf einfache Weise eine zertifikatsbasierte (PKI, x509) Authentifizierung
des Clients gegenüber dem Gateway Service erreicht werden,
indem der Dienstleister beim Verkauf des Clients bzw. des Anwendungsprogramms
an den Kunden ein Schlüsselpaar ausstellt, das fest in
den Client eingebaut wird. Der Kunde erhält also seine
Desktop-Anwendung bereits mit fest installiertem Kundenzertifikat.
Dieses Zertifikat erhält eine Lebensdauer entsprechend
der Lizenzvereinbarung zwischen Dienstleister und Kunde. Der Dienstleister
kann dazu eine eigene Zertifizierungsinstanz benutzen, da er – bzw. der
von ihm betriebene Grid Gateway Service – der einzige ist,
der dem Zertifikat vertrauen muss. Der Dienstleister stellt weiterhin
sicher, dass der Grid Gateway Service ausschließlich solchen
Service-Requests eine Autorisierung erteilt, die durch ein vom Dienstleister
ausgestelltes Zertifikat signiert und ggf. verschlüsselt
wurden.
-
Der
Grid Gateway Service führt dann entsprechend der Anfragen
des Kunden bzw. des Anwendungsprogramms Jobs im Grid aus. Diese
Jobs laufen unter der Identität des Dienstleisters. Um
später eine kundengenaue Abrechnung im Grid zu ermöglichen,
wird ein eindeutiges Kundenpseudonym als Job-Parameter bzw. Identifizierungsinformation mitgeführt,
welches auch von den Grid-Accounting-Systemen mit protokolliert
wird. Durch Accounting-Tools werden die Grid-Accounting-Daten dann für
den Dienstleister automatisch so aufbereitet, dass eine eindeutige
Zuordnung von Nutzungs-Parametern zu Kundenpseudonymen möglich
ist. Diese Daten kann der Dienstleister dann für die Rechnungsstellung
an den Endkunden nutzen. Ein für diesen Zweck geeignetes
System ist das Tool „CollAct” der Firma c. a.
r. u. s. IT AG in Verbindung mit dem in D-Grid eingesetzten Accounting
Tool DGAS.
-
Bei
jeder eingehenden Anfrage des Kunden-Clients erzeugt der Grid Gateway
Service Grid Jobs, die unter dem Grid Zertifikat des Grid Gateway Service
laufen und als Job-Parameter das Kundenpseudonym mitführen.
Auf diese Weise erreicht man folgende Ziele: a) eine PKI basierte
Authentifizierung des Kunden gegenüber dem Dienstleister,
b) gleichzeitig durchlauft der Kunde keine komplexen Zertifizierungsprozesse,
c) der Kunde gibt nicht ständig Passphrases oder Kennwörter
ein, wenn er das Grid bzw. dessen Ressourcen und Services benutzen
will, d) eine den Grid Sicherheitsnormen bzw. den Richtlinien der
Zertifizierungsinstanzen entsprechende PKI basierte Authentifizierung
des Dienstleisters gegenüber den Grid Ressourcen und Diensten,
e) eine Abrechnung der vom Dienstleister in Anspruch genommenen
Grid Ressourcen und Dienste zwischen den Betreibern dieser Ressourcen
und Dienste einerseits und dem Dienstleister andererseits, und f)
eine Zuordnung der eigenen Kosten des Dienstleisters im Grid zu
den Kunden, in deren Auftrag er im Grid agiert
-
4A und 4B zeigen
gemeinsam ein Flussdiagramm eines Ausführungsbeispiels.
Die Bestandteile des Ausführungsbeispiels werden im Folgenden beschrieben.
-
Ein
Grid Gateway Service 220 mit Schnittstellen zu den für
die Ausführung von Grid Jobs notwendigen Infrastrukturdiensten
anderer Betreiber, wie z. B. einem Grid Resource Broker, Grid Workflow Service,
Accounting Diensten, Grid User Management Systemen, etc. Dieser
Grid Gateway Service bietet nach außen (zum Kunden) Schnittstellen
für die Client Anwendungen bzw. Anwendungsprogramme, um
sich mit dem von dem Dienstleister für den Kunden ausgestellten
Zertifikat zu authentifizieren. Weiterhin erfolgt eine Autorisierung
am Grid Gateway Service auf Basis der Kundeninformationen, die der Nutzer
in einer Kundendatenbank verwaltet.
-
Eine
Kundendatenbank, in der Kundendaten, wie z. B. Adressdaten, Kreditkarten-
oder Kontodaten, verwaltet werden können und mit Rollen-
und Rechteinformationen für den Zugriff auf Grid Services/Grid
Anwendungen korreliert werden können. Dieses Kundenmanagementsystem
kann außerdem eine Schnittstelle zu den Accounting Services
im Grid aufweisen, um die Informationen über für
das Accounting relevante Vertragsdaten an diese weiter zu geben.
-
Eine
Desktop Anwendung bzw. ein Anwendungsprogramm, das als Client für
den Grid Gateway Service dient. Für eine generische Unterstützung
für die Erstellung solcher Clients, werden Software-Bibliotheken
verwendet, mit denen Desktop-Anwendungen auf einfache Weise zu Grid-Clients
erweitert werden können.
-
Einer
Unterstützungsplattform für den Dienstleister,
die ihn bei der Client-Initialisierung und der Ausstattung mit eigens
vom Dienstleister ausgestellten Zertifikaten unterstützt,
sowie die Erstellung von Zertifikaten ermöglicht. Diese
Unterstützungsplattform sorgt beispielsweise auch dafür,
dass der Grid Gateway Service automatisch informiert wird, dass
nun ein neuer Kunde existiert und welche Zugriffsrechte er hat.
Dazu zählt auch die Übermittlung des Distinguished
Names (DN) bzw. Unterscheidungsnamens des für die Nutzerauthentifizierung
in den Client eingebauten Schlüsselpaares an den Grid Gateway
Service.
-
Wie
in den 4A und 4B zu
sehen ist, reduziert sich der Aufwand für den Kunden auf
folgende Schritte: a) Lizenzerwerb, b) Bezug der Nutzung: entweder über
Download oder auf Datenträger, c) Fachliche Nutzung der
Desktop Anwendung, die als Grid Client fungiert, d) Nutzung der
Ergebnisdaten des Grid Service in seiner Desktop Anwendung, e) monatliche
Bezahlung der Rechnung für die Nutzung des Grid Services,
z. B. per Bankeinzug oder Kreditkartenabrechnung.
-
Je
nachdem, wie stark sich der Dienstleister gegenüber seinem
Kunden absichern will, kann für den Lizenzerwerb noch die
Einholung eines Identitätsnachweises, z. B. über
ein Postident-Verfahren, enthalten sein. Dies ist aber für
die weitere Nutzung von Grid Diensten nicht zwingend und ist optional.
-
Ein
Vorteil der Ausführungsbeispiele ist, dass der Kunde überhaupt
nicht mehr mit Sicherheitsmechanismen in Berührung kommt.
Nur, falls der Dienstleister seinerseits einen Identitätsnachweis des
Kunden haben möchte, ist auf Kundenseite noch das Ausfüllen
eines Formulars und die Identitätsprüfung auf
dem nächsten Postamt erforderlich. Der Kunde kommt aber
in keinem Fall mit der Beantragung oder Nutzung von Zertifikaten
in Berührung und kann trotzdem eine PKI-basierte Kommunikation
zwischen seinem Client und den Grid Diensten nutzen.
-
Weitere
Vorteile der Ausführungsbeispiele liegen in der weitgehenden
Unterstützung des Dienstleisters bei der Erstellung solcher
Clients sowie in der Automatisierung der für das Funktionieren des
oben beschriebenen Konzepts notwendigen Schritte wie: a) Kommunikation
und Datenaustausch mit Accountingdiensten, b) Eintrag von Nutzerdaten in
den Autorisierungssystemen des Grid Gateway Service, c) Erstellung
von Nutzerzertifikaten für die Grid Clients, d) Erstellen
von kundenspezifischen Grid Client Instanzen inkl. der Kundenzertifikate,
und e) Bezug von Accountingdaten aus den Grid Accounting Systemen
und Aufbereitung für die automatische Rechnungsstellung.
-
Ausführungsbeispiele
ermöglichen einerseits Kunden einen möglichst
einfachen und dabei sicheren Zugang zu Grid Services oder generell
Web Services, indem dem Kunden ein spezieller Client für die
zu nutzenden Services zur Verfügung gestellt wird. Da zwischen
dem Client und den eigentlichen Services noch ein Gateway Service
geschaltet wird, kann die Funktionalität des Service-Angebots
auch im Nachhinein verbessert werden.
-
Ausführungsbeispiele
können für den Zugang zu Services in Computing
Grids, zu Cloud Services und zu Software as a Service (Software
als Dienstleistung), Infrastructure as a Service (Infrastruktur
als Dienstleistung) oder Plattform as a Service (Plattform als Dienstleistung)
Angeboten genutzt werden und generell auch für den Zugang
zu Web Services.
-
Darüber
hinaus ermöglichen Ausführungsbeispiele der Erfindung,
auf Anbieterseite alle für die Kundenverwaltung, die Abrechnung
und die Erstellung der kundenspezifischen Clients notwendigen Prozesse
soweit wie möglich zu automatisieren.
-
4A und 4B zeigen
ein Flussdiagramm eines Ausführungsbeispiels eines Verfahrens
von der Registrierung eines Nutzers bis zur Nutzung einschließlich
der Abrechnung der Nutzung.
-
Die
Abbildung des Flussdiagramms ist aufgrund der Größe
in zwei Figuren 4A und 4B unterteilt. 4A und B zeigen die verschiedenen Abschnitte
des Verfahrens bzw. Dienstschichten des Systems, wobei Abschnitt 4010 dem
Endkunden zugeordnet ist, Abschnitt 4020 der Grid-Klein-Anwendung
(für Nutzer sichtbar) zugeordnet ist, Abschnitt 4030 dem
Dienstleister (für Nutzer sichtbar) zugeordnet ist, Abschnitt 4040 wiederum
der Grid-Client Anwendung (für Nutzer transparent) zugeordnet
ist, Abschnitt 4050 der Software-Entwicklungsplattform
des Dienstleisters (für Nutzer transparent) zugeordnet
ist, Abschnitt 4060 dem Dienstleister via Unterstützungsplattform
(für Nutzer transparent) zugeordnet ist, Abschnitt 4070 der
Unterstützungsplattform des Dienstleisters (DL) (automatisch
und für Nutzer transparent) zugeordnet ist, Abschnitt 4080 dem
Grid-Gateway Service des Dienstleisters (für Nutzer transparent)
zugeordnet ist und Abschnitt 4090 dem Accounting Service
(für Nutzer transparent) zugeordnet ist. Abschnitt 4060 und
die entsprechenden Schritte sind in beiden 4A und 4B dargestellt.
-
In
dem Flussdiagramm ist die Startposition mit dem Bezugszeichen 4110 bezeichnet.
Zu Beginn erwirbt der Kunde (Schritt 4120) eine Lizenz
für einen Grid-Client und schließt einen Nutzungsvertrag
für die Grid-Dienste (Grid-Services) des Dienstleisters ab.
-
Nach
Abschluss des Nutzungsvertrages bzw. des Erwerbs der Lizenz wird
von dem Dienstleister über die Unterstützungsplattform
in Schritt 4130 der Kundenstamm für den Endkunden
angelegt und ein Kundenpseudonym festgelegt, wobei das Kundenpseudonym
als Identifizierungsinformation zur Identifizierung des Kunden verwendet
wird. In Schritt 4140 werden von dem Dienstleister über
die Unterstützungsplattform die Vertragsparameter und die
damit verbundenen Nutzungsrechte gesetzt. In anderen Worten, in
Schritt 4140 werden die für die Autorisierung
relevanten Parameter definiert und gespeichert. Danach werden in
Schritt 4150 die Kundendaten und Vertragsdaten durch die
Unterstützungsplattform des Dienstleisters automatisch
an den Accounting-Dienst (Accounting Service) übertragen
und in Schritt 4160 in dem Accounting-Service die Kundendaten
und Vertragsdaten gesetzt. Ferner werden in Schritt 4170 automatisch
in der Unterstützungsplattform des Dienstleisters die Zugangsrechte für
die Nutzung von Grid Application Services (Grid Anwendungsdiensten)
in dem Policy Decision Point des Grid-Gateway-Services eingetragen
und in Schritt 4180 erhält der Policy Decision
Point (PDP = Regelentscheidungspunkt) des Grid-Gateway-Service den
neuen Policy-Eintrag für den neuen Kunden, (z. B. in XACML – eXtensible
Access Control Markup Language). Ferner wird nach dem Eintrag der
Zugriffsrechte in Schritt 4170 ein PKI-Schlüsselpaar
für den Kunden erstellt (Schritt 4180), wobei
dem Schlüsselpaar der Kundennummer CN zugeordnet wird und
eine Lebensdauer, im Englischen auch als life time bezeichnet, gesetzt,
die der Dauer der Lizenz entspricht. In Schritt 4190 wird
automatisch durch die Software-Entwicklungs-Plattform des Dienstleisters
ein kundenspezifischer Grid-Client erstellt und das Kundenzertifikat
bzw. das PKI-Schlüsselpaar wird fest in diesen Grid-Client
eingebaut. In Schritt 4200 wird der Client auf sichere
Weise an den Kunden geliefert. Nach Erhalt kann der Kunde die Desktop-Anwendung
bzw. das Anwendungsprogramm 212 einschließlich
der darin fest eingebauten Authentifizierungsinformationen 214 auf
seinem Computer 210 installieren und nach erfolgreicher
Installation das Anwendungsprogramm mit der Grid Service Schnittstelle
nutzen (Schritt 4210). Bei der Durchführung des
Anwendungsprogramms initiiert das Anwendungsprogramm beispielsweise
einen Grid-Service-Call, z. B. verschlüsselt, wobei sich
das Anwendungsprogramm mittels des eingebauten Zertifikats und des
darin enthaltenen Kundenpseudonyms (Identifizierungsinformation)
authentisiert (Schritt 4230). In Schritt 4240 authentifiziert
der Policy-Execution Point (PEP = Regelausführungspunkt) des
Grid-Gateway-Service den Kunden bzw. das Anwendungsprogramm über
das Zertifikat aus dem Anwendungsprogramm. In Schritt 4250 erteilt
der Policy-Execution Point des Grid-Gateway-Service die Autorisierung
entsprechend der im PDP hinterlegten Regeln, die dem Nutzungsvertrag
entsprechen und in Schritt 4260 wird der Grid-Job bzw.
die Grid Dienst Anfrage durch den Grid-Gateway-Service an einen oder
mehrere Grid-Rechner eines Rechner-Grids gesendet. Dabei wird das
Kundenpseudonym als Jobparameter mitgeschickt und der Grid Gateway
Service nutzt das Grid-Service Zertifikat des Dienstleisters. In
Schritt 4270 erhält der Grid-Service bzw. der Zugangsrechner 220 die
Ergebnisse aus dem Grid zurück und transferiert diese zurück
an das Anwendungsprogramm des Kunden (Schritt 4280).
-
Nach Übermittlung
der Ergebnisse kann der Kunde die Ergebnisse in seinem Anwendungsprogramm
sehen (Schritt 4290). Zusätzlich werden in Schritt 4300 die
Nutzungsdaten und Jobparameter, z. B. das Kundenpseudonym durch
die Accounting-Services erfasst, in Schritt 4310 die entsprechenden
Accounting- und Billingdaten aus den Grid-Accounting-Services erfasst,
und in Schritt 4320 zur Ermittlung der Kosten für
die Grid-Jobs des Kunden anhand der Accounting- und Billigdaten
verwendet. Basierend darauf kann in Schritt 4330, beispielsweise eine
monatliche Rechnungsstellung gegenüber dem Kunden erfolgen,
der diese in Schritt 4340 zahlt, z. B: monatlich, beispielsweise
per Bankeinzug. Der Endpunkt des Verfahrens ist mit dem Bezugszeichen 4350 bezeichnet.
-
Obwohl
manche Aspekte im Zusammenhang mit einer Vorrichtung beschrieben
wurden, versteht es sich, dass diese Aspekte auch eine Beschreibung
des entsprechenden Verfahrens darstellen, sodass ein Block oder
ein Bauelement einer Vorrichtung auch als ein entsprechender Verfahrensschritt
oder als ein Merkmal eines Verfahrensschrittes zu verstehen ist.
Analog dazu stellen Aspekte, die im Zusammenhang mit einem oder
als ein Verfahrensschritt beschrieben wurden, auch eine Beschreibung
eines entsprechenden Blocks oder Details oder Merkmals einer entsprechenden
Vorrichtung dar.
-
Je
nach bestimmten Implementierungsanforderungen können Ausführungsbeispiele
der Erfindung in Hardware oder in Software implementiert sein. Die
Implementierung kann unter Verwendung eines digitalen Speichermediums,
beispielsweise einer Floppy-Disk, einer DVD, einer Blu-ray Disc,
einer CD, eines ROM, eines PROM, eines EPROM, eines EEPROM oder
eines FLASH-Speichers, einer Festplatte oder eines anderen magnetischen
oder optischen Speichers durchgeführt werden, auf dem elektronisch
lesbare Steuersignale gespeichert sind, die mit einem programmierbaren
Computersystem derart zusammenwirken können oder zusammenwirken, dass
das jeweilige Verfahren durchgeführt wird. Deshalb kann
das digitale Speichermedium computerlesbar sein. Manche Ausführungsbeispiele
gemäß der Erfindung umfassen also einen Datenträger,
der elektronisch lesbare Steuersignale aufweist, die in der Lage
sind, mit einem programmierbaren Computersystem derart zusammenzuwirken,
dass eines der hierin beschriebenen Verfahren durchgeführt
wird.
-
Allgemein
können Ausführungsbeispiele der vorliegenden Erfindung
als Computerprogrammprodukt mit einem Programmcode implementiert
sein, wobei der Programmcode dahin gehend wirksam ist, eines der
Verfahren durchzuführen, wenn das Computerprogrammprodukt
auf einem Computer abläuft. Der Programmcode kann beispielsweise
auch auf einem maschinenlesbaren Träger gespeichert sein.
-
Andere
Ausführungsbeispiele umfassen das Computerprogramm zum
Durchführen eines der hierin beschriebenen Verfahren, wobei
das Computerprogramm auf einem maschinenlesbaren Träger
gespeichert ist.
-
Mit
anderen Worten ist ein Ausführungsbeispiel des erfindungsgemäßen
Verfahrens somit ein Computerprogramm, das einen Programmcode zum Durchführen
eines der hierin beschriebenen Verfahren aufweist, wenn das Computerprogramm
auf einem Computer abläuft. Ein weiteres Ausführungsbeispiel
der erfindungsgemäßen Verfahren ist somit ein Datenträger
(oder ein digitales Speichermedium oder ein computerlesbares Medium),
auf dem das Computerprogramm zum Durchführen eines der
hierin beschriebenen Verfahren aufgezeichnet ist.
-
Ein
weiteres Ausführungsbeispiel des erfindungsgemäßen
Verfahrens ist somit ein Datenstrom oder eine Sequenz von Signalen,
der bzw. die das Computerprogramm zum Durchführen eines
der hierin beschriebenen Verfahren darstellt bzw. darstellen. Der
Datenstrom oder die Sequenz von Signalen kann bzw. können
beispielsweise dahin gehend konfiguriert sein, über eine
Datenkommunikationsverbindung, beispielsweise über das
Internet, transferiert zu werden.
-
Ein
weiteres Ausführungsbeispiel umfasst eine Verarbeitungseinrichtung,
beispielsweise einen Computer oder ein programmierbares Logikbauelement,
die dahin gehend konfiguriert oder angepasst ist, eines der hierin
beschriebenen Verfahren durchzuführen.
-
Ein
weiteres Ausführungsbeispiel umfasst einen Computer, auf
dem das Computerprogramm zum Durchführen eines der hierin
beschriebenen Verfahren installiert ist.
-
Bei
manchen Ausführungsbeispielen kann ein programmierbares
Logikbauelement (beispielsweise ein feldprogrammierbares Gatterarray,
ein FPGA) dazu verwendet werden, manche oder alle Funktionalitäten
der hierin beschriebenen Verfahren durchzuführen. Bei manchen
Ausführungsbeispielen kann ein feldprogrammierbares Gatterarray
mit einem Mikroprozessor zusammenwirken, um eines der hierin beschriebenen
Verfahren durchzuführen. Allgemein werden die Verfahren
bei einigen Ausführungsbeispielen seitens einer beliebigen
Hardwarevorrichtung durchgeführt. Diese kann eine universell einsetzbare
Hardware wie ein Computerprozessor (CPU) sein oder für
das Verfahren spezifische Hardware, wie beispielsweise ein ASIC.
-
Die
oben beschriebenen Ausführungsbeispiele stellen lediglich
eine Veranschaulichung der Prinzipien der vorliegenden Erfindung
dar. Es versteht sich, dass Modifikationen und Variationen der hierin
beschriebenen Anordnungen und Einzelheiten anderen Fachleuten einleuchten
werden. Deshalb ist beabsichtigt, dass die Erfindung lediglich durch
den Schutzumfang der nachstehenden Patentansprüche und
nicht durch die spezifischen Einzelheiten, die anhand der Beschreibung
und der Erläuterung der Ausführungsbeispiele hierin
präsentiert wurden, beschränkt sei.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste
der vom Anmelder aufgeführten Dokumente wurde automatisiert
erzeugt und ist ausschließlich zur besseren Information
des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen
Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt
keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Nicht-Patentliteratur
-
- - X509-Standard [0024]
- - RFC2828 [0025]