DE102009037436A1 - Verfahren und System zum Zugreifen von einer Vorrichtung auf zumindest einen Rechner eines Rechnerverbundes - Google Patents

Verfahren und System zum Zugreifen von einer Vorrichtung auf zumindest einen Rechner eines Rechnerverbundes Download PDF

Info

Publication number
DE102009037436A1
DE102009037436A1 DE200910037436 DE102009037436A DE102009037436A1 DE 102009037436 A1 DE102009037436 A1 DE 102009037436A1 DE 200910037436 DE200910037436 DE 200910037436 DE 102009037436 A DE102009037436 A DE 102009037436A DE 102009037436 A1 DE102009037436 A1 DE 102009037436A1
Authority
DE
Germany
Prior art keywords
computer
access device
application program
signature
authentication
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
DE200910037436
Other languages
English (en)
Other versions
DE102009037436B4 (de
Inventor
Jürgen Falkner
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Original Assignee
Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV filed Critical Fraunhofer Gesellschaft zur Forderung der Angewandten Forschung eV
Priority to DE200910037436 priority Critical patent/DE102009037436B4/de
Publication of DE102009037436A1 publication Critical patent/DE102009037436A1/de
Application granted granted Critical
Publication of DE102009037436B4 publication Critical patent/DE102009037436B4/de
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer And Data Communications (AREA)
  • Storage Device Security (AREA)

Abstract

Es wird ein Verfahren zum Zugreifen von einer Vorrichtung auf zumindest einen ersten Rechner eines Rechnerverbundes beschrieben, 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 (100) des Anwendungsprogramms auf der Vorrichtung, wobei das Anwendungsprogramm 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 und 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.

Description

  • 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]

Claims (10)

  1. Verfahren zum Zugreifen von einer Vorrichtung (210) auf zumindest einen ersten Rechner (230) eines Rechnerverbundes, um zumindest Teilaufgaben eines Anwendungsprogramms (212) auf dem ersten Rechner des Rechnerverbundes durchzuführen, wobei das Zugreifen auf den ersten Rechner (230) eine Authentifizierung mittels öffentlich zugänglicher Authentifizierungsinformationen über eine von der Vorrichtung unabhängige Zugangsvorrichtung (260) voraussetzt, mit den folgenden Schritten: Bereitstellen (100) des Anwendungsprogramms (212) auf der Vorrichtung (210), wobei das Anwendungsprogramm fest eingebettete Authentifizierungsinformationen (214) aufweist, die das Anwendungsprogramm (212) gegenüber der Zugangsvorrichtung (220) authentifizieren; Authentifizieren (120) des Anwendungsprogramms (212) gegenüber der Zugangsvorrichtung (220) mittels der fest eingebetteten Authentifizierungsinformationen (214); und Authentifizieren (130) der Zugangsvorrichtung (220) gegenüber dem ersten Rechner (230) mittels der öffentlich zugänglichen Authentifizierungsinformationen der Zugangsvorrichtung, die von einer Zertifizierungsstelle (260) zertifiziert ist, der der erste Rechner (230) vertraut.
  2. Verfahren nach Anspruch 1, wobei bei dem Zugreifen auf den ersten Rechner (230) eine Identifizierungsinformation mitgegeben wird, die dem Anwendungsprogramm (212) zugeordnet ist.
  3. Das Verfahren nach Anspruch 1 oder 2, wobei das Verfahren ferner ein Zugreifen der Vorrichtung (210) auf einen zweiten Rechner (240) des Rechnerverbunds umfasst, um weitere Teilaufgaben des Anwendungsprogramms (212) auf dem zweiten Rechner des Rechnerverbunds durchzuführen, wobei das Zugreifen auf den zweiten Rechner eine Authentifizierung mittels der öffentlich zugänglichen Authentifizierungsinformationen der Zugangsvorrichtung (220) voraussetzt und das Zugreifen auf den zweiten Rechner (240) über den ersten Rechner (230) des Rechnerverbunds erfolgt, und wobei das Zugreifen auf den zweiten Rechner folgende Schritte aufweist: Senden eines von einem privaten Schlüssel der Zugangsvorrichtung (220) abgeleiteten Proxy von der Zugangsvorrichtung an den ersten Rechner (230); und Authentifizieren der Zugangsvorrichtung (220) gegenüber dem zweiten Rechner (240) mittels des Proxy und den öffentlich zugänglichen Authentifizierungsinformationen der Zugangsvorrichtung (220), wobei für die Authentifizierung der Zugangsvorrichtung (220) von dem ersten Rechner (230) eine von dem Proxy abgeleitete Signatur an den zweiten Rechner (240) gesendet wird und der zweite Rechner der Zertifizierungsstelle (260) vertraut; und wobei bei dem Zugreifen auf den zweiten Rechner (240) eine Identifizierungsinformation mitgegeben wird, um das Zugreifen dem Anwendungsprogramm (212) zuzuordnen
  4. Verfahren nach einem der Ansprüche 1 bis 3, wobei der Rechnerverbund ein Rechner-Grid ist, und der erste Rechner und der zweite Rechner verschiedenen Administrationsdomänen zugeordnet sind.
  5. Verfahren nach einem der Ansprüche 1 bis 4, wobei das Authentifizieren des Anwendungsprogramms (212) gegenüber der Zugangsvorrichtung (220) mittels eines asymmetrischen Signaturverfahrens erfolgt, und die fest eingebettete Authentifizierungsinformation (214) einen ersten privaten Schlüssel aufweist, der dem Anwendungsprogramm (212) zugeordnet ist, und der von dem Anwendungsprogramm für die Erzeugung einer ersten Signatur des Anwendungsprogramms verwendet wird.
  6. Verfahren nach Anspruch 5, wobei die fest eingebettete Authentifizierungsinformation (214) ferner ein erstes Zertifikat aufweist, das der Zugangsvorrichtung (220) zugeordnet ist, und das von dem Anwendungsprogramm (212) für die Authentifizierung der Zugangsvorrichtung verwendet wird, und das Verfahren ferner eine Authentifizierung der Zugangsvorrichtung (220) gegenüber dem Anwendungsprogramm mittels eines asymmetrischen Signaturverfahrens und basierend auf dem ersten Zertifikat aufweist.
  7. Verfahren nach Anspruch 6, wobei das Authentifizieren des Anwendungsprogramms gegenüber der Zugangsvorrichtung und der Zugangsvorrichtung gegenüber dem Anwendungsprogramm folgende Schritte aufweist: 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; und Authentifizieren (312) der Zugangsvorrichtung durch die Vorrichtung mittels eines zweiten Überprüfungsalgorithmus, basierend auf der zweiten Signatur und eines der Zugangsvorrichtung zugeordneten zweiten Zertifikats.
  8. Verfahren nach Anspruch 7, wobei zwischen dem Anwendungsprogramm und der Zugangsvorrichtung nach der gegenseitigen positiven Authentifizierung ein Verschlüsselungsalgorithmus und dessen Parameter für eine sichere Datenübertragung vereinbart werden.
  9. Verfahren nach einem der Ansprüche 1 bis 8, wobei das Authentifizieren der Zugangsvorrichtung gegenüber dem zumindest ersten Rechner mittels eines asymmetrischen Signaturverfahrens erfolgt und ein Zertifikat der Zertifizierungsstelle (260) die öffentlich zugängliche Authentifizierungsinformation der Zugangsvorrichtung bildet.
  10. System zum Zugreifen von einer Vorrichtung (210) auf zumindest einen ersten Rechner (230) eines Rechnerverbundes, um zumindest Teilaufgaben eines Anwendungsprogramms (212) auf dem ersten Rechner (230) des Rechnerverbundes durchzuführen, wobei das Zugreifen auf den ersten Rechner eine Authentifizierung mittels öffentlich zugänglicher Authentifizierungsinformationen über eine von der Vorrichtung (210) unabhängige Zugangsvorrichtung (220) voraussetzt; wobei das Anwendungsprogramm (212) fest eingebettete Authentifizierungsinformationen (214) aufweist, die das Anwendungsprogramm gegenüber der Zugangsvorrichtung (220) authentifizieren, und das Anwendungsprogramm auf der Vorrichtung bereitgestellt wird; wobei das Anwendungsprogramm (214) und die Zugangsvorrichtung (220) ausgebildet sind, um das Anwendungsprogramm gegenüber der Zugangsvorrichtung mittels der fest eingebetteten Authentifizierungsinformationen (214) zu authentifizieren; und wobei die Zugangsvorrichtung (220) und der erste Rechner (230) ausgebildet sind, um die Zugangsvorrichtung gegenüber dem ersten Rechner mittels öffentlich zugänglicher Authentifizierungsinformationen der Zugangsvorrichtung zu authentifizieren, die von einer Zertifizierungsstelle (260) zertifiziert sind, der der erste Rechner (230) vertraut;
DE200910037436 2009-08-13 2009-08-13 Verfahren und System zum Zugreifen von einer Vorrichtung auf zumindest einen Rechner eines Rechnerverbundes Active DE102009037436B4 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
DE200910037436 DE102009037436B4 (de) 2009-08-13 2009-08-13 Verfahren und System zum Zugreifen von einer Vorrichtung auf zumindest einen Rechner eines Rechnerverbundes

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
DE200910037436 DE102009037436B4 (de) 2009-08-13 2009-08-13 Verfahren und System zum Zugreifen von einer Vorrichtung auf zumindest einen Rechner eines Rechnerverbundes

Publications (2)

Publication Number Publication Date
DE102009037436A1 true DE102009037436A1 (de) 2011-02-24
DE102009037436B4 DE102009037436B4 (de) 2012-10-25

Family

ID=43495319

Family Applications (1)

Application Number Title Priority Date Filing Date
DE200910037436 Active DE102009037436B4 (de) 2009-08-13 2009-08-13 Verfahren und System zum Zugreifen von einer Vorrichtung auf zumindest einen Rechner eines Rechnerverbundes

Country Status (1)

Country Link
DE (1) DE102009037436B4 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014000168A1 (de) 2014-01-02 2015-07-02 Benedikt Burchard Verfahren zur Abrechnung einer Internetdienstleistung

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
FALKNER, J.: Services(a)MediGRID-Entwickler Workshop. IAT, Uni Stuttgart/Fraunhofer IAO UMG, Göttingen, 15. Juni 2009, S. 1-14, 15, 15a, 16-29 *
RFC2828
X509-Standard

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102014000168A1 (de) 2014-01-02 2015-07-02 Benedikt Burchard Verfahren zur Abrechnung einer Internetdienstleistung

Also Published As

Publication number Publication date
DE102009037436B4 (de) 2012-10-25

Similar Documents

Publication Publication Date Title
EP3125492B1 (de) Verfahren und system zum erzeugen eines sicheren kommunikationskanals für endgeräte
DE112011101729B4 (de) Verwaltung von Ressourcenzugriff
EP3108610B1 (de) Verfarhen und system zum erstellen und zur gültigkeitsprüfung von gerätezertifikaten
DE602004012996T2 (de) Verfahren und vorrichtung zum authentifizieren von benutzern und websites
DE60214632T2 (de) Multidomäne Berechtigung und Authentifizierung
DE60031755T2 (de) Verfahren und Vorrichtung für authentifizierten Zugang zu einer Mehrzahl von Netzbetreibern durch eine einzige Anmeldung
DE112012002741T5 (de) Identitäts- und Berechtigungsprüfungsverfahren für die Sicherheit einer Cloud-Datenverarbeitungsplattform
EP3764614B1 (de) Verteiltes authentifizierungssystem
DE102011089580B3 (de) Verfahren zum Lesen von Attributen aus einem ID-Token
DE102014119363A1 (de) Autorisierungsverwaltungsserver und autorisierungsverwaltungsverfahren
DE112018005203T5 (de) Authentifizierung unter Verwendung von delegierten Identitäten
WO2007045395A1 (de) Vorrichtungen und verfahren zum durchführen von kryptographischen operationen in einem server-client-rechnernetzwerksystem
DE102008024783A1 (de) Sichere, browser-basierte Einmalanmeldung mit Clientzertifikaten
DE602005003631T2 (de) Ausschluss der Passwortaufdeckung bei Attributzertifikatausgabe
DE112020002343T5 (de) Verteilung von Sicherheitsberechtigungsnachweisen
DE102019100335A1 (de) Verfahren zum sicheren Bereitstellen einer personalisierten elektronischen Identität auf einem Endgerät
DE60319985T2 (de) Verfahren zur selbst-registrierung und automatischen ausgabe von digitalen zertifikaten und entsprechendes netz
EP2620892B1 (de) Verfahren zur Erzeugung eines Pseudonyms mit Hilfe eines ID-Tokens
EP3540623B1 (de) Verfahren zur erzeugung eines pseudonyms mit hilfe eines id-tokens
DE102009037436B4 (de) Verfahren und System zum Zugreifen von einer Vorrichtung auf zumindest einen Rechner eines Rechnerverbundes
EP3283999B1 (de) Elektronisches system zur erzeugung eines zertifikats
EP4115584B1 (de) Gesicherter und dokumentierter schlüsselzugriff durch eine anwendung
EP4092958B1 (de) Ausstellen eines digitalen verifizierbaren credentials
WO2017190857A1 (de) Verfahren und vorrichtung zur absicherung von gerätezugriffen
DE102006043497A1 (de) Computersystem und Verfahren zur Signierung, Signaturverifizierung und/oder Archivierung

Legal Events

Date Code Title Description
OP8 Request for examination as to paragraph 44 patent law
R018 Grant decision by examination section/examining division
R020 Patent grant now final

Effective date: 20130126