-
Technisches Gebiet der Erfindung
-
Die vorliegende Erfindung betrifft Adress-Mechanismen im Internet-Protokoll (IP) und im einzelnen Adress-Mechanismen in IPv6.
-
Hintergrund der Erfindung
-
Der gewaltige Wachstum bei der Verwendung des Internets hat Schwächen und Einschränkungen des gegenwärtigen, als IPv4 bekannten Internet-Protokolls an den Tag gelegt. Die Internet Engineering Task Force (IETF), die eine lose Verbindung von interessierten Parteien ist, entwickelt von daher ein verbessertes Internet-Protokoll, welches als IPv6 bekannt ist. Im einzelnen enthält IPv6 wesentlich verbesserte Sicherheitsmechanismen, die als IPSec bekannt sind, welche zwei oder mehrere Parteien in die Lage versetzen, auf sicherem Wege über das Internet zu kommunizieren, sowie Vorkehrungen für einen mobilen Internetzugriff (mobileIP) bereitstellen. MobileIP gestattet es einem Benutzer, auf das Internet zuzugreifen, während er sich bewegt, indem er von einem IP-Zugriffsknotenpunkt zu einem anderen roamt. MobileIP wird im einzelnen von solchen Benutzern verwendet, die auf das Internet über kabellose Mobilvorrichtungen (die beispielsweise mit Wireless LANs und zellularen Telefonnetzwerken verbunden sind) zugreifen.
-
IPv6 bietet für eine wesentlich größere IP-Adresse Raum, den IP-Adressen von 128 Bits in der Länge voraussetzen. Die ersten 64 Bits einer Adresse bilden einen Routing-Vorspann bzw. Leitwegelenkungs-Vorspann, welcher eindeutig den durch ein IP-Terminal oder Host verwendeten Internet-Zugriffsknotenpunkt (oder eine sogenannte „lokale Verknüpfung”) identifiziert, während die letzten 64 Bits einen Host-Nachspann ausbilden, welcher eindeutig das Mobilterminal zu dem Zugriffsknotenpunkt (oder innerhalb der lokalen Verknüpfung) identifiziert. Der Host-Nachspann wird als ein „Schnittstellen-Identifizierer” bezeichnet, da er den Host über die Zugriffsschnittstelle eindeutig identifiziert. Wenn sich ein Host bei einem Zugriffsknotenpunkt anmeldet, dann lernt der Host typischerweise den Routing-Vorspann des Zugriffsknotenpunktes von einer Ankündigungsnachricht, die von dem Zugriffsknotenpunkt gesendet wird. Gemäß RFC3041 (IETF) erzeugt dann ein Host seinen Schnittstellen-Identifizierer unter Verwendung einer mittels des Hosts erzeugten Zufallszahl. Der Host kann zusätzlich eine Sicherungsschicht
![Figure 00020001](https://patentimages.storage.***apis.com/71/a4/5d/81eb32ea3b6ffa/00020001.png)
bzw. Verbindungsschicht-Adresse verwenden, um den Schnittstellen-Identifizierer zu erzeugen, wobei die Sicherungsschicht- bzw. Verbindungsschicht-Adresse beispielsweise eine von dem Zugriffsnetz verwendete MAC-Schicht-Adresse ist.
-
Ein potentielles Problem mit diesem Ansatz liegt darin, dass zwei mit dem gleichen Zugriffsknotenpunkt verbundene Hosts (und von daher den gleichen Routing-Vorspann aufweisen), die gleichen Schnittstellen-Identifizierer und von daher die gleichen IP-Adressen erzeugen können. Dieses darf nicht vorkommen. Von daher sieht IPv6 einen als Duplicate Adress Detektion (DAD) bzw. Zweitadressen-Erfassung bekannten Mechanismus vor. Sobald ein Host eine potentielle IP-Adresse erzeugt hat, sendet er eine Nachbar-Ansuchungs-Nachricht, welche die vorgeschlagene IP-Adresse enthält, an den Zugriffsknotenpunkt oder direkt an die lokale Verknüpfung, wenn die lokale Verknüpfung für lokale Übertragung oder Multicast vorgesehen ist. Falls erforderlich, überträgt der Zugriffsknotenpunkt die Nachricht an sämtliche Hosts, die mit dem Knotenpunkt verbunden sind. Wenn ein Host, der die Nachricht empfängt, bemerkt, dass die in der Nachricht enthaltene IP-Adresse eine Adresse ist, die er bereits angenommen hat, dann antwortet dieser Host, indem er an dem ansuchenden Host eine Nachbar-Ankündigungs-Nachricht sendet. Wenn ein ansuchender Host innerhalb einer bestimmten Zeit keine Nachbar-Ankündigungs-Nachricht empfängt, dann wird er die erzeugte Adresse annehmen. Wenn andererseits innerhalb der bestimmten Zeit eine Nachbar-Ankündigungs-Nachricht empfangen wird, dann wird der ansuchende Host einen neuen Schnittstellen-Identifizierer und eine neue IP-Adresse erzeugen und den Ansuchungsprozess wiederholen.
-
Ein Problem bei dem oben beschriebenen Ansatz liegt darin, dass es für eine böswillige dritte Partei relativ einfach sein kann, den ansuchenden Knotenpunktzugriff zu verweigern, indem grundsätzlich auf eine Nachbar-Ansuchungs-Nachricht mit einer Nachbar-Ankündigungs-Nachricht geantwortet wird. Diese Art von Attacke ist als „Dienstverweigerungs-Attacke” bekannt.
-
Ein weiteres Problem kann in IPv6 mit MobileIP entstehen. Wie bereits erwähnt, gestattet es MobileIP, dass Hosts zwischen Zugriffsknotenpunkten und sogar zwischen Zugriffsnetzwerken umherwandern, eine Eigenschaft, die es erforderlich macht, dass es den Hosts gestattet ist, die IP-Adressen zu ändern, welche ihren gegenwärtigen physikalischen Standort definieren. Typischerweise wird einem mobilen Host eine „feste” Heimat-IP-Adresse in einem Heimat-Netzwerk zugewiesen. Wenn der Host zu Hause ist, dann kann er diese Heimatadresse als seine physikalische Adresse verwenden. Wenn sich jedoch ein Host selbst an einen „fremden” Zugriffsknotenpunkt anhängt, dann wird dem Host eine temporäre Care-of-Adresse zugewiesen. Hosts, die mit dem mobilen Host übereinstimmen, erhalten einen Binding-Cache, der Zuordnungen zwischen Heimatadressen und Care-of-Adressen enthält. Für eintreffende Pakete ändert die MobileIP-Schicht bei einem entsprechenden Host die Care-of-Adresse für die Heimatadresse in das Bestimmungsfeld, während für abgehende Pakete die MobileIP-Schicht bei einem entsprechenden Host die Heimatadresse für die Care-of-Adresse in das Zieladressen-Feld ändert. Wenn ein mobiler Host eine Care-of-Adresse erhält, dann muss er eine Einding-Aktualisierungs-Nachricht an alle entsprechenden Hosts senden, um ihre Binding-Caches zu aktualisieren.
-
Ein potentielles Risiko von diesem Mechanismus liegt darin, dass eine böswillige dritte Partei in der Lage sein kann, eine fehlerhafte Binding- bzw. Anbindungs-Aktualisierung an einen entsprechenden Host zu senden, um zu veranlassen, dass Datenpakete, die für einen mobilen Host beabsichtigt sind, an die böswillige Partei geroutet bzw. leitweggelenkt werden. Wenn die Pakete dann durch die böswillige Partei an den mobilen Host weitergeleitet werden (nachdem sie von dieser Partei geöffnet und gelesen wurden), kann der mobile Host nicht wissen, dass seine Pakete zurückgeroutet und gelesen wurden. Dieses Problem ist nicht auf MobileIP beschränkt, sondern tritt ebenso in anderen Signalisierungsfunktionen innerhalb der IPv6-Architektur auf. Die im Zusammenhang mit MobileIP bestehenden Probleme und einige der anderen Probleme werden detaillierter in dem IETF-Vortrag „draft-nikanderipng-address-ownership-00.txt” vom Februar 2001 beschrieben.
-
Eine Lösung für dieses Problem wurde in dem IETF-Vortrag „draft-bradner-pbk-frame-00.txt” vom Februar 2001 vorgeschlagen. Dieses schließt das Erzeugen eines zweckgebundenen Schlüssel(PBK)-Paares bei dem mobilen Host ein, das einen öffentlichen und einen privaten Schlüssel aufweist. Bei dem mobilen Host wird durch das Anwenden einer Hash-Funktion auf den öffentlichen Schlüssel eine Endpunkt-ID (EID) erzeugt. Die EID wird an einen entsprechenden Host gesendet, sobald eine IP-Verbindung initiiert ist. Dem nachfolgend sendet der mobile Host den öffentlichen Schlüssel an den entsprechenden Host
![Figure 00050001](https://patentimages.storage.***apis.com/1f/52/18/f34a26f73f1425/00050001.png)
der entsprechende Host ist in der Lage, zu verifizieren, dass der öffentliche Schlüssel zu der Verbindung „gehört”, indem die Ein-Wege-Codier-Funktion bei dem Schlüssel angewandt wird und indem das Ergebnis mit der zuvor empfangenen EID verglichen wird. Jede Binding Aktualisierung, die nachfolgend gesendet wird, wird bei dem mobilen Host mit dem privaten Schlüssel des Hosts signiert. Der entsprechende Host verifiziert die Signatur, die an der Binding-Aktualisierung angefügt ist, indem er den zuvor empfangenen öffentlichen Schlüssel verwendet.
-
Zusammenfassung der vorliegenden Erfindung
-
Oben wurden zwei Probleme bei IPv6 betrachtet, nämlich die Möglichkeit einer Dienstverweigerungs-Attacke, die durch das Senden einer Nachbar-Ankündigungs-Nachricht an einen ansuchenden Host eingeführt wird, und einer „Mann-in-der-Mitte”-Attacke, die auf einer Falschausstellung von Binding-Aktualisierungen basiert. Ähnliche Probleme können in den folgenden Situationen auftreten: ICMP Router Discovery (RFC2461 Abschnitt 6.1.2), ICMP Redirect (RFC 2461 Abschnitt 8.1), Generic Tunnelling (RFC2473); Ipsec Tunnelling (RFC 2401), Router Renumbering (RFC2894), IPv6 Routing Header (RFC2460 Abschnitt 8.4), und möglicherweise in der Inverse Neighbour Discovery (draft-ietf-ion-ipvo-ind-05.txt) und SCTP (RFC2960). Es kann ebenso in dem HIP-Vorschlag sowie in einer Anzahl anderer Vorschläge auftreten. Sämtliche Probleme haben einen gemeinsamen Grund
es ist nicht möglich, den Besitzer einer IP-Adresse zu verifizieren.
-
In Anbetracht des Vorschlages von Bradner bindet der PBK den öffentlichen Schlüssel nicht an eine IP-Adresse, sondern vielmehr nur an die EID. Des weiteren gibt es keine direkte Bindung zwischen der EID und der IP-Adresse. Von daher verbessert der PBK nicht direkt die beschriebenen Probleme.
-
Eine Aufgabe der vorliegenden Erfindung liegt darin, die obig genannten Probleme zu lösen. Im einzelnen liegt eine Aufgabe der vorliegenden Erfindung darin, eine Einrichtung zum Überprüfen des Besitzers einer IP-Adresse bereitzustellen. In diesem Dokument bezeichnet der Besitz einer IP-Adresse, dass der Besitzer autorisiert ist, die IP-Adresse innerhalb des bestimmten Umfanges der Adresse zu verwenden, und dass er autorisiert ist, die Routing- bzw. Leitwegelenkungs-Information zu ändern, die für die IP-Adresse gilt.
-
Gemäß einem ersten Aspekt der vorliegenden Erfindung wird ein Verfahren angegeben, um zu verifizieren, dass ein an ein IP-Netz gekoppelter Host autorisiert ist, eine IP-Adresse zu verwenden, die der Host als Besitz beansprucht, wobei die IP-Adresse einen Routing- bzw. Leitwegelenkungs-Vorspann und einen Schnittstellen-Identifizierer-Teil aufweist, wobei das Verfahren folgende Schritte aufweist: Empfang von einer oder mehreren Komponenten von dem Host, Anwendung einer Ein-Wege-Codier-Funktion an der oder an sämtlichen Komponenten und/oder an Ableitungen von der oder von jeder Komponente, und Vergleich des Ergebnisses oder einer Ableitung des Ergebnisses gegenüber dem Schnittstellen-Identifizierer-Teil der IP-Adresse, wobei, wenn das Ergebnis oder seine Ableitung mit dem Schnittstellen-Identifizierer übereinstimmt, der Host als autorisiert angenommen wird, die IP-Adresse zu verwenden, und wobei, wenn das Ergebnis oder seine Ableitung nicht mit dem Schnittstellen-Identifizierer übereinstimmt, der Host als nicht autorisiert angesehen wird, die IP-Adresse zu verwenden.
-
Es wird einsehbar sein, dass ein Host den Schnittstellen-Identifizierer-Teil von seiner IP-Adresse unter Verwendung der Komponente bzw. der Komponenten und/oder der Ableitungen der Komponente bzw. der Komponenten erzeugen wird. Wenn eine Vielzahl von Komponenten involviert ist, dann kann die Ein-Wege-Codier-Funktion an einer Kombination von bestimmten dieser Komponenten und Ableitungen von anderen der Komponenten angewandt werden. Der erzeugende Host wird diese Komponenten während einer Verbindung aufbewahren, und er wird in der Lage sein, diese bei Bedarf einer anderen Partei zur Verfügung zu stellen. Die andere Partei kann die Komponenten verwenden, um den Schnittstellen-Identifizierer zu rekonstruieren und um den Besitz der IP-Adresse von dem Host zu verifizieren. Für eine böswillige dritte Partei ist es schwierig, die Codierung zu umzukehren und die Komponenten von der IP-Adresse zurückzugewinnen, und von daher den wahren Besitzer einer Adresse zu personifizieren bzw. sich als den Besitzer einer Adresse auszugeben.
-
Diese Ein-Wege-Codier-Funktion kann SHA-1, MD5, oder irgendeine andere bekannte, kryptographische Ein-Wege-Codier-Funktion sein.
-
Ein Vorteil von Ausführungsformen der vorliegenden Erfindung ist der, dass sie nicht irgendwelche globale Infrastrukturen, wie etwa eine Public Key Infrastruktur (PKI), erfordern, sondern auf einer neuen Anwendung kryptographischer Funktionen basieren. Da bestimmte Ausführungsformen dieser Erfindung keine Architekturänderungen bezüglich der gegenwärtig vorgeschlagenen IPv6-Spezifikationen erfordern, ist des weiteren die vorliegende Erfindung vorteilhafter als der obig betrachtete Bradner-Vorschlag, welcher Änderungen in der gegenwärtig verwendeten IPv6-Architektur erfordern würde.
-
Das IP-Netzwerk kann das Internet oder ein privates IP-Netz, wie etwa LAN oder WAN, aufweisen. Das IP-Netz kann ein Zugriffsnetz, das mit dem Internet und/oder einem privaten IP-Netz gekoppelt ist, aufweisen.
-
In bevorzugter Weise weisen die Komponenten einen mittels des Hosts erzeugten oder von einer anderen Partei an den Host ausgestellten öffentlichen Schlüssel, oder einen Auszug eines öffentlichen Schlüssels oder eine feste (beispielsweise Null) Sequenz der gleichen Länge, und einen Hash-Wert auf, der eine Wert einer Sequenz von ähnlichen Hash-Werten ist. Alternativ hierzu oder zusätzlich hierzu umfassen die Komponenten einen Anfangs-Schnittstellen-Identifizierer, der einer Sicherungs- bzw. Verbindungsschicht-Adresse des Hosts entspricht oder von einer Sicherungs- bzw. Verbindungsschicht-Adresse des Hosts abgeleitet ist, oder eine feste (beispielsweise Null) Bit-Sequenz der gleichen Länge. Noch bevorzugter umfassen die Komponenten sowohl den öffentlichen Schlüssel oder einen Auszug eines öffentlichen Schlüssels als auch den Anfangs-Schnittstellen-Identifizierer, der einer Sicherungs- bzw. Verbindungsschicht-Adresse des Hosts entspricht oder von einer Sicherungs- bzw. Verbindungsschicht-Adresse des Hosts abgeleitet ist, oder eine feste (beispielsweise Null) Bit-Sequenz der gleichen Länge. Noch bevorzugter umfassen die Komponenten einen Zählerwert, der die Position des empfangenen Hash-Wertes in der Sequenz identifiziert.
-
In bevorzugter Weise werden die Serie der Hash-Werte bei dem Host durch Anwenden einer Ein-Wege-Codier-Funktion an einem Keimwert, dem öffentlichen Schlüssel oder einem Auszug des öffentlichen Schlüssels und dem Anfangs-Schnittstellen-Identifizierer abgeleitet. Alternativ hierzu wird die Serie der Hash-Werte bei dem Host durch Anwenden einer Ein-Wege-Codier-Funktion an dem Keimwert und entweder an dem öffentlichen Schlüssel oder einem Auszug des öffentlichen Schlüssel oder an dem Anfangs-Schnittstellen-Identifizierer abgeleitet. Der Hash-Wert, der von dem empfangenen Hash-Wert ableitbar ist, und welcher verwendet wird, um das Ergebnis zu erzeugen, ist der letzte Hash-Wert in der Sequenz. In dem Fall einer ersten IP-Adressen-Verifikation ist der von dem Host empfangene Hash-Wert der Hash-Wert, der dem End-Hash-Wert in der Sequenz vorausgeht. Für jeden nachfolgenden Verifikationsprozess muss der nächste vorangehende Hash-Wert empfangen werden.
-
In bevorzugter Weise umfasst das Verfahren das Ableiten des Endwertes der HASH-Sequenz und das Anwenden einer Ein-Wege-Codier-Funktion an diesem Endwert, welcher mit einer oder mehreren anderen Komponenten verknüpft ist. Das Ergebnis kann vor dem Vergleich des Endergebnisses mit dem Schnittstellen-Identifizierer weiterverarbeitet werden.
-
Gemäß einem zweiten Aspekt der vorliegenden Erfindung wird ein Verfahren des Erzeugens einer IP-Adresse bei einem Host angegeben, wobei die IP-Adresse einen Routing- bzw. Leitwegelenkungs-Vorspann und einen Schnittstellen-Identifizierer-Teil aufweist, wobei das Verfahren das Erzeugen des Schnittstellen-Identifizierer-Teils durch Anwenden einer Ein-Wege-Codier-Funktion an einer Komponente oder mehreren Komponenten aufweist.
-
In bevorzugter Weise weisen die Komponenten einen Hash-Wert auf, der mittels eines Verfahrens erzeugt wird, das Information von einer Zufallszahl verwendet. In bevorzugter Weise wird der Hash-Wert durch Anwenden einer Ein-Wege-Codier-Funktion an einer Kombination der Zufallszahl und einem Anfangs-Schnittstellen-Identifizierer, einem öffentlichen Schlüssel oder einem Auszug des öffentlichen Schlüssels, oder an einer Kombination des Anfangs-Schnittstellen-Identifizierers und einem öffentlichen Schlüssel oder eines Auszuges des öffentlichen Schlüssels erzeugt.
-
Gemäß einem dritten Aspekt der vorliegenden Erfindung wird ein Verfahren des Unterlaufens bzw. des Vermeidens der Duplikation der IP-Adresse in einem IP-Netz angegeben, wenn sich ein neuer Host an das Netzwerk anbindet, wobei das Verfahren die folgenden Verfahrensschritte aufweist:
Erzeugen eines Schnittstellen-Identifizierers bei dem neuen Host durch Kombination einer Komponente oder Komponenten und/oder Ableitungen der Komponente oder Komponenten unter Verwendung einer Ein-Wege-Codier-Funktion und unter Verwendung des Ergebnisses oder einer Ableitung des Ergebnisses als den Schnittstellen-Identifizierer, wobei der Schnittstellen-Identifizierer einen Teil der IP-Adresse ausbildet;
Versenden einer Nachbar-Ansuchungs-Nachricht von dem neuen Host an andere Hosts, die bereits an das Zugriffsnetz angeschlossen sind;
Empfang einer Nachbar-Ankündigungs-Nachricht bei dem neuen Host von jedem anderen Host, der die IP-Adresse für sich beansprucht, wobei die oder jede Nachbar-Ankündigungs-Nachricht die Komponente bzw. die Komponenten enthält; und
für jede empfangene Nachbar-Ankündigungs-Nachricht:
Kombination der Komponente bzw. der Komponenten und/oder der Ableitungen der Komponente bzw. der Komponenten unter Verwendung der Codier-Funktion; und
Vergleich des Ergebnisses oder einer Ableitung des Ergebnisses gegenüber dem Schnittstellen-Identifizierer-Teil der IP-Adresse, wobei, wenn das Ergebnis oder die Ableitung des Ergebnisses mit dem Schnittstellen-Identifizierer übereinstimmt, der Host, von welchem die Nachbar-Ankündigungs-Nachricht empfangen wird, als autorisiert gilt, die IP-Adresse zu verwenden, und, wenn das Ergebnis oder seine Ableitung nicht mit dem Schnittstellen-Identifizierer übereinstimmt, dieser Host als nicht autorisiert gilt, die IP-Adresse zu verwenden.
-
In bevorzugter Weise weist bzw. weisen die Komponente bzw. die Komponenten einen öffentlichen Schlüssel, einen Auszug eines öffentlichen Schlüssels oder eine Ableitung hiervon auf. Dieses gestattet es dem neuen Host, einen öffentlichen Schlüssel derart zu lernen, dass der neue Host auf sichere Weise annehmen kann, dass der Host, der die Ankündigung sendet, den öffentlichen Schlüssel verwendet, um seine IP-Adresse zu erzeugen, und von daher kann der neue Host annehmen, dass der andere Host im Besitz des entsprechenden privaten Schlüssels sein muss, um bezüglich der IP-Adresse autorisiert zu sein.
-
Basierend auf der obig genannten Annahme kann in bevorzugter Weise der neue Host jedes wohlbekannte Authentitations-Protokoll oder andere auf einem öffentlichen Schlüssel kryptographisch basierende Protokolle (wie etwa Zero-Knowledge-Protokolle) verwenden, um zu verifizieren, dass der andere Host gegenwärtig im Besitz des notwendigen privaten Schlüssels ist. In bevorzugter Weise wird bei erfolgreichem Ablauf des (Verifikations-)Protokolls angenommen, dass der andere Host autorisiert ist, die IP-Adresse zu verwenden, und bei einem Fehlschlagen des erfolgreichen Ablaufes des Protokolls wird angenommen, dass der andere Host nicht autorisiert ist, die IP-Adresse zu verwenden.
-
Gemäß einem vierten Aspekt der vorliegenden Erfindung wird ein Verfahren angegeben zum Verifizieren, dass ein Host, der an ein IP-Netz gekoppelt ist, autorisiert ist, eine IP-Adresse zu verwenden, welche der Host als seine eigene beansprucht, und dass der Host in der Lage ist, Datenpakete, die zu dieser Adresse gesendet werden, zu empfangen, wobei das Verfahren folgende Verfahrensschritte aufweist:
Ausführen des Verfahrens des obigen ersten Aspekts der Erfindung um sicherzustellen, dass der Host autorisiert ist, die IP-Adresse zu verwenden;
Senden einer Aufgabe bzw. einer Infragestellung an den Host unter Verwendung der IP-Adresse als Zieladresse für die Aufgabe bzw. Infragestellung;
Empfang einer Antwort von dem Host; und
Verifizieren, dass die empfangene Antwort eine richtige Antwort hinsichtlich der Aufgabe bzw. Infragestellung ist.
-
In bevorzugter Weise weist diese Aufgabe bzw. Infragestellung eine zufällig erzeugte Zahl auf. Noch bevorzugter weist diese Aufgabe bzw. Infragestellung die IP-Adresse auf, die mit einer zufällig erzeugten Zahl verknüpft ist. Noch bevorzugter ist die Aufgabe bzw. Infragestellung durch Anwenden einer Ein-Wege-Codier-Funktion an die IP-Adresse, die mit einer zufällig erzeugten Zahl verknüpft ist, konstruiert.
-
In bevorzugter Weise weist die Antwort die Aufgabe bzw. Infragestellung auf. In noch bevorzugter Weise weist die Antwort die mit der Aufgabe bzw. Infragestellung verknüpfte IP-Adresse auf. Noch bevorzugter wird die Antwort durch Anwenden einer Ein-Wege-Codier-Funktion an die IP-Adresse, die mit der Aufgabe bzw. Infragestellung verknüpft ist, konstruiert.
-
Gemäß einem fünften Aspekt der vorliegenden Erfindung wird ein Verfahren zum Authentifizieren eines öffentlichen Schlüssels angegeben, welcher über ein IP-Netz von einem ersten zu einem zweiten Host übermittelt wird, wobei das Verfahren die folgenden Verfahrensschritte aufweist:
Erzeugen eines Schnittstellen-Identifizierers beim ersten Host unter Verwendung des öffentlichen Schlüssels und Kombinieren des Schnittstellen-Identifizierers mit einem Leitwegelenkungs- bzw. Routing-Vorspann, um eine IP-Adresse für den ersten Host auszubilden;
Senden des öffentlichen Schlüssels über das IP-Netz von dem ersten zu dem zweiten Knotenpunkt; und
Verifizieren beim zweiten Knotenpunkt, dass der öffentliche Schlüssel der Schlüssel war, der erzeugt wurde, um den Schnittstellen-Identifizierer zu erzeugen.
-
Gemäß einem sechsten Aspekt der vorliegenden Erfindung wird ein Verfahren des Anbindens einer IP-Adresse an einen öffentlichen Schlüssel angegeben, wobei die IP-Adresse einen Leitwegelenkungs- bzw. Routing-Vorspann und ein Schnittstellen-Identifizierer-Teil aufweist, wobei das Verfahren die folgenden Verfahrensschritte aufweist:
Erzeugen des Schnittstellen-Identifizierers durch Kombination von einer oder mehreren Komponenten und/oder Ableitungen der Komponenten unter Verwendung einer Codier-Funktion; und
Erzeugen eines Zertifikats, welches mit einem privaten Schlüssel eines öffentlichen-privaten-Schlüsselpaares signiert ist, wobei das Zertifikat den Schnittstellen-Identifizierer und eine der Komponenten oder der Ableitungen oder weitere Ableitungen enthält, so dass das Zertifikat unter Verwendung des öffentlichen Schlüssels des Hosts authentifiziert werden kann und wobei der Besitz des Schnittstellen-Identifizierers durch Rekonstruktion des Schnittstellen-Identifizierers unter Verwendung der Inhalte des Zertifikates verifiziert werden kann, und Vergleich des Ergebnisses gegenüber dem echten Schnittstellen-Identifizierer.
-
Kurze Beschreibung der Zeichnungen
-
1 zeigt schematisch ein Netzwerk, welches eine Anzahl von Hosts aufweist, die mit dem Internet verbunden sind;
-
2 ist ein Ablaufdiagramm, welches einen Duplicate-Address-Detection-Prozess bzw. Zweitadressen-Erfassungs-Prozess in dem Netzwerk von 1 zeigt;
-
3 ist ein Ablaufdiagramm, welches ein Verfahren zum Durchführen einer Anbindungs-Aktualisierung in dem Netzwerk von 1 darstellt.
-
Detaillierte Beschreibung bestimmter Ausführungsformen
-
In 1 wird ein Internet-Kommunikationsszenario dargestellt, in welchem eine Anzahl von Benutzerterminals oder Hosts 1 bis 4 mit dem Internet 5 verbunden sind. Die Hosts 1 bis 3 sind mit dem Internet 5 über einen Zugriffsknotenpunkt 6 eines Zugriffsnetzwerks 7 verbunden. Der Host 4 ist mittels eines Zugriffsnetzes, das nicht in der Figur gezeigt wird, verbunden.
-
Es sei angenommen, dass einer der Hosts 1 in dem Zugriffsnetzwerk 7 neu ist, und dass für diesen Host das Zugriffsnetzwerk ein fremdes Netzwerk ist (und. von daher ist der Zugriffsknotenpunkt 6 ein fremder Agent). Der Host 1 findet diese Tatsachen durch Empfang einer Router-Advertisement-Nachricht von dem fremden Agenten heraus (diese Nachricht kann eine durch den fremden Agenten periodisch verwendete Nachricht sein, oder sie kann an den Host 1 in Erwiderung auf eine Router-Solicitation-Nachricht, die an den fremden Agenten von dem Host 1 gesendet wird, gesendet werden). Der Host 1 lernt von der Router-Advertisement-Nachricht einen Leitwegelenkungs- bzw. Routing-Vorspann, der den fremden Agenten innerhalb des Internets eindeutig identifiziert. Der Host 1 sendet dann eine Einding-Update-Nachricht bzw. Anbindungs-Aktualisierungs-Nachricht an den Heimatagenten 8 von seinem Heimatnetzwerk 9 über den fremden Agenten 6, um den Heimatagenten bezüglich seines neuen Standortes zu informieren. Der Heimatagent antwortet durch das Senden einer Einding-Acknowledgement-Nachricht über den fremden Agenten 6 an den Host 1. Wie bereits obig erklärt, kombiniert der Host 1 den Leitwegelenkungs- bzw. Routing-Vorspann und einen Schnittstellen-Identifizierer, um eine IP-Adresse auszubilden.
-
Ein neues Verfahren zum Erzeugen von Schnittstellen-Identifizierer wird nun beschrieben. Dieses Verfahren weist verschiedene Vorteile auf, die folgendes aufweisen:
- – Einbinden des Schnittstellen-Identifizierers an die Sicherungsschicht- bzw. Verbindungsschicht-Adresse;
- – Einbinden des Schnittstellen-Identifizierers an einen öffentlichen Schlüssel;
- – es stellt eine Einrichtung zur Verfügung, um eine Denial-of-Service-Attacke bzw. Dienstverweigerungs-Attacke während der Duplicate-Address-Detection bzw. Zweitadressen-Erfassung zu verhindern;
- – es stellt eine Einrichtung zur Verfügung, um das „Adressen-Besitzverhältnis” aus einer Entfernung zu überprüfen.
-
Allgemeine Beschreibung des Schnittstellen-Identifizierers
-
Das beschriebene Verfahren basiert auf einer kryptographisch stabilen Ein-Wege-Codier-Funktion. Eine Ein-Wege-Codier-Funktion wird mit HASH(...) bezeichnet, und die hier verwendete, bestimmte Ein-Wege-Codier-Funktion ist SHA-1 (obwohl andere alternativ hierzu verwendet werden können). Sehr allgemein ausgedrückt, lautet das vorgeschlagene Verfahren zum Erzeugen eines Schnittstellen-Identifizierers:
interface identifier:= HASH(component1|component2|component3)
wobei „...|...” Konkatenation bzw. Dateienverknüpfung bezeichnet, wobei eine der Komponenten eine neu erzeugte („frische”) Zufallszahl ist und die anderen Komponenten Informationsteile sind, die der Knotenpunkt (oder Host), der den Schnittstellen-Identifizierer erzeugt, an den Schnittstellen-Identifizierer anbinden möchte.
-
Bei einem gegebenen Schnittstellen-Identifizierer ist es rechnerisch schwierig, einen Satz von Komponenten zu berechnen, deren Prüfsumme zu diesem Schnittstellen-Identifizierer-Wert gehört. Wenn der Schnittstellen-Identifizierer 64 Bit lang ist, dann sind 63 Bits hiervon in diesem Zusammenhang signifikant, im Durchschnitt dauert es (263)/2 = 264 Operationen, einen solchen Satz von Komponenten aufzufinden. Während es möglich sein kann, einen Hash-Wert dieser Länge mit heutzutage zur Verfügung stehenden Geräten aufzulösen, würde es in der Praxis leicht einige hundert Jahre dauern. Da angenommen wird, dass die Zufalls-Schnittstellen-Identifizierer eine relativ kurze Lebenszeit von in der Regel einigen Tagen haben, wirft dieses ein vernachlässigbares Risiko auf. Selbst wenn in Zukunft ein voraussichtliches Anwachsen der Verarbeitungsleistung angenommen wird (Verdoppelung alle 18 Monate), wird es viele Jahre dauern, bevor das Risiko bedeutend wird. Anstatt es zu versuchen, Komponenten mittels eines böswilligen Knotenpunktes zu jeder Zeit, wenn ein NS-Paket empfangen wird, zu berechnen, kann stattdessen dieser Knotenpunkt ausgewählt werden, vorberechnete Werte in einem Cache-Speicher aufzunehmen. Jedoch würde der für diese Aufgabe erforderliche Speicherplatz unerschwinglich werden.
-
Die Sicherheit des Verfahrens verlässt sich auf die Prämisse, dass keiner außer der Erzeuger des Schnittstellen-Identifizierers bei Bedarf die Werte der Komponenten schnell und auf einfache Weise bereitstellen kann. Selbstverständlich könnte ein Sicherheitslevel durch das Erzeugen des Schnittstellen-Identifizierers unter Verwendung von lediglich einer einzelnen Komponente bereitgestellt werden. Jedoch liefert das Verwenden mehrerer Komponenten andere Vorteile, wie es in den folgenden Abschnitten diskutiert wird.
-
Um von den mittels dieses Verfahrens des Erzeugens von Schnittstellen-Identifizierern bereitgestellten Vorteilen Gebrauch zu machen, müssen sämtliche der teilnehmenden Knotenpunkte einer „Abmachung” zustimmen. Diese Abmachung spezifiziert eine Anzahl von Angelegenheiten. Zunächst spezifiziert sie das Verfahren zum Erzeugen von Schnittstellen-Identifizierern. Ferner spezifiziert sie, dass, wenn ein Knotenpunkt die Komponenten bereitstellt, die verwendet werden, um einen Schnittstellen-Identifizierer zu erzeugen, dieser Knotenpunkt wahrscheinlicher diesen Schnittstellen-Identifizierer als ein Knotenpunkt, der diese Komponenten nicht bereitstellen kann, „besitzt”. Ferner spezifiziert sie die Struktur und die semantische Bedeutung der Komponenten, d. h. sie spezifiziert, dass eine der Komponenten eine Zufallszahl ist, und der Zweck der anderen Komponenten.
-
Anbinden des Schnittstellen-Identifizierers an die Sicherungsschicht- bzw. Verbindungsschicht-Adresse
-
In dem grundlegenden IETF-Dokument [RFC2373] wird die Sicherungsschicht- bzw. Verbindungsschicht-Adresse direkt verwendet, um den Schnittstellen-Identifizierer zu erzeugen. Das Ausführungsverfahren ist reversibel, was es ermöglicht, zu prüfen, dass eine Sicherungsschicht- bzw. Verbindungsschicht-Adresse und der Schnittstellen-Identifizierer einander entsprechen. Das heißt, bei einem gegebenen Schnittstellen-Identifizierer kann jeder die entsprechende Sicherungsschicht- bzw. Verbindungsschicht-Adresse konstruieren, und umgekehrt. Dieses ist innerhalb einer lokalen Verknüpfung nützlich. In einem nachfolgenden IETF-Dokument [RFC3041] ist jedoch diese Verknüpfung zerbrochen, um zu verhindern, dass die Sicherungsschicht- bzw. Verbindungsschicht-Adresse außerhalb der lokalen Verknüpfung gesendet wird und die Privatsphäre eines Hosts riskiert wird. Obwohl die Sicherungsschicht- bzw. Verbindungsschicht-Adresse verwendet wird, um den Schnittstellen-Identifizierer zu erzeugen, wird in der Praxis diese Information nicht verwendet. Das heißt, die Zufallszahl, die verwendet wird, um den neuen Schnittstellen-Identifizierer zu erzeugen, wird niemals veröffentlicht oder sonstwie verwendet. Von daher besteht keine Möglichkeit, von einem gegebenen Schnittstellen-Identifzierer auf die Sicherungsschicht- bzw. Verbindungsschicht-Adresse zu schließen, oder sogar herauszufinden, ob ein bestimmter Knotenpunkt (der durch die Sicherungsschicht- bzw. Verbindungsschicht-Adresse identifiziert wird) tatsächlich einen gegebenen Schnittstellen-Identifizierer erzeugt hat.
-
Das hier beschriebene Verfahren erzeugt teilweise die Verknüpfung zwischen der Sicherungsschicht- bzw. Verbindungsschicht-Adresse und dem Schnittstellen-Identifizierer neu. Wie bereits erläutert, wird der Schnittstellen-Identifizierer von verschiedenen Komponenten erzeugt, wobei (zumindest) einer von diesen nur dem erzeugenden Knotenpunkt anfänglich bekannt ist. Eine andere dieser Komponenten ist die Sicherungsschicht- bzw. Verbindungsschicht-Adresse. Wenn ein Knotenpunkt, der einen Schnittstellen-Identifizierer als eigen beansprucht, Komponenten offenbart (wie er es tun muss), die verwendet wurden, um den Schnittstellen-Identifizierer zu erzeugen, werden andere Knotenpunkte, die die offengelegten Komponenten lernen, automatisch die Sicherungsschicht- bzw. Verbindungsschicht-Adresse aus den Komponenten heraussuchen. Durch das Prüfen, dass die Prüfsumme der Komponenten tatsächlich mit dem Schnittstellen-Identifizierer übereinstimmt, bekommen sie eine relative Gewissheit, dass der Erzeuger des Schnittstellen-Identifizierers es tatsächlich wollte, die gegebene Sicherungsschicht- bzw. Verbindungsschicht-Adresse zu verwenden.
-
Um für das Anbinden des Schnittstellen-Identifizierers an die Sicherungsschicht- bzw. Verbindungsschicht-Adresse zu sorgen, genügt es, den Schnittstellen-Identifizierer durch
Interface identifier := HASH(random|link layer address)
zu erzeugen, wobei „random” eine frische Zufallszahl und „link layer address” die Sicherungsschicht- bzw. Verbindungsschicht-Adresse ist, die der erzeugende Knotenpunkt verwenden möchte.
-
Anbinden des Schnittstellen-Identifizierers an einen öffentlichen Schlüssel
-
Üblicherweise stellt das Unvermögen, eine IP-Adresse mit einem öffentlichen Schlüssel (oder einem anderen sicherheitsbezogenen Informationsteil) zu verknüpfen, ein schwerwiegendes Problem hinsichtlich der Sicherheit von verschiedenen IPv6-ähnlichen Signalisierungsmechanismen dar. Beispielsweise muss ein Knotenpunkt, der andere Knotenpunkte hinsichtlich eines Änderns der Routing- bzw. Leitwegelenkungs-Information für eine spezifizierte Adresse informieren möchte, zeigen, dass er die IP-Adresse „besitzt”.
-
Es wurden drei mögliche Quellen einer solchen Autorisation betrachtet. Als erstes kann die Autorisation lokal konfiguriert sein. Dieses funktioniert gut für kleine bis mittlere Netzwerke, die unter einer einzelnen Administration stehen. Als zweites gibt es einige Arten von globaler Infrastruktur, die einen Nachweis des Besitzes der IP-Adresse bereitstellen. Eine spezielle PKI, wie etwa eine auflösungssichere DNS, kann solch einen Dienst bereitstellen. Jedoch ist das Einrichten von solch einem Dienst in der Praxis sehr schwierig. Drittens kann die Autorisation auf gegenseitigen Abmachungen basieren. Dieses ist der sogenannte AAA-Ansatz, der von der IETF-AAA-Arbeitsgruppe avanciert wird. Jedoch nähert sich solch ein System asymptotisch dem globalen Infrastruktur-Fall an, wenn sein Versorgungsbereich expandiert, was zu Anzahl-Skalierbarkeit- und Vertrauens-Transitivitäts-Problemen führt. Zusammengefasst leiden diese sämtlichen drei Verfahren unter Skalierbarkeitseinschränkungen.
-
Ein viertes Verfahren, welches hier eingebracht wird, verwendet die Kryptographie und die Tatsache, dass der IPv6-Schnittstellen-Identifizierer-Teil einer IPv6-Adresse lang genug ist, einige kryptographische Signifikanz zu haben. Die Grundidee liegt darin, das komponentenbasierende Erzeugen des Schnittstellen-Identifizierers zu verwenden, um eine kryptographische Signifikanz-Verknüpfung zwischen dem Schnittstellen-Identifizierer und einem öffentlichen Schlüssel bereitzustellen. Das heißt, eine der bei der Erzeugung eines Schnittstellen-Identifizierers verwendeten Komponenten ist ein öffentlicher Schlüssel (oder die Kontrollsumme bzw. Prüfsumme des öffentlichen Schlüssels, d. h. der kryptographische Auszug oder „Fingerabdruck” des öffentlichen Schlüssels). Wie in dem Fall der Sicherungsschicht- bzw. Verbindungsschicht-Adresse stellt der Knotenpunkt durch Offenbarung der Komponenten einen Anspruch bereit, dass der Erzeuger des Schnittstellen-Identifizierers den bestimmten öffentlichen Schlüssel verwenden möchte. Von daher kann, wenn nur ein Schnittstellen-Identifizierer und die Komponenten, von welchen er erzeugt wurde, gegeben sind, jeder andere Knotenpunkt eine angemessene Gewissheit erhalten, dass der gegenwärtige Verwender des Schnittstellen-Identifizierers tatsächlich einen gegebenen kryptographischen Schlüssel verwenden möchte. Die entgegengesetzte Überprüfung, d. h., dass der Benutzer eines öffentlichen Schlüssels es wünscht, einen gegebenen Schnittstellen-Identifizierer zu verwenden, wird durch Signieren des Schnittstellen-Identifizierers mit dem Schlüssel bereitgestellt. Um diese Eigenschaften anzubieten, genügt es, den Schnittstellen-Identifizierer durch:
interface identifier:= HASH(random|public key)
zu erzeugen und ihn als
certificate/signed message:= {interface identifier|public key}privatekey
zu signieren, wobei „...|...” die Konkatenation bezeichnet, „{...}K” eine mit dem Schlüssel K signierte Nachricht bezeichnet, „random” eine frische bzw. neue Zufallszahl ist, „public key” der öffentliche Schlüssel oder eine kryptographische Kontrollsumme hiervon ist, und „private key” ein entsprechender privater Schlüssel ist. Für zusätzliche Gewissheit kann die Zufallszahl in die signierte Nachricht wie folgt eingebunden werden:
certificate/signed message:= {interface identifier|random|public key}privatekey
-
Eine vollständige Schnittstellen-Identifizierer-Erzeugungs-Prozedur
-
Zum Zwecke der weiteren Darstellung der Erfindung und ihrer Anwendungen wird der folgende detaillierte Anwendungsvorschlag angegeben. Dieser verwendet sowohl die Sicherungsschicht- bzw. Verbindungsschicht-Adresse und einen öffentlichen Schlüssel, um den Schnittstellen-Identifizierer zu erzeugen.
-
Die folgenden Operatoren werden hier verwendet:
- ...|...
- bezeichnet Konkatenation
- {...}K
- bezeichnet eine mit dem Schlüssel K signierte Nachricht.
- [...]K
- bezeichnet eine mit dem Schlüssel K verschlüsselte Nachricht.
- 1. II0 sei ein 64-Bit Anfangs-Schnittstellen-Wert, der basierend auf der Sicherungsschicht- bzw. Verbindungsschicht-Adresse des Hosts genau wie im Anhang A von [RFC2373] spezifiziert erzeugt wird. Wenn solch ein Wert nicht vorliegt, muss II0 eine 64-Bit lange Nullfolge sein.
- 2. Optional wird von einer autorisierten dritten Partei ein Schlüsselpaar <K+, K–> erzeugt oder erzielt, wobei K+ ein öffentlicher Schlüssel und K– ein entsprechender privater Schlüssel ist.
- 3. Berechnung eines Auszuges eines öffentlichen Schlüssels, #K+: = HASH(K+). Wenn kein öffentlicher Schlüssel verwendet wird, muss #K+ ein Nullwert der gleichen Länge sein.
- 4. Erzeugung eines anfänglichen Zufallswertes HN, wobei N die Länge der in dem nächsten Schritt zu erzeugenden Serie ist.
- 5. Erzeugung einer Serie von Hash-Werten HN, ..., Hi, ... H0, wobei Hi-1: = HASH(Hi|II0|#K+) ist, durch n-maliges Anwenden der Funktion, d. h., bis H0 erzeugt ist.
- 6. Der History-Keim H sei für den RFC3041Schnittstellen-Identifizierer-Erzeugungsalgorithmus der letzte Wert in der Hash-Serie, d. h., H: = H0.
- 7. Fortfahren wie im Abschnitt 3.2.1 von RFC3041 spezifiziert (mit geringfügigen Modifikationen)
– Verknüpfe H|II0' wobei H der im Schritt 6 erzeugte History-Keim und II0' ein 64-Bit Nullwert* ist.
– Berechne II': = MD5 (H|II0')
– Nehme die äußersten 64 Bits des MD5-Auszuges II' heraus und setze Bit 6 auf 0. Das Ergebnis ist der Schnittstellen-Identifizierer II.
– Wenn mehrere Versuche benötigt werden (d. h., aufgrund einer authentisierten Kollision), verwerfe den letzten Wert der Hash-Serie, wobei N um 1 vermindert wird: N:= N – 1, und fahre vom obigen Schritt 6 an fort. Es sei darauf hingewiesen, dass dieses verschieden von [RFC3041] ist, wo die MD5-Funktion einfach noch einmal angewendet wird.
- 8. Wenn der optionale öffentliche Schlüsselwert in Schritt 2 erzeugt oder erzielt wurde, erzeuge ein selbstsignierendes Zertifikat, welches den Schnittstellen-Identifizierer, den Auszug des öffentlichen Schlüssels, die Anzahl der Werte in der Hash-Serie, den letzten Wert in der Hash-Serie und die Sicherungsschicht- bzw. Verbindungsschicht-Adresse des Hosts wie folgt enthält:
CERT:= {II, #K+, N, H0}K–.
Wenn der öffentliche Schlüssel nicht verwendet wird, muss ein leerer Wert verwendet werden, wann auch immer das CERT ansonsten verwendet werden würde. Die Verwendung von diesem Zertifikat wird nachfolgend beschrieben:
-
*) Der Grund, warum II0' anstelle II0 ist, ist zweifach. Einmal wurde II0 bei der Erzeugung der HN, ..., Hi, ... H0-Serien berücksichtigt, wobei auf mögliche schlechte Zufallszahlerzeugungen achtgegeben wird, wie es in RFC3041 durchdacht ist. Zusätzlich erfordert das Prüfen des Besitzes mit H1 ebenso II0, was es möglich macht, den Besitz mit der Sicherungsschicht- bzw. Verbindungsschicht-Adresse wie nachfolgend begründet lokal zu verknüpfen. Zweitens macht das Auslassen von II0 bei der Berechnung von II es möglich, anfänglich H nur an einem entfernten Knotenpunkt offenzulegen. Die Enthüllung bzw. Offenlegung von II0 über entfernte Verknüpfungen ist nicht gewünscht, da es effektiv die Datenschutzziele von RFC3041 annullieren würde.
-
In dem hier beschriebenen Verfahren ist der Besitz eines Schnittstellen-Identifizierers primär auf den erzeugten Hash-Serien und auf der Offenlegung früherer Werte von der Hash-Serie bei Bedarf basiert. Da der Bedarf gering sein sollte (nahezu nicht existierend, bis eine Attacke auftritt), scheint es für die meisten Hosts hinreichend zu sein. Jedoch wurde das Verfahren derart ausgelegt, dass der Schnittstellen-Identifizierer eng an einen kryptographischen Schlüssel gebunden ist, und der Schlüssel kann ebenso an den Schnittstellen-Identifizierer gebunden sein. Des weiteren bindet ebenso das Verfahren die Sicherungsschicht- bzw. Verbindungsschicht-Adresse in die Erzeugung des Schnittstellen-Identifizierers ein. Die Begründung lautet wie folgt:
Wenn die Hash-Serie HN, ..., Hi, ... H0 konstruiert wird, werden in jedem Schritt sowohl die Sicherungsschicht- bzw. Verbindungsschicht-Adresse als auch eine Kontrollsumme eines öffentlichen Schlüssels verwendet. In Wirklichkeit zeigt dies, dass der Host den spezifizierten öffentlichen Schlüssel und die spezifizierte Sicherungsschicht- bzw. Verbindungsschicht-Adresse verwenden möchte, wenn er den Schnittstellen-Identifizierer verwendet. Dieses gestattet es lokal, dass die Knotenpunkte Pakete ignorieren, die von anderen Knotenpunkten unter Verwendung des Schnittstellen-Identifizierers des Knotenpunktes jedoch mit einer „falschen” Sicherungsschicht- bzw. Verbindungsschicht-Adresse gesendet werden. In Umgebungen, wo das Ändern der Sicherungsschicht- bzw. Verbindungsschicht-Adresse spezielle Privilegien oder Hardware-Operationen erfordert, steigert dies etwas die Sicherheit.
-
Die Einbeziehung des öffentlichen Schlüssels hat mehrere tiefsinnige Effekte. Im einzelnen bedeutet dies, dass die anderen Hosts direkt einen öffentlichen Schlüssel lernen können, so dass sie sicher den Besitzer eines Schnittstellen-Identifizierers zum Halten annehmen können. Das heißt, durch die Verwendung der Prüfsumme eines bestimmten öffentlichen Schlüssels in dem Schnittstellen-Identifizierer-Erzeugungs-Prozess hat der Knotenpunkt nachhaltig angedeutet, dass er möchte, dass der bestimmte Schnittstellen-Identifizierer den Schlüssel „besitzt”. Die umgekehrte Richtung wird mittels des selbstsignierenden Zertifikats gezeigt, das im wesentlichen angibt, dass der Besitzer von dem Schlüssel den Schnittstellen-Identifizierer „besitzen” möchte. Zusammen erzeugen diese beiden eine kryptographisch feste Zwei-Wege-Anbindung zwischen dem Schnittstellen-Identifizierer und dem öffentlichen Schlüssel. Tatsächlich scheint dies so nutzvoll zu sein, dass Hosts diese Information bei einer früheren Stufe unter Verwendung der Neighbour Solicitation-Nachrichten zu veröffentlichen möchten mögen, und dass sie es mögen, diese Information in ansuchenden Neighbour Advertisements erneut vortragen mögen. Aus diesem Grund können die Neighbour Solicitation (NS)- und Neighbour Advertisement (NA)-Nachrichten die folgende Information enthalten:
- – Den öffentlichen Schlüssel K+ selbst.
- – Das selbstsignierte Zertifikat CERT.
- – Optional den Anfangs-Schnittstellen-Identifizierer II0.
-
Jedoch wird es für keinen anderen Zweck als zum Überprüfen der Sicherungsschicht- bzw. Verbindungsschicht-Adresse benötigt, und solch eine Überprüfung sollte möglichst nicht durchgeführt werden, bis der Besitz des Schnittstellen-Identifizierers verifiziert worden ist. Die Einbeziehung von K+ und CERT gestattet es dem empfangenden Host, zu verifizieren, dass der Besitzer des Schlüssels K+ wirklich den angegebenen Schnittstellen-Identifizierer verwenden möchte.
-
Der unter Verwendung dieses Verfahrens erzeugte Schnittstellen-Identifizierer hat viele Verwendungen, wobei einige von ihnen nun detailliert betrachtet werden.
-
Verhinderung der Dienstverweigerung während DAD
-
Während der Adressen-Autokonfiguration ist es möglich, dass der neu erzeugte Schnittstellen-Identifizierer mit einem bestehenden Schnittstellen-Identifizierer kollidiert. Dieses wird durch den Empfang eines Neighbour Advertisement-Pakets angezeigt, das beansprucht, dass irgendein anderer Knotenpunkt bereits den Identifizierer „besitzt”. In RFC3041 besteht das Verfahren, solch eine Kollision zu verhindern, darin, einen sukzessiven Schnittstellen-Identifizierer unter Verwendung von MD5 zu berechnen, und es maximal fünfmal wieder zu versuchen. Unglücklicherweise ist dieses Verfahren nicht wirksam gegenüber böswilligen Knotenpunkten, die einfach sämtliche Schnittstellen-Identifizierer beanspruchen.
-
Hash-basierende DoS-Vermeidung
-
Um zu verhindern, dass böswillige Knotenpunkte Schnittstellen-Identifizierer, die ein neuer Knotenpunkt erzeugt hat, als „Besitz” beanspruchen, wird vorgeschlagen, dass das DAD-Protokoll wie folgt erweitert wird:
- a) Sämtliche Neighbour-Solicitation(NS)-Pakete weisen die Form
<TA, C, K+, CERT>
auf, wobei TA die provisorische Adresse, C eine Zufallszahl, K+ der öffentliche Schlüssel des antwortenden Knotenpunktes und CERT das im obigen Schritt 8 erzeugte Zertifikat ist. Streng gesprochen, werden die Zufallszahl (die als eine Aufgabe bzw. Infragestellung verwendet wird) und das Zertifikat nicht benötigt, jedoch tragen sie wenig Zuschlag und geringe Sicherheitssteigerung.
- b) Eine Aufhebungs-NA-Nachricht, die als ein Teil von DAD gesendet wird, muss die folgende Form aufweisen:
<TA, TLLA, i, Hi, #K+, R>,
wobei TA die Adresse ist, deren Besitz die NA beansprucht, TLLA die Ziel-Sicherungsschicht- bzw. Verbindungsschicht-Adresse ist, II0 von TLLA wie im Anhang A von [RFC2373] spezifiziert berechnet wird, i der Zähler der verwendeten Hash-Werte (für die erste kollidierende NA ist i gleich 1) ist, Hi die i-te Kontrollsumme der Hash-Serie ist, #K+ der Auszug des öffentlichen Schlüssels ist (oder 128-Bit Nullwert, wenn die öffentliche Schlüssel-Verschlüsselung nicht verwendet wird) und R MD5(Hi|C) ist. Durch das Veröffentlichen dieser Werte zeigt der antwortende Knotenpunkt, dass er den Schnittstellen-Identifizierer „besitzt”. Wenn zusätzlich das optionale öffentliche Schlüsselpaar durch den antwortenden Knotenpunkt erzeugt oder erzielt wurde, wenn er den Schnittstellen-Identifizierer erzeugt, sollte die Nachricht den öffentlichen Schlüssel und eine Signatur enthalten, d. h.
<TA, TLLA, i, Hi, #K+, R, K+, SIGN>
, wobei K+ der im obigen Schritt 2 erzeugte öffentliche Schlüssel und SIGN eine Signatur über das gesamte Paket einschließlich der IP-Kopfzeile ist, die unter Verwendung von K– erzeugt wird.
-
Um zu verifizieren, dass der Host, der die NA sendet, wirklich den Schnittstellen-Identifizierer besitzt, berechnet der empfangende Host das folgende:
- 1. Berechne H0 durch i-faches Berechnen von Hi-1: = HASH(Hi|II0|#K+)
- 2. Setze H = H0
- 3. Berechne II':= MD5(H|II0'), wobei II0' ein 64-Bit Nullwert ist
- 4. Berechne II: = II' Bitwiseand 0xDFFFFFFFFFFFFFFF, was im wesentlichen Bit 6 von II' leert, wobei II hervorgebracht wird
- 5. Überprüfe, dass TA = 0xfe80000000000000|II ist, wobei 0xfe80000000000000 der lokale Adressen-Vorspann der IPv6-Verknüpfung ist
- 6. Überprüfe, dass R = MD5 (Hi|C) ist.
Wenn des weiteren die NA die optionale Signatur enthält, dann kann der empfangende Host das folgende berechnen:
- 7. Überprüfe, dass #K+ = HASH(K+) ist
- 8. Überprüfe unter Verwendung von K+, dass SIGN eine gültige Signatur über das empfangene Paket ist.
-
Wenn beispielsweise i = 1 gilt, dann würde NA enthalten
<TA, TLLA, 1, H1, #K+, TIME, K+, SIGN>
und die Berechnung läuft wie folgt ab:
- 1. H0: = HASH(H1|II0|#K+)
- 2. H:= H0
- 3. II':= MD5(H|64-Bit 0)
- 4. II:= II' Bitwiseand 0xDFFFFFFFFFFFFFFF
- 5. Überprüfe, dass TA = 0xfe80000000000000|II ist
- 6. Überprüfe, dass R = MD5(Hi|C) ist
- 7. Überprüfe, dass #K+ = HASH(K+) ist
- 8. Überprüfe, dass SIGN = Signatur über das empfangene Paket ist.
-
Wenn die Überprüfungen durchgeht, dann kann der ansuchende Knotenpunkt annehmen, dass der Ansprechende wirklich den Schnittstellen-Identifizierer besitzt, und dass er einen neuen Schnittstellen-Identifizierer erzeugen sollte.
-
Es verbleibt jedoch eine Möglichkeit einer Wiedergabe-Attacke. Anstelle den Schnittstellen-Identifizierer als seinen Besitz zu beanspruchen, wenn der neue Knotenpunkt ihn erzeugt, kann ein Angreifer es gestatten, dass der Knotenpunkt den Schnittstellen-Identifizierer einrichtet, und er wirkt lediglich auf diesen ein. Sobald der Knotenpunkt seinen Besitz über den Schnittstellen-Identifizierer eingerichtet hat, sendet der Angreifer eine NS, die den Schnittstellen-Identifizierer abfragt bzw. anfordert. Gemäß diesem Protokoll muss der rechtmäßige Besitzer durch Offenlegung des soweit geheimen Wertes H1 entgegnen bzw. kontern, wodurch der Angreifer anfänglich abgeblockt wird. Jedoch kann der Angreifer nun erneut beanspruchen, den Schnittstellen-Identifizierer zu besitzen, dieses Mal durch einfaches Wiedergeben der NA, die die H1 aufdeckt. Der rechtmäßige Besitzer blockt diese Wiedergabe-Attacke durch Wiedergabe des vorhergehenden Hi-Wertes in der Hash-Serie ab. Soweit bekannt, ist die einzige Strategie, dieses Problem anzugehen, brutale Gewalt, die in der Größenordnung von 2(i-(Länge(Hi)-1))-Operationen benötigt, abhängig von der Länge des Wertes Hi. Wenn zusätzlich immer mehr als ein Paar von Hi-Werten aufgefordert werden, lokal aufgedeckt zu werden, ist es ein gutes Anzeichen eines Attackenversuches.
-
Dieses Verfahren wird ferner in dem Ablaufdiagramm in 2 dargestellt.
-
PK-basierende DoS-Vermeidung
-
Ein anderer, nicht verwandter Weg zum Lösen des Problems einer Wiedergabe-Attacke liegt in der Verwendung von einer der offengelegten und festgebundenen Komponenten. Das heißt, während zwei Knotenpunkte einen bestimmten Schnittstellen-Identifizierer durch das Bereitstellen der gleichen offengelegten Komponenten als „eigen” beanspruchen mögen, kann nur einer zeigen, dass er eine der Komponenten „besitzt”, und diese bestimmte Komponente kann verwendet werden, um den Konflikt zu lösen. Hier ist die Komponente, die verwendet wird, der öffentliche Schlüssel. Wenn von daher zwei Parteien beanspruchen, den gleichen Schnittstellen-Identifizierer durch das Aufzeigen der gleichen Komponenten zu besitzen (oder wenn die Komponenten bereits öffentlich gemacht wurden), kann der Streit durch einen der Anspruchsteller gelöst werden, der sein Vermögen zeigt, den privaten Schlüssel zu verwenden, welcher dem an den Schnittstellen-Identifizierer gebundenen öffentlichen Schlüssel entspricht.
-
Es gibt verschiedene Arten von öffentlicher Schlüssel-Kryptographie, einschließlich herkömmlicher öffentlicher Schlüssel-Verschlüsselungen, wie etwa RSA, öffentliche Schlüssel-Signatur-Algorithmen, wie etwa DSA, und selbst Null-Wissen-Protokolle bzw. Zero-Knowledge-Protokolle. Zum Zwecke des Überprüfens des Besitzes hinsichtlich eines Schnittstellen-Identifizierers ist jedes solcher Verfahren verwendbar. Das heißt, die einzigen Anforderungen liegen darin, dass es möglich ist, einen öffentlichen Schlüssel mittels eines kryptographischen Auszuges auszudrücken, und einen zeitlichen Nachweis zu bringen, dass der Anspruchsteller tatsächlich auf den privaten Schlüssel zugegriffen hat. Die gewöhnliche Art und Weise des Bereitstellens eines rechtzeitigen Nachweises liegt darin, ein Authentikations-Protokoll ablaufen zu lassen.
-
Sicherungsschicht- bzw. Verbindungsschicht-Adressen basierende DoS-Vermeidung
-
Abhängig von der Natur der verwendeten Sicherungsschicht- bzw. Verbindungsschicht-Kommunikation kann es ebenso möglich sein, die Sicherungsschicht- bzw. Verbindungsschicht-Adresse zu verwenden, um Konflikte zu lösen (und um sich gegen Wiedergabe-Attacken zu verteidigen), oder als die einzige Einrichtung zum lokalen Überprüfen des Besitztums des Schnittstellen-Identifizierers. Das heißt, wenn das verwendete Kommunikationsmedium sichere Sicherungsschicht- bzw. Verbindungsschicht-Adressen aufweist, dann ist die Möglichkeit, eine Sicherungsschicht- bzw. Verbindungsschicht-Adresse, wie obig diskutiert, an einen Schnittstellen-Identifizierer zu binden, hinreichend, um sicherzugehen, dass nur legitime Schnittstellen-Identifizierer verwendet werden.
-
Erweitern von Schnittstellen-Identifizierern auf leitwegelenkungsfähige Adressen
-
Bis jetzt wurden lediglich Schnittstellen-Identifizierer diskutiert. Wie jedoch in [RFC3041] spezifiziert, gelten zufällig erzeugte Schnittstellen-Identifizierer nur als lokal eindeutig. Von daher ist es möglich und sogar vermutlich, dass es kollidierende Schnittstellen-Identifizierer in dem globalen Internet gibt (gemäß dem „Geburtstags-Paradoxon” beträgt bei einem angenommenen Satz von etwa 2(63/2) oder etwa drei Billionen Schnittstellen die Wahrscheinlichkeit einer solchen Kollision etwa 50%). Selbst wenn wir durch das Voraussetzen von Eindeutigkeit in der (erweiterten) Duplicate Address Detection-Prozedur bzw. Zweitadressen-Erfassungs-Prozedur lokale Kollisionen nicht zulassen, müssen sie in dem nicht-lokalen Fall toleriert werden. Demzufolge ist es in dem nicht-lokalen Fall nicht sinnvoll, die Autorisation nur auf den Schnittstellen-Identifizierer zu basieren.
-
Anfrage bzw. Infragestellung/Erwiderung
-
Ein Grundproblem bei paketbasierender Kommunikation ist die Leichtigkeit des Beschwindelns der Quell-Adresse. Das heißt, außer wenn eine globale Zugangsfiltrierung verwendet wird, ist es einfach, Pakete zu verwenden, wobei die Quell-Adresse keine Relevanz aufweist. Ein Grundlevel von Sicherheit kann durch das Senden einer Aufgabe bzw. Infragestellung zurück an die in dem Paket spezifizierte Quell-Adresse und durch das Abwarten auf eine Antwort erzielt werden. Der Erzeuger des Paketes ist in der Lage, nur dann mit einer geeigneten Erwiderung zu antworten, wenn er in der Lage ist, Pakete zu empfangen, die an die Adresse gesendet werden. Dieses Verfahren ist wohlbekannt und wird beispielsweise in dem Cookie-Mechanismus in verschiedenen Protokollen verwendet.
-
Das grundlegende, nur auf Kontrollsummen basierende Verfahren zum Bereitstellen des Beweises des Schnittstellen-Identifizierers-Besitzes kombiniert den Infragestellungs-/Erwiderungs-Ansatz mit dem einfachen Ansatz der Offenbarung von Komponenten oder mit dem komplizierteren Ansatz der wiederholten Offenbarung von Komponenten (beide hiervon wurden obig beschrieben). Des weiteren wird die Kombination derart durchgeführt, dass die Partei, die den Besitz verifiziert, nicht umfangreiche Berechnungen durchführen muss. Die geringe Rechenintensität des Prozesses verhindert einige potentielle Ressourcen-aufreibende Dienstverweigerungs-Attacken.
-
Die Grundidee liegt darin, dass ein Anspruchsteller zunächst die zu prüfende Adresse verwendet, einschließlich des Schnittstellen-Identifizierers und der Komponenten, von welchen der Schnittstellen-Identifizierer erzeugt wurde. Dieses ist die erste Nachricht in dem Protokoll. Der Prüfer bzw. Verifizierer kann die Komponenten prüfen, wodurch er sicherstellt, dass der Anspruchsteller entweder den Schnittstellen-Identifizierer selbst erzeugt hat oder dass er ihn von dem Ursprungs-Knotenpunkt gelernt hat. Jedoch ist das Protokoll in der Art ausgelegt, dass die Anzahl der Knotenpunkte, die den zweiten Satz von Komponenten, die später verwendet werden, gelernt haben mag, wesentlich geringer ist, da wahrscheinlich eine große Anzahl von Knotenpunkten, die diesen ersten Satz von Komponenten gelernt haben, besteht.
-
Sobald der Prüfer den Schnittstellen-Identifizierer und die Komponenten geprüft hat, sendet er eine Infragestellung an die zu verifizierende Adresse. Im Prinzip könnte die Infragestellung eine einfache Zufallszahl sein. Jedoch wird hier die Zufallszahl mit dem zu verifizierenden Schnittstellen-Identifizierer und den Komponenten kombiniert, wodurch es gestattet wird, dass die gleiche Zufallszahl wiederholt verwendet wird. Die Infragestellung ist die zweite Nachricht in dem Protokoll. Wenn der Anspruchsteller die Infragestellung empfängt, erzeugt er eine Erwiderung. Die Erwiderung bildet die dritte und letzte Nachricht des Protokolls aus. Beim Erzeugen einer Erwiderung gibt es zwei mögliche Optionen:
- a) Der Anspruchsteller verwendet den Schnittstellen-Identifizierer und den gleichen Satz von Komponenten, die er bereits in der ersten Nachricht offenbart hat
interface identifier:= HASH(components)
und versendet die Schnittstellen-Identifizierer und Komponenten (weil diese nicht durch den Prüfer zurückgehalten wurden).
- b) Beim Erzeugen der Erwiderung verwendet der Anspruchsteller den Schnittstellen-Identifizierer und einen früheren Satz von Komponenten, d. h., einen Satz von Komponenten, der bei der Erzeugung der in der ersten Nachricht offengelegten Komponenten verwendet wurde
interface identifier:= HASH(components1)
components 1:= HASH(components2)
und versendet den Schnittstellen-Identifizierer und components2.
-
Diese beiden Ansätze haben ihre Vor- und Nachteile. Der wesentliche Vorteil von a) liegt darin, dass der zweite Satz von Komponenten nicht offenbart zu werden braucht, wodurch dieser für die spätere Verwendung „gesichert” wird. Jedoch liegt der Nachteil darin, dass jeder, der den ersten Satz von Komponenten kennt, die Erwiderung erzeugen kann. Im Gegensatz hierzu macht in b) die Verwendung des zweiten Satzes von Komponenten den Satz von Komponenten zu öffentlicher Information. Nachdem sie einmal verwendet wurden, hat von daher jeder Host, der in der Lage ist, den ersten Satz von Komponenten zu lernen, höchstwahrscheinlich jedenfalls den zweiten Satz von Komponenten gelernt. Von daher liegt nahezu keine zusätzliche Sicherheit vor.
-
Das erste Verfahren a) wird hier bevorzugt, wo der gleiche Satz von Komponenten in der ersten und letzten Nachricht verwendet wird. Dieses Verfahren bietet die folgenden Zusicherungen an:
- – Der Anspruchsteller ist in der Lage, Nachrichten zu empfangen, die an die Adresse gesendet werden, welche verifiziert wird. Diese Eigenschaft kann durch ein einfaches Aufgaben/Erwiderungs-Protokoll erzielt werden.
- – Der Anspruchsteller hat entweder selbst den Satz von Komponenten erzeugt, von welchen der Schnittstellen-Identifizierer erzeugt wurde, oder er hat diese irgendwie gelernt.
-
Von daher liegt der hinzugefügte Sicherheitslevel (im Vergleich mit der grundsätzlichen Aufgabe/Erwiderung) in dem Bedarf, die Komponenten zu kennen (oder zu lernen). Unglücklicherweise ist das Erlernen der Komponenten nicht besonders schwer. Glücklicherweise funktionieren die Komponenten in dem hier beschriebenen Protokoll nur als eine erste Schutzschicht, und der tatsächliche Besitz wird nur durch die öffentliche Schlüsselkryptographie nachgewiesen.
-
Ein Angreifer kann die Komponenten durch zumindest drei verschiedene Verfahren gelernt haben. Er kann sie gelernt haben, weil er auf der gleichen lokalen Verknüpfung wie der Knotenpunkt, der die Komponenten erzeugt hat, liegt, weil er in der Lage ist, den Verkehr zwischen dem Knotenpunkt, der die Komponenten erzeugt hat, und einem anderen entfernten Knotenpunkt abzuhören, oder weil er sie von dem Ursprungsknotenpunkt durch das Ausführen von diesem äußersten Protokoll gelernt hat.
-
Wenn ein Angreifer die Komponenten gelernt hat, weil er auf der gleichen lokalen Verknüpfung wie der Erzeuger der Komponenten liegt, wird er es als schwierig empfinden, den Schnittstellen-Identifizierer zu verwenden. Der ursprüngliche Erzeuger der Komponenten wird noch immer als der Besitzer des Schnittstellen-Identifizierers betrachtet. Wenn der Angreifer versucht, Pakete mit dem gegebenen Schnittstellen-Identifizierer zu versenden, ist er auf einfache Weise nachweisbar. Wenn sich der Ursprungsknotenpunkt zu einer lokale Verknüpfung bewegt, oder wenn sich der Angreifer zu einer anderen lokalen Verknüpfung bewegt, ist die Situation ähnlich dem Fall, wenn der Angreifer die Komponenten durch das Abhören oder durch das Ablaufenlassen des Verifikations-Protokolls erlernt hat.
-
In dem anderen Szenario befinden sich der Angreifer und der tatsächliche Erzeuger der Komponenten auf verschiedenen Verknüpfungen. Von daher werden sie verschiedene Routing- bzw. Leitwegelenkungs-Vorpanne aufweisen. Da der Ursprungsknotenpunkt und der Angreifer verschiedene leitweglenkbare Adressen aufweisen, kann nun der Angreifer, der den gleichen Schnittstellen-Identifizierer wie der Ursprungsknotenpunkt verwendet, als ein Angreifer angesehen werden. Der Angreifer wird in der Lage sein, das grundsätzliche Aufgabe/Erwiderungs-Protokoll, wie es in diesem Abschnitt beschrieben wird, ablaufen zu lassen, jedoch wird es und sollte es nicht viel helfen.
-
Dieses Verfahren ist ferner in dem Ablaufdiagramm von 3 dargestellt.
-
Kombination der Aufgabe/Erwiderungs- und auf öffentlichem Schlüssel basieren Authentikation
-
In dem lokalen Fall war die Fragestellung sehr stark auf die Eindeutigkeit des Schnittstellen-Identifizierers gerichtet. Wie bereits diskutiert, müssen im globalen Fall Schnittstellen-Identifizierer nicht eindeutig sein, und sie sind es im allgemeinen nicht. Von daher gibt es keinen Punkt, der versucht, dieses sicherzustellen oder zu überprüfen. Auf ähnliche Weise hat die Sicherungsschicht- bzw. Verbindungsschicht-Adresse keine Relevanz in dem globalen Ausmaß. Statt dessen ist die Möglichkeit, einen öffentlichen Schlüssel und einen Schnittstellen-Identifizierer miteinander fest zu verbinden, sehr wichtig. Da jedoch Operationen hinsichtlich des öffentlichen Schlüssels, wie etwa das Erzeugen von Signaturen und die Verifikationen von Signaturen, sehr aufwendig sind, ist ein bevorzugtes Verfahren ein Verfahren, wo zunächst die Ein-Wege-Codier-Funktionen als die „Frontbarriere” verwendet wird, welches Angriffe schwieriger macht, und Funktionen hinsichtlich des öffentlichen Schlüssels werden nur danach verwendet. Die Verwendung von Funktionen hinsichtlich des öffentlichen Schlüssels kann direkt Möglichkeit eröffnen für Ressourcen-erschöpfende Dienstverweigerungs-Attacken
-
In dem auf dem öffentlichen Schlüssel basierenden Verfahren verwendet der Anspruchsteller zunächst ein Paket, welches die zu verifizierende Adresse einschließlich des Schnittstellen-Identifizierers und der Komponenten, von welchen der Schnittstellen-Identifizierer erzeugt wurde, enthält. Jedoch enthalten diese Komponenten noch nicht irgendeine Information hinsichtlich des öffentlichen Schlüssels des Anspruchstellers, da von dem Prüfer bzw. Verifizierer nicht erwartet wird, einen Zustand oder eine andersartige Erinnerung zu erzeugen, dass er jemals diese erste Nachricht empfangen hat. Der Prüfer erzeugt eine Aufgabe bzw. Infragestellung wie zuvor. Jedoch kann er zusätzlich zu der Aufgabe bzw. Infragestellung seinen öffentlichen Schlüssel an den Anspruchsteller als ein zusätzliches Informationsteil versenden. In diesem Fall wird der öffentliche Schlüssel am besten als ein selbstsigniertes Zertifikat versendet. Es wird erwartet, dass der Prüfer dieses Zertifikat fertig hat, so dass das Senden hiervon lediglich das Anhängen von diesem an die Nachrichten erfordert.
-
Der nächste Schritt schließt verschiedene Optionen ein, abhängig davon, was erforderlich ist. Wenn der Prüfer seinen öffentlichen Schlüssel anbietet, kann der Anspruchsteller ihn verwenden. In jedem Fall muss der Anspruchsteller seinen eigenen privaten Schlüssel bei der Aufgabe bzw.
-
Infragestellung verwenden, um eine vielgeschichtete Erwiderung effektiv zu erzeugen. Das heißt, der Anspruchsteller zeigt, dass er tatsächlich in der Lage war, die Aufgabe bzw. Infragestellung zu empfangen, und er richtet sich nach dieser. Es muss sehr „billig” für den Prüfer sein, dieses zu verifizieren, da ansonsten ein Angreifer falsche Erwiderungsnachrichten senden kann, wobei die Verarbeitung von diesen viele Betriebsmittel bzw. Ressourcen von dem Prüfer verbrauchen würde.
-
Eine weitere Sicherungsschicht wird dann unter Verwendung des öffentlichen Schlüssels erzeugt. Hier muss der Prüfer zunächst in der Lage sein, zu überprüfen, dass tatsächlich eine Bindung zwischen dem Schnittstellen-Identifizierer und dem öffentlichen Schlüssel besteht. Sobald jedoch die Information über den öffentlichen Schlüssel an den Prüfer übergeben ist, gibt es verschiedene Standard-Optionen, wie dieser zu verwenden ist.
-
Zusammengefasst weist das Verfahren folgende Sicherungsschichten auf:
- 0.1. Der Prüfer kann selbst vor dem Senden einer Aufgabe bzw. Infragestellung sehr günstig verifizieren, dass der Anspruchsteller einen Satz von Komponenten kennt, die dem Schnittstellen-Identifizierer entsprechen.
- 0.2. Der Prüfer ist in der Lage, eine Aufgabe bzw. Infragestellung auf günstige Weise zu konstruieren, ohne die Zustandinformation sichern zu müssen.
- 1.1. Der Prüfer kann auf günstige Weise verifizieren, dass der Anspruchsteller in der Lage war, die Aufgabe bzw. Infragestellung zu empfangen.
- 1.2. Der Prüfer kann auf günstige Weise verifizieren, dass der Anspruchsteller noch immer den gleichen Satz von Komponenten kennt, die in der ersten Nachricht versendet wurden.
- 2.1. Der Prüfer kann auf günstige Art verifizieren, dass der durch den Anspruchsteller gegebene öffentliche Schlüssel tatsächlich eine der Komponenten ist, die bei der Erzeugung des Schnittstellen-Identifizierers verwendet wurden.
- 2.2. Der Prüfer kann (aufwendig) verifizieren, dass der Anspruchsteller den privaten Schlüssel besitzt, der zu dem öffentlichen Schlüssel gehört.
-
Detaillierte Protokoll-Beschreibung
-
Der Mechanismus wird im Hinblick auf Alice und Bob beschrieben, wobei Bob Alice beweisen möchte, dass er die IP-Adresse TA „besitzt”. Das nachfolgende Drei-Nachrichten-Protokoll wird verwendet. Zusätzlich wird ein 0-Schritt benötigt, um zu spezifizieren, wie Bob die Adresse erzeugt hat.
- 0. Bob erzeugt eine neue IP-Adresse TA unter Verwendung des obig dargestellten Verfahrens.
- 1. Bob möchte Alice beweisen, dass er die Adresse TA besitzt. Um dieses zu tun, sendet er Alice eine Nachricht, die das folgende enthält:
MSG1 = <TA, H0, #K+, N>
, wobei:
– TA die IP-Adresse ist, deren Besitz Bob beweisen möchte, die sich aus einem Routing- bzw. einem Leitwegelenkungs-Vorspann RP und einem Schnittstellen-Identifizierer II zusammensetzt,
– H0 ist das H0, welches Bob während der Erzeugung von II verwendete,
– #K+ ist eine Prüfsumme eines öffentlichen Schlüssels, den Bob während der Erzeugung von H0 verwendete, und
– N ist eine Zufallszahl (einstweilig), welche Bob verwenden kann, um die Erwiderung zu identifizieren, die er erwartet, von Alice zu empfangen. Da N irgendeine Zahl sein kann, kann Bob irgendeine Zahl, beispielsweise 0, verwenden, wenn Bob nicht eine Zufallszahl verwenden möchte.
- 2. Alice empfängt das Paket und sendet eine Aufgabe bzw. Infragestellung.
- 2.1. Alice prüft, dass
interface_identifier (TA) = MD5 (H0|64-Bit 0) Bitwiseand 0xDFFFFFFFFFFFFFFF.
Dieses beweist, dass Bob den richtigen Wert von H0 kennt, entweder, weil er ihn selbst erzeugt hat, oder weil er ihn durch Abhören oder durch das Ausführen des bestimmten Protokolls zuvor erlernt hat. Bereits dieses kann als ein schwacher Beweis des Besitzes des Schnittstellen-Identifizierers betrachtet werden.
- 2.2. Alice erzeugt eine Aufgabe bzw. Infragestellung
C:= MD5(P|H0|#K+|N|TA)
, wobei P eine Zufallszahl (eine einstweilige) ist. Eine einzelne einstweilige wird für verschiedene Aufgaben bzw. Infragestellungen dienen, und von daher braucht Alice nicht einen Zustand zu erzeugen.
- 2.3. Alice versendet ein Paket an die Adresse TA, wobei das Paket die Aufgabe bzw. die Infragestellung C enthält. Es ist wichtig, darauf hinzuweisen, dass diese Nachricht an die Adresse TA gesendet wird, da sie prüft, dass Bob durch TA erreichbar ist. Optional kann das Paket ebenso das von Alice selbst signierte Zertifikat CERTA = {IIA, #KA+, NA, HA,0}KA– enthalten.
MSG2 = <N,C> oder MSG2 = <N, C, KA+, CERTA>
- 3. Bob empfängt die Aufgabe bzw. Infragestellung und sendet eine Erwiderung.
- 3.1. Optional prüft Bob N, um zu sehen, dass die Aufgabe bzw. Infragestellung tatsächlich in einer Erwiderung auf sein anfängliches Paket gesendet wurde.
- 3.2. Bob berechnet die Erwiderung
R:= MD5(C|TA|H0|#K+|N).
- 3.3. Optional extrahiert Bob den öffentlichen Schlüssel KA+ von Alice und prüft CERTA.
Zunächst verifiziert Bob das folgende:
– IIA stimmt mit dem Schnittstellen-Identifizierer überein, den Alice als Quell-IP-Adresse in der IP-Kopfzeile verwendete, als sie MSG2 sendete.
– IIA = MD5(H0|64-bit 0) Bitwiseand 0xDFFFFFFFFFFFFFFF
– #KA+ = HASH (KA+)
– CERTA enthält #KA+
– CERTA ist gültig signiert
Wenn diese Verifikation fehlschlägt, fährt Bob fort, als ob die optionalen Teile KA+ und CERTA insgesamt nicht empfangen wurden.
- 3.4. Wenn Bob den öffentlichen Schlüssel von Alice und die Verifikation in Schritt 3.3. erfolgreich empfangen hat, bereitet Bob einen Sicherheitsschlüssel vor, der zwischen ihm und Alice geteilt bzw. gemeinsam verwendet wird.
– Erzeugen eines symmetrischen Sicherheitsschlüssels KAB, der von Alice und Bob gemeinsam verwendet wird.
– Verschlüsseln einer Nachricht unter Verwendung des öffentlichen Schlüssels von Alice, die den neu erzeugten Schlüssel KAB, das II0, welches Bob bei der Erzeugung von H0 verwendete und das H1, welches Bob bei der Erzeugung von H0 verwendete, enthält. Dieses ist der Sicherheitsteil S, den nur Alice wird öffnen können.
– S:= [II0, KAB, H1]KA+
Wenn S nicht erzeugt wird, wird es durch eine leere Zeichenkette ersetzt.
- 3.5. Bob sendet ein Paket an Alice, welches die Erwiderung R enthält. Zusätzlich muss diese Nachricht die gleiche TA, H0, #K+ und N enthalten, wie MSG1 es enthielt.
MSG3 = <TA, H0, #K+, N, R, S>
Optional kann die Nachricht ebenso den öffentlichen Schlüssel K+ von Bob, das Zertifikat CERT und die Signatur SIGN enthalten.
MSG3 = <TA, H0, #K+, N, R, S, K+, CERT, SIGN>
Die Signatur SIGN ist eine Signatur über den Rest der Nachricht, die unter Verwendung von dem privaten Schlüssel K– von Bob erzeugt wird.
- 4. Alice empfängt die Erwiderung und prüft diese.
- 4.1. Da Alice keinen Zustand gesichert hat, wird sie zunächst erneut überprüfen, dass der Schnittstellen-Identifizierer hinsichtlich H0 gültig ist.
interface_identifier (TA) = MD5(H0|64-bit 0) Bitwiseand 0xDFFFFFFFFFFFFFFF.
Wenn dieses nicht gehalten wird, verwirft Alice einfach das Paket.
- 4.2. In Kenntnis von P, berechnet Alice erneut C unter Verwendung von Information von der empfangenen Nachricht
C': = MD5(P|H0|#K+|N|TA)
und prüft, dass die Erwiderung R den erwarteten Wert
R = MD5(C'|TA|H0|#K+|N)
aufweist. Wenn dieses nicht gehalten wird, nimmt sie an, dass der Anspruch von Bob nicht gültig ist. Andererseits ist ein gültiger Anspruch ein Beweis, dass Bob in der Lage ist, Pakete zu empfangen, die an TA gesendet werden.
- 4.3. Wenn die Nachricht den optionalen Teil enthalten hat, d. h., den öffentlichen Schlüssel K+ von Bob, sein Zertifikat CERT und die entsprechende Signatur SIGN, prüft Alice das folgende:
– II in CERT stimmt mit dem Schnittstellen-Identifizierer von TA überein
– #K+ = HASH(K+)
– CERT enthält #K+
– CERT ist gültig signiert
– die Signatur SIGN ist gültig
Dieses beweist, dass der Besitzers des Schlüssels K+ die Adresse TA verwenden möchte und dass Bob den Schlüssel K+ besitzt, da er K– kennt.
- 4.4. Wenn die Nachricht den Sicherheitsteil S enthält, entschlüsselt Alice S unter Verwendung ihres privaten Schlüssels KA–, wobei II0, KAB und H1 offengelegt werden. Alice prüft das folgende:
II = MD5(HASH(H1|II0|#K+)
Dieses beweist, dass der Erzeuger von II einen öffentlichen Schlüssel verwenden wollte, dessen Auszug #K+ ist, und dass er eine Sicherungsschicht- bzw. Verbindungsschicht-Adresse aufweist, die mit II0 übereinstimmt. Dieses schließt die Schleife von II zu K+ und zurück von K+ auf II. Die Tatsache, dass II0 aufgedeckt ist, ist nicht grundsätzlich ein Problem, da die Nachricht verschlüsselt ist.
-
Wenn alles von dem Protokoll bestätigt ist, einschließlich des optionalen Schrittes 4.3., hat Alice gelernt, dass Bob gegenwärtig bei TA erreichbar ist, und dass K+ der öffentliche Schlüssel ist, den Bob verwendete, um TA zu erzeugen. Zusätzlich weiß Alice, dass die Sicherungsschicht- bzw. Verbindungsschicht-Adresse von Bob II0 ist, jedoch macht sie nicht viel mit dieser Information.
-
Zusammengefasst sind die Vorzüge der dargestellten Schemata die folgenden:
- – Die starke Bindung zwischen der Sicherungsschicht- bzw. Verbindungsschicht-Adresse und dem Schnittstellen-Identifizierer, wie in [RFC2373] spezifiziert und in [RFC3041] eingebrochen, wird teilweise auf eine Art erzeugt, die nicht die Ziele hinsichtlich der Privatsphäre von [RFC3041] beeinträchtigt.
- – Eine neue Bindung bzw. Verknüpfung von einem Schnittstellen-Identifizierer zu einem öffentlichen Schlüssel wird erzeugt.
- – Eine Einrichtung, eine Dienstverweigerungs-Attacke während der IPv6-Autokonfiguration [RFC2462] zu blockieren, wird der Duplicate Adress Detektion (DAD) bzw. Zweitadressen-Erfassungs-Prozedur hinzugefügt.
- – Eine Einrichtung, um den Besitz eines Schnittstellen-Identifizierers zum Zwecke des Modifizierens lokaler Leitwegelenkungs- bzw. Routing-Information zu „prüfen”, wie es beispielsweise bei Verknüpfungsaktualisierungen von mobilen IPv6 erforderlich ist, ist dargestellt.
-
Bestimmte Schlüsseleigenschaften der Schemata sind wie folgt:
- – Durch das Ausbilden des Schnittstellen-Identifizierer-Teils einer IPv6-Adresse durch das Anwenden einer Ein-Wege-Funktion an Komponenten, wobei zumindest eine von diesen anfänglich sicher ist, ist eine spätere Offenbarung dieser Komponenten gestattet, um als ein Beweis des Besitzes des Schnittstellen-Identifizierers zu dienen.
- – Es wird vorgeschlagen, die Ein-Wege-Funktion mehrmals an den Komponenten anzuwenden, wodurch Sicherheit gegenüber Attacken bereitgestellt wird, wenn ein Angreifer zuvor offenbarte Komponenten verwendet.
- – Durch das Ausbilden des Schnittstellen-Identifizierer-Teils einer IPv6-Adresse durch das Anwenden einer Ein-Wege-Funktion an Komponenten durch das Spezifizieren semantischer Bedeutung zu diesen Komponenten und durch das Offenbaren dieser Komponenten ist es dem Schnittstellen-Identifizierer gestattet, als ein kryptographisches Kürzel zu dienen, der Werte für semantisch signifikante Komponenten angibt im Namen des Benutzers des Schnittstellen-Identifizierers.
- – Im einzelnen kann die Sicherungsschicht- bzw. Verbindungsschicht-Adresse eine der verwendeten semantisch bedeutungsvollen Komponenten sein. Die Sicherheitsrelevanz des Einführens der Sicherungsschicht- bzw. Verbindungsschicht-Adresse hängt von der einzelnen Implementation bzw. Verwendung der lokalen Verknüpfung ab.
- – Im einzelnen kann ein öffentlicher Schlüssel oder ein Nachrichten-Auszug eines öffentlichen Schlüssels eine der verwendeten, semantisch bedeutungsvollen Komponenten sein. Potentiell hat dieses sehr starke Sicherheitskonsequenzen, da es gestattet, dass ein Schlüssel und eine IPv6-Adresse verknüpft werden ohne irgendeine externe Infrastruktur, wie etwa eine PKI- oder eine AAA-Infrastruktur.
- – Durch das Kombinieren des bekannten Aufgaben/Erwiderungs-Verfahrens bei der Prüfung der Erreichbarkeit mit der Möglichkeit, einen öffentlichen Schlüssel an einen Schnittstellen-Identifizierer zu binden, wird es möglich, über das Internet zu prüfen, dass jemand, der beansprucht, Kontrolle über einen bestimmten Schnittstellen-Identifizierer zu haben, wirklich mit hoher Wahrscheinlichkeit diese Kontrolle hat.
- – Durch Kombinieren der wiederholten Erzeugung des Schnittstellen-Identifizierers von Komponenten ist es gestattet, die Prüfung des Besitzes von einem Schnittstellen-Identifizierer derart durchzuführen, dass der Prüfer einen gewissen Schutz gegenüber einer Ressourcen- bzw. Betriebsmittel-erschöpfenden Dienstverweigerung hat. Dieser DoS-Schutz wird durch Einschränkung der Anzahl der Knotenpunkte, die den Prüfer veranlassen könnten, aufwendige Berechnungen hinsichtlich des öffentlichen Schlüssels durchzuführen, erzeugt.
-
Es wird ersichtlich sein, dass verschiedene Modifikationen an den obig beschriebenen Ausführungsformen, ohne von dem Umfang der vorliegenden Erfindung abzuweichen, durchgeführt werden können.