DE102010044517A1

DE102010044517A1 - Verfahren zur Zertifikats-basierten Authentisierung

Info

Publication number: DE102010044517A1
Application number: DE102010044517A
Authority: DE
Inventors: Dr. Falk Rainer; Steffen Fries
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2010-09-07
Filing date: 2010-09-07
Publication date: 2012-03-08
Also published as: WO2012031821A1; EP2594047A1; US20130173914A1; CN103109508A; CN103109508B; US9432198B2

Abstract

Die Erfindung betrifft ein Verfahren zur Zertifikats-basierten Authentisierung, bei der sich ein erster Teilnehmer (R1) gegenüber einem zweiten Teilnehmer (R2) mit Hilfe eines, dem ersten Teilnehmer (R1) zugeordneten digitalen Zertifikats (C) authentisiert. Das Zertifikat (C, C') spezifiziert dabei eine oder mehrere Anforderungen (CL, CL'), wobei die Erfüllung einer Anforderung (CL, CL') durch einen dritten Teilnehmer (R3) zugesichert wird, indem der dritte Teilnehmer (R3) die Anforderung (CL, CL') herausgibt. Im Rahmen der Authentisierung wird durch den zweiten Teilnehmer (R2) eine Gültigkeitsbedingung überprüft und das Zertifikat von dem zweiten Teilnehmer (R2) als gültig eingestuft, falls die Gültigkeitsbedingung erfüllt ist, wobei die Gültigkeitsbedingung von der Herausgabe und/oder der fehlenden Herausgabe von einer oder mehreren der im Zertifikat spezifizierten Anforderungen (CL, CL') durch den dritten Teilnehmer (R3) abhängt. Das erfindungsgemäße Verfahren zeichnet sich dadurch aus, dass zur Gültigkeitsbeschränkung des Zertifikats Anforderungen eingesetzt werden, wobei die Anforderungen z. B. auf den an sich bekannten SAML-Assertions beruhen können. Hierdurch kann einfach und flexibel die Gültigkeit eines Zertifikats gesteuert werden, ohne dass die Gültigkeit im Zertifikat explizit festgelegt ist. Das Verfahren kann zur Authentisierung in beliebigen technischen Gebieten eingesetzt werden, z. B. kann es zur Authentisierung von Teilnehmern in der Form von Komponenten einer Automatisierungsanlage verwendet werden.

Description

Die Erfindung betrifft ein Verfahren zur Zertifikats-basierten Authentisierung, bei der sich ein erster Teilnehmer gegenüber einem zweiten Teilnehmer mit Hilfe eines, dem ersten Teilnehmer zugeordneten digitalen Zertifikats authentisiert.
Digitale Zertifikate sind an sich aus dem Stand der Technik bekannt. Sie enthalten die Identität einer Entität in der Form einer Person bzw. Institution bzw. Maschine, für die das Zertifikat ausgestellt ist. Hier und im Folgenden wird der Betriff des Teilnehmers verwendet, dem ein Zertifikat zugeordnet sein kann. Ein Teilnehmer kann dabei ein Computer bzw. eine Maschine sein, für die das Zertifikat ausgestellt ist. Ebenso kann sich ein Teilnehmer auf einen Computer bzw. eine Maschine beziehen, welche das Zertifikat einer Person bzw. Institution verwaltet. Durch die Zuständigkeit für die Zertifikatsverwaltung wird dem Computer bzw. der Maschine das Zertifikat zugeordnet.
Ein Zertifikat enthält einen öffentlichen Schlüssel für die entsprechende Entität, und über eine digitale Signatur im Zertifikat kann der Eigentümer des Zertifikats bestätigt werden. Die digitale Signatur wird dabei von einer Zertifikatsausgabestelle berechnet. Über ein Root-Zertifikat dieser Ausgabestelle bzw. eine Zertifikatskette hin zu dem Root-Zertifikat kann die Signatur als gültig verifiziert werden. In einem digitalen Zertifikat können Zusatzinformationen in der Form sog. Attribute eincodiert werden, durch welche Berechtigungen für den Nutzer des Zertifikats oder Nutzungseinschränkungen des Zertifikats festgelegt werden.
Zertifikate weisen in der Regel eine begrenzte Gültigkeitsdauer auf, welche als Information in dem Zertifikat spezifiziert ist. Nach Ende der Gültigkeitsdauer wird das Zertifikat automatisch ungültig. Es muss somit im Rahmen der Verwaltung von Zertifikaten sichergestellt werden, dass ein Zertifikat, welches über seine Gültigkeitsdauer hinaus verfügbar sein soll, rechtzeitig durch ein entsprechendes Zertifikat mit neuer Gültigkeitsdauer ersetzt wird. Dies ist in der Praxis mit einem hohen administrativen Aufwand verbunden. Insbesondere bei der Ausstellung von Zertifikaten für Automatisierungsgeräte, die über einen langen Zeitraum genutzt werden und keiner stringenten Rechner-Administration unterliegen, ist dies nur schwer umsetzbar. Es besteht zwar die Möglichkeit, Zertifikate mit sehr langer bzw. unbegrenzter Gültigkeitsdauer auszustellen, jedoch wird hierdurch die Missbrauchsgefahr erhöht.
Aus dem Stand der Technik ist es ferner bekannt, Zertifikate zu widerrufen. Der Rückruf von Zertifikaten ist jedoch aufwändig, da dazu Zertifikatswiderrufslisten ausgestellt und verteilt werden müssen. Ferner ist ein einmalig widerrufenes Zertifikat dauerhaft ungültig und kann nicht wieder reaktiviert werden.
Zur Authentisierung eines Teilnehmers gegenüber einem anderen Teilnehmer bzw. einem Dienst (z. B. Webservice) ist die Verwendung sog. SAML-Assertions (SAML = Security Assertion Markup Language) bekannt. Diese Assertions stellen Aussagen dar, welche durch einen Herausgeber der Assertions zugesichert werden. Die Authentisierung des Teilnehmers gegenüber einem anderen Teilnehmer bzw. einem Dienst kann somit an die Herausgabe entsprechender SAML-Assertions gekoppelt sein. Nur wenn vorbestimmte Assertions für einen Teilnehmer zugesichert sind, erfolgt dessen Authentisierung.
Aus dem Stand der Technik ist ferner das sog. ”Claims-based Authorization Model” bekannt, das von der Firma Microsoft^® entwickelt wurde. Ein Nutzer wird dabei nicht durch eine feste Identität repräsentiert, sondern über eine Menge sog. Claims, die Eigenschaften des Nutzers bestätigen. Ein möglicher Claim ist z. B. eine Authentisierung mittels Zertifikat, mittels Passwort und dergleichen. Abhängig von den vorhandenen Claims wird ein Zugriff gewährt oder abgewiesen.
Aufgabe der Erfindung ist es, eine Zertifikats-basierte Authentisierung zu schaffen, bei der einfach und flexibel die Gültigkeit des hierfür genutzten Zertifikats gesteuert werden kann.
Diese Aufgabe wird durch das Verfahren gemäß Patentanspruch 1 bzw. das Kommunikationsnetz gemäß Patentanspruch 14 gelöst. Weiterbildungen der Erfindung sind in den abhängigen Patentansprüchen definiert.
Im Rahmen des erfindungsgemäßen Verfahrens wird eine Authentisierung durchgeführt, bei der sich ein erster Teilnehmer gegenüber einem zweiten Teilnehmer mit Hilfe eines, dem ersten Teilnehmer zugeordneten digitalen Zertifikats authentisiert. Das Zertifikat spezifiziert dabei eine oder mehrere Anforderungen, wobei die Erfüllung einer Anforderung durch einen dritten Teilnehmer zugesichert wird, indem der dritte Teilnehmer die Anforderung herausgibt. Der Begriff der Spezifikation von Anforderungen im Zertifikat ist dabei weit zu verstehen. Die spezifizierten Anforderungen können direkt im Zertifikat hinterlegt sein bzw. über einen Identifikator oder Namen spezifiziert werden. Ebenso kann die Spezifikation von einer oder mehrerer Anforderungen über eine Referenz erfolgen, die auf die Anforderungen verweist, wie z. B. eine URI oder eine URL. Auch der Begriff der Herausgabe einer Anforderung ist im Sinne der Erfindung weit zu verstehen. Eine Anforderung kann beispielsweise dann als herausgegeben angesehen werden, wenn sie auf dem entsprechenden dritten Teilnehmer hinterlegt ist bzw. von diesem Teilnehmer abgerufen werden kann.
Im Rahmen der erfindungsgemäßen Authentisierung wird durch den zweiten Teilnehmer eine Gültigkeitsbedingung überprüft und das Zertifikat des ersten Teilnehmers von dem zweiten Teilnehmer dann als gültig eingestuft, falls die Gültigkeitsbedingung erfüllt ist. Erfindungswesentlich ist dabei, dass die Gültigkeitsbedingung von der Herausgabe und/oder der fehlenden Herausgabe von einer oder mehreren der im Zertifikat spezifizierten Anforderungen durch den dritten Teilnehmer abhängt. Ist die entsprechend festgelegte Gültigkeitsbedingung dabei nicht erfüllt, wird das Zertifikat als ungültig erachtet und eine entsprechende Authentisierung abgebrochen. Dabei kann insbesondere als Gültigkeitsbedingung durch den zweiten Teilnehmer geprüft werden, ob zum Zeitpunkt der Überprüfung des Zertifikats des ersten Teilnehmers die spezifizierten Anforderungen aufgrund einer Herausgabe der Anforderungen durch den dritten Teilnehmer erfüllt sind.
Das erfindungsgemäße Verfahren zeichnet sich dadurch aus, dass die Gültigkeit eines Zertifikats nicht mehr direkt im Zertifikat selbst festgelegt wird, sondern mittelbar über die Verwendung entsprechender Anforderungen, die einfach und flexibel durch einen dritten Teilnehmer verwaltet werden, der die entsprechenden Anforderungen herausgibt. In einer besonders bevorzugten Ausführungsform kann auf eine an sich bekannte Syntax zur Definition entsprechender Anforderungen zurückgegriffen werden, insbesondere können die Anforderungen die eingangs erwähnten SAML-Assertions bzw. entsprechende Claims aus dem ”Claims-based Authorization Model” darstellen.
In einer bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens fragt der erste Teilnehmer beim dritten Teilnehmer die Information ab, ob eine oder mehrere der im Zertifikat spezifizierten Anforderungen vom dritten Teilnehmer herausgegeben wurden. Der erste Teilnehmer stellt dabei die abgefragte Information dem zweiten Teilnehmer bereit, beispielsweise indem er die herausgegebenen Anforderungen an den zweiten Teilnehmer übermittelt. Daraufhin überprüft der zweite Teilnehmer basierend auf dieser Information die Gültigkeitsbedingung. Alternativ oder zusätzlich ist es auch möglich, dass der zweite Teilnehmer direkt beim dritten Teilnehmer die Information abfragt, ob eine oder mehrere der im Zertifikat spezifizierten Anforderungen vom dritten Teilnehmer herausgegeben wurden, um anschließend basierend auf der abgefragten Information die Gültigkeitsbedingung zu überprüfen.
Um einen Missbrauch durch ein unbefugtes Abfragen von Anforderungen beim dritten Teilnehmer zu vermeiden, muss sich in einer besonders bevorzugten Ausführungsform der erste und/oder zweite Teilnehmer beim dritten Teilnehmer zur Abfrage des oder der Anforderungen authentisieren. Nur bei erfolgreicher Authentisierung erhält der entsprechende Teilnehmer dann die Informationen über die Anforderungen.
Je nach Anwendungsfall können beliebige Arten von Anforderungen in dem Zertifikat spezifiziert werden. Insbesondere kann eine Anforderung in Bezug auf die zeitliche Gültigkeit des Zertifikats spezifiziert werden, d. h. die zeitliche Gültigkeit des Zertifikats wird an die Herausgabe einer entsprechenden Anforderung gekoppelt, ohne weitere Kriterien zu berücksichtigen. Ferner kann sich eine Anforderung auf die Kommunikationsumgebung beziehen, in welcher der erste Teilnehmer betrieben wird. Diese Kommunikationsumgebung kann z. B. durch spezielle Eigenschaften bzw. eine entsprechende Adresse des Kommunikationsnetzes festgelegt werden. Ebenfalls kann sich eine Anforderung auf eine oder mehrere Eigenschaften des ersten und/oder zweiten und/oder dritten Teilnehmers beziehen. Zum Beispiel kann festgelegt werden, dass nur bestimmte erste bzw. zweite bzw. dritte Teilnehmer im Rahmen der Zertifikats-basierten Authentisierung verwendet werden dürfen. Insbesondere kann dabei auch festgelegt werden, von welchem Teilnehmer die herausgegebenen Zertifikate stammen müssen. Darüber hinaus kann eine Anforderung die Vertrauenswürdigkeit der Authentisierung des ersten Teilnehmers beim zweiten Teilnehmer spezifizieren. Nur wenn die in der Anforderung festgelegte Vertrauenswürdigkeit, z. B. in der Form eines Vertrauenswerts, gegeben ist, wird das Zertifikat als gültig erachtet. Hierdurch kann berücksichtigt werden, dass sich die Vertrauenswürdigkeit einer Authentisierung mit der Zeit ändern kann, da z. B. ein Angriff auf einen bestimmten Teilnehmer bekannt geworden ist.
In einer weiteren Ausführungsform des erfindungsgemäßen Verfahrens ist die Gültigkeitsbedingung eine logische Verknüpfungskette umfassend eine oder mehrere AND- und/oder NAND- und/oder OR- und/oder XOR- und/oder NOR-Verknüpfungen, wobei die Verknüpfungskette vorzugsweise in dem Zertifikat codiert ist. Auf diese Weise können sehr gut z. B. Sperr-Anforderungen verarbeitet werden, wobei bei Vorliegen einer Sperr-Anforderung das Zertifikat als ungültig betrachtet wird. Durch eine NAND-Verknüpfung kann somit die Gültigkeit des Zertifikats an die Abwesenheit einer Sperr-Anforderung gekoppelt werden.
In einer weiteren, besonders bevorzugten Ausführungsform des erfindungsgemäßen Verfahrens findet im Rahmen der Authentisierung des ersten Teilnehmers gegenüber dem zweiten Teilnehmer neben der obigen Überprüfung der Gültigkeitsbedingung des Zertifikats auch eine Verifikation des Zertifikats statt. Diese Verifikation kann in an sich bekannter Weise durch Überprüfung der Signatur des Zertifikats erfolgen.
In einer weiteren Ausführungsform des erfindungsgemäßen Verfahrens wird mit einem im Zertifikat enthaltenen öffentlichen Schlüssel des ersten Teilnehmers sowie dem diesem öffentlichen Schlüssel zugeordneten privaten Schlüssel eine kryptographisch gesicherte Verbindung zwischen dem ersten und zweiten Teilnehmer aufgebaut. Gegebenenfalls kann im Rahmen dieser kryptographisch gesicherten Verbindung auch eine Übermittlung der entsprechenden Anforderungen zur Überprüfung der Gültigkeitsbedingung erfolgen. Sollte sich dabei ergeben, dass die Gültigkeitsbedingung nicht erfüllt ist, wird die verschlüsselte Verbindung und somit die Authentisierung abgebrochen. In einer Variante erfolgt bei aufgebauter verschlüsselter Verbindung wiederholt, z. B. periodisch alle 5 Minuten oder stündlich, eine erneute Überprüfung der Gültigkeitsbedingung. Falls dies nicht der Fall ist, wird in einer Variante der Erfindung die Verbindung beendet.
Die mit dem erfindungsgemäßen Verfahren durchgeführte Authentisierung kann auf an sich bekannten Protokollen basieren, z. B. dem SSL/TLS-Protokoll und/oder dem IKE/IPsec-Protokoll und/oder dem IKEv2/IPsec-Protokoll, wobei zusätzlich die erfindungsgemäße Überprüfung der Gültigkeitsbedingung anhand entsprechender Anforderungen erfolgt. Ebenso kann das im Rahmen der Erfindung verwendete Zertifikat auf einem an sich bekannten Zertifikat basieren. Insbesondere kann das Zertifikat ein erweitertes X.509-Zertifikat darstellen, welches zusätzlich zu den an sich bekannten Einträgen eine oder mehrere Anforderungen spezifiziert.
Das erfindungsgemäße Verfahren kann gegebenenfalls auch zur gegenseitigen Authentisierung zwischen dem ersten und zweiten Teilnehmer genutzt werden. Das heißt, mit dem Verfahren authentisiert sich der erste Teilnehmer beim zweiten Teilnehmer und unter Vertauschung der Rollen von erstem und zweitem Teilnehmer analog der zweite Teilnehmer beim ersten Teilnehmer.
Das erfindungsgemäße Verfahren kann für beliebige erste bzw. zweite bzw. dritte Teilnehmer in der Form von Rechnern bzw. Maschinen eingesetzt werden. Vorzugsweise stellen die Teilnehmer dabei Komponenten einer Automatisierungsanlage dar, wie z. B. entsprechende Steuerungsgeräte, Sensoren, Aktoren und dergleichen.
Neben dem oben beschriebenen Verfahren betrifft die Erfindung ferner ein Kommunikationsnetz mit einem ersten, zweiten und dritten Teilnehmer, wobei im Betrieb des Kommunikationsnetzes eine Zertifikats-basierte Authentisierung gemäß dem oben beschriebenen Verfahren bzw. einer oder mehrerer Varianten des oben beschriebenen Verfahrens durchführbar ist.
Ausführungsbeispiele der Erfindung werden nachfolgend anhand der beigefügten Figuren detailliert beschrieben.
Es zeigen:
1 eine schematische Darstellung eines Kommunikationsnetzes, in dem eine Ausführungsform der Zertifikats-basierten Authentisierung durchgeführt wird; und
2 eine schematische Darstellung eines Nachrichtenaustauschs zwischen zwei Teilnehmern in einem Kommunikationsnetz, welche sich gegenseitig basierend auf einer Ausführungsform des erfindungsgemäßen Verfahrens authentisieren.
1 zeigt in schematischer Darstellung ein Kommunikationsnetz N mit einer Mehrzahl von Rechnern, wobei die an der nachfolgend beschriebenen Zertifikats-basierten Authentisierung beteiligten Rechner mit R1, R2, und R3 bezeichnet sind. Der Rechner R1 entspricht dabei einem ersten Teilnehmer im Sinne von Anspruch 1, der Rechner R2 einem zweiten Teilnehmer und der Rechner R3 einem dritten Teilnehmer. Bei den Teilnehmern muss es sich nicht zwangsläufig um Rechner handeln, sondern die Teilnehmer können auch beliebige andere kommunizierende Einheiten, wie z. B. Automatisierungseinheiten bzw. Maschinen darstellen. Insbesondere kann es sich bei den Automatisierungseinheiten um entsprechende Komponenten einer Automatisierungsanlage handeln, welche einen automatischen Fertigungs- bzw. Produktionsprozess durchführt. Die einzelnen Automatisierungseinheiten können z. B. eine programmierbare Steuerung, ein Sensor, ein Elektroauto, eine Stromladesäule für ein Elektroauto, einen Stromzähler, ein Energieautomatisierungsgerät, einen Computer-Tomographen, ein Röntgengerät und dergleichen darstellen. Alle Automatisierungseinheiten zeichnen sich dadurch aus, dass sie über eine entsprechende Kommunikationsschnittstelle zur Kommunikation mit anderen Einheiten ausgestattet sind. Bei der Kommunikationsschnittstelle kann es sich z. B. um eine Ethernet-Schnittstelle, eine IP-Schnittstelle, eine WLAN-Schnittstelle, eine Bluetooth-Schnittstelle oder eine Zig-Bee-Schnittstelle handeln.
In dem Szenario der 1 erfolgt eine Authentisierung des Rechners R1 gegenüber dem Rechner R2 unter Verwendung eines erweiterten X.509-Zertifikats. Dieses Zertifikat enthält in an sich bekannter Weise neben anderen Informationen einen öffentlichen Schlüssel des Teilnehmers R1, der im Rahmen der Authentisierung zum verschlüsselten Austausch eines Geheimnisses und zur Generierung eines Sitzungsschlüssels für eine kryptographisch gesicherte Kommunikation zwischen Rechner R1 und R2 verwendet werden kann. Das Zertifikat ist dabei durch eine vertrauenswürdige Zertifizierungsstelle signiert. Zur Verifikation des Zertifikats wird dieses zum Rechner R2 übermittelt, der anschließend die Signatur in an sich bekannter Weise basierend auf einem Root-Zertifikat der das Zertifikat herausgebenden Zertifizierungsstelle bzw. einer Zertifikatskette hin zum Root-Zertifikat verifiziert.
In der nachfolgenden Tabelle 1 sind die wesentlichen Informationen eines herkömmlichen X.509-Zertifikats wiedergegeben. Dieses Zertifikat wird z. B. bei der bekannten SSL/TLS-Authentisierung oder einer IKE/IPsec-Authentisierung verwendet.
Tabelle 1:
In obiger Tabelle bezeichnet der Ausdruck ”certificateID” eine Identität des Zertifikats, welche durch die Seriennummer ”SerialNumber” spezifiziert wird. Durch den englischen Ausdruck ”issuedTo” wird angegeben, für welchen Teilnehmer das Zertifikat ausgestellt ist, wobei der Ausdruck ”issuedTo” von dem Namen des Teilnehmers gefolgt ist. Durch den Ausdruck ”issuer” wird der Herausgeber des Zertifikats bezeichnet, der durch einen geeigneten Namen des Herausgebers spezifiziert wird. Durch die Ausdrücke ”validFrom” und ”validTo” wird der Gültigkeitszeitraum des Zertifikats spezifiziert, wobei der Ausdruck ”validFrom” einen Zeitpunkt ”Time” spezifiziert, an der die Gültigkeit des Zertifikats anfängt bzw. angefangen hat, und der Ausdruck ”validTo” wiederum einen Zeitpunkt ”Time” spezifiziert, der das Ablaufdatum des Zertifikats festlegt. Anschließend ist in dem Zertifikat der öffentliche Schlüssel ”Public Key” des Teilnehmers enthalten. Zusätzlich können in dem Zertifikat mehrere Attribute vorhanden sein, welche im Abschnitt ”Attributes” des Zertifikats definiert sind. Beispielhaft ist dabei ein Attribut AttributeA und ein Attribut AttributeB angegeben. Solche Attribute können beispielsweise Berechtigungen spezifizieren, durch welche festgelegt wird, welche Aktionen der Teilnehmer, dem das Zertifikat gehört, durchführen kann. Ebenso können Attribute Nutzungseinschränkungen des Zertifikats spezifizieren, z. B. kann festgelegt werden, dass das Zertifikat nur zur digitalen Signatur und zur Authentisierung geeignet ist, jedoch nicht zur Verschlüsselung verwendbar ist. Das Zertifikat enthält ferner die bereits oben beschriebene Signatur, welche mit ”Signature” bezeichnet ist und die Verifikation des Zertifikats basierend auf einem Root-Zertifikat bzw. einer Zertifikatkette hin zum Root-Zertifikat ermöglicht.
Im Rahmen der weiter unten noch näher beschriebenen Authentisierung des Rechners R1 gegenüber dem Rechner R2 wird in der hier beschriebenen Ausführungsform ein erweitertes X.509-Zertifikat eingesetzt, dessen Aufbau in nachfolgender Tabelle 2 wiedergegeben ist.
Tabelle 2:
Der Aufbau des Zertifikats der Tabelle 2 entspricht weitestgehend dem Zertifikat der Tabelle 1, so dass die gleichen Bestandteile nicht nochmals erläutert werden. Im Unterschied zum Zertifikat der Tabelle 1 enthält das erweiterte X.509-Zertifikat nunmehr ein weiteres Attribut, welches als ”requiredClaims” bezeichnet ist. Hierüber wird ein sog. Claim-Classifier spezifiziert, der einen oder mehrere sog. Claims angibt, welche erfüllt sein müssen, damit das Zertifikat als gültig betrachtet wird. Die Claims stellen dabei Ausführungsformen von Anforderungen im Sinne von Anspruch 1 dar. In der hier beschriebenen Ausführungsform beruht die Syntax der Claims auf dem sog. ”Claims-based Authorization Model”, das von der Firma Microsoft als Teil des Geneva Frameworks 2008 ermittelt wurde (siehe auch http://msdn.microsoft.com/en-us/magazine/dd278426.aspx). Der Claim-Classifier kann direkt im Zertifikat eincodiert sein, jedoch kann gegebenenfalls auch eine Referenz auf einen Claim-Classifier (z. B. eine URL oder URI) im Zertifikat enthalten sein, über die auf den Claim-Classifier zugegriffen werden kann.
Ein Beispiel für eine Syntax, gemäß der ein Claim-Classifier durch das oben genannte Claims-based Authorization Modell spezifiziert werden kann, lautet wie folgt:
Die dargestellte Syntax ist an sich aus dem Stand der Technik bekannt und wird deshalb nicht im Detail erläutert. Durch den Ausdruck ”claimType” wird auf die entsprechenden Claims bzw. deren Namen verwiesen. Der Ausdruck ”isOptional” spezifiziert, ob das Vorhandensein des entsprechenden Claims optional ist oder nicht. Im obigen Claim-Classifier ist die Variable ”isOptional” auf ”false” gesetzt, d. h. die Claims müssen erfüllt sein, damit das Zertifikat als gültig betrachtet wird.
Anstatt der oben beschriebenen Claims zur Spezifikation von Anforderungen zu verwenden, besteht in einer weiteren Ausführungsform des erfindungsgemäßen Verfahrens auch die Möglichkeit, SAML-Assertions in das Zertifikat einzucodieren. Durch diese SAML-Assertions, welche auf der bekannten XML-basierten SAML-Sprache beruhen, wird eine Aussage spezifiziert. Ein Beispiel einer Syntax, wie SAML-Assertions anstatt eines Claim-Classifiers in einem erfindungsgemäßen Zertifikat codiert werden können, lautet wie folgt:
Diese Syntax ist an sich bekannt und wird deshalb nicht im Detail erläutert. Die Syntax enthält die Variable ”value”, welche eine SAML-Assertion spezifiziert, die erfüllt sein muss, damit das Zertifikat als gültig betrachtet wird.
Um in dem Kommunikationsnetz der 1 sicherzustellen, dass ein entsprechender Claim bzw. eine entsprechende SAML-Assertion tatsächlich erfüllt sind, wird der Rechner R3 verwendet, der einen Herausgeber für entsprechende Claims bzw. Assertions darstellt. Nur wenn dieser Rechner eine oder mehrere der in dem entsprechenden Zertifikat spezifizierten Assertions bzw. Claims herausgegeben hat, ist das Zertifikat als gültig anzusehen. In 1 ist dabei das entsprechende Zertifikat des Rechners R1 mit dem Bezugszeichen C und die darin enthaltenen Claims mit Bezugszeichen CL angedeutet. In einer Variante kann in dem Zertifikat zusätzlich angegeben werden, durch welchen herausgebenden Rechner die entsprechenden Claims bzw. SAML-Assertions ausgestellt werden müssen, damit das Zertifikat Gültigkeit hat. Diese Information kann gegebenenfalls wiederum in der Form eines entsprechenden Claims bzw. einer entsprechenden SAML-Assertion im Zertifikat codiert sein.
Nachfolgend wird anhand von 1 eine Realisierung einer Authentisierung basierend auf dem oben beschriebenen erweiterten X.509-Zertifikat erläutert, wobei entsprechende Anforderungen in der Form von Claims CL in dem Zertifikat C spezifiziert sind. In einem Schritt S1 fordert der Rechner R1, der sich gegenüber dem Rechner R2 authentisieren möchte, zunächst die entsprechenden Claims basierend auf dem Claim-Classifier in seinem Zertifikat bei dem Rechner R3 an. Wenn der Rechner R3 einen entsprechenden Claim herausgibt, so sichert er damit auch zu, dass die entsprechende Anforderung gemäß dem Claim erfüllt ist. Basierend auf den in Schritt S1 angeforderten Claims bestimmt der Rechner R3, welche der Claims er tatsächlich herausgegeben hat. Diese Information überträgt der Rechner R3 dann in Schritt S2 an den Rechner R1. In der hier beschriebenen Ausführungsform werden die Claims selbst an den Rechner R1 übermittelt.
Nachfolgend erfolgt schließlich die eigentliche Zertifikats-basierte Authentisierung, die durch Schritt S3 angedeutet ist. Dabei wird das Zertifikat C des Rechners R1 sowie alle oder eine Teilmenge der in Schritt S2 übertragenen Claims an den Rechner R2 übermittelt. Der Rechner R2 verifiziert dann das Zertifikat in an sich bekannter Weise und überprüft ferner, ob er das Zertifikat als gültig einstuft. Dies ist insbesondere dann der Fall, wenn die im Zertifikat spezifizierten Claims mit den weiteren übermittelten Claims übereinstimmen. Wird das Zertifikat C nicht als gültig eingestuft, wird die Authentisierung abgebrochen. Die Authentisierung kann dabei basierend auf an sich bekannten Protokollen, wie z. B. SSL/TLS bzw. IKE/IPsec bzw. IKEv2/IPsec beruhen, wobei im Rahmen dieser Protokolle nunmehr zusätzlich das Vorhandensein der Claims überprüft wird. Ist die oben beschriebene Authentisierung gemäß dem Schritt S3 abgeschlossen, kann anschließend über einen entsprechenden öffentlichen Schlüssel in dem Zertifikat ein Sitzungsschlüssel ausgehandelt werden und eine kryptographisch gesicherte Kommunikation zwischen den Rechnern R1 und R2 stattfinden. Dies ist in 1 durch den Schritt S4 angedeutet.
In einer Abwandlung der Ausführungsform der 1 besteht auch die Möglichkeit, dass die Überprüfung der in dem Zertifikat C spezifizierten Claims CL durch den Rechner R2 direkt vorgenommen wird, d. h. der Rechner R2 fordert die Claims selbst bei dem herausgebenden Rechner R3 an. In diesem Fall müssen die Claims nicht mehr von dem Rechner R1 zum Rechner R2 übertragen werden. In einer weiteren Ausgestaltung besteht ferner die Möglichkeit, dass im Rahmen der Authentisierung auch ein Zertifikat des Rechners R2 mit entsprechend darin enthaltenen Claims zum Rechner R1 übertragen und dort überprüft wird. Das heißt, es kann auch eine beidseitige Authentisierung sowohl von dem Rechner R1 gegenüber dem Rechner R2 als auch von dem Rechner R2 gegenüber dem Rechner R1 stattfinden. Um Missbrauch im Rahmen der Festlegung der Gültigkeit des Zertifikats über entsprechende Claims zu vermeiden, kann im Rahmen der Anforderung der Claims durch den Rechner R1 bzw. den Rechner R2 beim Rechner R3 auch eine Authentisierung vorgeschaltet sein, d. h. nur wenn sich die Rechner R1 bzw. R2 beim Rechner R3 authentisieren können, haben sie Zugriff auf die herausgegebenen Claims.
Im Rahmen von 2 ist nochmals schematisiert ein Informationsaustausch zwischen den Rechnern R2 und R1 zur beidseitigen Zertifikats-basierten Authentisierung zwischen den Rechnern angedeutet. Dieser Informationsaustausch erfolgt dabei über das an sich bekannte SSL/TLS-Protokoll. Die nachfolgend genannten Schritte S101 bis S104 umfassen dabei in der Regel jeweils eine Vielzahl von Teilschritten, welche an sich aus dem SSL/TLS-Protokoll bekannt sind und deshalb nicht näher ausgeführt werden. Im Rahmen des Schritts S101 fordert der Rechner R2 von dem Rechner R1 dessen Zertifikat C mit den darin enthaltenen Claims CL an. In Schritt S102 wird dieses Zertifikat übermittelt, wobei in Schritt S103 die Überprüfung des Zertifikats erfolgt. Im Rahmen dieses Schrittes wird auch überprüft, ob die im Zertifikat C enthaltenen Claims auch tatsächlich von dem Rechner R3 herausgegeben wurden. In Schritt S104 übermittelt auch der Rechner R2 sein Zertifikat C' mit darin enthaltenen Claims CL' an den Rechner R1. Nach Empfang des Zertifikats im Rechner R1 wird in Schritt S105 analog zu Schritt S103 eine Überprüfung des Zertifikats C' dahingehend vorgenommen, ob die Claims CL' auch tatsächlich von dem Rechner R3 herausgegeben worden sind. Sind die Überprüfungen in Schritt S103 und S105 beide positiv, werden beide Zertifikate von den entsprechenden Rechnern als gültig erachtet und es kann eine entsprechende Authentisierung erfolgen, in deren Rahmen ein Sitzungsschlüssel SK zwischen den beiden Rechnern R1 und R2 eingerichtet wird. Mit Hilfe dieses Schlüssels kann nachfolgend eine vertrauensgeschützte Kommunikation stattfinden.
In der Variante der 2 erfolgt die Überprüfung der entsprechenden Anforderungen des Zertifikats im Rahmen des Protokollablaufs. Diese Überprüfung kann jedoch alternativ auch außerhalb des Protokolls separat zwischen den authentisierenden Kommunikationspartnern durchgeführt werden, z. B. mittels des HTTP-Protokolls nach einem abgeschlossenen SSL/TLS-Verbindungsaufbau über die aufgebaute SSL/TLS-Verbindung.
Wie sich aus den obigen Ausführungen ergibt, wird die Gültigkeit eines Zertifikats in den beschriebenen Ausführungsbeispielen über entsprechend in den Zertifikaten spezifizierte Anforderungen festgelegt, wobei die Überprüfung, ob eine Anforderung erfüllt ist, unter Zuhilfenahme eines Teilnehmers erfolgt, der diese Anforderungen herausgibt und damit zusichert, dass die entsprechende Anforderung erfüllt ist. Zur Realisierung einer solchen Gültigkeitsbeschränkung können dabei an sich aus dem Stand der Technik bekannte Mechanismen basierend auf entsprechenden Claims des oben genannten Claims-based Authorization Modells bzw. basierend auf SAML-Assertions eingesetzt werden. Das im Rahmen der Erfindung verwendete Zertifikat ist somit nicht alleine gültig, sondern nur zusammen mit entsprechend herausgegebenen Anforderungen. Durch Herausgabe bzw. Rücknahme der Herausgabe der entsprechenden Anforderungen über den Teilnehmer, der die Anforderungen herausgibt, kann dabei flexibel die Gültigkeit eines digitalen Zertifikats gewährt bzw. widerrufen werden.
Die Anforderungen können dabei an beliebige Kriterien gekoppelt sein. Beispielsweise kann ein Zertifikat für einen Teilnehmer herausgegeben werden, das nur solange gültig ist, wie dieser Teilnehmer in der aktuellen Kommunikationsumgebung betrieben wird, wobei die Kommunikationsumgebung z. B. durch eine entsprechende Netzadresse spezifiziert ist. Die Anforderungen können auch in Abhängigkeit von dem Teilnehmer ausgestellt werden, der sich authentisieren möchte, bzw. gegebenenfalls auch von dem Teilnehmer, gegenüber dem die Authentisierung erfolgt. Die Anforderung kann dabei derart festgelegt sein, dass sich ein Teilnehmer z. B. gegenüber einem Teilnehmer authentisieren kann, wohingegen eine Authentisierung gegenüber einem anderen Teilnehmer nicht möglich ist. In einer Weiterbildung der Erfindung kann über eine Anforderung auch ein Vertrauenswert spezifiziert sein, der die Vertrauenswürdigkeit in die durchgeführte Authentisierung festlegt. Hierbei wird berücksichtigt, dass sich die Güte einer Authentisierung im Laufe der Lebensdauer eines Teilnehmers ändern kann, z. B. wenn Angriffe bekannt werden oder ein bestimmter Teilnehmer gehackt wurde oder wenn der Teilnehmer möglicherweise manipuliert sein könnte, z. B. bei einem nicht vertrauenswürdigen Vorbesitzer.
In einer weiteren Ausführungsform können die im Zertifikat spezifizierten Anforderungen auch geeignet verkettet werden. Damit ist es möglich, den Kreis der Teilnehmer einzuschränken, die z. B. auf eine bestimmte, im Netz vorhandene Ressource zurückgreifen darf. Eine mit einem Teilnehmerzertifikat assoziierte Anforderung kann hierbei eine weitere Anforderung vom Teilnehmer erfordern, welche beschreibt, wie dieser sich authentisiert hat. Die entsprechenden Anforderungen können z. B. von dem Gerätehersteller des entsprechenden Teilnehmers herausgegeben werden. Dieser Gerätehersteller stellt üblicherweise auch das Zertifikat für den Teilnehmer aus.
Die oben beschriebene Verkettung von Anforderungen kann mit an sich bekannten logischen Operatoren AND, NAND, OR, XOR und NOR erfolgen. Die entsprechende logische Verkettung ist dabei vorzugsweise im Zertifikat eincodiert. Durch eine solche Verkettung ist es z. B. möglich, Sperr-Anforderungen für entsprechende Zertifikate auszugeben. Diese Sperr-Anforderungen können dazu genutzt werden, Zertifikate einer Vielzahl von Teilnehmern für ungültig zu erklären. Wird eine Sperr-Anforderung dabei mit einer NAND-Verknüpfung mit anderen Anforderungen verknüpft, ist ein notwendiges Kriterium, dass das Zertifikat gültig ist, die Abwesenheit der Sperr-Anforderung.
Die im Vorangegangenen beschriebenen Ausführungsformen des erfindungsgemäßen Verfahrens weisen eine Reihe von Vorteilen auf. Insbesondere können Zertifikate für entsprechende Teilnehmer mit praktisch unendlicher Gültigkeit ausgestellt werden. Dies kann bei einem X.509-Zertifkat beispielsweise dadurch erfolgen, dass die entsprechenden Spezifikationen ”validFrom” und ”validTo” auf einen unendlich gültigen Zeitraum gesetzt werden. Um dennoch das Zertifikat zu widerrufen, genügt es dabei, dass eine Anforderung, welche zur Gültigkeit eines entsprechenden Zertifikats vorhanden sein muss, nicht mehr durch den Herausgeber der Anforderungen bereitgestellt wird.
Ebenso besteht die Möglichkeit, dass die entsprechenden Anforderungen zur Regelung der Gültigkeit des Zertifikats in einem lokalen Kommunikationsnetz, z. B. in dem Kommunikationsnetz einer Automatisierungsanlage, durch einen lokalen Teilnehmer in der Anlage herausgegeben werden. Insbesondere kann der Hersteller einer Automatisierungsanlage für die einzelnen Komponenten entsprechende Zertifikate mit darin spezifizierten Anforderungen ausstellen, wobei jedoch die Herausgabe der Anforderungen lokal durch den Betreiber der Automatisierungsanlage geregelt wird.
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

http://msdn.microsoft.com/en-us/magazine/dd278426.aspx [0032]

Claims

Verfahren zur Zertifikats-basierten Authentisierung, bei der sich ein erster Teilnehmer (R1) gegenüber einem zweiten Teilnehmer (R2) mit Hilfe eines, dem ersten Teilnehmer (R1) zugeordneten digitalen Zertifikats (C, C') authentisiert, wobei – das Zertifikat (C, C') eine oder mehrere Anforderungen (CL, CL') spezifiziert und die Erfüllung einer Anforderung (CL, CL') durch einen dritten Teilnehmer (R3) zugesichert wird, indem der dritte Teilnehmer (R3) die Anforderung (CL, CL') herausgibt; – im Rahmen der Authentisierung durch den zweiten Teilnehmer (R2) eine Gültigkeitsbedingung überprüft wird und das Zertifikat (C, C') des ersten Teilnehmers (R1) von dem zweiten Teilnehmer (R2) als gültig eingestuft wird, falls die Gültigkeitsbedingung erfüllt ist, wobei die Gültigkeitsbedingung von der Herausgabe und/oder der fehlenden Herausgabe von einer oder mehreren der im Zertifikat (C, C') spezifizierten Anforderungen (CL, CL') durch den dritten Teilnehmer (R3) abhängt.
Verfahren nach Anspruch 1, bei dem der erste Teilnehmer (R1) beim dritten Teilnehmer (R3) die Information abfragt, ob eine oder mehrere der im Zertifikat (C, C') spezifizierten Anforderungen (CL, CL') vom dritten Teilnehmer (R3) herausgegeben wurden, wobei der erste Teilnehmer (R1) die abgefragte Information dem zweiten Teilnehmer (R2) bereitstellt, woraufhin der zweite Teilnehmer (R2) basierend auf dieser Information die Gültigkeitsbedingung überprüft.
Verfahren nach Anspruch 1 oder 2, bei dem der zweite Teilnehmer (R2) beim dritten Teilnehmer (R3) die Information abfragt, ob eine oder mehrere der im Zertifikat (C, C') spezifizierten Anforderungen (CL, CL') vom dritten Teilnehmer (R3) herausgegeben wurden, wobei der zweite Teilnehmer (R2) basierend auf der abgefragten Information die Gültigkeitsbedingung überprüft.
Verfahren nach Anspruch 2 oder 3, bei dem sich der erste und/oder zweite Teilnehmer (R1, R2) beim dritten Teilnehmer (R3) zur Abfrage des oder der Anforderungen (CL, CL') authentisieren müssen.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem in dem Zertifikat (C, C') eine oder mehrere der folgenden Anforderungen (CL, CL') spezifiziert werden: – eine Anforderung (CL, CL') in Bezug auf eine zeitliche Gültigkeit des Zertifikats (C); – eine Anforderung (CL, CL') in Bezug auf eine Kommunikationsumgebung, in welcher der erste Teilnehmer (R1) betrieben wird; – eine Anforderung (CL, CL') in Bezug auf eine oder mehrere Eigenschaften des ersten und/oder zweiten und/oder dritten Teilnehmers (R1, R2, R3); – eine Anforderung (CL, CL') in Bezug auf die Vertrauenswürdigkeit der Authentisierung des ersten Teilnehmers (R1) beim zweiten Teilnehmer (R2).
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Gültigkeitsbedingung eine logische Verknüpfungskette umfassend mehrere AND- und/oder NAND- und/oder OR- und/oder XOR- und/oder NOR-Verknüpfungen ist, wobei die Verknüpfungskette vorzugsweise in dem Zertifikat (C, C') codiert ist.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Anforderungen (CL, CL') auf SAML basieren.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem im Rahmen der Authentisierung des ersten Teilnehmers (R1) gegenüber dem zweiten Teilnehmer (R2) eine Verifikation des Zertifikats (C, C') des ersten Teilnehmers durch den zweiten Teilnehmer (R) erfolgt.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem mit einem im Zertifikat (C, C') enthaltenen öffentlichen Schlüssel des ersten Teilnehmers (R1) sowie dem diesem öffentlichen Schlüssel zugeordneten privaten Schlüssel eine kryptographisch gesicherte Verbindung zwischen dem ersten und zweiten Teilnehmer (R1, R2) aufgebaut wird.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem die Authentisierung auf dem SSL/TLS-Protokoll und/oder dem IKE/IPsec-Protokoll und/oder dem IKEv2/IPsec-Protokoll basiert.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem das Zertifikat ein erweitertes X.509-Zertifikat ist, welches zusätzlich eine oder mehrere Anforderungen (CL, CL') spezifiziert.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem das Verfahren zur Authentisierung des ersten Teilnehmers (R1) beim zweiten Teilnehmer (R2) und des zweiten Teilnehmers (R2) beim ersten Teilnehmer (R1) genutzt wird.
Verfahren nach einem der vorhergehenden Ansprüche, bei dem der erste und/oder zweite und/oder dritte Teilnehmer (R2, R2, R3) Komponenten einer Automatisierungsanlage darstellen.
Kommunikationsnetz mit einem ersten, zweiten und dritten Teilnehmer (R1, R2, R3), wobei im Betrieb des Kommunikationsnetzes (N) eine Zertifikats-basierte Authentisierung durchführbar ist, bei der sich der erste Teilnehmer (R1) gegenüber dem zweiten Teilnehmer (R2) mit Hilfe eines, dem ersten Teilnehmer (R1) zugeordneten digitalen Zertifikats (C, C') authentisiert, wobei – das Zertifikat (C, C') eine oder mehrere Anforderungen (CL, CL') spezifiziert und die Erfüllung einer Anforderung (CL, CL') durch einen dritten Teilnehmer (R3) zugesichert wird, indem der dritte Teilnehmer (R3) die Anforderung (CL, CL') herausgibt; – im Rahmen der Authentisierung durch den zweiten Teilnehmer (R2) eine Gültigkeitsbedingung überprüft wird und das Zertifikat (C, C') des ersten Teilnehmers (R1) von dem zweiten Teilnehmer (R2) als gültig eingestuft wird, falls die Gültigkeitsbedingung erfüllt ist, wobei die Gültigkeitsbedingung von der Herausgabe und/oder der fehlenden Herausgabe von einer oder mehreren der im Zertifikat (C, C') spezifizierten Anforderungen (CL, CL') durch den dritten Teilnehmer (R3) abhängt.
Kommunikationsnetz nach Anspruch 14, welches derart ausgestaltet ist, dass in dem Kommunikationsnetz (N) ein Verfahren nach einem der Ansprüche 2 bis 13 durchführbar ist.