專利名稱：公鑰證明書發(fā)行裝置的制作方法
技術領域：
本發(fā)明涉及發(fā)行公鑰證明書的發(fā)行裝置。
背景技術：
由于IPv6的出現，已經需要考慮以往無需與網絡連接的裝置與網絡連接的情況了。例如，可以直接與因特網連接的面向最終用戶的數字照相機。
在與IPv6對應的個人計算機和工作站的情況下，與網絡連接的接口通常使用以太網(R)，以具有它的IEEE接口(傳輸媒體訪問控制地址)為基礎構成IPv6地址。
對于IPv6地址，如后述那樣存在連線局部地址、站點局部地址和(可以聚集)全局地址這3種。
它們的詳細構成方法等的地址體系，在RFC 2373“IPVersion 6Addresssing Architecture”，RFC 2374“An IPv6 AggregatabaleGlobal Unicast Address Format”，RFC 2375“IPv6 Multicast AddressAssignment”，RFC 2450“Proposed TLA and NLA AssignmentRule”，RFC 2461“Neighbor Discovery for IP Version 6(IPv6)”，RFC 2462“IPv6 Stateless Address Autoconfiguration”等中有記載。
可是，如IEEE接口(傳輸媒體訪問控制地址)那樣固定使用與硬件一一對應的信息，被看作與裝置或者該裝置的用戶一一對應的信息，由于是監(jiān)視使用該地址的通信，所以保密性被侵害的危險性較大。
針對這一問題，在RFC3041“Privay Extensions for StatelessAddress Autoconfiguration in IPv6”等中提出了生成隨機的IPv6地址(準確地說是接口ID)的方法。還記述了在所生成的隨機地址值已經被使用了的情況下，檢測它，并計算/生成另一隨機值，確定唯一的隨機值的協議(的擴展)。
在裝置使用利用上述那樣的解決方法生成的隨機的IPv6地址的情況下，考慮用IPsec進行加密通信的情形。IPesc是因特網上的2個裝置共有其他人不知道的秘密數據，根據該秘密數據進行加密和認證的協議，在通信時需要安全地共用秘密數據和相互的IPv6地址等。秘密數據和相互的IPv6地址等數據被稱為SA(安全關聯)。
安全地共用SA的協議被稱為IKE(因特網密鑰交換)，在RFC2409“因特網密鑰交換(IKE)”中被規(guī)定。在此，安全地共用SA的意義是只和希望的對方可靠地共用SA，所以需要確認對方。在IKE中，規(guī)定了1)使用預共享鍵(pre-shared key)的方法，2)使用數字署名的方法，3)采用公鑰密碼的加密方法，4)采用公鑰密碼的加密的修訂模式的方法這4種認證方法。
可是，考慮實現保護保密性(不給予明確的身份信息)的狀況，例如用戶進行與購物站點的IPsec通信的情況，如果站在購物站點的立場上考慮，因為要在IPsec通信前與預先不確定的不特定多個通信對方共用預共享鍵，所以不能使用預共享鍵的方法。
在其他的方法的情況下，如果可以可靠地得到在使用數據署名或者公鑰密碼時所需要的信息(在多數情況下是公鑰)，則可以在不特定多個通信對方之間執(zhí)行IKE。因此最有希望的是被稱為PKI(公鑰基礎結構)的環(huán)境結構，其中起到中心效果的是公鑰證明書。
公鑰證明書是可以信賴的第三者為了確認實體(通信的主體，計算機和人)和其主體的公鑰的對應關系，并保證它，由可以信賴的第三者發(fā)行的相對于實體的ID信息等與公鑰的組合的數字署名?？梢孕刨嚨牡谌弑环Q為CA(認證機構)，而用于確認CA的數字署名的正當性的公鑰，是眾所周知的。
但是，在現在運用的公鑰證明書中， 因為包含表示其主體(Subject)的ID信息，例如FQDN(完全符合域名)，所以這樣不能實現安全性保護。
在公鑰證明書中還可以考慮未包含其主體的ID信息的方法，被稱為匿名公鑰證明書。
但是，在匿名公鑰證明書中也存在和上述的IEEE接口(傳輸媒體訪問控制地址)同樣的問題。即，只要繼續(xù)使用同一匿名公鑰證明書，就可以聯接到多個(基于公鑰證明書的IPsec等的)通信，則在一次明確了匿名公鑰證明書和其主體的對應關系時，就有可能侵害保密性，所以保密保護仍然較弱。
對于上述問題，例如，如果可以在與不同的通信對方通信時使用不同的IPv6以及匿名公鑰證明書，則可以實現較強的保密性保護。把它們稱為非重復使用IPv6地址以及非重復使用匿名公鑰證明書。作為非重復使用的間隔，考慮在每次改變通信對方時使用新的非重復使用IPv6地址，或者在每個信息包時改變等幾種。
但是，作為非重復使用IPv6地址，已知有上述的RFC3041“Privacy Extensions for Stateless Address Autoconfiguration inIPv6”，但并不知道向可以進行v6通信的裝置(以下，稱為IPv6對應裝置)高效率可靠地發(fā)行非重復使用匿名公鑰證明書的方法。
進而，還存在以下問題。在不知道通信對方的ID信息的情況下，只能利用IP地址進行通信對方的識別。但是，例如在以太網(R)的LAN上發(fā)送接收的信息包因為可以訪問其LAN上的全部節(jié)點，所以原本實體A和實體B應該通信的地點，有可能出現和A同樣的在LAN上具有惡意的C冒充A的現象。即，為了在A和B之間進行基于非重復使用匿名公鑰證明書的IPsec通信，在把A的公鑰證明書送到B時，通過把A的公鑰證明書偷換為C的證明書，則C就可以冒充A。
針對DNS(域名系統)服務器和路由器的DoS(拒絕服務)攻擊，其間如果偽DNS服務器和路由器發(fā)出偽信息，則不限于LAN，還可以在更廣泛的范圍中進行冒充。如果判明通信對方的ID，則可以通過識別它進行對應，但在上述所示那樣的匿名性高的狀態(tài)下，至今還不知道防止這種攻擊的方法。

發(fā)明內容
本發(fā)明的目的在于實現強力的保密性保護。
另外，本發(fā)明的另一目的，是防止冒充。
本發(fā)明的另一目的是，高效率并且可靠地，即不會出現發(fā)行對象錯誤地迅速發(fā)行在證明對象中包含有IPv6地址的非重復使用匿名公鑰證明書。
本發(fā)明的另一目的是，保密性保護程度高地，可以以低成本實現地，高效率地實現執(zhí)行時負荷小的非重復使用匿名公鑰證明書。
本發(fā)明的另一目的是，高效率地實現IPsec通信。
本發(fā)明的另一目的是，實現強力的保密性保護，并且在防止冒充的同時進行采用IKE的IPsec通信。
本發(fā)明的其它目的，可以從以下的實施例的說明中明確。


圖1是實施例1中的匿名公鑰證明書發(fā)行協議(以太網(R)LAN的情況下)的圖。
圖2是以太網(R)LAN的模式圖。
圖3是節(jié)點結構圖。
圖4是以太網(R)的傳輸媒體訪問控制地址的結構圖。
圖5是接口ID的結構圖。
圖6是試探性連線局部地址(a tentative link-local address)的結構圖。
圖7是某個試探性連線局部地址的應答節(jié)點多點廣播地址的結構圖。
圖8是說明主機在結束DAD(重復地檢測)前的動作的流程圖。
圖9是說明主機在結束地址自動設定前的動作的流程圖。
圖10是主機在DHCP下取得地址前的動作流程圖。
圖11是主機進行地址自動設定，至取得匿名公鑰證明書前的動作流程。
圖12是主機在DHCP下至取得地址和匿名公鑰證明書前的動作流程圖。
圖13是在實施例2中的匿名公鑰證明書發(fā)行協議(PPP的情況下)的圖。
圖14是撥號/ADSL連接模式圖。
圖15是在實施例2中的匿名公鑰證明書發(fā)行協議(以太網(R)LAN的情況下)的圖。
圖16是主機直至取得證明書為止的動作流程圖。
具體實施例方式
(實施例1)在本實施例中，說明主機經由以太網(R)的LAN與因特網進行連接的情況。首先說明其狀況，其后說明本發(fā)明的實施例。
圖2是模式化展示適用本發(fā)明的連接環(huán)境(主機經由以太網(R)的LAN與因特網進行連接的環(huán)境)的圖。
圖2展示了連接在LAN上的主機204、205、206經由缺省網關202訪問因特網201的環(huán)境。在本實施例中，假設各主機通過連線207連接，具體地說就是以太網(R)。所謂連線，是指與它連接的裝置可以經由它進行通信的設備或者介質，連接在IP層的下層。在連線中除了以太網(R)以外，還有PPP連線，X.25，幀中繼，ATM網絡。
把與連線連接的IPv6對應裝置稱為節(jié)點。
圖3展示了節(jié)點的內部結構的典型例子。
在節(jié)點中有路由器和主機，路由器發(fā)送不是發(fā)給自己的信息包而主機不發(fā)送。由圖3可知，節(jié)點300是具有網絡接口301、302、CPU303、ROM304、RAM305、HD(硬盤)306、電源307、鍵盤/位置指示裝置的接口308、監(jiān)視器的接口309、總線310等的計算機。
與路由器具有多個接口301、302相反，主機在多數情況下具有一個接口301。網絡接口301被連接到連線207上，與被連接到連線207上的其他的節(jié)點通信。主機204、205、206通過網絡接口301，經由連線207與被連接到連線207上的其他節(jié)點通信，或者，還經由網關202與因特網201上的站點通信。在網關(路由器)202中，網絡接口302與因特網201連接，網關(路由器)202通過網絡接口302，經由因特網進行通信。進而，認證機構209也具有和圖3同樣的構成。認證機構209經由網絡接口301，與因特網201連接。根據節(jié)點不同也有不具有HD的。
進而，以下的處理內容(步驟)可以作為裝置或者程序被實現。即，在用裝置實現的形態(tài)下，具有該裝置的節(jié)點300執(zhí)行以下的處理內容(步驟)。另外，在作為程序實現的形態(tài)中，在ROM303或者HD306中存儲有該程序的節(jié)點執(zhí)行以下的處理內容(步驟)。例如，在作為程序實現的情況下，CPU303讀入該程序，根據需要一邊把RAM305作為用于計算的空間使用，一邊經由總線310進行把地址分配給接口301、302的動作。
簡單地說明了在本實施例的以太網(R)LAN環(huán)境下取得IPv6全局地址的前綴和缺省網關的地址的協議的結構，以下說明適用本發(fā)明的具體的實施例。
圖8展示了圖3的節(jié)點在電源接通或者重新啟動的情況下所執(zhí)行的動作的流程圖。該動作被稱為DAD(重復地址檢測)。以下，沿著圖8的流程說明處理內容。
在步驟S801中，節(jié)點300在電源接通或者重新啟動后，首先根據網絡接口301的以太網(R)的傳輸媒體訪問控制地址(參照圖4)生成接口ID(參照圖5)，把它作為試探性連線局部地址(tentativelink-local address)(參照圖6)(步驟S802)。
以下，為了判斷該試探性連線局部地址在連線上是否是唯一的，節(jié)點300進行以下的處理。
最初，進行接口301的初始設定。即，向接口301分配全節(jié)點多點廣播地址(FF021)、該試探性連線局部地址的應答節(jié)點多點廣播地址(參照圖7)。即，該接口301在發(fā)現發(fā)送到全節(jié)點多點廣播地址的信息包或者發(fā)送到該試探性連線局部地址的應答節(jié)點多點廣播地址的信息包時，把它作為發(fā)送到自己的接口地址的信息包進行接收。
通過分配前者(全節(jié)點多點廣播地址)，可以接收到來自已經使用該試探性連線局部地址的另一節(jié)點的數據。另外，通過分配后者(該試探性連線局部地址的應答節(jié)點多點廣播地址)，可以檢測出要同時使用同一試探性連線局部地址的另一節(jié)點的存在。
所謂某一試探性連線局部地址的應答節(jié)點多點廣播地址，是指如RFC2461第91頁定義的那樣的，把試探性連線局部地址的下位24位附加在前綴FF0200001FF00/104上的數據，就是局域連接范圍多點廣播地址(link-local scope multicast address)。圖6和圖7展示了它們的關系。以上的地址分配就是圖8的步驟S803。
以下，生成相鄰征求信息。在相鄰征求信息的目標地址中設定判斷對象的試探性連線局部地址，在IP源(發(fā)送源地址)中設定不確定地址(128位全部是0)，在IP目的地(目的地地址)中設定判斷對象的試探性連線局部地址的應答節(jié)點多點廣播地址。
把該相鄰征求信息以中繼定時器的毫秒間隔發(fā)送多地址檢測傳送個到以太網(R)207。圖8的步驟S804就是該處理。
接收到相鄰征求信息的節(jié)點，如果其發(fā)送源地址是不確定地址，則判斷為該信息是來自進行DAD的節(jié)點的數據。
在多個節(jié)點同時把同樣的地址作為對象進行DAD的情況下，除了自己發(fā)送的相鄰征求信息以外，因為還接收到在目標地址中包含相同地址的相鄰征求信息(接收到自己發(fā)送的相鄰征求信息和同時把該地址作為對象進行DAD的另一節(jié)點發(fā)送的相鄰征求信息)，所以知道發(fā)生了重復。在這種情況下，哪個節(jié)點也不使用該地址。
進而，如果接收到的相鄰征求信息是自己發(fā)送的(為了應答多點廣播的信息包)，則表示不存在其他使用它或者要使用它的節(jié)點。除了自己發(fā)送的相鄰征求信息，在接收到在目標地址中包含相同地址的相鄰征求信息的情況下，判斷為多個節(jié)點同時把同樣的地址作為對象進行DAD。
另一方面，如果接收到相鄰征求信息的節(jié)點已經使用包含在信息的目標地址中的地址，則把在目標地址中設定有該試探性連線局部地址(tentative link-local address)的多點廣播相鄰通知反送回全節(jié)點多點廣播地址。因而，發(fā)送了相鄰征求信息的節(jié)點收到發(fā)送給全部節(jié)點多點廣播地址的多點廣播相鄰通知，在該目標地址是(判斷對象的)試探性(tentative)地址的情況下(圖8的S805步驟的“是”的情況)，判斷對象的試探性地址不是唯一的(即，是重復的)。
根據以上的DAD的結果，如果確認了判斷對象的試探性連線局部地址在連線207上是唯一的(圖8的S805步驟的“否”的情況下)，則把該地址作為連線局部地址分配給接口301。這是圖8的步驟S806。以上DAD結束。
以上說明的圖8的動作，可以由圖2的缺省網關202、DHCP服務器203、主機204、主機205、主機206各自執(zhí)行。
圖2的主機，例如主機206，如果把連線局部地址分配給接口301，則接著試著從缺省網關202得到為了確定站點局部地址和全局地址所需要的信息(被稱為路由器通知)。
圖9展示了該動作。缺省網關202因為通常被稱為路由器，所以以下表示為路由器202。路由器202由管理者進行必要的設定，并定期把路由器通知發(fā)送到連線207。在主機206想盡早得到路由器通知的情況下，主機206就把被稱為路由器請求的數據發(fā)送到路由器202。因為主機206在分配了連線局部地址之后不知道路由器202的存在，所以實際上路由器請求是向連線上的全部路由器進行多點廣播發(fā)送的。圖9的步驟S901表示了該處理。
接收到路由器請求的路由器202發(fā)送路由器通知。如圖9的步驟S902的“是”的情況所示，接收到只指定了無狀態(tài)地址自動配置的路由器通知的主機206，確認包含在該信息中的前綴的有效性(以前該裝置未使用等)，并把在其中附加了接口ID生成的地址，作為站點局部地址或者全局地址分配給接口301。圖9的步驟S903是該處理。
如圖9的步驟S902的“否”的情況所示，在主機206未接收到只指定無狀態(tài)地址自動配置的路由器通知的情況下，分為以下二種情況。接收到指定了無狀態(tài)地址自動配置和全狀態(tài)地址自動配置兩方的路由器通知的情況(步驟S904的“是”的情況)，和未接收到任何路由器通知的情況(步驟S904的“否”的情況)。
在后者的情況下，只執(zhí)行全狀態(tài)地址自動配置，即DHCPv6。這是步驟S906，圖10展示了其基本的動作流程圖。
進而，在全狀態(tài)地址自動配置中，接收發(fā)送的信息的內容和形式等的詳細，在“draft-ietf-dhc-dhcpv6-xx.txt”(在2002年3月，xx＝23是最新版本)被說明了。以下按照圖10的號碼說明基本的動作流程。
DHCP服務器203由管理者進行必要的設定。具體地說，把自己的連線局部地址分配給作為節(jié)點的接口301，并設定為了作為DHCP服務器動作所需要的站點局部地址或者全局地址用的前綴等。
在圖10的步驟S1001中，主機204向DHCP服務器發(fā)送DHCP征求信息。主機206因為不知道在哪里存在DHCP服務器，所以向DHCP服務器以多點廣播形式發(fā)送到連線207。當在與連接到主機206上的連線207不同的連線(未圖示)上有DHCP服務器的情況下，DHCP征求信息實際上通過DHCP中繼器(未圖示)被中繼送到DHCP服務器203。
收到DHCP征求信息的DHCP服務器203作為對它的回應把通知信息返送到主機206。它(在另一連線的情況下通過DHCP中繼器中繼)被送到主機206。這是步驟S1002。在該時刻主機206知道了DHCP服務器203的地址。
以下，在步驟S1003中主機206把DHCP請求信息送到DHCP服務器203。DHCP服務器203如果接收到DHCP請求信息，則在步驟S1004中把DHCP應答信息發(fā)送到主機206。
在步驟S1004中接收到DHCP應答信息的主機206，因為從其中知道了站點局部地址或者全局地址，所以為了確認該地址中的接口ID是否重復，進行DAD處理所需要的處理。即，向接口301設定上述的多點廣播地址等。這是步驟S1005。
以下，在步驟S1006中發(fā)送相鄰征求信息，在步驟S1007中判斷是否接收到相鄰通知信息。在接收到的情況下因為該地址重復，所以為了從DHCP服務器203接收另一地址就返回步驟S1003，重復同樣的處理。
當主機206在圖10的步驟S1007中未接收到相鄰通知信息的情況下，因為該地址不重復，所以在步驟S1008中把該地址分配給接口301。
以上圖9的步驟S906結束。在步驟S904中當任何路由器通知也未接收到的情況下，正常結束。
在步驟S902中，當接收到指定了非全局和全狀態(tài)地址自動配置兩方的路由器通知的情況下，在步驟S905中進行無狀態(tài)地址自動配置和全狀態(tài)地址自動配置這兩方，處理內容和步驟S903和S906一樣。
如上所述，具有把以太網(R)作為接口的主機206通過任意組合應用無狀態(tài)地址自動配置和全狀態(tài)地址自動配置(DHCPv6)，可以自動設定連線局部地址、站點局部地址、全局地址、缺省網關等。
在以上的協議中，當在接口ID中使用隨機值的情況下，如果把該值作為對象進行DAD，確認在連線207中的唯一性，則與全局地址的前綴進行組合，就可以利用非重復使用的IPv6全局地址了。詳細內容記述在“Privacy Extensions for Stateless AddressAutoconfiguration in IPv6”中。
以下說明本發(fā)明的實施例。說明擴展上述的動作(協議)，并可以利用非重復使用匿名公鑰證明書的協議。首先，說明匿名公鑰證明書的例子，其次說明用于高效率發(fā)行它的協議。
對于匿名公鑰證明書，在Kazuomi Oishi、Masahiro Mambo、Eiji Okamoto，“Anonymous Public Key Certificates and theirApplications”IEICE Transactions on Fundamentals of Electronics，Communications and Computer Sciences，E81-A，1，pp。56-64，1998中理論地提出了其概念和具體的實現方法，該基本實現方法還被揭示在USA專利6,154,841中。在這些方式中，證明書的用戶隱匿性體現在計算量中。
作為提供更強力的匿名性的方法，具有信息量隱匿性的匿名公鑰證明書的實現方法被揭示在Kazuomi Oishi，“Unconditionallyanonymous public key certificates”The 2000 Symposium onCryptography and Information Security，SCIS2000-C32，2000中。
在本發(fā)明中，可以利用被記載在上述的論文Kazuomi Oishi、Masahiro Mambo、Eiji Okamoto，“Anonymous Public KeyCertificates and their Applications”中的任意方式。在可以容許效率差的情況下，也可以使用上述論文中的方式1、方式2、方式3，這些也包含在本發(fā)明中。
在本實施例中以使用具有計算量隱匿性的匿名公鑰證明書方式的情況為例說明。在定義、導入說明所需要的記號等后，說明本實施例的協議。
發(fā)行匿名公鑰證明書的實體CA確定作為共用的參數的大的素數p和q。q能除盡p-1。還確定指令q的生成源g和隨機函數H。生成秘密的隨機數s-ca(1以上q以下)，計算v-ca＝g^(s-ca)mod p。在此，A＝(B)^(C)mod D表示對于整數A、B、C、D，用D除B乘C的值，把其余數作為A的計算。實體CA公開p和q和g和H和v-ca。因而，實體i掌握p和q和g和H和v-ca。
另一方面，使用匿名公鑰證明書的實體i生成秘密的隨機數s-i(1以上q以下)，并計算v-i＝g^(s-i)mod p。把s-ca和s-i稱為密鑰，把v-ca和v-i(以及公開的參數(g等))稱為公鑰，密鑰的管理除自己以外誰都不知道。實體CA，以及i，掌握公鑰v-ca和v-i(以及公開的參數(g等))。
實體i在開始使用匿名公鑰證明書時，把自己的實體名(用戶名)和口令、公鑰v-i登錄在實體CA上。實體CA根據需要用物理方法等識別實體的身份，存儲被提示的實體名(用戶名)和口令、公鑰v-i。
在發(fā)行匿名公鑰證明書時，實體CA生成隨機數r(1以上q以下)，計算(g’，v-i’)＝(g^r mod p，(v-i)^(r)mod p)。把公開的參數(p等)和該匿名公鑰證明書的有效期限、對公鑰v-ca的公鑰證明書等的證明書的管理·屬性信息作為X，則對于包含(g’v-i’)和X的信息(的隨機值)生成數字署名。CA可以使用基于離散對數問題的數字署名方式，例如，可以使用Schnorr署名方式。在此，使用密鑰s-ca生成數字署名。把該數字署名記為Sig-ca(g’，v-i’，X)。
對于實體i，CA發(fā)行的匿名公鑰證明書APC-ca(i)是APC-ca(i)＝(g’，v-i’，X，Sig-ca(g’，v-i’，X))。進而，在本發(fā)明的變形例中，在匿名公鑰證明書的管理·屬性信息X中不包含針對v-ca的公鑰證明書。
接收到匿名公鑰證明書APC-ca(i)＝(g’，v-i’，X，Sig-ca(g’，v-i’，X))的實體i從其中取出(g’，v-i’，X)，計算其隨機值(例如，H(g’|v-i’|X)，而|表示連接)，利用公鑰v-ca確認Sig-ca(g’，v-i’，X)是否是相對于隨機值的正確的數字署名。另外，還確認v-i’＝(g’)^(s-i)mod p。如果可以確認它們是正確的，則可以把g’和v-i’(和共用的參數p)作為公鑰，把s-i作為密鑰使用基于離散對數問題的公鑰密碼和數字署名。
接收到匿名公鑰證明書(g’，v-i’，X，Sig-ca(g’，v-i’，X))的實體從其中取出(g’，v-i’，X)，計算其隨機值，利用公鑰v-ca確認Sig-ca(g’，v-i’，X)是否是相對于隨機值的正確的數字署名。如果可以確認其是正確的，則可以用g’和v-i’(和共用的參數p)進行基于離散對數問題的公鑰密碼的加密和數字署名的驗證。
進而，在上述的敘述中說明了基于乘法群(mod p)上的離散對數問題的困難性的署名方式，但也可以使用基于橢圓曲線上的離散對數問題的困難性的署名方式，在這種情況下因為可以用比乘法群還少位數的鑰實現同樣的安全性，所以效率更高。
下面說明把以上的匿名公鑰證明書方式適用于圖2的環(huán)境的情況。
認證機構209是實體CA，主機206是(或者利用它的用戶)利用匿名公鑰證明書的實體i。但是，認證機構209當然不具有上述匿名公鑰證明書方式中的CA的全部功能。以下，說明存在于利用公鑰證明書的IPv6對應裝置(主機206)的位置的局部連線207內的，并且公鑰證明書發(fā)行者(CA，即認證機構209)信任的IPv6對應裝置是缺省網關202的情況。即，在公鑰證明書方式中的實體CA的功能的一部分，代替認證機構209而具有缺省網關202的情況。
進而，CA209信任的IPv6對應裝置也可以是DHCP服務器203和專用CA服務器。另外，以下，說明在證明書中包含隨機的IPv6地址的形態(tài)，也許還有在證明書中未包含隨機IPv6的形態(tài)。如上所述，把缺省網關202稱為路由器202。
認證機構209的管理者確定上述的公開參數p、g等，并公開。另外，確定作為實體CA的公鑰v-ca。
在此，所謂認證機構209信任缺省網關202(或者DHCP服務器和專用CA服務器)，是指使明確缺省網關202等的管理源，在發(fā)生問題時由該管理源負責的條件下，在認證機構209和其管理源之間進行協商。例如，在發(fā)生與某一匿名公鑰有關的故障時，缺省網關202等的管理源有責任明確該匿名公鑰的用戶，并負責進行處理，并在認證機構209和缺省網關202等的管理源之間通過合同進行協商的情況等。
另外，在這種情況下，認證機構209和缺省網關202(或者DHCP服務器和專用CA服務器)，例如，通過安全地交換公鑰密碼或者安全地共用秘密的密鑰等，可以在它們之間經由因特網安全可靠地進行通信。
路由器202具有控制信息包的轉送的作用，管理者負責禁止在該路由器202管轄的子網絡和外部之間的不正當的信息包進出。某一子網絡為了連接在因特網201上，該子網絡的管理者把身份登錄在JPNIC(在日本的情況下)上，并接收IP地址的分配。因而，因為在子網絡中的路由器202管理責任明確，并且還考慮到了安全方面，在運用和管理上花費了費用，所以認為認證機構209是可信任的。
在用戶i申請對LAN進行訪問時，使用公開的參數p、g等生成自己的密鑰s-i，計算對應的公鑰v-i，并把用戶名和口令、公鑰v-i提交給LAN的管理者(路由器202的管理者)。LAN的管理者(路由器202的管理者)根據其運營方針進行用戶i的身份確認和口令的核對等，許可訪問。管理者將其，登錄在路由器202的RAM305或者HD306上并使從用戶i的實體名可以檢索到用戶i的公鑰v-i。假設公開參數和公鑰v-i，特別是密鑰s-i由用戶i管理，并可以在主機206中安全地被利用。
進行以上的準備后執(zhí)行的本實施例的協議如圖1所示。在圖1中把實體(用戶i使用的IPv6終端)作為主機206，把CA作為認證機構209，認證機構209信任路由器202，并在它們之間進行匿名公鑰證明書的發(fā)行協議。在此，路由器202是把用于設定地址的地址信息提供給主機(通信裝置)206的地址信息提供裝置，或者提供者。進而，地址信息是IPv6的全局地址的前綴，或者是IPv6全局地址自身。
因為為了發(fā)行匿名公鑰證明書需要特定實體，所以是在路由器202和實體(這種情況下，是主機206)之間執(zhí)行某一特定的(認證)協議。在本實施例中，把基于以下那樣的公鑰密碼的方式作為例子說明。按照圖1的流程說明其動作。
主機206在步驟S101中生成認證請求。認證請求是要求匿名公鑰證明書的信息，假設是路由器202可以理解的包含其主旨和接口301的接口ID的數據的形式。內容可以根據實體名(用戶名)和口令和串行號碼計算得出。串行號碼可以采用例如將主機206的IPv6連線局部地址和缺省網關的IPv6連線局部地址和此時的時刻這3項連接起來作為一個數據的值。為了防止再發(fā)送攻擊和冒充，相對于把實體名(用戶名)和口令和串行號碼輸入到隨機函數中的值，使利用密鑰s-i生成的數字署名(認證用署名)(＝Sig-i(hash(實體名，口令，串行號碼)))被包含在認證請求中。
以下，在步驟S102中主機206把認證請求從網絡接 301發(fā)送到路由器202。
在步驟S103中，路由器202從RAM305或者HD306中檢索出根據在步驟S102中從網絡接 301接收到的包含在認證請求中的實體名(識別符)登錄的公鑰v-i，并使用它確認認證用署名的正當性。具體地說，把實體名(用戶名)和口令和串行號碼作為隨機函數的輸入，求出其隨機值，用公鑰v-i確認認證用署名是與此相對的正當的數字署名。即，如果接 301從主機206接收到包含數字署名的認證請求，則CPU303利用主機206的公鑰v-i，確認數字署名的正當性。如上所述，路由器202根據公鑰密碼，確認主機206。
如果認證成功，則路由器202根據IPv6的全局地址的前綴和主機206的接口301的接口ID生成主機206的IPv6全局地址。而后，在S103A中，生成隨機數r，如上所述，根據生成源g和公鑰v-i，求出(g’，v-i’)＝(g^r mod p，(v-i)^(r)mod p)(把該g’和v-i’這兩個稱為匿名公鑰)。即，CPU303根據公鑰v-i生成v-i’。而后，生成作為相對于主機206的IPv6全局地址和匿名公鑰(g’，v-i’)的路由器202的署名的認證用署名(2)。
進而，在此，認證成功后，生成了公鑰v-i’，但在變形例中，認證成功前，或者在請求匿名公鑰證明書前，預先生成公鑰v-i’，并登錄在RAM305、HD306中。
最后在步驟S104中，把包含IPv6全局地址和匿名公鑰和與它們對應的認證用署名(2)的匿名公鑰證明書信息＝{IPv6全局地址、匿名公鑰、認證用署名(2)}，從網絡接 302經由因特網201發(fā)送到認證機構209。即，在CPU303的控制下，接口302把請求發(fā)行相對于匿名公鑰(g’，v-i’)的公鑰證明書的公鑰證明書請求信息，發(fā)送到認證機構209中。認證機構209是發(fā)行公鑰證明書的發(fā)行者，或者發(fā)行裝置。路由器202是公鑰生成裝置。路由器202的接口301是經由網絡207與通信裝置(主裝置206)進行通信的通信裝置，CPU303是生成公鑰的生成裝置。另外，路由器202的接口302是在從通信裝置(主機206)請求公鑰證明書時，把由CPU302生成的公鑰發(fā)送到公鑰證明書發(fā)行者(CA209)的發(fā)送裝置。
如上所述，因為路由器202和認證機構209可以經由因特網201安全可靠地進行通信，所以不會有數據內容被篡改或者第三者冒充。
在步驟S105中，認證機構209確認從網絡接口301取得的認證用署名(2)是否確實是在正當的路由器202中生成的。由上述可靠的安全通信接收的情況，包括證明了接收數據自身是由正常的路由器202生成的數據的情況?；蛘呤腔诠€密碼的數字署名的情況。
無論怎樣，確認了認證用署名(2)的正當性的認證機構209，在包含在證明書請求信息中的IPv6全局地址和匿名公鑰(g’，v-i’)中，針對附加了與它們有關的管理·屬性信息X后的信息(的隨機值)生成數字署名Sig-ca(g’，v-i’)。在該數字署名中，使用密鑰s-ca。證明書的管理·屬性信息X包含公開的參數和證明書的有效期限、v-ca的公鑰證明書等。在本發(fā)明的變形例中，在該信息X中，不包含對v-ca的公鑰證明書。匿名公鑰證明書APC-ca(i)是由IPv6全局地址、匿名公鑰(g’，v-i’)、與它們有關的管理·屬性信息X和與它們對應的數字署名組成的數據。即，如果接口301從路由器202接收到公鑰證明書請求信息，則CPU303對應于被包含在公鑰證明書請求信息中的IPv6全局地址的地址信息和公鑰(g’，v-i’)(以及證明書的管理·屬性信息X)的信息，生成數據署名。路由器202是把用于設定地址的地址信息提供給主機202(通信裝置)的提供者。
而后，在步驟S106中把匿名公鑰證明書APC-ca(i)＝(g’，v-i’，X，Sig-ca(g’，v-i’，X))從網絡接口301經由因特網201發(fā)送到路由器202。即，接口301發(fā)行包含有IPv6全局地址的地址信息、公鑰(g’，v-i’)和數字署名的公鑰證明書。
在步驟S107中，從網絡接口302取得了匿名公鑰證明書的路由器202把由IPv6全局地址的前綴、缺省網關202的地址和匿名公鑰證明書組成的認證通知從網絡接口301發(fā)送到已被認證了的主機206。在此，在本發(fā)明的一個實施例中，用已登錄的公鑰v-i進行加密后發(fā)送。即，接口301把由認證機構209對應于公鑰(g’，v-i’)發(fā)行的公鑰證明書發(fā)送到主機206。主機206是在S103中已被認證了的通信裝置，在S103中也是包含正當性被認證后的數字署名的認證請求的發(fā)送源。
在步驟S108中，從由網絡接口301取得的認證通知中取出前綴，生成IPv6全局地址，并確認匿名公鑰證明書的正當性。
在此，主機206，使用認證機構209的公鑰v-ca，確認匿名公鑰證明書APC-ca(i)＝(g’，v-i’，X，Sig-ca(g’，v-i’，X))的正當性，即，(g’，v-i’)和Sig-ca(g’，v-i’，X)的對應關系的正當性。例如，主機206從匿名公鑰證明書APC-ca(i)中取出(g’，v-i’，X)，計算該隨機值(例如，H(g’，|v-i’|，X)，其中|表示連接)，并用公鑰v-ca確認Sig-ca(g’，v-i’，X)是否是對應于隨機值的正當的數字署名。主機206預先存儲認證機構209的公鑰v-ca。在匿名公鑰證明書的管理·屬性信息X包含公鑰v-ca的公鑰證明書的狀態(tài)下，主機206在確認了預先存儲著的公鑰v-ca與包含在匿名公鑰證明書的管理·屬性信息X中的公鑰v-ca的公鑰證明書中的公鑰v-ca是一致的后，用該公鑰v-ca確認匿名公鑰證明書的正當性。
圖11展示了把以上的協議和已有的路由器請求和路由器通知的發(fā)送接收協議組合后的擴展協議的主機的動作流程圖。
所謂圖11的步驟S1101中的路由器認證請求信息，是指包含了圖9的步驟901的路由器請求和在圖1的步驟S102中發(fā)送的認證請求兩方的數據。路由器202如果接收到該數據，則進行圖1的S103、S103A、S104的處理，并和S106一樣，從認證機構209中取得匿名公鑰證明書。而后，路由器202把包含有只指定了無狀態(tài)地址自動配置的路由器通知和認證通知兩方的路由器認證通知信息發(fā)送到主機206。
因而，所謂在步驟S1102中接收到的路由器認證通知信息，是指包含有在圖9的步驟S902中接收到的路由器通知信息和在圖1的步驟S107中接收到的認證通知兩方的數據。
如果在圖1中的步驟S108中可以確認正當性，則在步驟S1102中為“是”的情況下，在步驟S1103中生成IPv6全局地址，在分配給接口301的同時，確認匿名公鑰證明書的正當性。在此，和S108一樣，使用認證機構209的公鑰，確認匿名公鑰證明書的正當性。
通過以上的協議，可以不改變以往的協議的步驟數而發(fā)行與只在增加數據時可以非重復使用的IPv6地址對應的非重復使用匿名公鑰證明書。
進而，在代替路由器202而認證機構209信任DHCP服務器203的情況下，因為未接收到路由器認證通知信息，所以在圖11中的步驟S1106中，代替路由器202，而由DHCP服務器203執(zhí)行和圖1一樣的協議。進而，DHCP服務器的管理源和缺省網關202的管理源一樣具有故障時的責任。
這種情況下在圖11的步驟S1106中，主機執(zhí)行全狀態(tài)地址自動配置擴展協議，即從DHCP服務器取得地址和證明書的協議。圖12展示了其動作流程圖。
和圖10的協議不同之處是步驟S1203和步驟S1204兩處。
在步驟S1203中送出的DHCP認證請求信息，是包含有在圖10的步驟S1003中送出的DHCP請求信息和與在圖1的步驟S102中被送出的認證請求相當的數據(在發(fā)送目標不是路由器202而是DHCP服務器203這一點上不同)兩方的數據。
如果取得了該信息，則DHCP服務器203進行圖1的S103、S103A、S104的處理，和S106一樣，從認證機構209中取得匿名公鑰證明書。而后，DHCP服務器203把包含有DHCP應答信息和與認證通知相當的數據兩方的DHCP認證應答信息送到主機206。
因而，在步驟1204中取得的DHCP認證應答信息，是包含有在圖10的步驟S1004中取得的DHCP應答信息和與在圖1的步驟S107中取得的認證通知相當的數據(在發(fā)送源不是路由器202而是DHCP服務器203這一點上不同)兩方的數據。而后，生成IPv6全局地址，在分配給接口301的同時，確認匿名公鑰證明書的正當性。在此，和S108一樣，利用認證機構209的公鑰v-ca，確認匿名公鑰證明書的正當性。
通過以上的協議，可以不改變以往的協議的步驟數，發(fā)行與只在增加數據時可以非重復使用的IPv6地址對應的非重復使用匿名公鑰證明書。
在路由器202以及DHCP服務器203的兩方都被CA的認證機構209信任的情況，相當于在圖11中的步驟S1104中，接收到指定了非全局和全局這兩方的路由器認證通知信息的情況下(“是”的情況下)，通過任意組合應用上述的兩個擴展協議，可以自動設定以及取得連線局部地址、站點局部地址、非重復使用IPv6全局地址和與之對應的非重復使用匿名公鑰證明書、缺省網關等。這種情況下，路由器202以及DHCP服務器203相當于把用于設定地址的地址信息提供給主機(通信裝置)206的信息處理裝置群，作為該信息處理群的路由器202以及DHCP服務器203向認證機構209請求公鑰證明書，并把認證機構209發(fā)行的公鑰證明書發(fā)送到主機206。
在不是路由器202也不是DHCP服務器203的另一IPv6對應裝置的專用CA服務器得到公鑰證明書發(fā)行者209的信任，而專用CA服務器和公鑰證明書發(fā)行者209協調動作向某一主機發(fā)行公鑰證明書的情況下，如果該專用CA服務器存在于和對象主機相同的局部連線207內，則可以通過和圖1的路由器202的動作大致相同的動作發(fā)行公鑰證明書。
在圖2中，對象主機是主機206，在專用CA服務器是主機204的情況下，它們之間的動作和圖1一樣。而在專用CA服務器是其子網的情況下，如果是圖2的情況則其前提是需要知道分配給連線207的正當的IPv6前綴。因而由具有和路由器202的管理者一樣責任的管理者管理專用CA服務器，而在有問題時的應對等也和路由器202的情況一樣，要在認證機構209和管理者之間取得意見一致。
主機206在每次通信對方改變時，或者在每次通話改變時，或者在每次通信信息包發(fā)送時，從接口301向連線207發(fā)送圖11的S1101的路由器認證請求信息(作為圖1的S101的請求匿名公鑰證明書的信息的認證請求)，并從認證機構209取得匿名公鑰證明書。即，主機206通過根據需要，請求、取得新的公鑰證明書，實現保密性保護。進而，通過向通信對方發(fā)送包含IPv6地址的公鑰證明書，防止假冒。在此，公鑰證明書(g’，v-i’)是同一實體的公鑰，但也是隨著時間流逝變更的公鑰。
進而，說明了路由器202或者DHCP服務器203把IPv6地址的前綴提供給主機206的形態(tài)，但在通過IPv6地址自身的形態(tài)中，除了代替前綴而發(fā)送地址這一點和不需要主機生成地址的處理以外，其他用同樣的協議也可以實現。
(實施例2)在實施例1中，在缺省網關(路由器)認證了主機后，缺省網關(路由器)和認證機構協調動作，向主機發(fā)送匿名公鑰證明書和包含前綴的認證通知。在本實施例中，說明發(fā)送前綴和發(fā)行匿名公鑰證明書的獨立的例子。
和實施例1一樣，認證機構209為實體CA、主機206(或者利用它的用戶)是利用匿名公鑰證明書的實體i。但是，認證機構209并不具有在上述匿名公鑰證明書方式中的CA的全部功能。以下，說明存在于利用公鑰證明書的IPv6對應裝置(主機206)所在的局部連線207內，并且公鑰證明書發(fā)行者(CA，即認證機構209)信任的IPv6對應裝置是缺省網關202的情況。即，說明缺省網關202具有代替認證機構209而在匿名公鑰證明書方式中的實體CA的功能的一部分的情況。
進而，認證機構209信任的IPv6對應裝置也可以是DHCP服務器和專用服務器。另外，以下，說明在證明書中包含有隨機的IPv6地址的形態(tài)，但也許還有在證明書中不包含隨機IPv6地址的形態(tài)。如上所述，把缺省網關稱為路由器202。在此，缺省網關202，向主機206提供IPv6的全局地址的前綴。
另外，在這種情況下，假設認證機構209和缺省網關202(或者DHCP服務器和專用服務器)，例如，通過安全地交換公鑰密碼或者安全地共用秘密的密鑰等，在它們之間可以經由因特網安全可靠地進行通信。
認證機構209的管理者確定作為CA的公鑰v-ca。
路由器202的管理者確定上述公開參數p、g等，并公開。也可以確定并公開路由器202的公鑰v-router。
用戶i在申請對LAN的訪問時，使用被公開的參數p、g等生成自己的密鑰s-i，計算對應的公鑰v-i，并把用戶名和口令、公鑰v-i提供給LAN管理者(路由器202的管理者)。LAN的管理者(路由器202的管理者)根據其運營方針進行用戶i的身份確認和口令的核對等，允許訪問。管理者使根據實體名可以檢測出對應的公鑰v-i那樣地，登錄在RAM304或者HD306上。假設公開參數p、g等和公鑰v-i、特別是密鑰s-i由用戶i管理，并在主機206上可以安全地被利用。
圖15展示了在進行以上的準備后執(zhí)行的本實施例的協議。在圖15中，把利用公鑰證明書的實體(用戶i使用的IPv6終端)作為主機206，把提供前綴的IPv6終端作為缺省網關202，把發(fā)行匿名公鑰證明書的CA作為認證機構209，并展示了在它們之間進行的匿名公鑰證明書的發(fā)行協議的動作流程。
因為為了發(fā)行匿名公鑰證明書需要特定實體，所以在路由器202和實體(這種情況下，是主機206)之間執(zhí)行某種特定的(認證)協議。在本實施例下，把基于以下那樣的公鑰密碼的方式作為例子進行說明。參照圖15說明其動作。
在主機206接通電源或者重新啟動的情況下，根據網絡接口(圖3的301)的MAC地址(傳輸媒體訪問控制地址)生成接口ID。另外，主機206通過例如RFC3041的算法生成隨機的接口ID。而后，生成在根據MAC地址生成的接口ID上附加了規(guī)定的前綴的連線局部地址等，并把路由器請求(RS)發(fā)送到路由器(步驟S1501)。RS如上所述是連線上的至全部路由器的多點傳送。
路由器202在接收到RS后發(fā)送路由器通知(RA)(步驟S1502)。
接收到RA的主機206抽出包含在RA中的前綴，并根據從MAC地址生成的接口ID和前綴，生成全局地址(稱為“共用地址”)。另外，根據隨機的接口ID和前綴，生成非重復使用IPv6地址(稱為“暫時地址”)。而后，進行共用地址和暫時地址的重復檢測DAD(重復地址檢測)，確認在連線中的地址的唯一性，并向接口分配這些地址(步驟S1503)。
以下，主機206生成認證請求(步驟S1504)。認證請求是請求匿名公鑰證明書的信息，以主機202可以理解的包含主機206請求匿名公鑰證明書的主旨的數據形式被生成。例如，在RFC2986，“PKCS#10認證授權請求語法規(guī)范版本1.7”規(guī)定的PKCS#10，和REC2511、“因特網X.509證明書請求信息格式”等中規(guī)定了它們的形式。雖然省略了詳細說明，但假設是由證明書請求信息和對應的(主機的)署名組成的數據。在證明書請求信息中包含有暫時地址。
以下，主機206把認證請求經由連線207發(fā)送到路由器202(步驟S1505)。進而，因為主機206在此時知道路由器202的(單點傳播)地址，所以可以單點傳播。
路由器202從RAM305或者HD306中檢索根據在步驟S1505中取得的包含在認證請求中的實體名(主機206的識別符或者利用主機206的用戶姓名)登錄的公鑰v-i，并用它確認署名的正當性。如果確認成功，則生成主機206的匿名公鑰。具體地說，上述的g’、v-i’、p、q是匿名公鑰。而后，為了使認證機構209發(fā)行對應于匿名公鑰的證明書，生成匿名公鑰證明書請求信息(步驟S1506)。
以下，路由器202把匿名公鑰證明書請求信息發(fā)送到認證機構209(步驟S1507)。假設該匿名公鑰證明書請求信息的形式和上述的證明書請求信息一樣，并假設是由匿名公鑰證明書請求信息和由對應的路由器的署名組成的數據等。在該匿名公鑰證明書請求信息中包含有主機206的暫時地址。
從路由器202取得了匿名公鑰證明書請求信息的認證機構209，確認它是否由路由器202生成或者是否是正當的數據。例如，是通過上述可靠安全的通信取得的情況，可以是證明了接收到的數據自身是由正當的路由器202生成的數據的情況，或者是在基于公鑰密碼的數字署名的情況下可以用路由器的公鑰v-router確認的情況。
無論哪種情況，確認了匿名公鑰證明書請求信息的正當性的認證機構209，針對包含在證明書請求信息中的匿名公鑰(g’、v-i’、p、q)和暫時地址、附加了與它們有關的管理·屬性信息的信息(的隨機值)生成數字署名，并生成由該信息和署名組成的匿名公鑰證明書(步驟S1508)。在本發(fā)明的一個實施形態(tài)中，該匿名公鑰證明書包含認證機構209的公鑰。
而后，認證機構209把匿名公鑰證明書發(fā)送到路由器209(步驟S1509)。在本發(fā)明的一個實施形態(tài)中，使用登錄有該匿名公鑰證明書的公鑰進行加密、發(fā)送。
路由器202把包含匿名公鑰證明書的認證通知發(fā)送到主機206(步驟S1510)。在本發(fā)明的一個實施形態(tài)中，使用登錄有該認證通知的公鑰進行加密、發(fā)送。進而，這時，作為向暫時地址的單點廣播，也可以從認證機構209直接發(fā)送到主機206。
主機206根據接收到的認證通知確認匿名公鑰證明書的正當性(步驟S1511)。
圖16展示了把以上的協議和現存的無狀態(tài)地址自動配置以及全狀態(tài)地址自動配置組合后的擴展協議的主機的動作流程圖。
在主機206接通電源或者重新啟動的情況下，根據網絡接口(圖3的301)的MAC地址生成接口ID。另外，主機206利用例如RFC3041的算法生成隨機接口ID。而后，生成在根據MAC地址生成的接口ID上附加了規(guī)定的前綴的連線局部地址等，并把路由器請求(RS)發(fā)送到路由器(步驟S1701)。RS如上所述是連線上的至全部路由器的多點傳送。
如步驟S1702的“是”的情況所示，接收到只指定了無狀態(tài)地址自動配置的路由器通知信息(RA)的主機206，抽出包含在RA中的前綴，根據從MAC地址生成的接口ID和已抽出的前綴，生成全局地址(稱為共用地址)。另外，根據隨機的接口ID和已抽出的前綴，生成非重復使用IPv6地址(稱為暫時地址)。而后，進行共有地址和暫時地址的重復檢測DAD(重復地址檢測)，確認地址在連線中的唯一性，并向接口分配這些地址(步驟S1703)。
以下，主機206執(zhí)行證明書請求和證明書發(fā)行的協議(步驟S1707)。即，如圖15的步驟S1504、S1505所示，主機206生成認證請求，發(fā)送到路由器202。主機206從路由器202接收認證通知，確認包含在其中的匿名公鑰證明書的正當性。進而，在未取得任何路由器通知的情況下(步驟S1704的“否”的情況)，只執(zhí)行全狀態(tài)地址自動配置，即只執(zhí)行DHCPv6。這是步驟S1706，其詳細和圖10的協議相同。
在步驟S1704中，在接收到指定了無狀態(tài)地址自動配置和全狀態(tài)地址自動配置兩方的路由器通知信息的情況下，在步驟S1705中進行無狀態(tài)地址自動配置和全狀態(tài)地址自動配置兩方。處理內容和步驟S1703和S1706一樣。
(實施例3)在實施例3中，說明主機以撥號或者ADSL方式和因特網連接的情形，首先說明其狀況，之后說明本發(fā)明的形態(tài)。
圖14是模式化展示適用本發(fā)明的連接環(huán)境的圖。圖14展示了主機1406經由PSTN(公用交換電話網)，訪問ISP(因特網服務提供商)所提供的因特網1401的環(huán)境。在本實施例中，假設ISP和主機通過PPP(端對端協議)連線連接。
在圖14中，ISP的PPP端1402是節(jié)點，利用調制解調器1403經由PSTN1404接收來自主機1406的PPP連接請求。PPP端1402具有作為缺省網關模塊14021、DHCP模塊14022、認證模塊14023的功能。主機1406使用調制解調器1405通過PPP連接訪問PPP端1402。主機1406的結構和圖3一樣，經由網絡接口301與調制解調器1405連接。另外，PPP端1402的結構也和圖3一樣，經由網絡接口301與調制解調器1403連接，經由網絡接口302與連線1407(進而，因特網1401)連接。PPP端1402是把用于設定地址的地址信息提供給主機1406(通信裝置)的地址信息提供裝置。
在本實施例中，以調制解調器和PSTN為例進行說明，但即使是TA(終端適配器)和ISDN(綜合業(yè)務數字網)、PHS通信轉接器和PHS通信網、專用線連接裝置和專用線等其他的通信形態(tài)，如果是可以確立PPP連接的環(huán)境，則本質上是相同的。PPP連接的詳細，被記述在REC 1661“The Point-to-point Protocol(PPP)”中。
主機1406經由調制解調器1405、PSTN1404、調制解調器1403把PPP連接請求傳送到PPP端1402。PPP端1402接收其連接請求，認證模塊13023進行主機的認證。典型的認證方式是基于用戶名和口令的認證協議CHAP，詳細內容被記述在RFC1994“PPP競爭握手確認協議”中。
如果認證結束，則DHCP模塊14022根據其設定，把IPv6全局地址(的前綴)和缺省網關的IPv6地址等傳送到主機1406。DHCP模塊14022根據IPS的管理者的運營方針進行設定。
進而，在圖14中為了使說明簡單，假設缺省網關、DHCP服務器和證明服務器分別作為缺省網關模塊14021、DHCP模塊14022、認證模塊14023存在于PPP端內部，但實際上還可以作為各自不同的節(jié)點在連線1407上存在。無論哪種實現形態(tài)，因為只要這些模塊或者節(jié)點在ISP的管理者的管理下安全運行就可以，所以，以下，在圖14的形態(tài)中說明主機和PPP端之間的PPP連線已被確立的狀態(tài)。
主機1406如果從DHCP模塊14022取得了IPv6全局地址(的前綴)和缺省網關的IPv6地址等，就通過組合IPv6全局地址(的前綴)和自己的(用RFC3041等方法生成的)隨機的接口ID來生成隨機的IPv6全局地址，并在確認其在連線中不重復后，分配給接口301，并將缺省網關的IPv6地址存儲起來。
通過以上的動作，主機1406就可以使用非重復使用IPv6地址和因特網的任意對方進行通信了。
以下，說明本發(fā)明的實施例。說明擴展了上述的動作(協議)的，可以使用非重復使用匿名公鑰證明書的協議。
以下，說明把匿名公鑰證明書方式適用于圖14的環(huán)境中的形態(tài)。認證機構1408是CA，而主機1406(或者利用它的用戶)是利用匿名公鑰證明書的實體i。以下，說明在證明書中包含有隨機的IPv6地址的形態(tài)，但也可以不包含隨機的IPv6地址。
認證機構1408確定上述的公開參數p、g等，還確定自己的密鑰s-ca和公鑰v-ca并公開。假設認證機構1408信任PPP端1402。即，在PPP端1402的管理下，即在和ISP之間，對產生問題時的責任取得了一致意見，在認證機構1408和PPP端1402之間可以安全可靠地進行通信。
在用戶i申請加入ISP時，使用認證機構1408公開的參數p、g等生成自己的密鑰s-i，計算對應的公鑰v-i，并把用戶名、口令、公鑰v-i提供給ISP。ISP的管理源(PPP端1402的管理者)根據其運營方針進行用戶i的身份確認和口令的核對等，允許訪問。管理者使之可以與用戶名對應地檢索到公鑰v-i那樣地將其登錄在RAM305或者HD306上。假設公開參數和公鑰v-i，特別是密鑰s-i由用戶管理，在主機1406中可以安全地被利用。
圖13展示了在進行了以上的準備后執(zhí)行的本實施例的協議。在圖13中，把實體(用戶i使用的IPv6通信裝置)作為主機1406，把CA作為認證機構1408，認證機構1408信任PPP端1402，是在它們之間進行的匿名公鑰證明書的發(fā)行協議。
在PPP連接的數據連線層的處理結束后，進行基于上述用戶名和口令的采用認證協議CHAP的認證。
即，在步驟S1301中主機1406把實體名(用戶名)從接口301傳送到PPP端1402。在步驟S1302中如果從接口301接收到實體名(識別符)，則PPP端1402生成CHAP-查詢，并在步驟S1303中從接口301向主機1406發(fā)送它。
主機1406如果在步驟S1304中從接口301接收到CHAP-查詢，則在步驟S1305中把將實體名、口令和CHAP-查詢輸入隨機函數求得的結果值CHAP-應答從接口310送到PPP端1402。
在步驟S1306中，PPP端1402從接口301接收CHAP-應答，確認CHAP-應答的正當性。在確認并且認證成功后，在步驟S1307中從接口301向該被認證后的主機1406傳送IPv6全局地址(的前綴)和缺省網關的地址。
在步驟S1308中，主機1406在確認了從接口301接收到的IPv6全局地址(根據前綴和隨機接口ID生成的IPv6地址)不重復后，把它分配給接口301，缺省網關的地址也被存儲起來。以下在步驟S1309中從接口301向PPP端1402發(fā)送作為請求匿名公鑰證明書的信息的認證請求。
認證請求和實施例1一樣，是把請求匿名公鑰證明書的主旨和包含接口ID的數據的信息以PPP端1402可以理解的形式生成的。根據實體名(用戶名)、口令和串行號碼計算其內容，串行號碼是例如將主機206的IPv6連線局部地址和缺省網關的IPv6連線局部地址和此時的時刻這3項連接成一個數據的值。在認證請求中，包含有對應于把實體名(用戶名)、口令和串行號碼輸入到隨機函數中的值生成的數字署名(認證用署名)。
在步驟S1310，PPP端1402如果從接口301接收到認證請求，則和圖1A的S103A一樣，從RAM305或者HD306中檢索與實體名(作為主機(通信裝置)206的識別符的用戶名)對應被登錄的公鑰v-i，如上所述生成隨機數r后生成匿名公鑰(g’和v-i’)(＝(g^rmod p，(v-i’)^(r)mod p))，并生成主機1406的IPv6全局地址和對應于匿名公鑰(g’和v-i’)的認證用署名。而后，在步驟S1311中把由主機1406的IPv6全局地址、匿名公鑰(g’和v-i’)和認證用署名組成的證明書請求信息從網絡接口302發(fā)送到認證機構1408。
通過上述安全可靠的通信進行接收的情況，有認證機構1408證明了從網絡接口301接收到的來自PPP端1402的數據自身是在正當的PPP端1402中生成的數據的情況。或者是基于公鑰密碼的數字署名的情況。
無論哪種情況，和圖1的S105一樣，在步驟S1312中確認了認證用署名的正當性的認證機構1408，生成主機1406的IPv6全局地址、匿名公鑰(g’和v-i’)和對應于管理屬性信息X的數字署名Sig-ca(g’，v-i’，X)，并生成由主機1406的IPv6全局地址、匿名公鑰(g’和v-i’)和管理屬性信息X和相對于它們的數字署名組成的匿名公鑰證明書。而后，在步驟S1313中，認證機構1408從網絡接口301向PPP端1402發(fā)送該匿名公鑰證明書。在管理屬性信息X中，還包含該匿名公鑰證明書的有效期限等。
PPP端1402從網絡·接口302中取得它，在步驟S1314中從接口301向主機1406發(fā)送認證通知即匿名公鑰證明書。在步驟S1315中主機1406確認從網絡接口301取得的匿名公鑰證明書的正當性。
在此，主機1406使用認證機構1408的公鑰v-ca，確認匿名公鑰證明書APC-ca(i)＝(g’，v-i’，X，Sig-ca(g’，v-i’，X))的正當性，即，確認(g’，v-i’)和Sig-ca(g’，v-i’，X)的對應關系的正當性。例如，主機1406從匿名公鑰證明書APC-ca(i)中取出(g’，v-i’，X)，計算該隨機值(例如，H(g’|v-i’|X)，其中|表示連接)，用公鑰v-ca確認Sig-ca(g’，v-i’，X)是否是對應于隨機值的正當的數字署名。主機1406預先存儲認證機構1408的公鑰v-ca。當在匿名公鑰證明書的管理屬性信息X中包含公鑰v-ca的公鑰證明書的狀態(tài)下，主機1406在確認了預先被存儲的公鑰v-ca和被包含在匿名公鑰證明書的管理屬性信息X中的公鑰v-ca的公鑰證明書中的公鑰v-ca是一致的后，用該公鑰v-ca確認匿名公鑰證明書的正當性。
在以上的協議中，也可以把在步驟S1305和S1309中接收到的數據歸納為1個在步驟S1305中發(fā)送。雖然未圖示，但在該情況下，在步驟S1305’中主機1406把隨機的接口ID、CHAP-應答和認證請求(和實施例1相同)發(fā)送到PPP端1402。
在步驟S1306’中，PPP端1402確認CHAP-應答的正當性，檢索登錄的公鑰v-i，生成包含有分配給主機1406的IPv6全局地址(根據IPv6前綴和接口ID生成)和其使用期限(使用期限，例如24小時等)等的數據，還生成認證用署名和證明書請求信息，并在步驟S1307’中將其發(fā)送到認證機構1408。
認證機構1408在步驟S1308’中進行和步驟S1312中同樣的處理，在步驟S1309中把匿名公鑰證明書發(fā)送到PPP端1402。在步驟S1310’中PPP端1402把認證通知發(fā)送到主機1406。在步驟S1311’中主機1406確認接收到的匿名公鑰證明書的正當性。
主機1406在通信對方每次改變時，或者在每次改變通話時，或者在每次發(fā)送通信信息包時，實行圖13的步驟，接收來自認證機構1408的匿名公鑰證明書。即，主機1406通過根據需要請求、取得新的公鑰證明書，實現保密性保護，進而，通過向通信對方發(fā)送包含IPv6地址的公鑰證明書，防止冒充。在此，公鑰(g’，v-i’)是同一實體的公鑰，但也是隨著時間的流逝變更的公鑰。
進而，在以上的說明中敘述了PPP端1402把IPv6前綴傳送到主機1406，主機1406根據IPv6前綴和接口ID生成IPv6地址的情況，但即使在PPP端1402把IPv6地址傳送給主機1406，主機1406使用它的情況下也可以用同樣的協議實現。在這種情況下，除了在圖3的步驟S1307中代替IPv6前綴而發(fā)送IPv6地址這一點和在步驟S1308中不需要根據前綴生成IPv6地址的處理這一點外，其他都可以用同樣的協議實現。
(實施例4)下面說明使用在實施例1、實施例2和實施例3中發(fā)行的非重復使用IPv6地址和非重復使用匿名公鑰證明書進行IPsec通信的形態(tài)。
首先，簡單地說明一下在作為安全地共用秘密數據和作為相互的IPv6地址等數據的SA(安全關聯)的協議的IKE(因特網密鑰交換)中的采用公鑰密碼進行加密的修訂模式的認證方法，并說明使用匿名公鑰證明書的方法。
IKE由兩階段組成，在第1階段中確立安全通信，在第2階段中，協調在IPsec等的通信中在上述安全通信連線上被使用的SA。以下，只說明第1階段。在IKE的第1階段中存在主模式和探索性模式，以下說明的是RFC2409“因特網密鑰交換(IKE)”的pp.13-15的5.3第1階段的認證具有1個修訂模式的公鑰加密的主模式。
在IKE中，通信的2個實體被稱為啟動者和應答者。啟動者開始通信。最初，啟動者把多個SA(秘密數據和相互的IPv6地址等的數據)發(fā)送到應答者，應答者通過把判定為可以使用的一個SA發(fā)送到啟動者，確定第1階段使用的SA。
啟動者生成隨機數(被稱為暫時號)，把用應答者的公鑰加密的數據發(fā)送到應答者。應答者生成隨機數，把用啟動者的公鑰加密的數據發(fā)送到啟動者。由此，因為可以共用各自生成的暫時號，所以可以根據共用的暫時號生成在其他的通信中使用的密鑰。其詳細記載在RFC2409“因特網密鑰交換(IKE)”中。從以上的說明可知，需要在IPsec通信前知道通信對方的公鑰。
考慮以下的情況。用戶206(圖2)、1406(圖14)訪問某個購物站點。該站點與因特網201(圖2)、1401(圖14)連接(未圖示)。該站點具有和圖3一樣的結構，通過接口301與因特網201、1401連接。進而，站點的種類并不限于購物站點。主機206、1406在把該購物站點等站點作為通信對方開始通信前，用上述的協議得到IPv6地址以及包含公鑰的公鑰證明書。在該形態(tài)中，根據上述的公鑰證明書執(zhí)行鑰交換、更新、變更協議，執(zhí)行加密、認證通信的步驟。
這時，用戶知道購物站點的IPv6地址(不管是明示還是非明示的)。在實際訪問對用戶來說是正當的站點時，通過確認通信對方的IPv6地址，用戶可以明確地知道地址。在通信正在進行中，購物站點也知道了通信對方206、1406的地址?？梢岳梅侵貜褪褂肐Pv6地址進行以上的通信。
在本方式中，在確定發(fā)送接收者的時刻，非重復使用IPv6地址使用(未更新)同一的地址。進而，在該時刻，站點和用戶204、1406相互發(fā)送非重復使用匿名公鑰證明書APC-ca(i)。因為IPv6地址包含在非重復使用匿名公鑰證明書APC-ca(i)的X中，所以兩者都確認該IPv6地址和實際通信中的對方的IPv6地址是否一致。進而，確認非重復使用匿名公鑰的正當性，判斷這是否確實是通信對方的非重復使用匿名公鑰證明書，并確認包含在其中的公鑰是否確實是通信對方的公鑰。
即，用戶206、1406把非重復使用匿名公鑰證明書從接口301發(fā)送到站點。與因特網201、1401連接的站點，確認經由接口301從用戶206、1406接收到的包含在非重復使用匿名公鑰證明書APC-ca(i)中的IPv6地址，與用戶206、1406的IPv6地址是否一致。進而，站點使用認證機構209、1408的公鑰v-ca，確認非重復使用匿名公鑰證明書APC-ca(i)的正當性。用戶206、1406也一樣，在確認包含在接收到的公鑰證明書中的IPv6地址與站點地址的一致性的同時，用認證機構209、1408的公鑰v-ca確認公鑰證明書的正當性。
如下述那樣確認非重復使用匿名公鑰證明書的正當性。主機206、1406使用CA(提供商用認證服務的真實標號等)209(圖2)、1408(圖14)的公鑰v-ca，確認非重復使用匿名公鑰證明書APC-ca(i)＝(g’，v-i’，X，Sig-ca(g’，v-i’，X))的正當性，即，(g’，v-i’)和Sig-ca(g’，v-i’，X)的對應關系的正當性。例如，主機206、1406從匿名公鑰證明書APC-ca(i)中取出(g’，v-i’，X)，計算該隨機值(例如，H(g’|v-i’|X)，其中|表示連接)，用公鑰v-ca確認Sig-ca(g’，v-i’，X)是否是對應于隨機值的正當的數字署名。主機206、1406預先存儲CA(提供商用認證服務的真實標號等)209(圖2)、1408(圖14)的公知的公鑰v-ca。在匿名公鑰證明書的管理屬性信息X中包含有公鑰v-ca的公鑰證明書的形態(tài)中，主機206、1406在確認預先存儲的公鑰v-ca與包含在匿名公鑰證明書的管理屬性信息X中的公鑰v-ca的公鑰證明書中的公鑰v-ca是否一致后，使用該公鑰v-ca確認匿名公鑰證明書的正當性。
主機206、1406在通信對方每次變化時(即，每次新連接站點時)，或者在每次變更通話時，執(zhí)行圖11、圖13的協議，更新變更所使用的IPv6地址以及公鑰g’和v-i’。進而，也可以在每次發(fā)送通信信息包時，更新、變更公鑰g’和v-i’。即，主機206、1406通過根據需要請求、取得新的公鑰證明書，實現保密性保護，進而，通過把包含IPv6地址的公鑰證明書發(fā)送到通信對方，防止冒充。
如上所述，使用非重復使用IPv6地址和包含它的非重復使用匿名公鑰證明書，可以可靠地得到利用IPv6地址定義的通信對方的公鑰。使用這樣的交換的公鑰執(zhí)行上述IKE的第1階段的主模式，并與具有該IPv6地址的通信對方進行IPsec通信。
即，上述站點如果確認了從用戶206、1406接收到的非重復使用匿名公鑰證明書是正當的非重復使用公鑰證明書，則使用該非重復使用公鑰證明書的公鑰(g’，v-i’)，通過接口301，執(zhí)行上述IKE的第1階段的主模式，與具有該IPv6地址的用戶206、1406進行IPsec通信。用戶206、1406也一樣，通過接口301，執(zhí)行上述IKE的第1階段的主模式，與具有該IPv6地址的站點進行IPsec通信。
因而，可以防止所述問題中的通信對方的冒充。
以上，通過理想的實施例說明了本發(fā)明，但本發(fā)明并不限于上述實施例，在權利要求的范圍內，可以有各種變形。
權利要求
1.一種公鑰生成裝置，其特征在于包括通信部件，經由網絡與通信裝置進行通信；生成部件，生成公鑰；發(fā)送部件，如果通信裝置請求公鑰證明書，則把由上述生成部件生成的公鑰發(fā)送到公鑰證明書發(fā)行者。
2.權利要求1所述的裝置，其特征在于上述通信部件把由公鑰證明書發(fā)行者發(fā)行的公鑰證明書發(fā)送到通信裝置。
3.權利要求1所述的裝置，其特征在于上述發(fā)送部件把與請求了公鑰證明書的通信裝置的第1公鑰對應的由上述生成部件生成的第2公鑰發(fā)送到公鑰證明書發(fā)行者。
4.權利要求3所述的裝置，其特征在于上述通信部件如果從通信裝置接收到包含數字署名的公鑰證明書請求信息，則用通信裝置的第一公鑰，確認數字署名的正當性。
5.權利要求1所述的裝置，其特征在于上述發(fā)送部件把通信裝置的地址信息發(fā)送到公鑰證明書發(fā)行者。
6.一種公鑰生成程序，其特征在于包含以下步驟生成公鑰；經由網絡接收通信裝置發(fā)出的公鑰證明書請求信息的接收步驟；根據公鑰證明書請求信息，把上述生成的公鑰發(fā)送到公鑰證明書發(fā)行者的發(fā)送步驟。
7.權利要求6所述的程序，其特征在于在上述發(fā)送步驟中，把根據請求了公鑰證明書的通信裝置的第1公鑰生成的第2公鑰發(fā)送到公鑰證明書發(fā)行者。
8.權利要求7所述的程序，其特征在于在上述接收步驟中，如果從通信裝置接收到包含數字署名的公鑰證明書請求信息，則使用通信裝置的第一公鑰，確認數字署名的正當性。
9.一種公鑰證明書發(fā)行方法，其特征在于包含以下步驟公鑰生成裝置生成公鑰，經由網絡接收通信裝置發(fā)出的公鑰證明書請求信息，并根據公鑰證明書請求信息，把上述生成的公鑰發(fā)送到公鑰證明書發(fā)行者，上述公鑰證明書發(fā)行者發(fā)行從公鑰生成裝置接收到的公鑰的公鑰證明書。
10.權利要求9所述的方法，其特征在于上述公鑰生成裝置把根據請求了公鑰證明書的通信裝置的第1公鑰生成的第2公鑰，發(fā)送到上述公鑰證明書發(fā)行者。
11.權利要求10的方法，其特征在于上述公鑰生成裝置如果從通信裝置接收到包含數字署名的公鑰證明書請求信息，則使用通信裝置的第一公鑰，確認數字署名的正當性。
全文摘要
在本發(fā)明的公鑰證明書發(fā)行裝置中，主機向網關請求公鑰證明書，網關向認證機構(CA)請求公鑰證明書。認證機構生成公鑰證明書，該公鑰證明書經由網關被發(fā)送到主機。進而，主機根據來自網關的信息，設定IPv6地址。主機根據需要，請求新的公鑰證明書并接收，向通信對方發(fā)送包含IPv6地址的公鑰證明書。
文檔編號H04L29/06GK1457170SQ0312352
公開日2003年11月19日 申請日期2003年5月9日 優(yōu)先權日2002年5月9日
發(fā)明者大石和臣 申請人:佳能株式會社