DE60308251T2 - Vorrichtung zur Bereitstellung von öffentlichen Schlüsselzertifikaten - Google Patents

Vorrichtung zur Bereitstellung von öffentlichen Schlüsselzertifikaten Download PDF

Info

Publication number
DE60308251T2
DE60308251T2 DE60308251T DE60308251T DE60308251T2 DE 60308251 T2 DE60308251 T2 DE 60308251T2 DE 60308251 T DE60308251 T DE 60308251T DE 60308251 T DE60308251 T DE 60308251T DE 60308251 T2 DE60308251 T2 DE 60308251T2
Authority
DE
Germany
Prior art keywords
public key
address
certificate
host
apc
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60308251T
Other languages
English (en)
Other versions
DE60308251D1 (de
Inventor
c/o Canon Kabushiki Kaisha Kazuomi Ohta-ku Oishi
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Canon Inc
Original Assignee
Canon Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Canon Inc filed Critical Canon Inc
Publication of DE60308251D1 publication Critical patent/DE60308251D1/de
Application granted granted Critical
Publication of DE60308251T2 publication Critical patent/DE60308251T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H04L9/3006—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters
    • H04L9/3013—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy underlying computational problems or public-key parameters involving the discrete logarithm problem, e.g. ElGamal or Diffie-Hellman systems
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3263—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving certificates, e.g. public key certificate [PKC] or attribute certificate [AC]; Public key infrastructure [PKI] arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/42—Anonymization, e.g. involving pseudonyms

Description

  • Die vorliegende Erfindung bezieht sich auf eine Vorrichtung zur Bereitstellung eines öffentlichen Schlüsselzertifikats.
  • Mit dem Aufkommen von IPv6 ergibt sich eine Situation, die eine Netzwerkverbindung einer Einrichtung ermöglicht, die bisher nicht mit einem Netzwerk verbunden werden konnte. Ein Beispiel einer derartigen Einrichtung ist eine Digitalkamera für Endnutzer, die direkt mit dem Internet verbunden werden kann.
  • In einem Personalcomputer oder einer Arbeitsplatzstation, die IPv6 unterstützen, wird normalerweise Ethernet® als Schnittstelle zur Verbindung mit dem Netzwerk verwendet, und ein darin vorgesehener IEEE-Identifizierer (MAC-Adresse) wird zur Herstellung einer IPv6-Adresse verwendet.
  • IPv6 ist auf drei Arten vorhanden, das heißt durch eine lokale Verbindungsadresse, eine lokale Stellenadresse und eine (aggregierbare) globale Adresse.
  • Ein Adresssystem, das Einzelheiten dieser Adressen und ein zugehöriges Konstruktionsverfahren enthält, ist beispielsweise in RFC2373 „IP Version 6 Addressing Architecture", RFC2374 „An IPv6 Aggregatable Global Unicast Address Format", RFC2375 „IPv6 Multicast Address Assignment", RFC2350 „Proposed TLA and NLAA Assignment Rule", RFC 2461 „Neighbor Discovery for IP Version 6 (IPv6)" und RFC2462 „IPv6 Stateless Address Autoconfiguration" beschrieben.
  • Werden allerdings Informationen auf feststehende Art und Weise verwendet, die eins-zu-eins einer Hardware entsprechen, wie ein IEEE-Identifizierer (MAC-Adresse), können diese Informationen derart betrachtet werden, als ob sie eins-zu-eins der Vorrichtung oder deren Benutzer entsprechen, und ein Eindringen in die Privatsphäre kann durch die Überwachung von Kommunikationen unter Verwendung dieser Adresse resultieren.
  • Zur Verhinderung dieses Nachteils wird ein Verfahren zur Erzeugung einer zufälligen IPv6-Adresse (genauer gesagt einer Schnittstellen-ID) beispielsweise in RFC3041 „Privacy Extensions for Stateless Autoconfiguration in IPv6" vorgeschlagen.
  • Für den Fall, dass ein zufällig erzeugter Wert bereits verwendet wird, ist auch ein Protokoll (bzw. eine Erweiterung dazu) zur Erfassung eines derartigen Zustands und Berechnung/Erzeugung eines anderen Zufallswerts beschrieben, wodurch ein eindeutiger Zufallswert bestimmt wird.
  • Nun wird eine verschlüsselte Kommunikation unter Verwendung von IPsec betrachtet, wenn die Vorrichtung eine durch ein vorstehend beschriebenes Verfahren erzeugte IPv6-Adresse verwendet.
  • IPsec ist ein Protokoll, bei dem zwei Geräte im Internet geheime Daten teilen, die anderen nicht bekannt sind, und eine Verschlüsselung und Authentifizierung werden beruhend auf diesen geheimen Daten ausgeführt, wobei es bei der Kommunikation erforderlich ist, geheime Daten und gegenseitige IPv6-Adressen sicher zu teilen. Die Daten wie die geheimen Daten und gegenseitigen IPv6-Adressen werden SA („Security association", Sicherheitsassoziation) genannt.
  • Ein Protokoll zur sicheren gemeinsamen Nutzung von SA wird IKE (Internet key exchange) genannt und ist in RFC2409 „The Internet Key Exchange (IKE)" definiert. Eine sichere gemeinsame Nutzung von SA bedeutet, dass SA lediglich mit einem beabsichtigen Gegenüber sicher geteilt wird und erfordert eine sichere Authentifizierung des Gegenübers. IKE definiert vier Authentifizierungsverfahren, das heißt 1) ein Verfahren unter Verwendung eines zuvor geteilten Schlüssels, 2) ein Verfahren unter Verwendung einer digitalen Signatur, 3) eine Authentifizierung mit einer öffentlichen Schlüsselverschlüsselung und 4) ein überarbeitetes Verfahren der Authentifizierung mit einer Verschlüsselung unter Verwendung eines öffentlichen Schlüssels.
  • Wird allerdings eine Situation betrachtet, die den Schutz der Privatsphäre realisiert (wobei keine Identifizierungsinformationen bereitgestellt werden), beispielsweise bei einer IPsec-Kommunikation eines Benutzers mit einem Geschäft, ist es praktisch unmöglich, dass das Geschäft mit einer nicht spezifizierten Vielzahl von Kommunikationsgegenübern vor der IPsec-Kommunikation zuvor geteilte Schlüssel teilt, so dass das Verfahren der Verwendung der zuvor verteilten Schlüssel nicht anwendbar ist.
  • In anderen Verfahren ist es möglich, IKE unter einer Vielzahl nicht spezifizierter Kommunikationspartner auszuführen, wenn Informationen (ein öffentlicher Schlüssel in den meisten Fällen), die zur Verwendung der digitalen Signatur oder der Verschlüsselung mit öffentlichem Schlüssel erforderlich sind, auf sichere Weise verfügbar gemacht werden können. Zu diesem Zweck wird eine Umgebung oder ein System, das PKI („public-key infrastructure", öffentliche Schlüssel-Infrastruktur) genannt wird, als am vielversprechendsten erachtet, und ein öffentliches Schlüsselzertifikat spielt darin die Hauptrolle.
  • Das öffentliche Schlüsselzertifikat ist eine digitale Signatur zum Bestätigen und Sicherstellen einer Übereinstimmung zwischen einer Instanz (einer die Kommunikation ausführenden Instanz, wie ein Computer oder eine Person) und einem öffentlichen Schlüssel dieser Instanz, der durch einen Dritten ausgegeben wird, der für eine Kombination der ID-Informationen usw. der Instanz und des öffentlichen Schlüssels sicher ist. Der sichere Dritte wird CA („certification authority", Zertifizierungsinstanz) genannt, und der öffentliche Schlüssel zur Bestätigung der Instanz der digitalen Signatur von CA ist bekannt.
  • Allerdings enthält das gegenwärtig verwendete öffentliche Schlüsselzertifikat ID-Informationen des Eigentümers (Subjekts), wie FQDN („fully qualified domain name", Voll-Domainname), und kann daher den Schutz der Privatsphäre in diesem Zustand nicht realisieren.
  • Es wird auch ein Verfahren betrachtet, bei dem die ID-Informationen des Subjekts nicht in das öffentliche Schlüsselzertifikat aufgenommen werden, und dieses Zertifikat wird anonymes öffentliches Schlüsselzertifikat genannt.
  • Allerdings ist dieses anonyme öffentliche Schlüsselzertifikat immer noch mit demselben Nachteil wie der vorstehend angeführte IEEE-Identifizierer (MAC- Adresse) behaftet. Das heißt, solange dasselbe anonyme öffentliche Schlüsselzertifikat kontinuierlich verwendet wird, ist es möglich, eine Vielzahl von Kommunikationen (wie IPsec beruhend auf dem öffentlichen Schlüsselzertifikat) zu verbinden, und die Übereinstimmung zwischen dem anonymen öffentlichen Schlüsselzertifikat und dem zugehörigen Subjekt, wenn diese einmal herausgefunden wurde, führt zu einer Verletzung der Privatsphäre, so dass das Niveau des Schutzes der Privatsphäre immer noch schwach ist.
  • In Anbetracht dieser Nachteile wird ein starker Schutz der Privatsphäre als realisierbar betrachtet, wenn es möglich ist, eine andere IPv6-Adresse und ein anderes anonymes öffentliches Schlüsselzertifikat in einer Kommunikation mit einem anderen Gegenüber zu verwenden. Diese werden Einmal-IPv6-Adresse und anonymes öffentliches Einmal-Schlüsselzertifikat genannt. Eine derartige Einmal-IPv6-Adresse kann bei jedem Kommunikationsgegenüber oder bei jedem Paket geändert werden.
  • Bezüglich dieser Einmal-IPv6-Adresse ist RFC3041 „Privacy Extensions for Stateless Address Autoconfiguration in IPv6" wie vorstehend angeführt bekannt, es ist aber kein Verfahren bekannt, das anonyme öffentliche Einmal-Schlüsselzertifikat zu einer Vorrichtung effektiv und sicher auszugeben, die eine IPv6-Kommunikation durchführen kann (die nachstehend IPv6-unterstützende Vorrichtung genannt wird).
  • Auch ist folgender Nachteil vorhanden. Sind die ID-Informationen des Kommunikationsgegenübers nicht bekannt, wird das Kommunikationsgegenüber nur durch die IP-Adresse identifiziert. Da aber ein im LAN des Ethernet® ausgetauschtes Paket für alle Knoten in diesem LAN zugänglich ist, kann in einer Situation einer Kommunikation zwischen Instanzen A und B eine im selben LAN vorhandene arglistige Instanz C sich als Instanz A ausgeben. Das heißt, wird das öffentliche Schlüsselzertifikat der Instanz A zu B zur Ausführung einer IPsec-Kommunikation beruhend auf einem anonymen öffentlichen Einmal-Schlüsselzertifikat zwischen A und B gesendet, kann C sich als A verstellen, indem es das öffentliche Schlüsselzertifikat von A durch das von C ersetzt. Eine derartige Personifizierung ist auch über einen weiteren Bereich möglich, und nicht auf ein LAN beschränkt, indem ein DoS („Denial of Services", Dienstablehnung)-Angriff auf einen DNS (Domain Name System) Server oder Router angewendet wird und falsche Informationen durch einen falschen DNS-Server oder Router während dieses Angriffs bereitgestellt werden. Eine derartige Situation wird durch eine Bestätigung der ID des Gegenübers, wenn diese ID bekannt ist, bewältigt, es ist aber kein Verfahren zur Verhinderung eines derartigen Angriffs in der vorstehend beschriebenen Situation einer anonymen Kommunikation bekannt.
  • In der US 6 233 341 ist ein System zur Bereitstellung eines temporären öffentlichen Schlüssels beschrieben, der durch einen roamenden Benutzer verwendet wird, der ein temporäres Computerterminal benutzt. Die Schlüsselerzeugung des temporären öffentlichen Schlüssels zusammen mit dem entsprechenden privaten Schlüssel wird entweder am vorübergehenden Ort des Client oder an der Stelle eines globalen Server durchgeführt.
  • In der US-Patentanmeldung 2002/0004900 A1 ist eine sichere anonyme Kommunikation zwischen zwei Beteiligten beschrieben, die eine Errichtung einer Identität mit einem Dritten enthält, wobei ein anonymes Zertifikat mit einem ausgewählten Attribut von dem Dritten erhalten wird, und das anonyme Zertifikat dem anderen Beteiligten zum Errichten der anonymen Kommunikation präsentiert wird.
  • In der EP-A-0386867 ist ein kryptografisches System mit öffentlichem Schlüssel beschrieben, das eine Hierarchie verschachtelter Zertifizierungen und Signaturen verwendet, die die Instanz und die Verantwortlichkeitsstufen des Individuums angeben, dessen Signatur zertifiziert wurde.
  • In der US 5 982 898 ist ein Zertifizierungsvorgang beschrieben, bei dem eine Registrierinstanz ein Passwort zu einem Beteiligten ausgibt, wenn sie einmal überzeugt wurde, dass der Beteiligte echt ist. Danach gibt die Zertifizierungsinstanz einen privaten Schlüssel und ein entsprechendes kurzlebiges Zertifikat aus.
  • Eine Aufgabe der Erfindung besteht in der Realisierung einer Einmal-IPv6-Adresse und eines anonymen öffentlichen Einmal-Schlüsselzertifikats, das diese enthält.
  • Eine weitere Aufgabe der Erfindung besteht in der Verminderung einer Rechenlast eines Host bei der Erzeugung eines anonymen öffentlichen Schlüssels.
  • Eine weitere Aufgabe der Erfindung besteht in der effektiven Realisierung eines anonymen öffentlichen Einmal-Schlüsselzertifikats, das ein hohes Niveau an Schutz der Privatsphäre aufweist, mit geringem Aufwand realisierbar ist und eine geringe Belastung bei der Ausführung zeigt.
  • Eine weitere Aufgabe der Erfindung besteht in der Realisierung einer IPsec-Kommunikation durch IKE, wobei ein starker Schutz der Privatsphäre realisiert wird, und eine Tarnung verhindert wird.
  • Eine weitere Aufgabe der Erfindung besteht darin, es einer Ausgabeeinrichtung eines öffentlichen Schlüsselzertifikats zu ermöglichen, die Eindeutigkeit einer IPv6-Adresse leicht zu bestätigen, die durch eine IPv6-unterstützende Vorrichtung verwendet wird, und das öffentliche Schlüsselzertifikat nach dieser Bestätigung auszugeben.
  • Eine weitere Aufgabe der Erfindung besteht in der effizienten und sicheren Ausgabe eines anonymen öffentlichen Einmal-Schlüsselzertifikats, das eine IPv6-Adresse als Ziel der Zertifizierung enthält, wodurch eine prompte Ausgabe ohne Fehler im Ziel der Ausgabe erreicht wird.
  • Eine weitere Aufgabe der Erfindung besteht in der Ausführung von IKE- und IPsec-Kommunikationen unter Verwendung eines anonymen öffentlichen Einmal-Schlüsselzertifikats mit einer IPv6-Adresse als Ziel der Zertifizierung.
  • Eine weitere Aufgabe der Erfindung besteht in der effektiven Realisierung einer IPsec-Kommunikation unter Verwendung eines anonymen öffentlichen Schlüsselzertifikats mit einer zufälligen IPv6-Adresse, die jedes Mal anders ist, wodurch ein starker Schutz der Privatsphäre realisiert und eine Tarnung verhindert werden.
  • Weitere Aufgaben der Erfindung werden aus der folgenden Beschreibung der Ausführungsbeispiele ersichtlich, die lediglich Beispiele der Erfindung sind, wobei auf die beiliegenden Zeichnungen Bezug genommen wird, die zeigen:
  • 1 eine Darstellung eines Protokolls zur Ausgabe eines anonymen öffentlichen Schlüsselzertifikats (für Ethernet® LAN) gemäß einem ersten Ausführungsbeispiels;
  • 2 ein Blockschaltbild eines Ethernet®;
  • 3 eine Darstellung einer Architektur eines Knotens;
  • 4 eine Darstellung einer Architektur einer MAC-Adresse des Ethernet®;
  • 5 eine Darstellung einer Architektur einer Schnittstellen-ID;
  • 6 eine Darstellung einer Architektur einer provisorischen lokalen Verbindungsadresse;
  • 7 eine Darstellung einer Architektur einer Bewerbungsknoten-Multicast-Adresse einer gegebenen provisorischen lokalen Verbindungsadresse;
  • 8 ein Ablaufdiagramm von Vorgängen, bis ein Host DAD abgeschlossen hat;
  • 9 ein Ablaufdiagramm von Vorgängen, bis der Host eine Autokonfiguration abgeschlossen hat;
  • 10 ein Ablaufdiagramm von Vorgängen, bis der Host eine Adresse abruft;
  • 11 ein Ablaufdiagramm von Vorgängen, bis der Host eine Adressenautokonfiguration ausführt und ein anonymes öffentliches Schlüsselzertifikat empfängt;
  • 12 ein Ablaufdiagramm von Vorgängen, bis der Host eine Adresse und ein anonymes öffentliches Schlüsselzertifikat durch DHCP empfängt;
  • 13 eine Darstellung eines Protokolls zur Ausgabe eines anonymen öffentlichen Schlüsselzertifikats (für PPP) gemäß einem dritten Ausführungsbeispiel;
  • 14 ein Blockschaltbild einer Verbindungsaufbau-/ADSL-Verbindung;
  • 15 eine Darstellung eines Protokolls zur Ausgabe eines anonymen öffentlichen Schlüsselzertifikats (für Ethernet® LAN) gemäß einem zweiten Ausführungsbeispiel;
  • 16 eine Darstellung eines allgemeinen Protokolls zur Ausgabe eines anonymen öffentlichen Schlüsselzertifikats; und
  • 17 ein Ablaufdiagramm von Vorgängen, bis der Benutzer ein Zertifikat abruft.
  • (Erstes Ausführungsbeispiel)
  • Dieses Ausführungsbeispiel zeigt einen Fall, in dem ein Host mit dem Internet über ein Ethernet® LAN verbunden ist. Zuerst wird eine aktuelle Situation beschrieben, und das Ausführungsbeispiel wird nachstehend beschrieben.
  • 2 zeigt schematisch eine Verbindungsumgebung (die den Host mit dem Internet über ein Ethernet® LAN verbindet), bei dem die Erfindung anwendbar ist.
  • 2 zeigt eine Umgebung, in dem Hosts 204, 205, 206, die mit einem LAN verbunden sind, auf ein Internet 201 über einen voreingestellten Gateway (gateway) 202 zugreifen. Bei diesem Ausführungsbeispiel ist jeder Host über eine Verbindung verbunden, die insbesondere als Ethernet® angenommen wird. Die Verbindung bedeutet eine Einrichtung oder ein Medium, über das eine damit verbundene Vorrichtung eine Kommunikation ausführen kann, und ist an der unteren Seite der IP-Schicht positioniert. Zusätzlich zu Ethernet® kann die Verbindung eine PPP-Verbindung, X.25, eine Rahmenweitergabe oder ein ATM-Netz sein.
  • Eine mit der Verbindung verbundene IPv6-unterstützende Vorrichtung wird Knoten genannt.
  • 3 zeigt eine typische interne Architektur eines Knotens.
  • Der Knoten kann ein Router oder ein Host sein, und der Router überträgt ein nicht an ihn adressiertes Paket, während der Host eine derartige Übertragung nicht ausführt. Wie aus 3 ersichtlich, ist der Knoten 300 ein Computer mit Netzschnittstellen 301, 302, einer CPU 303, einem ROM 304, einem RAM 305, einer HD (Festplatte) 306, einer Stromversorgung 307, einer Schnittstelle 308 für eine Tastatur-/Zeigeeinrichtung, einer Schnittstelle 309 für einen Monitor, einem Bus 310, usw.
  • Der Router hat viele Netzschnittstellen 301, 302, jedoch hat der Host in den meisten Fällen lediglich eine Netzschnittstelle 301. Die Hosts 204, 205, 206 kommunizieren durch die Netzschnittstelle 301 und über die Verbindung 207 mit einem anderen mit der Verbindung 207 verbundenen Knoten, oder mit einer Stelle im Internet 207 ferner über einen Gateway 202. Der voreingestellte Gateway 202 führt durch die Netzschnittstelle 301 eine Kommunikation mit einem anderen mit der Verbindung 207 verbundenen Knoten und durch die Netzschnittstelle 302 über das Internet 201 aus. Die HD kann in bestimmten Knoten fehlen.
  • Der folgende Verarbeitungsinhalt (die folgende Prozedur) wird als Vorrichtung oder Programm realisiert, und wird durch einen Knoten mit einer derartigen Vorrichtung oder durch einen Knoten ausgeführt, in dem ein derartiges Programm im ROM 304 oder RAM 305 gespeichert ist. Im Fall der Realisierung als Programm führt die CPU 303 des Computers Vorgänge zum Lesen des derartigen Programms und der Zuordnung einer Adresse zu der Schnittstelle 301 über den Bus 310 aus, während bei Bedarf das RAM 305 als Platz für Berechnungen verwendet wird.
  • Im Folgenden wird die Grundlage der Prozedur der Zuordnung einer Adresse zu der Schnittstelle beschrieben.
  • Zuerst wird kurz die Architektur eines Protokolls beschrieben, bei dem jeder Host einen Vorspann einer globalen Adresse oder einer Adresse eines voreingestellten Gateway 202 in der Ethernet® LAN-Umgebung bei diesem Ausführungsbeispiel abruft, und dann wird ein bestimmtes Ausführungsbeispiel der Erfindung beschrieben.
  • 8 zeigt ein Ablaufdiagramm einer durch einen Knoten 300 ausgeführten Prozedur, der mit der in 2 gezeigten Verbindung 207 verbunden ist, wenn die Stromversorgung eingeschaltet wird oder im Fall eines neuen Bootvorgangs. Diese Prozedur wird DAD („duplicate address detection", Duplizierungsadresserfassung) genannt. Im Folgenden werden die Inhalte der Prozedur anhand des Ablaufs in 8 beschrieben, bis der Knoten 300 die DAD abgeschlossen hat.
  • Nachdem der Knoten 300 in Schritt S801 eingeschaltet oder neu gebootet wurde, wird eine Schnittstellen-ID (siehe 5) aus einer MAC-Adresse des Ethernet® (MAC-Adresse) (siehe 4) ausgebildet, die der Schnittstelle 301 zugeordnet ist, und als provisorische lokale Verbindungsadresse (siehe 6) verwendet (Schritt S802).
  • Dann führt der Knoten (Host 300) zur Unterscheidung, ob die provisorische lokale Verbindungsadresse auf der Verbindung eindeutig ist, folgende Prozedur durch.
  • Zuerst wird eine Initialisierung der Schnittstelle 391 ausgeführt. Das heißt, eine Multicastadresse aller Knoten (FF02:1) und eine Bewerbungsknoten-Multicastadresse, die eine provisorische lokale Verbindungsadresse dieser ist, werden der Schnittstelle 301 zugeordnet (7). Infolgedessen empfängt die Schnittstelle 301 beim Auffinden einer Paketadresse zu der Multicastadresse aller Knoten oder zu der Bewerbungsknoten-Multicastadresse der vorübergehenden lokalen Verbindungsadresse dieser ein derartiges Paket als zu dieser Schnittstelle adressiert.
  • Die Zuordnung der Erstgenannten (Multicastadresse aller Knoten) ermöglicht den Empfang von Daten von einem anderen Knoten, der bereits die provisorische lokale Verbindungsadresse verwendet. Ferner ermöglicht die Zuordnung der Zweitgenannten (Bewerbungsknoten-Multicastadresse dieser provisorischen lokalen Verbindungsadresse) die Erfassung des Vorhandenseins eines anderen Knotens, der dieselbe provisorische lokale Verbindungsadresse gleichzeitig verwenden wird.
  • Die Bewerbungsknoten-Multicastadresse einer provisorischen lokalen Verbindungsadresse stellt wie auf Seite 91 von RFC 2461 definiert Daten dar, die durch Addieren niedriger 24 Bits der provisorischen lokalen Verbindungsadresse zu einem Vorspann FF02:0:0:0:0:1:FF00::/104 gebildet werden, und bildet eine Verbindungsmulticastadresse mit lokalem Umfang. Die 6 und 7 zeigen diese Beziehungen. Die vorstehend beschriebene Adresszuordnung wird in Schritt S803 in 8 ausgeführt.
  • Dann wird eine Nachbarbewerbungsnachricht ausgebildet. In der Nachbarbewerbungsnachricht wird eine provisorische lokale Verbindungsadresse eines Beurteilungsziels in einer Zieladresse eingestellt, und eine unbestimmte Adresse (128 Bits sind alle 0) wird in einer IP-Quelle (Sendequellenadresse) eingestellt, und eine angeforderte Knoten-Multicastadresse der provisorischen lokalen Verbindungsadresse des Beurteilungsziels wird in einem IP-Ziel (Zieladresse) eingestellt.
  • Diese Nachbarbewerbungsnachricht wird zum Ethernet® DupAddrDetectTransmits-Mal mit einem Intervall einer Millisekunde von RetransTimer gesendet. Dieser Vorgang wird in Schritt S804 in 8 ausgeführt.
  • Beim Empfang der Nachbarbewerbungsnachricht urteilt der Knoten, dass diese Nachricht von einem Knoten ist, der DAD ausführt, wenn die Sendequellenadresse die unbestimmte Adresse ist.
  • Führt eine Vielzahl von Knoten DAD für dieselbe Adresse aus, empfängt die Vielzahl der Knoten, denen die Bewerbungsknoten-Multicastadresse der provisorischen lokalen Verbindungsadresse dieser zugeordnet ist, eine Vielzahl von Nachbarbewerbungsnachrichten mit derselben Adresse in der Zieladresse (das heißt, eine von ihm selbst gesendete Nachbarbewerbungsnachricht und eine von einem anderen Knoten gesendete Nachbarbewerbungsnachricht, der DAD für dieselbe Adresse ausführt), wodurch eine Duplizierung identifiziert werden kann. In diesem Fall wird diese Adresse nicht von einem Knoten verwendet.
  • Ist die empfangene Nachbarbewerbungsnachricht die von ihm selbst gesendete Nachricht (das heißt, durch Rückkopplung des Multicastpakets), gibt dies nicht das Vorhandensein eines anderen Knotens an, der diese Adresse verwendet oder verwenden wird. Wird zusätzlich zum Empfang der selbst gesendeten Nachbarbewerbungsnachricht eine Nachbarbewerbungsnachricht mit derselben Adresse in der Zieladresse empfangen, wird geurteilt, dass eine Vielzahl von Knoten DAD für dieselbe Zieladresse ausführt.
  • Verwendet ein Knoten, der die Nachbarbewerbungsnachricht empfängt, andererseits bereits eine in der Zieladresse dieser Nachricht enthaltene Adresse, gibt er eine Multicast-Nachbaranzeige, in der diese provisorische lokale Verbindungsadresse in der Zieladresse eingestellt ist, zu einer Multicastadresse aller Knoten zurück. Empfängt der Knoten, der die Nachbarbewerbungsnachricht gesendet hat, eine Multicast-Nachbaranzeige, die zu der Multicastadresse für alle Knoten adressiert ist, und ist deren Zieladresse die provisorische Adresse (Ziel) (was einem Fall „JA" in Schritt S805 in 8 entspricht), kann er beurteilen, dass die provisorische Adresse des Ziels nicht eindeutig (sondern dupliziert) ist.
  • Bestätigt der zuvor beschriebene DAD-Vorgang, dass die provisorische lokale Verbindungsadresse des Ziels auf der Verbindung eindeutig ist (was einem Fall „NEIN" in Schritt S805 in 8 entspricht), wird diese Adresse der Schnittstelle 301 als lokale Verbindungsadresse zugewiesen. Dieser Vorgang entspricht Schritt S806 in 8, und der DAD-Vorgang ist abgeschlossen.
  • Der vorstehende Ablauf von 8 kann im voreingestellten Gateway 202, der einen mit der Verbindung 207 in 2 verbundenen Knoten darstellt, im DHCP-Server und den Hosts 204, 205, 206 an der Netzwerkschnittstelle 301 mit der Verbindung 207 ausgeführt werden.
  • Ein Host in 2, beispielsweise der Host 206, versucht nach der Zuordnung der lokalen Verbindungsadresse zur Schnittstelle 301, erforderliche Informationen zur Bestimmung einer lokalen Stellenadresse oder einer globalen Adresse (diese Informationen werden Routeranzeige, „Router Advertisement" genannt) vom voreingestellten Gateway 202 zu erhalten. Dieser Vorgang ist in 9 gezeigt.
  • Der voreingestellte Gateway 202, der normalerweise Router genannt wird, wird nachstehend als Router 202 vorgestellt. Der Router 202 erhält erforderliche Einstellungen durch einen Administrator und sendet periodisch eine Routeranzeige zur Verbindung 207. Möchte der Host 206 die Routeranzeige sofort erhalten, sendet er Daten, die Routerbewerbung genannt werden, zum Router 202. Sofort nach der Zuordnung der lokalen Verbindungsadresse kann der Host 206 das Vorhandensein des Router 202 nicht identifizieren, so dass die Routerbewerbung als Multicast zu allen Routern auf der Verbindung 207 gesendet wird. In 9 bezeichnet Schritt S901 diesen Vorgang.
  • Der Router 202, der die Routerbewerbung empfangen hat, sendet eine Routeranzeige. Wie durch „JA" in Schritt S902 in 9 angegeben, bestätigt der Host 206, der eine Routeranzeigenachricht empfangen hat, die nur eine zustandslose Adressenautokonfiguration bezeichnet, die Gültigkeit (beispielsweise nicht bereits in der Vorrichtung verwendet) des Vorspanns in der empfangenen Nachricht und weist der Schnittstelle 301 eine Adresse zu, die durch Addieren einer geeigneten Schnittstellen-ID als lokale Stellenadresse oder globale Adresse gebildet wird. Schritt S903 in 9 entspricht diesem Vorgang.
  • Empfängt der Host 206 keine Routeranzeigenachricht, die nur eine zustandslose Adressenautokonfiguration bezeichnet, was durch „NEIN" in Schritt S902 in 9 angegeben ist, teilt sich der Vorgang in die folgenden zwei Fälle, das heißt einen Fall des Empfangs einer Routeranzeige, die sowohl eine zustandslose Adressenautokonfiguration als auch eine Zustands-Adressenautokonfiguration bezeichnet („JR" in Schritt S904), und einen Fall, dass keine Routeranzeige empfangen wird („NEIN" in Schritt S904). Im letzten Fall wird eine Zustands-Adressenautokonfiguration ausgeführt, das heißt nur DHCPv6. Dieser Vorgang entspricht Schritt 906, dessen Einzelheiten in 10 gezeigt sind.
  • Der DHCP-Server 203 wird erforderlichen Einstellungen durch den Administrator unterzogen. Das heißt, seine lokale Verbindungsadresse als Knoten wird der Netzwerkschnittstelle 301 zugeordnet, und es wird auch ein Vorspann usw. für eine lokale Stellenadresse oder eine globale Adresse eingestellt, wie es für einen DHCP-Server erforderlich ist.
  • In Schritt S1001 in 10 sendet der Host 206 eine DHCP-Bewerbungsnachricht zum DHCP-Server. Da der Host 206 den Ort des DHCP-Server 203 nicht kennt, wird diese als Multicast zum DHCP-Server 203 gesendet. Befindet sich der DHCP-Server in einer Verbindung (nicht gezeigt), die von der Verbindung 207 verschieden ist, mit der der Host 206 verbunden ist, wird die DHCP-Bewerbungsnachricht tatsächlich über eine DHCP-Weitergabe (nicht gezeigt) zum DHCP-Server 203 geschickt.
  • Der DHCP-Server 203, der die DHCP-Bewerbungsnachricht empfängt, gibt eine DHCP-Anzeigenachricht als Antwort zum Host 206 zurück. Sie wird zum Host 206 (über die DHCP-Weitergabe im Fall unterschiedlicher Verbindungen) geschickt. Dieser Vorgang bildet einen Schritt S1002. An diesem Punkt wird die Adresse des DHCP-Server 203 für den Host 206 bekannt.
  • In Schritt S1003 sendet der Host 206 eine DHCP-Anforderungsnachricht zum DHCP-Server 203. Beim Empfang der DHCP-Anforderungsnachricht sendet der DHCP-Server 203 eine DHCP-Antwortnachricht zum Host 206.
  • In Schritt S1004 bestimmt der Host 206, der die DHCP-Antwortnachricht empfangen hat, eine lokale Stellenadresse oder eine globale Adresse darin und führt einen für den DAD-Vorgang erforderlichen Vorgang zum Bestätigen aus, ob die Schnittstellen-ID in dieser Adresse eine Verdoppelung zeigt. Das heißt, wie in Schritt S803 wird eine Multicastadresse usw. in der Schnittstelle 301 eingestellt. Dieser Vorgang bildet einen Schritt S1005.
  • Schritt S1006 sendet eine Nachbarbewerbungsnachricht ähnlich der in Schritt S804, und Schritt S1007 unterscheidet, ob eine Nachbarbewerbungsnachricht empfangen wird. Im Fall des Empfangs zeigt eine derartige Adresse eine Verdoppelung, so dass die Abfolge zu Schritt S1003 zum Empfang einer anderen Adresse vom DHCP-Server 203 zurückkehrt und den vorstehend angeführten Prozess wiederholt.
  • Wird keine Nachbarbewerbungsnachricht in Schritt S1007 in 10 empfangen, zeigt die Adresse keine Verdoppelung und der Host 206 ordnet der Schnittstelle 301 eine lokale Stellenadresse oder eine globale Adresse in Schritt S1008 zu, die aus der DHCP-Antwortnachricht bestimmt wird.
  • Somit ist Schritt S906 in 8 abgeschlossen. Die Abfolge wird auf normale Art und Weise beendet, wenn keine Routeranzeige in Schritt S904 empfangen wird.
  • Empfängt Schritt S904 eine Routeranzeigenachricht, die sowohl die zustandslose Adressenautokonfiguration als auch die Zustands-Adressenautokonfiguration bezeichnet, führt Schritt S905 sowohl eine zustandslose Adressenautokonfiguration als auch eine Zustands-Adressenautokonfiguration aus. Der Inhalt des Vorgangs ist der Gleiche wie in den Schritten S903 und S906.
  • Wie vorstehend beschrieben kann der Host 206 mit dem Ethernet© 207 als Schnittstelle die zustandslose Adressenautokonfiguration und die Zustands-Adressenautokonfiguration in einer willkürlichen Kombination verwenden, wodurch die lokale Verbindungsadresse, die lokale Stellenadresse, die globale Adresse, der voreingestellte Gateway, usw. automatisch eingestellt werden.
  • Bei dem vorstehend beschriebenen Protokoll kann durch das Verwenden eines Zufallswerts für die Schnittstellen-ID, Ausführen von DAD für diesen Wert als Ziel und Bestätigen der Eindeutigkeit auf der Verbindung 207 eine globale Einmal-IPv6-Adresse in Kombination mit einem Vorspann der globalen Adresse erhalten werden, die vom Gateway 206 oder vom DHCP-Server 203 erhalten wird. Dieser Vorgang ist in RFC3041 „Privacy Extensions for Stateless Address Autoconfiguration in IPv6" beschrieben.
  • Im Folgenden wird ein Ausführungsbeispiel der Erfindung beschrieben, bei dem die vorstehenden Vorgänge (das Protokoll) erweitert sind, um die Verwendung eines anonymen öffentlichen Einmal-Schlüsselzertifikats zu ermöglichen. Zuerst werden ein Beispiel eines anonymen öffentlichen Schlüsselzertifikats sowie ein Protokoll zur effizienten Ausgabe des Zertifikats beschrieben.
  • Ein Konzept und ein bestimmtes Realisierungsverfahren für das anonyme öffentliche Schlüsselzertifikat sind von Kazuomi Oishi, Masahiro Mambo und Eiji Okamoto „Anonymous Public Key Certificates and their Applications", IEICE Transactions on Fundamentals of Electronics, Communications and Computer Sciences, E81-A, 1, Seiten 56-64, 1998 vorgeschlagen, und ein grundlegendes Realisierungsverfahren ist im US Patent Nr. 6,154,841 offenbart. Bei diesem Verfahren wird die Anonymität des Zertifikats durch den Berechnungsumfang sichergestellt.
  • Zur Bereitstellung einer stärkeren Anonymität wird ein Verfahren der Realisierung eines anonymen öffentlichen Schlüsselzertifikats mit unbedingter Anonymität von Kazuomi Oishi „Unconditionally anonymous public key certificates", The 2000 Symposium on Cryptography and Information Security, SCIS2000-C32, 2000 beschrieben.
  • Erfindungsgemäß kann jedes Schema verwendet werden, das in der vorstehenden Druckschrift durch Kazuomi Oishi, Masahiro Mambo und Eiji Okamoto, „Anonymous Public Key Certificates and their Applications" beschrieben ist. Wird eine geringerwertige Wirksamkeit toleriert, kann Schema 1, Schema 2 oder Schema 3 der vorstehenden Druckschrift angewendet werden, wobei diese auch in der Erfindung enthalten sind. Das vorliegende Ausführungsbeispiel zeigt einen Fall, in dem ein anonymes öffentliches Schlüsselzertifikat mit Berechnungsanonymität verwendet wird. Für Einzelheiten wird auf die vorstehende Druckschrift verwiesen, und das Protokoll des vorliegenden Ausführungsbeispiels wird beschrieben, nachdem für die Beschreibung erforderliche Symbole definiert wurden.
  • Eine Instanz CA, die ein anonymes öffentliches Schlüsselzertifikat ausgibt, bestimmt große Primzahlen p und q als gemeinsame Parameter. Die Primzahl q kann p-1 teilen. Ein Generator g einer Größenordnung q und eine Hash-Funktion H werden bestimmt. Eine geheime Zufallszahl s_ca (zwischen 1 und einschließlich q) wird erzeugt und v_ca=g^(s_ca) mod p wird berechnet. A = (B)^(C) mod D bedeutet eine Berechnung für ganze Zahlen A, B, C, und eine Teilung von B hoch C durch D zum Erhalten eines Rests A. Die Instanz CA legt p, q, g, H und va ca offen. Andererseits erzeugt eine Instanz i, die das anonyme öffentliche Schlüsselzertifikat verwendet, eine geheime Zufallszahl s_i (zwischen 1 und einschließlich q) und berechnet v_i=g^(s_i) mod p.
  • s_ca und s_i werden geheime Schlüssel genannt, während v_ca und v_i (und offengelegte Parameter) öffentliche Schlüssel genannt werden, wobei die geheimen Schlüssel derart gespeichert werden, dass sie keinem anderen offenbart werden.
  • Beim Beginn der Verwendung des anonymen öffentlichen Schlüsselzertifikats registriert die Instanz i ihren Instanznamen (Benutzernamen), ein Passwort und den öffentlichen Schlüssel v_i in der Instanz CA. Die Instanz CA bestätigt bei Bedarf die Identität der Instanz i physikalisch oder dergleichen und speichert den Instanznamen (Benutzernamen), ein Passwort und den öffentlichen Schlüssel v_i.
  • Bei der Vergabe eines anonymen öffentlichen Schlüsselzertifikats erzeugt die Instanz CA eine Zufallszahl r (zwischen 1 und einschließlich q) und berechnet (g', v_i')=(g^r mod p, (v_i)^(r) mod p). X seien Verwaltungs-/Attributinformationen eines Zertifikats. Dann enthält X die vorstehend angeführten öffentlichen Parameter, die Gültigkeitsperiode des anonymen öffentlichen Schlüsselzertifikats, ein öffentliches Schlüsselzertifikat für den öffentlichen Schlüssel v_ca, usw. Eine digitale Signatur wird für eine Nachricht (deren Hash-Wert) erzeugt, die (g', v_i') und X enthält. Ein digitales Signaturschema beruhend auf einem diskreten Logarithmusproblem kann verwendet werden, beispielsweise eine Schnorr-Signatur. Bei diesem Ausführungsbeispiel wird der geheime Schlüssel s_ca verwendet. Diese digitale Signatur wird durch Sig_ca(g', v_i', X) dargestellt.
  • Ein anonymes öffentliches Schlüsselzertifikat APC_ca(i), das durch die Instanz CA zu der Instanz i ausgegeben wird, ist APC_ca(i) = (g', v_i', X, Sig_ca(g', v_i', X)).
  • Beim Empfang der Ausgabe des anonymen öffentlichen Schlüsselzertifikats APC_ca(i)=(g', v_i', X, Sig_ca(g', v_i', X)) extrahiert die Instanz i (g', v_i', X) und berechnet den zugehörigen Hash-Wert (beispielsweise H(g'|v_i'|X), wobei „|" ein Verkettung bezeichnet), wodurch bestätigt wird, ob Sig_va(g', v_i', X) eine korrekte digitale Signatur für den Hash-Wert ist, indem der öffentliche Schlüssel v_ca verwendet wird. Ferner wird v_i'=(g')^(s_i) mod p bestätigt. Werden diese als richtig bestätigt, kann eine Verschlüsselung mit öffentlichem Schlüssel oder eine digitale Signatur beruhend auf einem diskreten Logarithmusproblem unter Verwendung von g' und v_i' (und des gemeinsamen Parameters p) als öffentliche Schlüssel und s_i als geheimer Schlüssel verwendet werden. Somit enthält das anonyme öffentliche Schlüsselzertifikat APC_ca(i) eine Gültigkeitsperiode in den Verwaltungs-/Attributinformationen X, und die öffentlichen Schlüssel g' und v_i', die im anonymen öffentlichen Schlüsselzertifikat APC_ca(i) enthalten sind, sind die öffentlichen Schlüssel derselben Instanz, werden aber mit der Zeit geändert.
  • Eine Instanz, die das anonyme öffentliche Schlüsselzertifikat APC_ca(i)=(g', v_i', X, Sig_ca(g', v_i', X)) empfängt, extrahiert (g', v_i', X) und berechnet einen zugehörigen Hash-Wert, wodurch bestätigt wird, ob Sig_ca(g', v_i', X) eine korrekte digitale Signatur für den Hash-Wert ist, wobei der öffentliche Schlüssel v_ca verwendet wird. Bei der Bestätigung als korrekt wird eine Verschlüsselung mit öffentlichem Schlüssel oder eine Authentifizierung einer digitalen Signatur beruhend auf einem diskreten Logarithmusproblem unter Verwendung von g' und v_i' (und einem gemeinsamen Parameter p) als öffentliche Schlüssel ausgeführt.
  • Die Legitimität des öffentlichen Schlüssels v_ca selbst kann durch die Ausgabe eines öffentlichen Schlüsselzertifikats für den öffentlichen Schlüssel v_ca durch Übermittelung des öffentlichen Schlüssels v_ca zu einer oberen und überzeugenderen Instanz CA bestätigt werden, beispielsweise VeriSign, die einen kommerziellen Zertifizierungsdienst anbietet. Die Verwaltungs-/Attributinformationen X des anonymen öffentlichen Schlüsselzertifikats enthalten ein öffentliches Schlüsselzertifikat für den öffentlichen Schlüssel v_ca. Die Legitimität des öffentlichen Schlüssels v_ca selbst kann durch dieses öffentliche Schlüsselzertifikat für den öffentlichen Schlüssel v_ca bestätigt werden. Dies entspricht einer hierarchischen Konfiguration der Instanz CA, und ermöglicht die Ausbildung einer geeigneten PKI (Public-key Infrastructure).
  • Vorstehend wurde ein Signatursystem beruhend auf der Schwierigkeit des diskreten Logarithmusproblems bei einer Multiplikationsgruppe (mod p) beschrieben, jedoch ist es auch möglich, ein Signatursystem beruhend auf der Schwierigkeit des diskreten Logarithmusproblems bei einer elliptischen Kurve zu verwenden, wobei in diesem Fall die Wirksamkeit weiter verbessert werden kann, da dieselbe Sicherheitsstufe mit einem Schlüssel einer geringeren Anzahl an Bits verglichen mit dem Fall der Multiplikationsgruppe erreicht werden kann.
  • Nun wird ein Fall der Anwendung des vorstehend beschriebenen anonymen öffentlichen Schlüsselzertifizierungsproblems in der in 2 gezeigten Umgebung beschrieben.
  • Der voreingestellte Gateway 202 bzw. der DHCP-Server 203 ist die Instanz CA zur Ausgabe des anonymen öffentlichen Schlüsselzertifikats, während der Host 206 (oder dessen Benutzer) die Instanz ist, die das anonyme öffentliche Schlüsselzertifikat verwendet. Andererseits kann ein exklusiver CA-Server nur zur Ausführung der Ausgabe des Zertifikats vorgesehen sein. Im Folgenden wird ein Fall beschrieben, dass der voreingestellte Gateway 202 als Instanz CA dient, die das anonyme öffentliche Schlüsselzertifikat ausgibt, und eine zufällige IPv6-Adresse ist in dem Zertifikat enthalten, wobei es aber auch möglich ist, dass der DHCP-Server oder exklusive CA-Server die Instanz CA darstellt, die das anonyme öffentliche Schlüsselzertifikat ausgibt, oder dass die zufällige IPv6-Adresse nicht in dem Zertifikat enthalten ist. Der voreingestellte Gateway 202 versieht den Host 206 mit einem Vorspann der globalen Adresse von IPv6. Der voreingestellte Gateway 202, der wie vorstehend beschrieben oft ein Router ist, wird Router 202 genannt.
  • Der Administrator des Router 202 bestimmt und legt die vorstehend angeführten öffentlichen Parameter p, g usw. offen. Er bestimmt auch den öffentlichen Schlüssel v_ca für die Instanz CA, die das anonyme öffentliche Schlüsselzertifikat ausgibt, und schickt ihn zu einer höher stehenden bzw. überzeugenderen Instanz CA (209 in 2), beispielsweise VeriSign, was einen kommerziellen Autentifizierungsdienst bereitstellt, um ein öffentliches Schlüsselzertifikat für den öffentlichen Schlüssel v_ca zu empfangen.
  • Der Router (Gateway) 202 hat eine Funktion der Steuerung der Übertragung von Paketen und wird unter der Verwaltung des Administrators betrieben, um keinen ungeeigneten Paketaustausch zwischen einem vom Router verwalteten Unternetzwerk und der äußeren Umgebung zu bewirken. Zur Verbindung eines Unternetzwerks mit dem Internet registriert der Administrator des Unternetzwerks die Identität bei JPNIC (im Fall von Japan) und empfängt eine Zuordnung eines Satzes von IP-Adressen. Der Router im Unternetzwerk wird daher vom Administrator mit einer klaren Verwaltungsverantwortlichkeit verwaltet und es wird von ihm erwartet, dass er Aufwand für den Betrieb und die Verwaltung auch im Hinblick auf die Sicherheit treibt, und kann als geeignet für die Instanz CA zur Ausgabe des anonymen öffentlichen Schlüsselzertifikats betrachtet werden.
  • Möchte ein Benutzer i auf das LAN zugreifen, erzeugt der Benutzer seinen eigenen geheimen Schlüssel s_i unter Verwendung der öffentlichen Parameter p, g, usw., berechnet einen entsprechenden öffentlichen Schlüssel v_i und gibt dem Administrator des LAN (Administrator des Router 202) den Benutzernamen, das Passwort und den öffentlichen Schlüssel v_i an. Der Administrator des LAN (Administrator des Router 202) erlaubt den Zugang, nachdem er eine Identifizierung des Benutzers i und eine Passwortüberprüfung entsprechend seiner Betreiberpolitik ausgeführt hat. Der Administrator führt eine Registrierung im RAM 304 oder auf der HD 306 derart durch, dass der entsprechende öffentliche Schlüssel aus dem Instanznamen abgerufen werden kann. Die öffentlichen Parameter p, g, und so weiter und der öffentliche Schlüssel v_i und insbesondere der geheime Schlüssel s_i werden vom Benutzer i verwaltet und werden im Host 206 sicher verwendbar gemacht.
  • 1 zeigt ein Protokoll dieses Ausführungsbeispiels, das nach den vorstehenden Vorbereitungen ausgeführt wird. 1 zeigt ein Ausdgabeprotokoll für ein anonymes öffentliches Schlüsselzertifikat zwischen einer Instanz, die das anonyme öffentliche Schlüsselzertifikat verwendet (IPv6-Terminal, benutzt vom Benutzer i), die durch den Host 206 gebildet wird, und eine Instanz CA, die das anonyme öffentliche Schlüsselzertifikat ausgibt, die durch den Router 202 gebildet wird. Somit dient eine IPv6-unterstützende Vorrichtung 202, die in der lokalen Verbindung 207 vorhanden ist, als Ausgabeeinrichtung des öffentlichen Schlüsselzertifikats.
  • Da es erforderlich ist, die Instanz zu bestimmen, um das anonyme öffentliche Schlüsselzertifikat auszugeben, wird ein Bestimmungs-(Authentifizierungs-) Protokoll zwischen dem Router 202 und der Instanz (in diesem Fall dem Host 206) durchgeführt. Bei diesem Ausführungsbeispiel wird ein System beruhend auf einer Verschlüsselung mit einem öffentlichen Schlüssel im Folgenden beschrieben. Die Vorgänge werden entsprechend einem Ablauf in 1 beschrieben.
  • In Schritt S101 erzeugt der Host 206 eine Zertifikatbewerbung. Die Zertifikatbewerbung ist eine Nachricht, die ein anonymes öffentliches Schlüsselzertifikat anfordert, und wird in einem Format erzeugt, das vom Router 202 verstanden werden kann, dass es ein anonymes öffentliches Schlüsselzertifikat anfordert und dass es die Schnittstellen-ID des Host 206 enthält. Der Inhalt wird aus dem Instanznamen (Benutzernamen), dem Passwort und einer Seriennummer berechnet. Die Seriennummer wird beispielsweise durch Verknüpfung einer lokalen IPv6-Verbindungsadresse des Host 206, einer lokalen IPv6-Verbindungsadresse des voreingestellten Gateway 202 und der aktuellen Zeit gebildet. Zur Verhinderung eines Antwortangriffs und eines betrügerischen Auftretens enthält die Zertifikatbewerbung eine digitale Signatur (Authentifizierungssignatur) (Sig_i(Hash (Instanzname, Passwort, Seriennummer))), die durch Eingeben des Instanznamens (Benutzernamens), des Passworts und der Seriennummer in die Hash-Funktion unter Verwendung des geheimen Schlüssels s_i erzeugt wird.
  • Dann sendet der Host 206 in Schritt S102 die Zertifikatbewerbung zum Router 202 über die Verbindung 207.
  • In Schritt S103 ruft der Router 202 beruhend auf dem Instanznamen (Identifizierer der Kommunikationsvorrichtung (Host) 206), der in der in Schritt S102 empfangenen Zertifikatbewerbung enthalten ist, den registrierten öffentlichen Schlüssel v_i vom RAM 305 oder der HD 306 ab und bestätigt die Legitimität der Authentifizierungssignatur unter Verwendung dieses öffentlichen Schlüssel. Insbesondere werden der Instanzname (Benutzername), das Passwort und die Seriennummer in die Hash-Funktion zum Erhalten eines Hash-Werts eingegeben, und es wird durch den öffentlichen Schlüssel v_i bestätigt, dass die Authentifizierungssignatur dafür eine geeignete digitale Signatur ist.
  • Nach der Authentifizierung wird eine globale IPv6-Adresse aus dem Vorspann der globalen IPv6-Adresse, die dem Router 202 zugeordnet ist, und der Schnittstellen-ID des Host 206 erzeugt, und ein anonymes öffentliches Schlüsselzertifikat APC_ca(i) mit einer Lebensdauer (Gültigkeitsperiode, beispielsweise 24 Stunden) wird erzeugt. Insbesondere enthalten die Verwaltungs-/Attributinformationen X des Zertifikats in APC_ca(i)=(g', v_i', X, Sig_ca(g', v_i', X)) wie vorstehend beschrieben die globale IPv6-Adresse und die Lebensdauer. Die Lebensdauer (Gültigkeitsperiode) der globalen IPv6-Adresse ist nicht unbedingt dieselbe wie die Gültigkeitsperiode des anonymen öffentlichen Schlüsselzertifikats.
  • Dann sendet der Router 202 in Schritt S104 die Zertifikatanzeige, die durch den Vorspann der globalen IPv6-Adresse, die Adresse des voreingestellten Router 202 und das anonyme öffentliche Schlüsselzertifikat APC_ca(i) gebildet ist, zu dem authentifizierten Host 206 über die Verbindung 207. Gemäß einem Ausführungsbeispiel der Erfindung wird diese Zertifikatanzeige nach der Verschlüsselung mit dem registrierten öffentlichen Schlüssel gesendet.
  • In Schritt S105 extrahiert der Host 206 den Vorspann aus der empfangenen Zertifikatanzeige, erzeugt die globale IPv6-Adresse durch Anfügen der Schnittstellen-ID und bestätigt auch die Legitimität des anonymen öffentlichen Schlüsselzertifikats APC_ca(i). Somit enthält das anonyme öffentliche Schlüsselzertifikat APC_ca(i) eine Gültigkeitsperiode in den Verwaltungs-/Attributinformationen X, und die öffentlichen Schlüssel g' und v_i' im anonymen öffentlichen Schlüsselzertifikat APC_ca(i) sind die öffentlichen Schlüssel derselben Instanz i (Host 206), werden aber mit der Zeit ausgetauscht. Der Host 206 führt das in 1 gezeigte anonyme öffentliche Schlüsselzertifikatausgabeprotokoll für jede Sitzung oder Übertragung eines Kommunikationspakets durch, wodurch die zu verwendenden öffentlichen Schlüssel g' und v_i' ausgetauscht werden.
  • 11 zeigt ein Ablaufdiagramm des Hostbetriebs im erweiterten Protokoll, bei dem das vorstehend beschriebene Protokoll mit einem bekannten Sende-/Empfangsprotokoll für die Routerbewerbung und die Routeranzeige kombiniert ist.
  • In Schritt S1101 in 11 sendet der Host 206 über die Verbindung 207 eine Routerzertifikatbewerbungsnachricht, die sowohl die in Schritt S901 in 9 gesendete Routerbewerbungsnachricht als auch die in Schritt S102 in 1 gesendete Zertifikatbewerbung enthält. In Schritt 51102 empfängt er eine Routerzertifikatanzeigenachricht, die sowohl die in Schritt S902 in 9 empfangene Routeranzeigenachricht als auch die in Schritt S104 in 1 empfangene Zertifikatanzeige enthält.
  • Im Fall des Empfangs der Routerzertifikatanzeigenachricht über die Verbindung 207, das heißt „JA" in Schritt S1102, weist der Host 206 in Schritt S1103 wie in Schritt S903 in 9 eine Adresse, die durch Addieren der Schnittstellen-ID zu dem Vorspann in der Routeranzeigenachricht gebildet ist, der Schnittstelle 301 als lokale Stellenadresse oder globale Adresse zu, und führt auch Schritt S105 in 1 aus, wodurch das anonyme öffentliche Schlüsselzertifikat APC_ca(i) mit den öffentlichen Schlüsseln g' und v_i' erhalten wird.
  • Mit dem vorstehend beschriebenen Protokoll wird die Ausgabe einer Einmal-IPv6-Adresse und eines entsprechenden anonymen öffentlichen Einmal-Schlüsselzertifikats zu dem Host 206 durch einfache Erhöhung der Daten ohne Änderung der Anzahl der Schritte des herkömmlichen Protokolls ermöglicht.
  • Dient der DHCP-Server 203 als Instanz CA zur Ausgabe des anonymen öffentlichen Schlüsselzertifikats an Stelle des Router 202, führt ein Schritt S1106 in 11 ein dem in 1 ähnliches Protokoll aus. In diesem Fall versieht der DHCP-Server 203 den Host 206 mit dem Vorspann für die globale Adresse. In diesem Fall führt der Host in Schritt S1106 in 11 ein erweitertes Protokoll für eine Zustands-Adressenautokonfiguration aus, das heißt, ein Protokoll zur Erfassung der Adresse und des Zertifikats vom DHCP-Server. 12 zeigt ein Ablaufdiagramm der Vorgänge dieses Protokolls.
  • Dieses Ablaufdiagramm unterscheidet sich von dem in 10 in zwei Punkten, das heißt in den Schritten S1203 und S1204.
  • In Schritt S1203 wird über die Verbindung 207 eine DHCP-Zertifikatanforderungsnachricht gesendet, die sowohl die in Schritt S1003 in 10 gesendete DHCP-Anforderungsnachricht als auch Daten enthält, die der in Schritt S102 in 1 gesendeten Zertifikatbewerbung entsprechen (die Daten sind unterschiedlich in der Hinsicht, dass CA nicht der Router 202 sondern der DHCP-Server 203 ist).
  • Beim Empfang der DHCP-Zertifikatanforderungsnachricht erzeugt der DHCP-Server 203 eine DHCP-Zertifikatantwortnachricht und sendet die erzeugte DHCP-Zertifikatantwortnachricht über die Verbindung 207. Dann erzeugt der DHCP-Server 203 ein anonymes öffentliches Schlüsselzertifikat APC_ca(i) wie in Schritt S103 in 1 und nimmt in die DHCP-Zertifikatantwortnachricht den Vorspann der globalen Adresse des DHCP-Server 203, die Adresse des DHCP-Server 203, Daten, die der Zertifikatanzeige entsprechen, die durch das anonyme öffentliche Schlüsselzertifikat APC_ca(i) gebildet wird, und die DHCP-Antwortnachricht von Schritt S1004 in 10 auf.
  • In Schritt S1204 empfängt der Host 206 die DHCP-Zertifikatantwortnachricht, die sowohl die in Schritt S1004 in 1 empfangene DHCP-Antwortnachricht als auch Daten enthält, die der in Schritt S104 in 1 empfangenen Zertifikatanzeige entsprechen (die Daten sind dahingehend verschieden, dass CA nicht der Router sondern der DHCP-Server ist). Somit bestimmt der Host die lokale Stellenadresse oder die globale Adresse aus der DHCP-Antwortnachricht und erhält das anonyme öffentliche Schlüsselzertifikat APC_ca(i), das die öffentlichen Schlüssel g' und v_i' enthält.
  • Mit dem vorstehend beschriebenen Protokoll ist es möglich, zu dem Host 206 eine Einmal-IPv6-Adresse und ein entsprechendes anonymes öffentliches Einmal-Schlüsselzertifikat durch einfache Erhöhung der Daten auszugeben, ohne die Anzahl der Schritte des herkömmlichen Protokolls zu ändern.
  • Fungieren sowohl der Router 202 als auch der DHCP-Server 203 als CA entspricht dies einer Situation des Empfangs der Routerzertifikatanzeigenachricht, die sowohl keinen Zustand als auch einen Zustand in Schritt S1104 in 11 bezeichnet (Fall „JA"), und in diesem Fall ist es möglich, die vorstehend beschriebenen zwei erweiterten Protokolle mit willkürlicher Kombination anzuwenden, wodurch eine automatische Einstellung und Erfassung der lokalen Verbindungsadresse, der lokalen Stellenadresse, der globalen Einmal-IPv6-Adresse, des entsprechenden anonymen öffentlichen Einmal-Schlüsselzertifikats und des voreingestellten Gateway erreicht wird. In diesem Fall entsprechen der Router 202 und der DHCP-Server 203 einer Kommunikationsvorrichtungsgruppe, die das anonyme öffentliche Schlüsselzertifikat bereitstellt.
  • Der Host 206 führt das Protokoll zum Empfang des anonymen öffentlichen Schlüsselzertifikats wie in 11 gezeigt für jedes Kommunikationsgegenüber, für jede Sitzung beziehungsweise für jede Übertragung eines Kommunikationspakets aus, wobei die zu verwendenden öffentlichen Schlüssel g' und v_i' ausgetauscht werden.
  • Es wurde ein Ausführungsbeispiel beschrieben, bei dem der DHCP-Server 203 den Vorspann der IPv6-Adresse bereitstellt, es kann aber auch ein Ausführungsbeispiel durch dieses Protokoll realisiert werden, bei dem die IPv6-Adresse selbst bereitgestellt wird, abgesehen davon, dass die Adresse anstelle des Vorspanns gesendet wird, und dass der Ablauf der Adressenerzeugung durch den Host entbehrt wird.
  • (Zweites Ausführungsbeispiel)
  • Bei dem ersten Ausführungsbeispiel sendete der voreingestellte Gateway (Router), der als die Instanz CA dient, das anonyme öffentliche Schlüsselzertifikat und die Zertifikatanzeige mit dem Vorspann zu dem Host nach der Authentifizierung des Host. Bei diesem Ausführungsbeispiel wird ein Fall beschrieben, in dem das Senden des Vorspanns und die Ausgabe des anonymen öffentlichen Schlüsselzertifikats unabhängig sind.
  • Wie bei dem ersten Ausführungsbeispiel ist der voreingestellte Gateway 202 oder der DHCP-Server 203 die Instanz CA zur Ausgabe des anonymen öffentlichen Schlüsselzertifikats, während der Host 206 (beziehungsweise sein Benutzer) die Instanz ist, die das anonyme öffentliche Schlüsselzertifikat verwendet. Es kann auch ein exklusiver CA-Server nur zur Ausführung der Ausgabe des Zertifikats vorgesehen sein. Nachstehend ist ein Fall beschrieben, bei dem der voreingestellte Gateway 202 als Instanz CA dient, die das anonyme öffentliche Schlüsselzertifikat ausgibt, und eine Zufalls-IPv6-Adresse ist in dem Zertifikat enthalten, wobei es aber auch möglich ist, dass der DHCP-Server oder der exklusive CA-Server die Instanz CA ist, die das anonyme öffentliche Schlüsselzertifikat ausgibt, oder dass die Zufalls-IPv6-Adresse nicht im Zertifikat enthalten ist. Der voreingestellte Gateway 202 versieht den Host 206 mit einem Vorspann der globalen Adresse von IPv6. Der voreingestellte Gateway 202, der wie vorstehend beschrieben oft ein Router ist, wird Router 202 genannt.
  • Der Administrator des Router 202 bestimmt und legt die vorstehend beschriebenen öffentlichen Parameter p, g, usw. offen. Er bestimmt auch den öffentlichen Schlüssel v_ca für die Instanz CA, die das anonyme öffentliche Schlüsselzertifikat ausgibt, und übermittelt ihn zu einem höherstehenden oder überzeugenderen CA (209 in 2), beispielsweise VerySign, was einen kommerziellen Authentifizierungsdienst bereitstellt, um ein öffentliches Schlüsselzertifikat für den öffentlichen Schlüssel v_ca zu empfangen.
  • Meldet sich ein Benutzer i für einen Zugang zu dem LAN an, erzeugt der Benutzer seinen eigenen geheimen Schlüssel s_i unter Verwendung der öffentlichen Parameter p, g, und so weiter, berechnet einen entsprechenden öffentlichen Schlüssel v_i und übermittelt den Benutzernamen, das Passwort und den öffentlichen Schlüssel v_i zum Administrator des LAN (Administrator des Router 202). Der Administrator des LAN (Administrator des Router 202) erlaubt nach der Ausführung einer Identifizierung des Benutzers i und einer Passwortüberprüfung entsprechend seiner Betreiberpolitik den Zugang. Der Administrator führt eine Registrierung im RAM 304 oder der HD 306 derart durch, dass der entsprechende öffentliche Schlüssel aus dem Instanznamen abgerufen werden kann. Die öffentlichen Parameter p, g, und so weiter und der öffentliche Schlüssel v_i und insbesondere der geheime Schlüssel s_i werden vom Benutzer i verwaltet und werden im Host 206 sicher verwendbar gemacht.
  • 15 zeigt ein Protokoll dieses Ausführungsbeispiels, das nach den vorstehend angeführten Vorbereitungen ausgeführt wird. 15 zeigt ein Ausgabeprotokoll für ein anonymes öffentliches Schlüsselzertifikat zwischen einer das anonyme öffentliche Schlüsselzertifikat verwendenden Instanz (IPv6-Terminal, vom Benutzer i verwendet), die durch den Host 206 gebildet wird, und einer Instanz CA, die ein IPv6-Terminal ist, das den Vorspann bereitstellt, das anonyme öffentliche Schlüsselzertifikat ausgibt und vom Router 202 gebildet wird. Somit dient eine IPv6-unterstützende Vorrichtung 202, die in der lokalen Verbindung 207 vorhanden ist, als Ausgabeeinrichtung des öffentlichen Schlüsselzertifikats.
  • Da es erforderlich ist, die Instanz zu bestimmen, um das anonyme öffentliche Schlüsselzertifikat auszugeben, wird ein Bestimmungs-(Authentifizierungs-) Protokoll zwischen dem Router 202 und der Instanz (dem Host 206 in diesem Fall) ausgeführt. Bei diesem Ausführungsbeispiel wird ein System beruhend auf einer Verschlüsselung mit öffentlichem Schlüssel wie folgt beschrieben. Die Verarbeitungen werden anhand eines Ablaufs in 15 beschrieben.
  • Nachdem der Host 206 eingeschaltet oder neu gebootet wurde, erzeugt er eine Schnittstellen-ID aus einer MAC-Adresse der Netzwerkschnittstelle (301 in 3). Der Host 206 erzeugt auch eine Zufallsschnittstellen-ID durch einen Algorithmus beispielsweise wie in RFC 3041 beschrieben. Dann erzeugt er eine lokale Verbindungsadresse durch Anfügen der aus der MAC-Adresse erzeugten Schnittstellen-ID an einen vorbestimmten Vorspann, führt eine DAD aus und sendet eine Routerbewerbung (Router Solicitation, RS) zum Router (Schritt S1501). Die RS wird zu allen Routern der Verbindung wie vorstehend beschrieben in einer Multicast-Sendung gesendet.
  • Beim Empfang der RS sendet der Router 202 eine Routeranzeige (Router Advertisement, RA) (Schritt S1502).
  • Beim Empfang der RA extrahiert der Host 206 den in der RA enthaltenen Vorspann und erzeugt eine globale Adresse (die öffentliche Adresse genannt wird) aus der aus der MAC-Adresse erzeugten Schnittstellen-ID und dem extrahierten Vorspann. Er erzeugt auch eine Einmal-IDv6-Adresse (die temporäre Adresse genannt wird) aus einer Zufallsschnittstellen-ID und dem extrahierten Vorspann. Dann führt er eine DAD (duplicate address detection, Duplizierungsadressenerfassung) zur Erfassung einer Duplizierung der öffentlichen Adresse und der temporären Adresse aus, wodurch die Eindeutigkeit der Adresse auf der Verbindung bestätigt wird, und ordnet diese Adressen der Schnittstelle zu (Schritt S1503).
  • Dann erzeugt der Host 206 eine Zertifikatbewerbung (Schritt S1504). Die Zertifikatbewerbung ist eine Nachricht, die ein anonymes öffentliches Schlüsselzertifikat anfordert, und wird in einem Format erzeugt, das der Router 202 versteht, dass der Host 206 ein anonymes öffentliches Schlüsselzertifikat anfordert. Ein derartiges Format ist beispielsweise durch PKC#10 in RFC 2986 (PKCS#10: Certification Request Syntax Specification Version 1.7", oder in RFC 2511 „Internet X.509 Certificate Request Message Format" definiert. Obwohl die Einzelheiten des Formats nicht beschrieben sind, wird angenommen, dass die Zertifikatbewerbung durch eine Zertifikatanforderungsnachricht und eine Signatur (des Host) dafür gebildet wird.
  • Der Host 206 sendet dann die Zertifikatbewerbung zum Router 202 über die Verbindung 207 (Schritt S1505). Eine Sendung an eine Adresse ist möglich, da der Host 206 die (Unicast-)Adresse des Router 202 kennt.
  • Der Router 202 ruft den öffentlichen Schlüssel v_i aus dem RAM 305 oder der HD 306 beruhend auf dem Instanznamen (Identifizierer des Host 206 oder des Namens des den Host 206 verwendenden Benutzers) in der in Schritt S1505 empfangenen Zertifikatbewerbung ab und bestätigt die Legitimität der Signatur unter Verwendung dieses öffentlichen Schlüssels. Nach der Bestätigung wird ein anonymes öffentliches Schlüsselzertifikat APC_ca(i) des Host 206 ausgebildet. Insbesondere sind die IPv6, die Lebensdauer, und so weiter in den Verwaltungs-/Attributinformationen X des Zertifikats im vorstehend angeführten APC_ca(i)=(g', v_i', X, Sig_ca(g', v_i', X)) enthalten (Schritt S1506).
  • Dann sendet der Router 202 die Zertifikatanzeige mit dem anonymen öffentlichen Schlüsselzertifikat APC_ca(i) zu dem authentifizierten Host 206 über die Verbindung 207 (Schritt S1507). Gemäß einem Ausführungsbeispiel der Erfindung wird diese Zertifikatanzeige nach einer Verschlüsselung mit dem registrierten öffentlichen Schlüssel gesendet. Bei diesem Vorgang kann eine Unicast-Sendung zu der vorübergehenden Adresse geschehen.
  • Beruhend auf der empfangenen Zertifikatanzeige bestätigt der Host 206 die Legitimität des anonymen öffentlichen Schlüsselzertifikats APC_ca(i) (Schritt S1508).
  • 17 zeigt ein Ablaufdiagramm des Hostbetriebs im erweiterten Protokoll, bei dem das vorstehend beschriebene Protokoll mit der bereits bekannten zustandslosen Adressenautokonfiguration und der Zustands-Adressenautokonfiguration kombiniert wird.
  • Nach dem Einschalten oder neu Booten des Host 206 erzeugt er eine Schnittstellen-ID aus einer MAC-Adresse der Netzwerkschnittstelle (301 in 3). Der Host 206 erzeugt auch eine Zufallsschnittstellen-ID durch einen Algorithmus, der beispielsweise in RFC 3041 beschrieben ist. Dann erzeugt er eine lokale Verbindungsadresse durch Anfügen der aus der MAC-Adresse erzeugten Schnittstellen-ID zu einem vorbestimmten Vorspann, führt eine DAD aus und sendet eine Routerbewerbung (RS) zum Router (Schritt S1701). Die RS wird zu allen Routern in der Verbindung wie vorstehend beschrieben in einer Mulitcast-Sendung übertragen.
  • Im Fall des Empfangs der Routeranzeigenachricht (RA), die die zustandslose Adressenautokonfiguration bezeichnet, das heißt, „JA" in Schritt S1702, extrahiert der Host 206 den in der RA enthaltenen Vorspann und erzeugt eine globale Adresse (eine so genannte öffentliche Adresse) aus der aus der MAC-Adresse erzeugten Schnittstellen-ID und dem extrahierten Vorspann. Er erzeugt auch eine Einmal-IPv6-Adresse (die temporäre Adresse genannt wird) aus einer Zufallsschnittstellen-ID und dem extrahierten Vorspann.
  • Dann führt er eine DAD (Duplizierungsadressenerfassung) zur Erfassung einer Duplizierung der öffentlichen Adresse und der temporären Adresse aus, wodurch die Eindeutigkeit der Adresse in der Verbindung bestätigt wird, und weist diese Adressen der Schnittstelle zu (Schritt S1703).
  • Dann führt der Host 206 ein Protokoll zur Anforderung und Ausgabe des Zertifikats aus (Schritt S1707). Insbesondere erzeugt der Host 206 die Zertifikatbewerbung wie in den Schritten S1504, S1505 in 15, und sendet sie zum Router 202. Der Host 206 empfängt die Zertifikatanzeige vom Router 202 und bestätigt die Legitimität des anonymen öffentlichen Schlüsselzertifikats APC_ca(i), das darin enthalten ist.
  • Wird keine Routeranzeige empfangen („NEIN" in Schritt S1704), wird lediglich die Zustands-Adressenautokonfiquration, das heißt DHCPv6 ausgeführt. Dieser Vorgang entspricht Schritt S1706, dessen Einzelheiten dieselben wie im Protokoll in 10 sind.
  • Empfängt der Schritt S1704 eine Routeranzeigenachricht, die sowohl die zustandslose Adressenautokonfiguration als auch die Zustands-Adressenautokonfiguration bezeichnet, führt ein Schritt S1705 sowohl die zustandslose Adressenautokonfiguration als auch die Zustands-Adressenautokonfiguration aus. Der Inhalt des Ablaufs ist derselbe wie in den Schritten S1703 und S1706.
  • In der vorstehenden Beschreibung dient der voreingestellte Gateway 202 (Router) als CA, jedoch sind der voreingestellte Gateway (Router) und die Instanz CA im Allgemeinen nicht unbedingt dieselbe IPv6-unterstützende Vorrichtung. 16 zeigt ein Ablaufdiagramm der Verarbeitungen für den Fall, dass der voreingestellte Gateway (Router) und die CA durch verschiedene IPv6-Vorrichtungen gebildet werden.
  • Der Administrator der Instanz CA bestimmt und legt die vorstehend angeführten öffentlichen Parameter p, g, und so weiter offen. Er bestimmt auch den öffentlichen Schlüssel v_ca für die Instanz CA, die das anonyme öffentliche Schlüsselzertifikat ausgibt, und überträgt es zu einer übergeordneten oder überzeugenderen CA (209 in 2), beispielsweise VerySign, was kommerziell einen Authentifizierungsdienst bereitstellt, um ein öffentliches Schlüsselzertifikat für den öffentlichen Schlüssel v_ca zu empfangen.
  • Möchte ein Benutzer i auf das LAN zugreifen, erzeugt er seinen eigenen geheimen Schlüssel s_i unter Verwendung der öffentlichen Parameter p, g, und so weiter, berechnet einen entsprechenden öffentlichen Schlüssel v_i und führt dem Verwalter von CA den Benutzernamen, das Passwort und den öffentlichen Schlüssel v_i zu. Der Verwalter von CA erlaubt einen Zugriff, nachdem er eine Identifizierung des Benutzers i und eine Passwortüberprüfung entsprechend seiner Betreiberpolitik ausgeführt hat. Der Administrator führt eine Registrierung im RAM 304 oder auf der HD 306 derart durch, dass der entsprechende öffentliche Schlüssel anhand des Instanznamens abgerufen werden kann. Die öffentlichen Parameter p, g, usw., und der öffentliche Schlüssel v_i und insbesondere der geheime Schlüssel s_i werden vom Benutzer i verwaltet und im Host 206 sicher verwendbar gemacht.
  • Der Administrator des voreingestellten Gateway (Router) 202 und der Administrator der CA können dieselben oder unterschiedliche Einheiten sein. Gemäß 16 sind der voreingestellte Gateway 202 (Router) und die CA verschiedene IPv6-Vorrichtungen, und die IPv6-Adresse der CA ist im voreingestellten Gateway eingestellt.
  • Nach dem Einschalten oder neu Booten erzeugt der Host 206 eine Schnittstellen-ID aus einer MAC-Adresse der Netzwerkschnittstelle (301 in 3). Der Host 206 erzeugt auch eine Zufalls-Schnittstellen-ID durch einen Algorithmus, beispielsweise den in RFC 3041 beschriebenen. Dann erzeugt er eine lokale Verbindungsadresse wie vorstehend beschrieben, führt DAD aus und sendet eine erweiterte Routerbewerbung (RS extended) zum Router (Schritt S1601). Die erweiterte RS stellt Informationen dar, die durch Addieren einer Nachricht zur Anforderung der CA-Adresse zu der Routerbewerbung gebildet und zu allen Routern auf der Verbindung wie die vorstehend beschriebene RA über einen Multicast gesendet werden.
  • Beim Empfang der erweiterten RS sendet der Router 202 eine erweiterte Routeranzeige (RA extended) (Schritt 51602). Die erweiterte RA stellt Informationen dar, die durch Hinzufügen der Adresse der CA zu der Routeranzeige gebildet werden.
  • Beim Empfang der erweiterten RA extrahiert der Host 206 den in der erweiterten RA enthaltenen Vorspann und erzeugt eine globale Adresse (eine so genannte öffentliche Adresse) aus der aus der MAC-Adresse erzeugten Schnittstellen-ID und dem Vorspann. Er erzeugt auch eine Einmal-IPv6-Adresse (eine so genannte temporäre Adresse) aus einer Zufalls-Schnittstellen-ID und dem extrahierten Vorspann. Dann führt er eine DAD (Duplizierungsadressenerfassung) zur Erfassung einer Duplizierung der öffentlichen Adresse und der temporären Adresse aus, wodurch die Eindeutigkeit der Adresse auf der Verbindung bestätigt wird, und weist diese Adressen der Schnittstelle zu. Es wird auch die Adresse von CA aus der erweiterten RA extrahiert (Schritt S1603).
  • Dann erzeugt der Host 206 eine Zertifikatbewerbung (Schritt S1604) und sendet sie zu der CA (Schritt S1606).
  • Der Router 202 ruft den registrierten öffentlichen Schlüssel v_i aus dem RAM 305 oder der HD 306 beruhend auf dem Instanznamen (Identifizierer der Kommunikationsvorrichtung (Host) 206) in der in Schritt S1605 empfangenen Zertifikatbewerbung ab und bestätigt die Legitimität der Signatur unter Verwendung dieses öffentlichen Schlüssels. Nach der Bestätigung wird ein anonymes öffentliches Schlüsselzertifikat APC_ca(i) des Host 206 ausgebildet. Insbesondere sind die IPv6, die Lebensdauer, usw. in den Verwaltungs-/Attributinformationen X des Zertifikats in dem vorstehend angeführten APC_ca(i)=(g', v_i', X, Sig_ca(g', v_i', X)) (Schritt S1606) enthalten.
  • Dann sendet die CA die Zertifikatanzeige mit dem anonymen öffentlichen Schlüsselzertifikat APC_ca(i) zum Host 206 (Schritt S1607). Bei einem Ausführungsbeispiel der Erfindung wird diese Zertifikatanzeige nach einer Verschlüsselung mit dem registrierten öffentlichen Schlüssel gesendet.
  • Beruhend auf der empfangenen Zertifikatanzeige bestätigt der Host 206 die Legitimität des anonymen öffentlichen Schlüsselzertifikats APC_ca(i) (Schritt S1608).
  • Ein Ablaufdiagramm der Hostarbeitsweise gemäß einem erweiterten Protokoll, bei dem das vorstehend beschriebenen Protokoll mit einer bereits bekannten zustandslosen Adressenautokonfiguration und einer Zustands-Adressenautokonfiguration kombiniert ist, ist dem in 7 gezeigten ähnlich, unterscheidet sich jedoch in den folgenden zwei Punkten. Das heißt, in Schritt S1701 wird eine erweiterte Routerbewerbungsnachricht anstelle der Routerbewerbungsnachricht gesendet, und in Schritt S1707 wird ein in 16 gezeigtes Protokoll als Protokoll zur Anforderung und Ausgabe des Zertifikats ausgeführt.
  • (Drittes Ausführungsbeispiel)
  • Dieses Ausführungsbeispiel zeigt einen Fall, in dem ein Host mit dem Internet durch ein Verbindungsaufbauverfahren oder durch ADSL verbunden ist. Zuerst wird die gegenwärtige Situation beschrieben und dann das Ausführungsbeispiel.
  • 14 zeigt schematisch eine Verbindungsumgebung, in der die vorliegende Erfindung anwendbar ist. 14 zeigt eine Umgebung, in der ein Host 1406 mit einem Internet 1401, das durch einen ISP („Internet Service Provider", Internetdienstbereitsteller) bereitgestellt wird, über ein PSTN („Public Switched Telephone Network", öffentliches Fernsprechnetz) verbunden ist. Bei dem vorliegenden Ausführungsbeispiel sind der ISP und der Host durch eine PPP-Verbindung verbunden.
  • Gemäß 14 ist ein PPP-Partner 1402 des ISP ein Knoten, der eine Anforderung für eine PPP-Verbindung vom Host 1406 unter Verwendung eines Modem 1403 und über das PSTN 1404 entgegennimmt. Der Host 1406 greift auf den PPP-Partner 1402 durch eine PPP-Verbindung unter Verwendung eines Modem 1405 zu. Der Host 1406 weist eine Architektur ähnlich der in 3 gezeigten auf, und ist mit dem Modem 1405 über die Netzwerkschnittstelle 301 verbunden. Auch der PPP-Partner 1402 weist eine Architektur ähnlich der in 3 gezeigten auf und ist mit dem Modem 1403 über die Netzwerkschnittstelle 301 und mit dem Internet 1401 über eine Netzwerkschnittstelle 302 verbunden. Wie in 14 gezeigt fungiert der PPP-Partner 1402 als voreingestelltes Gateway-Modul 14021, DHCP-Modul 14022 und Authentifizierungsmodul 14023. Im Fall einer Kommunikation zwischen dem Host 1406 und dem PPP-Partner 1402 führt der Host 1406 eine Kommunikation über das Modem 1405 aus, während der PPP-Partner 1402 eine Kommunikation über das Modem 1403 ausführt.
  • Im vorliegenden Ausführungsbeispiel wird eine Konfiguration beschrieben, bei der ein Modem und PSTN als Beispiel angewendet werden, jedoch ist die Situation grundlegend dieselbe bei anderen Kommunikationsformen, wie einem PHS-Kommunikationsadapter und einem PHS-Kommunikationsnetzwerk, oder einer exklusiven Leitungsverbindungsvorrichtung und einer exklusiven Leitung, solange die PPP-Verbindung errichtet werden kann. Die Einzelheiten der PPP-Verbindung sind in RFC 1661 „The point-to-point Protocol (PPP)" beschrieben.
  • Der Host 1406 sendet eine Anforderung für eine PPP-Verbindung zum PPP-Partner 1402 über ein Modem 1405, ein PSTN 1404 und ein Modem 1403. Als Antwort auf diese Verbindungsanforderung führt das Authentifizierungsmodul 14023 des PPP-Partners 1402 eine Authentifizierung des Host aus. Ein typischer Authentifizierungsvorgang ist ein Authentifizierungsprotokoll CHAP beruhend auf dem Benutzernamen und dem Passwort, dessen Einzelheiten in RFC 1994 „PPP Challenge Handshake Authentication Process" beschrieben sind.
  • Nach der Authentifizierung sendet das DHCP-Modul 14022 entsprechend der Einstellung den Vorspann der globalen IPv6-Adresse und die IPv6-Adresse des voreingestellten Gateway zum Host 1406. Das DHCP-Modul 14002 wird durch den Administrator von ISP entsprechend seiner Betreiberpolitik eingestellt.
  • In 14 wird der Einfachheit halber angenommen, dass der voreingestellte Gateway, der DHCP-Server und der Authentifizierungsserver jeweils als voreingestelltes Gateway-Modul 1402, DHCP-Modul 14002 und Authentifizierungsmodul 14023 vorhanden sind, die im PPP-Partner vorgesehen sind, können aber tatsächlich als jeweils unterschiedliche Knoten in der Verbindung 1407 vorhanden sein. Tatsächlich ist jede Form akzeptierbar, solange dieses Modul oder der Knoten unter der Verwaltung des Administrators von ISP sicher betrieben werden kann, und es wird in der folgenden Beschreibung angenommen, dass eine PPP-Verbindung zwischen dem Host 1406 und dem PPP-Partner 1402 in der in 14 gezeigten Konfiguration errichtet ist.
  • Nachdem der Host 1406 den Vorspann der globalen IPv6-Adresse, die IPv6-Adresse des voreingestellten Gateway, und so weiter vom DHCP-Modul 14022 empfangen hat, erzeugt er eine globale Zufalls-IPv6-Adresse durch Kombinieren des Vorspanns der globalen IPv6-Adresse und einer eigenen Zufalls-Schnittstellen-ID (beispielsweise erzeugt entsprechend RFC 3041), weist diese dann nach der Bestätigung des Fehlens einer Duplizierung dieser auf der Verbindung der Schnittstelle 301 zu und speichert die IPv6-Adresse des voreingestellten Gateway.
  • Mit den vorstehend beschriebenen Verarbeitungen kann der Host 1406 mit einem willkürlichen Gegenüber im Internet unter Verwendung der Einmal-IPv6-Adresse kommunizieren.
  • Nachstehend ist ein Ausführungsbeispiel der Erfindung beschrieben, bei dem die vorstehend beschriebenen Vorgänge (das Protokoll) zum Bereitstellen eines Protokolls erweitert sind, um die Verwendung eines anonymen öffentlichen Einmal-Schlüsselzertifikats zu ermöglichen.
  • Im Folgenden wird ein Fall der Anwendung der anonymen öffentlichen Schlüsselzertifizierung in einer in 4 gezeigten Umgebung beschrieben. Der PPP-Partner 1402 fungiert als CA, die das anonyme öffentliche Schlüsselzertifikat ausgibt, während der Host 1406 (beziehungsweise sein Benutzer) als Instanz i fungiert, die das anonyme öffentliche Schlüsselzertifikat verwendet. Im Folgenden wird ein Ausführungsbeispiel beschrieben, bei dem eine Zufalls-IPv6-Adresse in das Zertifikat aufgenommen ist, es ist aber auch möglich, keine derartige Zufalls-IPv6-Adresse aufzunehmen.
  • Der ISP bestimmt und legt die vorstehend beschriebenen öffentlichen Parameter p, g, und so weiter offen. Er bestimmt auch seinen öffentlichen Schlüssel v_ca und führt ihn einer übergeordneten beziehungsweise überzeugenderen CA (1408 in 14) zu, beispielsweise VerySign, was einen kommerziellen Authentifizierungsdienst bereitstellt, um ein öffentliches Schlüsselzertifikat für den öffentlichen Schlüssel v_ca zu empfangen.
  • Ersucht ein Benutzer i um einen Zutritt bei ISP, erzeugt der Benutzer seinen geheimen Schlüssel s_i unter Verwendung der Parameter p, g, und so weiter, die durch den ISP offen gelegt sind, berechnet einen entsprechenden öffentlichen Schlüssel v_i und führt dem ISP den Benutzernamen, das Passwort und den öffentlichen Schlüssel v_i zu. Der Administrator von ISP (Administrator des PPP-Partners 1402) erlaubt einen Zugang, nachdem er eine Identifizierung des Benutzers i und eine Passwortüberprüfung entsprechend seiner Betreiberpolitik ausgeführt hat. Der Verwalter führt eine Registrierung im RAM 304 oder der HD 306 derart durch, dass der entsprechende öffentliche Schlüssel anhand des Benutzernamens abgerufen werden kann. Die öffentlichen Parameter p, g, und so weiter und der öffentliche Schlüssel v_i und insbesondere der geheime Schlüssel s_i werden vom Benutzer i verwaltet und im Host 1406 sicher verwendbar gemacht.
  • 13 zeigt ein Protokoll des vorliegenden Ausführungsbeispiels, das nach den vorstehend beschriebenen Vorbereitungen ausgeführt wird. 13 zeigt ein Ausgabeprotokoll für ein anonymes öffentliches Schlüsselzertifikat zwischen einer das anonyme öffentliche Schlüsselzertifikat verwendenden Instanz (IPv6-Terminal, der vom Benutzer i verwendet wird), die durch den Host 1406 gebildet wird, und einer Instanz CA, die das anonyme öffentliche Schlüsselzertifikat ausgibt, und vom PPP-Partner 1402 gebildet wird.
  • Bei der Errichtung einer PPP-Verbindung veranlasst der PPP-Partner 1402 nach Beenden eines Vorgangs in der Datenverbindungsschicht beim Empfang einer Anforderung einer PPP-Verbindung vom Host 1406 das Authentifizierungsmodul 14023 zum Authentifizieren des Host durch ein Authentifizierungsprotokoll CHAP beruhend auf dem Benutzernamen (Identifizierer) und dem Passwort.
  • Insbesondere sendet der Host 1406 in Schritt S1301 den Instanznamen (Benutzername) zu dem PPP-Partner 1402. Der PPP-Partner 1402 erzeugt eine CHAP-Herausforderung in Schritt S1302 und sendet sie zum Host 1406 in Schritt S1303.
  • In Schritt S1304 gibt der Host 1406 den Instanznamen, das Passwort und die CHAP-Herausforderung in die Hash-Funktion zur Bestimmung einer CHAP-Antwort ein und sendet in Schritt S1304 einen Wert der bestimmten CHAP-Antwort zum PPP-Partner 1402.
  • In Schritt S1306 bestätigt der PPP-Partner 1402 die Legitimität der CHAP-Antwort. Nach der erfolgreichen Authentifizierung durch die Bestätigung werden der Vorspann der globalen IPv6-Adresse und die Adresse des voreingestellten Gateway zum authentifizierten Host 1406 in Schritt S1307 gesendet.
  • In Schritt S1208 erzeugt der Host 1406 eine globale IPv6-Adresse durch Kombinieren des Vorspanns der globalen IPv6-Adresse und einer Zufalls-Schnittstellen-ID, und weist diese nach einer Bestätigung des Fehlens einer Duplizierung dieser der Netzwerkschnittstelle 301 zu und speichert auch die Adresse des voreingestellten Gateway. Dann sendet er in Schritt S1309 eine Zertifikatbewerbung als Nachricht, die ein anonymes öffentliches Schlüsselzertifikat anfordert.
  • Wie beim ersten Ausführungsbeispiel wird die Zertifikatbewerbung in einem Format erzeugt, die vom PPP-Partner 1402 so zu verstehen ist, dass ein anonymes öffentliches Schlüsselzertifikat angefordert wird, und dass die Schnittstellen-ID enthalten ist. Der Inhalt wird aus dem Instanznamen (Benutzernamen), dem Passwort und einer Seriennummer berechnet, und die Seriennummer ist beispielsweise durch Verknüpfung einer lokalen IPv6-Verbindungsadresse des Host 1406, einer lokalen IPv6-Verbindungsadresse des voreingestellten Gateway und der aktuellen Zeit gebildet. Die Zertifikatbewerbung enthält eine digitale Signatur (Authentifizierungssignatur), die durch Eingeben des Instanznamens (Benutzernamens), des Passworts und der Seriennummer in die Hash-Funktion erzeugt wird.
  • Der PPP-Partner 1402 ruft den registrierten öffentlichen Schlüssel v_i aus dem RAM 305 oder der HD 306 beruhend auf dem Instanznamen (Benutzernamen) der Kommunikationsvorrichtung (Host 1406) ab und führt in Schritt S1310 eine Erzeugung eines anonymen öffentlichen Schlüssels wie in S103 in 1 beschrieben aus. Insbesondere wird eine globale IPv6-Adresse aus dem Vorspann der globalen IPv6-Adresse, die dem PPP-Partner 1402 zugeordnet ist, und der Schnittstellen-ID des Host 1406 erzeugt, und ein anonymes öffentliches Schlüsselzertifikat APC_ca(i) mit seiner Lebensdauer, und so weiter wird ausgebildet. Somit sind die globale IPv6-Adresse, die Lebensdauer, und so weiter in den Verwaltungs-/Attributinformationen X des vorstehend angeführten Zertifikats APC_ca(i) = (g', v_i', X, Sig_ca(g', v_i', X)) enthalten.
  • Dann wird in Schritt S1311 wie in Schritt S104 in 1 eine Zertifikatanzeige, die das erzeugte anonyme öffentliche Schlüsselzertifikat APC_ca(i) enthält, zum Host 1406 gesendet. In Schritt S1312 bestätigt der Host 1406 die Legitimität des empfangenen anonymen öffentlichen Schlüsselzertifikats APC_ca(i). Somit enthält das anonyme öffentliche Schlüsselzertifikat APC_ca(i) eine Gültigkeitsperiode in den Verwaltungs-/Attributinformationen X, und die öffentlichen Schlüssel g' und v_i', die in dem anonymen öffentlichen Schlüsselzertifikat APC_ca(i) enthalten sind, sind die öffentlichen Schlüssel derselben Instanz i (Host 1406), werden aber im Verlauf der Zeit ausgetauscht.
  • Bei dem vorstehend beschriebenen Protokoll können die in den Schritten S1305 und S1309 gesendeten und empfangenen Daten insgesamt in Schritt S1305 gesendet werden. In diesem Fall sendet der Host 1406 die Zufalls-Schnittstellen-ID, die CHAP-Antwort von Schritt S1305 in 13 und die Zertifikatbewerbung von Schritt S1309 (ähnlich wie im ersten Ausführungsbeispiel) in Schritt S1305' zum PPP-Partner 1402, obwohl dies nicht veranschaulicht ist.
  • Dann bestätigt der PPP-Partner 1402 in Schritt S1306' die Legitimität der CHAP-Antwort, ruft den registrierten öffentlichen Schlüssel v_i ab, erzeugt die globale IPv6-Adresse aus dem IPv6-Vorspann und der Schnittstellen-ID und erzeugt Daten, die diese globale Adresse und ihre Lebensdauer (effektive Verwendungsdauer, beispielsweise 24 Stunden) enthalten, wodurch das anonyme öffentliche Schlüsselzertifikat APC_ca(i) erzeugt wird. Dann wird in Schritt S1307' eine Zertifikatanzeige, die das erzeugte anonyme öffentliche Schlüsselzertifikat APC_ca(i) enthält, zum Host 1406 gesendet.
  • Der Host 1406 bestätigt die Legitimität des empfangenen anonymen öffentlichen Schlüsselzertifikats APC_ca(i) in Schritt S1308'. Es gibt keine folgenden Schritte, da der Schritt S1312 in 13 entsprechende Vorgang durch diesen Schritt S1308' abgeschlossen ist.
  • Mit dem vorstehend beschriebenen Protokoll gibt der PPP-Partner 1402 eine Einmal-IPv6-Adresse und ein entsprechendes anonymes öffentliches Einmal-Schlüsselzertifikat aus.
  • Der Host 1406 führt das in 13 gezeigte anonyme öffentliche Schlüsselzertifikatausgabeprotokoll für jedes Kommunikationsgegenüber, jede Sitzung bzw. jede Übertragung eines Kommunikationspakets aus, wobei die zu verwendenden öffentlichen Schlüssel g' und v_i' ausgetauscht werden.
  • Vorstehend wurde ein Fall beschrieben, in dem der PPP-Partner 1402 den IPv6-Vorspann zum Host 1406 sendet und der Host 1406 die IPv6-Adresse aus dem IPv6-Vorspann und der Schnittstellen-ID erzeugt, es ist aber ein ähnliches Protokoll im Fall anwendbar, dass der PPP-Partner 1402 die IPv6-Adresse zum Host 1406 sendet, der diese Adresse verwendet. Das Protokoll bleibt in einem derartigen Fall gleich, abgesehen davon, dass die IPv6-Adresse anstelle des IPv6-Vorspanns in Schritt S1307 gesendet wird, und dass der Vorgang der Erzeugung der IPv6-Adresse aus dem Vorspann in Schritt S1308 unnötig wird.
  • (Viertes Ausführungsbeispiel)
  • Nun wird ein Ausführungsbeispiel der Ausführung einer IPsec-Kommunikation unter Verwendung der Einmal-IPv6-Adresse und des anonymen öffentlichen Einmal-Schlüsselzertifikats beschrieben, das gemäß dem ersten, zweiten oder dritten Ausführungsbeispiel ausgegeben wird.
  • Zuerst wird kurz ein Authentifizierungsverfahren anhand eines überarbeiteten Modus einer Verschlüsselung mit öffentlichem Schlüssel in IKE („Internet Key Exchange", Internet-Schlüsselaustausch) beschrieben, das ein Protokoll zum sicheren gemeinsamen Nutzen von SA (Security Association) ist, das durch geheime Daten, gegenseitige IPv6-Adressen, usw. gebildet ist, und dann wird ein Verfahren der Verwendung des anonymen öffentlichen Schlüsselzertifikats beschrieben.
  • IKE ist anhand von zwei Phasen aufgebaut, das heißt einer Phase 1 zum Errichten eines sicheren Kommunikationswegs und einer Phase 2 zum Zustimmen zu SAs, die in der Kommunikation, wie einer IPsec-Kommunikation zu verwenden sind, wobei dieser sichere Kommunikationsweg verwendet wird. Im Folgenden wird lediglich Phase 1 beschrieben. Die IKE-Phase 1 umfasst einen Hauptmodus und einen aggressiven Modus, und im Folgenden wird der Hauptmodus entsprechend RFC 2409 „The Internet Key Exchange (IKE)", Seiten 13-15, 5.3, Phase 1 Authenticated with a Revised mode of Public Key Encryption beschrieben.
  • In IKE werden zwei Kommunikationsinstanzen Initiator und Responder genannt. Der Initiator beginnt die Kommunikation. Zuerst sendet der Initiator eine Vielzahl von SAs zum Responder, der eine zur Verwendung als geeignet beurteilte SA zu dem Initiator sendet, wodurch SA für die Phase 1 bestimmt wird.
  • Der Initiator erzeugt eine Zufallszahl (genannt Nonce), und sendet Daten zum Responder, die durch Verschlüsselung mit dem öffentlichen Schlüssel des Responder erhalten werden. Der Responder erzeugt eine Zufallszahl und sendet Daten zum Initiator, die durch Verschlüsselung mit dem öffentlichen Schlüssel des Initiators erhalten werden. Auf diese Weise können die jeweils erzeugten Nonces geteilt werden, und es wird ein Verschlüsselungskode aus den geteilten Nonces erzeugt, der bei einer anderen Kommunikation zu verwenden ist. Die Einzelheiten sind in RFC 2409 „The Internet Key Exchange (IKE)" beschrieben. Daraus ist ersichtlich, dass es erforderlich ist, den öffentlichen Schlüssel des Kommunikationsgegenübers vor der IPsec-Kommunikation zu kennen.
  • Nun wird eine Situation betrachtet, in der ein Benutzer auf eine Stelle im Internet zugreift, wie einen Einkaufsort. Der Benutzer ist beispielsweise der Host 206 in der in 2 gezeigten Konfiguration, oder der Host 1406 in der in 14 gezeigten Konfiguration. Der Einkaufsort ist in der in 2 gezeigten Konfiguration mit dem den Benutzer bildenden Host 206 über das Internet 201 und den Gateway 202 verbunden, und in der Konfiguration in 14 über das Internet 1401 und den PPP-Partner 1402 mit dem den Benutzer bildenden Host 1406 verbunden. Der Host 206 oder 1406 erhält eine IPv6-Adresse und ein öffentliches Schlüsselzertifikat mit dem öffentlichen Schlüssel vor dem Beginn einer Kommunikation mit einem Ort wie dem vorstehend angeführten Einkaufsort. Bei diesem Aufbau wird ein Protokoll zum Austauschen, Erneuern und Ändern des Schlüssels beruhend auf dem vorstehend angeführten öffentlichen Schlüsselzertifikat zum Erreichen einer Verschlüsselungs-/Authentifizierungskommunikation ausgeführt.
  • In diesem Zustand kennt der Benutzer die IPv6-Adresse (den Identifizier) des Einkaufsorts (entweder explizit oder implizit). Nach dem Durchführen eines tatsächlichen Zugriffs und Herausfinden, dass dies ein geeigneter Ort für den Benutzer ist, bestätigt der Benutzer die IPv6-Adresse des Kommunikationsgegenübers, wodurch er die Adresse explizit kennt. Auch der Einkaufsort kann die Adresse (den Identifizier) des Kommunikationsgegenübers im Verlauf der Kommunikation kennen. Die vorstehend angeführte Kommunikation kann mit einer Einmal-IPv6-Adresse ausgeführt werden.
  • Bei diesem Ausführungsbeispiel wird angenommen, dass nach Errichtung des Senders und des Empfängers die Einmal-IPv6-Adresse nicht erneuert sondern fortlaufend verwendet wird. An diesem Punkt werden die anonymen öffentlichen Einmal-Schlüsselzertifikate APC_ca(i)=(g', v_i', X, Sig_ca(g', v_i', X)) gegenseitig gesendet. Da die Verwaltungs-/Attributinformationen X in dem anonymen öffentlichen Einmal-Schlüsselzertifikat APC_ca(i) die globale IPv6-Adresse enthalten, wird es möglich gemacht, durch Bestätigen, ob diese IPv6-Adresse mit der IPv6-Adresse des Gegenübers in der tatsächlichen Kommunikation übereinstimmt, und durch Bestätigung der Legitimität des anonymen öffentlichen Schlüsselzertifikats zu beurteilen, ob dieses Zertifikat ein wahres anonymes öffentliches Einmal-Schlüsselzertifikat des Kommunikationsgegenübers ist, und zu Bestätigen, ob die darin enthaltenen öffentlichen Schlüssel (g', v_i') die wahren öffentlichen Schlüssel des Kommunikationsgegenübers sind.
  • Die Legitimität des anonymen öffentlichen Einmal-Schlüsselzertifikats kann auf die folgende Art und Weise bestätigt werden. Die Verwaltungs-/Attributinformationen X des Zertifikats enthalten den öffentlichen Schlüssel v_ca von CA (Router 202, DHCP-Server 203 oder PPP-Partner 1402) und ein öffentliches Schlüsselzertifikat dafür (das durch VeriSign oder dergleichen zur Bereitstellung des kommerziellen Authentifizierungsdienstes ausgegeben wird). Der Ort kann bestätigen, ob diese eine korrekte Übereinstimmung haben, indem der öffentliche Schlüssel von VeriSign oder dergleichen (ein bekannter und leicht erhältlicher Schlüssel) verwendet wird, was den kommerziellen Authentifizierungsdienst bereitstellt. Dann kann der als legitim bestätigte Schlüssel v_ca zum Bestätigen der Legitimität der anonymen öffentlichen Einmal-Schlüsselzertifikate APC_ca(i)=(g', v_i', X, Sig_ca(g', v_i', X)) verwendet werden, das heißt, der korrekten Übereinstimmung von g', v_i' und Sig_ca(g', v_i', X). Das anonyme öffentliche Schlüsselzertifikat APC_ca(i) enthält eine Gültigkeitsperiode in den Verwaltungs-/Attributinformationen X, und die öffentlichen Schlüssel g' und v_i', die in dem anonymen öffentlichen Schlüsselzertifikat APC_ca(i) enthalten sind, sind die öffentlichen Schlüssel derselben Instanz i, werden aber im Verlauf der Zeit geändert.
  • Der Host 206 oder 1406 führt das in 11 oder 13 gezeigte Protokoll für jedes Kommunikationsgegenüber (das heißt, für jede neue Verbindung zu einem Ort) bzw. für jede Sitzung aus, wodurch die IPv6-Adresse und die zu verwendenden öffentlichen Schlüssel g' und v_i' erneuert oder geändert werden. Die öffentlichen Schlüssel g' und v_i' können für jede Übertragung eines Kommunikationspakets erneuert oder geändert werden.
  • Durch das vorstehende Protokoll wird es ermöglicht, den öffentlichen Schlüssel des durch die IPv6-Adresse definierten Kommunikationsgegenübers sicher zu erhalten, indem die Einmal-IPv6-Adresse und das anonyme öffentliche Einmal-Schlüsselzertifikat verwendet werden, das diese enthält. Auch kann durch die Ausführung des Hauptmodus der Phase 1 des vorstehenden IKE mit so ausgetauschten öffentlichen Schlüsseln eine IPsec-Kommunikation mit einem Kommunikationsgegenüber mit dieser IPv6-Adresse realisiert werden.
  • Somit wird bei diesem Ausführungsbeispiel eine IPsec-Kommunikation, die ein Protokoll zum Betreiben einer IPv6-unterstützenden Vorrichtung, die auf einer lokalen Verbindung vorhanden ist, als Ausgabeeinrichtung für das öffentliche Schlüsselzertifikat, Teilen geheimer Informationen, die die IPv6-Adresse in dem anonymen öffentlichen Einmal-Schlüsselzertifikat enthalten, durch lediglich zwei Vorrichtungen im Internet, und Ausführen einer Verschlüsselung und Authentifizierung beruhend auf diesen geheimen Daten ist, und IKE (Internet Key Exchange) ausgeführt, das ein Protokoll zum sicheren Teilen von SA (Security Association) wie den geheimen Daten und den gegenseitigen IPv6-Adressen bei dieser IPsec-Kommunikation ist.
  • Demzufolge ist es möglich, ein betrügerisches Auftreten des Kommunikationsgegenübers zu verhindern, was als Nachteil der bekannten Technologie angeführt ist.

Claims (15)

  1. Vorrichtung zur Bereitstellung von öffentlichen Schlüsselzertifikaten, mit der ein Paar aus einem ersten öffentlichen Schlüssel (v_ca) und einem ersten geheimen Schlüssel (s_ca) und ein Zertifikat des ersten öffentlichen Schlüssels (v_ca) verbunden sind, das durch einen Authentifizierungsdienstanbieter ausgegeben wird, wobei die Vorrichtung zur Bereitstellung von öffentlichen Schlüsselzertifikaten gekennzeichnet ist, durch eine Erzeugungseinrichtung (303) zur Erzeugung eines zweiten öffentlichen Schlüssels (g', v_i') zur Verwendung durch eine entfernte Einrichtung in Verbindung mit einem zweiten geheimen Schlüssel (s_i), der durch die entfernte Einrichtung erzeugt wird, einer digitalen Signatur (Sig_ca) entsprechend dem ersten geheimen Schlüssel (s_ca), so dass die Legitimität mit dem ersten öffentlichen Schlüssel (v_ca) bestätigt werden kann, und eines Zertifikats (APC_ca) des zweiten öffentlichen Schlüssels (g', v_i'), der das Zertifikat des ersten öffentlichen Schlüssels (v_ca) und die digitale Signatur (Sig_ca) enthält, und eine Bereitstellungseinrichtung (301) zur Bereitstellung des Zertifikats (APC_ca) des zweiten öffentlichen Schlüssels (g', v_i').
  2. Vorrichtung nach Anspruch 1, wobei die Erzeugungseinrichtung (303) zur Berechnung des zweiten öffentlichen Schlüssels (g', v_i') beruhend auf einem dritten öffentlichen Schlüssel (v_i) eingerichtet ist, der mit dem durch die entfernte Einrichtung erzeugten geheimen Schlüssel (s_i) verbunden ist.
  3. Vorrichtung nach Anspruch 1 oder 2, wobei die Erzeugungseinrichtung zur Erzeugung des zweiten öffentlichen Schlüssels (g', v_i') beruhend auf einem öffentlichen Parameter (g) eingerichtet ist.
  4. Vorrichtung nach einem der vorhergehenden Ansprüche, wobei die Erzeugungseinrichtung zur Erzeugung der digitalen Signatur (Sig_ca) eingerichtet ist, die den zweiten öffentlichen Schlüssel (g', v_i') enthält.
  5. Vorrichtung nach einem der vorhergehenden Ansprüche, wobei die Bereitstellungseinrichtung dazu eingerichtet ist, das Zertifikat (APC_ca) des zweiten öffentlichen Schlüssels (g', v_i') einer Host-Einrichtung in einem Unternetzwerk bereitzustellen.
  6. Vorrichtung nach einem der vorhergehenden Ansprüche, wobei die Bereitstellungseinrichtung dazu eingerichtet ist, einer Host-Einrichtung das Zertifikat (APC_ca) des zweiten öffentlichen Schlüssels (g', v_i') und Informationen zur Bestimmung einer Adresse der Host-Einrichtung bereitzustellen.
  7. Vorrichtung nach einem der vorhergehenden Ansprüche, ferner mit einer Verbindungseinrichtung (302) zur Verbindung der entfernten Einrichtung, der das Zertifikat (APC_ca) des zweiten öffentlichen Schlüssels (g', v_i') durch die Bereitstellungseinrichtung bereitgestellt wird, mit dem Internet.
  8. Verfahren zur Bereitstellung eines Zertifikats eines öffentlichen Schlüssels von einer Vorrichtung mit einem Paar aus einem ersten öffentlichen Schlüssel (v_ca) und einem geheimen Schlüssel (s_ca), und einem Zertifikat des ersten öffentlichen Schlüssels (v_ca), der durch einen Authentifizierungsdienstanbieter ausgegeben wird, wobei das Verfahren einen Bereitstellungsschritt (S104) der Bereitstellung eines Zertifikats (APC_ca) eines zweiten öffentlichen Schlüssels (g', v_i') zur Verwendung durch eine entfernte Einrichtung mit einem durch die entfernte Einrichtung erzeugten zweiten geheimen Schlüssel (s_i) umfasst, gekennzeichnet durch Erzeugen des zweiten öffentlichen Schlüssels (g', v_i'), einer digitalen Signatur (Sig_ca) entsprechend dem geheimen Schlüssel (s_ca), so dass die Legitimität mit dem ersten öffentlichen Schlüssel (v_ca) bestätigt werden kann, und des Zertifikats (APC_ca) des zweiten öffentlichen Schlüssels (g', v_i'), der das Zertifikat des ersten öffentlichen Schlüssels (v_ca) und die digitale Signatur (Sig_ca) enthält, in dem Bereitstellungsschritt.
  9. Verfahren nach Anspruch 8, wobei der zweite öffentliche Schlüssel (g', v_i') unter Verwendung eines dritten öffentlichen Schlüssels (v_i) berechnet wird, der mit dem durch die entfernte Einrichtung erzeugten geheimen Schlüssel verbunden ist.
  10. Verfahren nach Anspruch 8 oder 9, wobei der zweite öffentliche Schlüssel (g', v_i') beruhend auf einem öffentlichen Parameter (g) berechnet wird.
  11. Verfahren nach einem der Ansprüche 8 bis 10, wobei die digitale Signatur (Sig_ca) den zweiten öffentlichen Schlüssel enthält.
  12. Verfahren nach einem der Ansprüche 8 bis 11, wobei der Bereitstellungsschritt das Zertifikat (APC_ca) des zweiten öffentlichen Schlüssels (g', v_i') für einen Host in einem Unternetzwerk bereitstellt.
  13. Verfahren nach einem der Ansprüche 8 bis 12, wobei der Bereitstellungsschritt für den Host das Zertifikat des zweiten öffentlichen Schlüssels (g', v_i') und Informationen zur Bestimmung einer Adresse des Host bereitstellt.
  14. Verfahren nach einem der Ansprüche 8 bis 13, ferner mit einem Verbindungsschritt der Verbindung des Host, dem das Zertifikat (APC_ca) des zweiten öffentlichen Schlüssels (g', v_i') durch den Bereitstellungsschritt bereitgestellt wird, mit dem Internet.
  15. Computerprogramm mit Computercode zum Veranlassen eines Computersystems zum Durchführen der Verfahrensschritte nach einem der Ansprüche 8 bis 14, wenn das Computerprogramm in das Computersystem geladen und ausgeführt wird.
DE60308251T 2002-04-17 2003-04-15 Vorrichtung zur Bereitstellung von öffentlichen Schlüsselzertifikaten Expired - Lifetime DE60308251T2 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2002115095 2002-04-17
JP2002115095 2002-04-17

Publications (2)

Publication Number Publication Date
DE60308251D1 DE60308251D1 (de) 2006-10-26
DE60308251T2 true DE60308251T2 (de) 2007-08-30

Family

ID=28672647

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60308251T Expired - Lifetime DE60308251T2 (de) 2002-04-17 2003-04-15 Vorrichtung zur Bereitstellung von öffentlichen Schlüsselzertifikaten

Country Status (4)

Country Link
US (1) US7529926B2 (de)
EP (1) EP1355447B1 (de)
CN (1) CN100499532C (de)
DE (1) DE60308251T2 (de)

Families Citing this family (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7194620B1 (en) * 1999-09-24 2007-03-20 Verizon Business Global Llc Method for real-time data authentication
US7461251B2 (en) 2002-05-09 2008-12-02 Canon Kabushiki Kaisha Public key certification issuing apparatus
US9009084B2 (en) 2002-10-21 2015-04-14 Rockwell Automation Technologies, Inc. System and methodology providing automation security analysis and network intrusion protection in an industrial environment
US8909926B2 (en) * 2002-10-21 2014-12-09 Rockwell Automation Technologies, Inc. System and methodology providing automation security analysis, validation, and learning in an industrial controller environment
US8156339B2 (en) * 2004-07-21 2012-04-10 Sanyo Electric Co., Ltd. Method for transmission/reception of contents usage right information in encrypted form, and device thereof
KR100643761B1 (ko) * 2005-01-28 2006-11-10 삼성전자주식회사 애드 혹 네트워크에서 주소 할당 방법 및 시스템
JP2007004461A (ja) * 2005-06-23 2007-01-11 Nec Corp サービス提供システム、アウトソーシング業者装置、サービス提供方法およびプログラム
JP4148246B2 (ja) * 2005-06-30 2008-09-10 ブラザー工業株式会社 通信システム、証明書更新装置、証明書更新プログラム、通信装置及び代替更新プログラム
JP4879524B2 (ja) * 2005-06-30 2012-02-22 ブラザー工業株式会社 通信装置、通信システム及びプログラム
US7861077B1 (en) * 2005-10-07 2010-12-28 Multiple Shift Key, Inc. Secure authentication and transaction system and method
US20080046571A1 (en) * 2006-08-16 2008-02-21 Nokia Corporation Pervasive inter-domain dynamic host configuration
US20080077976A1 (en) * 2006-09-27 2008-03-27 Rockwell Automation Technologies, Inc. Cryptographic authentication protocol
JP4410791B2 (ja) * 2006-12-20 2010-02-03 富士通株式会社 アドレス詐称チェック装置およびネットワークシステム
CN101335744B (zh) * 2007-06-29 2013-06-05 华为技术有限公司 一种加密生成地址的配置方法、系统和装置
CN101364974B (zh) * 2007-08-10 2011-09-07 北京三星通信技术研究有限公司 用于传输DHCP相关KEY的扩展的diameter方法
US8239549B2 (en) * 2007-09-12 2012-08-07 Microsoft Corporation Dynamic host configuration protocol
US8806565B2 (en) * 2007-09-12 2014-08-12 Microsoft Corporation Secure network location awareness
EP2217995A4 (de) * 2007-10-26 2012-11-21 Telcordia Tech Inc Verfahren und system zur sicheren sitzungsherstellung unter verwendung von auf identität basierender verschlüsselung (vdtls)
CN101547223B (zh) * 2008-03-26 2012-11-21 华为技术有限公司 地址配置方法、装置和系统
US8959353B2 (en) 2009-03-31 2015-02-17 Topaz Systems, Inc. Distributed system for multi-function secure verifiable signer authentication
CN101815037A (zh) * 2010-04-28 2010-08-25 中兴通讯股份有限公司 一种缺省路由信息的处理方法及装置
US8976807B2 (en) * 2011-06-07 2015-03-10 Cisco Technology, Inc. Dynamically determining hostnames of network devices
US10484355B1 (en) 2017-03-08 2019-11-19 Amazon Technologies, Inc. Detecting digital certificate expiration through request processing
US8886775B2 (en) * 2012-03-08 2014-11-11 Cisco Technology, Inc. Dynamic learning by a server in a network environment
US8392712B1 (en) 2012-04-04 2013-03-05 Aruba Networks, Inc. System and method for provisioning a unique device credential
US9325711B2 (en) * 2012-12-11 2016-04-26 Servmax, Inc. Apparatus and data processing systems for accessing an object
SG10201708125PA (en) 2013-04-05 2017-11-29 Biomarck Pharmaceuticals Ltd Inhibitors of metastasis
JP6079394B2 (ja) * 2013-04-11 2017-02-15 富士通株式会社 証明書生成方法、証明書生成装置、情報処理装置、通信機器、及びプログラム
CN103347102B (zh) * 2013-06-28 2016-08-10 华为技术有限公司 冲突地址检测报文的识别方法及装置
US10771261B1 (en) * 2016-09-29 2020-09-08 EMC IP Holding Company LLC Extensible unified multi-service certificate and certificate revocation list management
US10615987B2 (en) * 2017-03-08 2020-04-07 Amazon Technologies, Inc. Digital certificate usage monitoring systems
US10516542B2 (en) * 2017-03-08 2019-12-24 Amazon Technologies, Inc. Digital certificate issuance and monitoring
US10447665B2 (en) * 2017-03-31 2019-10-15 Konica Minolta Laboratory U.S.A., Inc. IPv6 link local secure network with biometric security to secure IOT devices
CN109921898A (zh) * 2019-03-28 2019-06-21 新华三技术有限公司 IPv6无状态地址生成方法及装置
US11218304B2 (en) * 2019-09-23 2022-01-04 Keeper Security, Inc. System and method for detecting breached passwords without disclosing identifiable information

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5005200A (en) * 1988-02-12 1991-04-02 Fischer Addison M Public key/signature cryptosystem with enhanced digital signature certification
US5606617A (en) * 1994-10-14 1997-02-25 Brands; Stefanus A. Secret-key certificates
US5689565A (en) * 1995-06-29 1997-11-18 Microsoft Corporation Cryptography system and method for providing cryptographic services for a computer application
US5790677A (en) * 1995-06-29 1998-08-04 Microsoft Corporation System and method for secure electronic commerce transactions
EP0835572A1 (de) * 1995-06-30 1998-04-15 Stefanus Alfonsus Brands Beschränkt verdeckbare beglaubigungen von geheimschlüsseln
EP0804003A3 (de) * 1996-04-26 2000-11-15 Canon Kabushiki Kaisha Verfahren zur digitalen Unterschrift und Kommunikationssystem
US5903882A (en) * 1996-12-13 1999-05-11 Certco, Llc Reliance server for electronic transaction system
US5982898A (en) * 1997-03-07 1999-11-09 At&T Corp. Certification process
US6978017B2 (en) * 1997-10-14 2005-12-20 Entrust Limited Method and system for providing updated encryption key pairs and digital signature key pairs in a public key system
US6374357B1 (en) * 1998-04-16 2002-04-16 Microsoft Corporation System and method for regulating a network service provider's ability to host distributed applications in a distributed processing environment
US6233341B1 (en) * 1998-05-19 2001-05-15 Visto Corporation System and method for installing and using a temporary certificate at a remote site
US20020004900A1 (en) * 1998-09-04 2002-01-10 Baiju V. Patel Method for secure anonymous communication
JP2000115160A (ja) 1998-10-05 2000-04-21 Ntt Data Corp 公開鍵証明証発行システム、方法及び記録媒体
US6675296B1 (en) * 1999-06-28 2004-01-06 Entrust Technologies Limited Information certificate format converter apparatus and method
US7194620B1 (en) * 1999-09-24 2007-03-20 Verizon Business Global Llc Method for real-time data authentication
US6842863B1 (en) * 1999-11-23 2005-01-11 Microsoft Corporation Certificate reissuance for checking the status of a certificate in financial transactions
FI109950B (fi) * 2000-01-20 2002-10-31 Nokia Corp Osoitteen saanti
US7275155B1 (en) * 2000-09-01 2007-09-25 Northrop Grumman Corporation Chain of trust processing
JP2002099211A (ja) * 2000-09-21 2002-04-05 Sony Corp 公開鍵証明書発行要求処理システムおよび公開鍵証明書発行要求処理方法
US20020116610A1 (en) * 2001-02-22 2002-08-22 Holmes William S. Customizable digital certificates
US20030105876A1 (en) * 2001-11-30 2003-06-05 Angelo Michael F. Automatic generation of verifiable customer certificates
US7404078B2 (en) * 2002-06-26 2008-07-22 Lucent Technologies Methods and apparatus for private certificates in public key cryptography

Also Published As

Publication number Publication date
DE60308251D1 (de) 2006-10-26
EP1355447B1 (de) 2006-09-13
CN1452356A (zh) 2003-10-29
US7529926B2 (en) 2009-05-05
US20030200437A1 (en) 2003-10-23
EP1355447A1 (de) 2003-10-22
CN100499532C (zh) 2009-06-10

Similar Documents

Publication Publication Date Title
DE60308251T2 (de) Vorrichtung zur Bereitstellung von öffentlichen Schlüsselzertifikaten
DE602004010519T2 (de) Fernzugriffs-vpn-aushandlungsverfahren und aushandlungseinrichtung
EP1361694B1 (de) Vorrichtung zur Ausgabe von Zertifikaten eines öffentlichen Schlüssels
DE60031878T2 (de) Schlüsselaustausch für eine netzwerkarchitektur
DE10296445B4 (de) Adress-Mechanismen im Internet-Protokoll
DE69831974T2 (de) Verfahren zur paketauthentifizierung in gegenwart von netzwerkadressübersetzungen und protokollumwandlungen
DE60013588T2 (de) Sim authentifizierungsmechanismus für dhcrv4/v6 nachrichten
DE60302882T2 (de) Sicherheitsübertragungsprotokoll für ein mobilitäts-ip-netzwerk
DE60302276T2 (de) Verfahren zur ferngesteuerten Änderung eines Kommunikationspasswortes
DE112019001209T5 (de) Sicheres Ble-Just-Works-Koppelverfahren gegen Man-In-The-Middle-Angriffe
CN101114900A (zh) 一种组播业务认证方法及其装置、系统
DE602004012233T2 (de) Verfahren zur Bereitstellung eines Signierungsschlüssels zur digitalen Signierung, Überprüfung oder Verschlüsselung von Daten
DE102009041805A1 (de) SIP-Signalisierung ohne ständige Neu-Authentifizierung
CN101217482A (zh) 一种穿越nat下发策略的方法和一种通信装置
JP3782788B2 (ja) 公開鍵証明書提供装置、方法、及び、接続装置
WO2018039901A1 (zh) 用于ip地址分配的方法、装置、系统和计算机程序产品
DE602005004341T2 (de) Cookie-basiertes Verfahren zur Authentifizierung von MAC-Nachrichten
US20070162607A1 (en) Insertion of protocol messages through a shim
CN101232369B (zh) 动态主机配置协议中密钥分发方法和系统
JP2003345742A (ja) ＣＵＧ（ＣｌｏｓｅｄＵｓｅｒＧｒｏｕｐ）管理方法及びＣＵＧ提供システム及びＣＵＧ提供プログラム及びＣＵＧ提供プログラムを格納した記憶媒体
JP4280536B2 (ja) 公開鍵生成装置、方法、及び、公開鍵証明書発行方法
Braun et al. An AAA architecture extension for providing differentiated services to mobile IP users
JP4208868B2 (ja) 公開鍵証明書発行方法
US20200287868A1 (en) Systems and methods for in-band remote management
Carpenter et al. Connecting IPv6 Routing Domains Over the IPv4 Internet

Legal Events

Date Code Title Description
8364 No opposition during term of opposition