無線通信系統(tǒng)、無線通信裝置及其認證方法
【專利摘要】本發(fā)明提供一種無線通信系統(tǒng)、無線通信裝置及其認證方法。在無線通信系統(tǒng)中，多個無線通信裝置以分布式自主方式而形成網(wǎng)絡。該多個無線通信裝置中的每個包括：識別信息獲取器，其從滿足預定條件的另一無線通信裝置獲取該另一通信裝置的識別信息；識別信息保持器，其保持所獲取的另一無線通信裝置的識別信息；以及認證單元，其在另一無線通信裝置的認證中，如果另一無線通信裝置的證書中的識別信息保持在識別信息保持器中，則繼續(xù)認證。
【專利說明】無線通信系統(tǒng)、無線通信裝置及其認證方法
[0001]本申請是2007年9月14日遞交的題為“無線通信系統(tǒng)、無線通信裝置及其認證方法、以及程序”的專利申請N0.200710151508.01的分案申請。

【技術領域】
[0002]本發(fā)明涉及無線通信系統(tǒng)，尤其涉及包括以分布式自主(autonomousdistributed)方式而形成網(wǎng)絡的多個無線通信裝置的無線通信系統(tǒng)、無線通信裝置、該系統(tǒng)和裝置中的處理方法以及使得計算機執(zhí)行該方法的程序。

【背景技術】
[0003]作為使用無線技術而構成網(wǎng)絡的模式，在電氣和電子工程師協(xié)會(IEEE，Institute of Electrical and Electronics Engineers)802.1li 中定義了基石出結構(Infrastructure)無線局域網(wǎng)(LAN, Local Area Network)系統(tǒng)。在該基礎結構無線LAN系統(tǒng)中，在被稱作接入點(AP，Access Point)等的無線通信裝置的整體控制下形成網(wǎng)絡。
[0004]在IEEE802.1li中，除了基礎結構無線LAN系統(tǒng)以外，還定義了獨立基本服務組(IBSS, Independent Basic Service Set)無線 LAN 系統(tǒng)。在該 IBSS 無線 LAN 系統(tǒng)中，不是由特定的接入點進行整體控制，而是通過在作為無線終端而工作的任何可選無線通信裝置之間以分布式自主方式進行的直接異步無線通信來形成網(wǎng)絡。
[0005]在IEEE802.1ls還提出的網(wǎng)狀(mesh)無線LAN系統(tǒng)中，通過無線通信裝置之間以分布式自主方式進行的直接異步的無線通信來形成網(wǎng)絡。在該網(wǎng)狀無線LAN系統(tǒng)中，經(jīng)由其它無線通信裝置實現(xiàn)對處在許可電波直接到達的范圍之外的無線通信裝置的多跳通信(mult1-hop communicat1n)。以下,將IBSS無線LAN系統(tǒng)以及網(wǎng)狀無線LAN系統(tǒng)統(tǒng)稱為分布式自主無線LAN系統(tǒng)。
[0006]在基礎結構無線LAN系統(tǒng)或分布式自主無線LAN系統(tǒng)中，提出了一種采用IEEE802.1X的認證服務器(AS,Authenticat1n Server)的認證方案作為用于增強安全功能的方案。例如，在基礎結構無線LAN系統(tǒng)中，所有無線終端的認證信息都由認證服務器來集中管理，而接入點作為到認證服務器的認證代理服務器并處理無線終端和認證服務器之間的認證協(xié)議序列。即，在該系統(tǒng)中，能夠明確地確定各終端的角色。將作為到其它無線終端的認證服務器的認證代理服務器而工作的實體稱為認證者(Authenticator)。將被進行認證者的認證處理的實體稱為懇求者(Supplicant)。另一方面，在分布式自主無線LAN系統(tǒng)中，未明確定義各無線終端的角色。因此，任何無線終端作為認證者/認證服務器，而另一無線終端作為懇求者。
[0007]然而，在這些IEEE802.1li以及IEEE802.1ls中，盡管打算使用IEEE802.1X，但未定義特定的認證協(xié)議。為了解決這個，在因特網(wǎng)工程工作小組(IETF，InternetEngineering Task Force)中，米用可擴展認證協(xié)議(ΕΑΡ, Extensible Authenticat1nProtocol)作為比IEEE802.1X更高等級的認證協(xié)議，從而提供靈活性和擴展性。
[0008]通過與加密協(xié)議結合，EAP能夠實現(xiàn)特定的認證方案。以下說明將處理將傳輸層安全協(xié)議(TLS, Transport Layer Security)用作加密協(xié)議的情況。將基于采用TLS作為加密協(xié)議的EAP的認證稱為EAP-TLS認證。在該EAP-TLS認證中，在認證服務器和客戶機之間進行使用電子證書(公鑰證書)的認證。盡管需要認證機構(CA,Certificat1n Authority)對認證服務器以及各終端預先發(fā)行公鑰證書，但EAP-TLS認證是不依賴于密碼等的系統(tǒng)，并因其安全性非常高而知名(例如參照非專利文獻1:B.Aboba and D.Simon:“PPP EAP TLSAuthenticat1n Protocol，，，RFC 2716, Network Working Group, IETF (http://www.1etf.0rg/rfc/rfc2716.txt))。
[0009]然而，在EAP-TLS認證中，只要公鑰證書是從認證服務器可信賴的認證機構發(fā)行的公鑰證書，則許可所有來自具有該公鑰證書的實體的連接。即，這種方案沒有僅許可特定實體的認證的系統(tǒng)。
[0010]為了實現(xiàn)僅許可特定實體，需要管理任何認證信息。然而，這種管理一般會導致復雜。尤其是在分布式自主無線LAN系統(tǒng)中，無線終端有可能移動，因此構成網(wǎng)絡的終端隨時間而異。因此沒有必要始終確保用于該管理的通信路徑。即，為了在分布式自主無線LAN系統(tǒng)中控制認證對象，需要有效地分散并管理無線終端的認證信息。


【發(fā)明內(nèi)容】

[0011]本發(fā)明需要在分布式自主無線LAN系統(tǒng)中控制認證對象，從而形成安全的網(wǎng)絡。
[0012]根據(jù)本發(fā)明的第一實施例，提供一種多個無線通信裝置以分布式自主方式形成網(wǎng)絡的無線通信系統(tǒng)。多個無線通信裝置中的每個包括:識別信息獲取器，其被配置為從滿足預定條件的另一無線通信裝置獲取該另一通信裝置的識別信息；識別信息保持器，其被配置為保持所獲取的另一無線通信裝置的識別信息；以及認證單元，其被配置為在另一無線通信裝置的認證中，如果另一無線通信裝置的證書中的識別信息保持在識別信息保持器中，則繼續(xù)認證。由此帶來這樣的優(yōu)勢:通過僅對預先獲取了識別信息的無線通信裝置繼續(xù)進行認證處理來形成安全的網(wǎng)絡。
[0013]根據(jù)本發(fā)明的第二實施例，提供一種多個無線通信裝置以分布式自主方式形成網(wǎng)絡的無線通信系統(tǒng)中的無線通信裝置。該裝置包括:識別信息獲取器，其被配置為從滿足預定條件的另一無線通信裝置獲取該另一通信裝置的識別信息；識別信息保持器，其被配置為保持所獲取的另一無線通信裝置的識別信息；以及認證單元，其被配置為在另一無線通信裝置的認證中，如果另一無線通信裝置的證書中的識別信息保持在識別信息保持器中，則繼續(xù)認證。由此帶來這樣的優(yōu)勢:通過僅對預先獲取了識別信息的無線通信裝置進行繼續(xù)認證處理來形成安全的網(wǎng)絡。
[0014]本發(fā)明還提供一種無線通信裝置的認證方法，所述無線通信裝置包括識別信息保持器，所述識別信息保持器保持由多個無線通信裝置以分布式自主方式而形成網(wǎng)絡的無線通信系統(tǒng)中的另一無線通信裝置的識別信息，所述方法包括以下步驟:從滿足預定條件的另一無線通信裝置獲取所述另一通信裝置的識別信息；將所獲取的所述另一無線通信裝置的識別信息保持在所述識別信息保持器中；以及在所述另一無線通信裝置的認證中，如果所述另一無線通信裝置的證書中的識別信息保持在所述識別信息保持器中，則繼續(xù)所述認證。
[0015]本發(fā)明還提供一種在無線通信裝置上運行的程序，所述無線通信裝置包括識別信息保持器，所述識別信息保持器保持由多個無線通信裝置以分布式自主方式而形成網(wǎng)絡的無線通信系統(tǒng)中的另一無線通信裝置的識別信息，所述程序使計算機執(zhí)行以下步驟:從滿足預定條件的另一無線通信裝置獲取所述另一通信裝置的識別信息；將所獲取的所述另一無線通信裝置的識別信息保持在所述識別信息保持器中；以及在所述另一無線通信裝置的認證中，如果所述另一無線通信裝置的證書中的識別信息保持在所述識別信息保持器中，則繼續(xù)所述認證。
[0016]本發(fā)明的實施例能夠取得極好的有利效果:在分布式自主無線LAN系統(tǒng)中形成安全的網(wǎng)絡。

【專利附圖】

【附圖說明】
[0017]圖1是示出本發(fā)明第一實施例中的通信裝置的一個結構例子的圖；
[0018]圖2A和2B是示出在本發(fā)明第一實施例中使用的公鑰證書的結構的圖；
[0019]圖3是示出本發(fā)明第一實施例中的訪問控制列表的一個結構例子的圖；
[0020]圖4A?4C是示出登記本發(fā)明第一實施例中的無線通信系統(tǒng)的通信裝置的識別信息的圖；
[0021]圖5是示出登記本發(fā)明第一實施例中的無線通信系統(tǒng)的通信裝置的識別信息的過程例子的圖；
[0022]圖6是示出本發(fā)明第一實施例中的IBSS無線LAN系統(tǒng)的通信裝置之間相互認證的過程例子的圖；
[0023]圖7是示出本發(fā)明第一實施例中的IBSS無線LAN系統(tǒng)的認證序列的過程例子的圖；
[0024]圖8是示出本發(fā)明第一實施例中接收公鑰證書時的處理過程例子的圖；
[0025]圖9是示出本發(fā)明第一實施例中的網(wǎng)狀無線LAN系統(tǒng)的通信裝置之間相互認證的過程例子的圖；
[0026]圖10是示出作為本發(fā)明第一實施例中通信裝置的變形例的移動電話終端的一個結構例子的圖；
[0027]圖11是示出本發(fā)明第一實施例的變形例中的電話簿的一個結構例子的圖；
[0028]圖12是示出本發(fā)明第一實施例的變形例中接收公鑰證書時的處理過程例子的圖；
[0029]圖13是示出本發(fā)明的第二實施例中接收公鑰證書時的處理過程例子的圖；以及
[0030]圖14是示出本發(fā)明的第二實施例的變形例中接收公鑰證書時的處理過程例子的圖。

【具體實施方式】
[0031]⑴第一實施例
[0032]下面將參照附圖來詳細說明本發(fā)明第一實施例。
[0033]圖1是示出本發(fā)明第一實施例中的通信裝置100的一個結構例子的圖。該通信裝置100包括通信控制器101、無線網(wǎng)絡接口 102、無線通信數(shù)據(jù)保持器103、鄰近終端列表104、路由表105、訪問控制列表107以及同步按鈕109。通信裝置100經(jīng)由無線ad-hoc (自組織)網(wǎng)絡190與另一通信裝置進行通信。
[0034]通信控制器101控制整個通信裝置100。通信控制器101還執(zhí)行與另一通信裝置的認證處理。
[0035]無線網(wǎng)絡接口 102用于與無線ad-hoc網(wǎng)絡190通信。
[0036]無線通信數(shù)據(jù)保持器103保持用于無線通信的設置數(shù)據(jù)。作為設置數(shù)據(jù)而保持的是:例如用于識別無線ad-hoc網(wǎng)絡190的服務組標識符(SSID, Service Set Identifier)、用于健壯(robust)安全網(wǎng)絡(RSN, Robust Security Network)的密碼和公鑰證書等安全設置數(shù)據(jù)、通信裝置100的MAC地址以及通信裝置100的裝置名等。
[0037]鄰近終端列表104包含了在無線ad-hoc網(wǎng)絡190中存在于通信裝置100附近的通信裝置(鄰近終端)的列表。通信控制器101接收從其它通信裝置周期性地發(fā)送的信標，從而進行控制使得將最新的狀態(tài)反映在該鄰近終端列表104中。
[0038]路由表105包含了用于到達無線ad-hoc網(wǎng)絡190中其它通信裝置的路由列表。具體地，路由表105保持:通信裝置的標識符，其作為最終的發(fā)送目的地；以及向該發(fā)送目的地傳送幀的通信裝置的標識符。
[0039]訪問控制列表107包含表示是否能單獨對于每個認證對象進行認證的認證信息的列表。通過參照該訪問控制列表107，通信控制器101單獨地對認證對象執(zhí)行認證的許可或拒絕。
[0040]同步按鈕109是用于將認證信息添加至訪問控制列表107的用戶界面。當按下該同步按鈕109時，如果類似地還按下了另一通信裝置的同步按鈕，則將該另一通信裝置的認證信息添加至訪問控制列表107。
[0041]圖2A和2B是示出在本實施例中使用的公鑰證書610的結構的圖。如圖2A所示，公鑰證書610大致分為簽名前證書611、簽名算法618和簽名619。簽名前證書611包含序列號612、發(fā)行者鑒別名614、有效性615、對象鑒別名616和對象公鑰617。
[0042]序列號612是公鑰證書的序列號，并由認證機構(CA)確定。發(fā)行者鑒別名614是與作為公鑰證書的發(fā)行者的CA相關的識別信息。發(fā)行者鑒別名614和序列號612允許公鑰證書被唯一地識別。有效性615是公鑰證書的有效期限。對象鑒別名616是與公鑰證書的所有者相關的識別信息。對象公鑰617是在對象鑒別名616中表示的所有者的公鑰。
[0043]簽名619是針對公鑰證書由CA所做的簽名，并且簽名算法618是用于該簽名619的簽名算法。簽名算法包括兩種算法:消息摘要算法和公鑰加密算法。消息摘要算法是哈希函數(shù)的一種，并且是用于創(chuàng)建簽名前證書611的消息摘要的算法。消息摘要是通過將輸入數(shù)據(jù)(簽名前證書611)壓縮成固定長度的位串而獲得的，還稱作拇指紋或指紋等。作為消息摘要算法，已知有SHA-1 (Secure Hash Algorithml,安全哈希算法I)、MD2 (MessageDigest#2,消息摘要#2)、MD5 (MESSAGE Digest#5,消息摘要#5)等。公鑰加密算法是一種用于通過使用CA的私鑰對基于消息摘要算法而獲得的消息摘要進行加密的算法。作為該公鑰加密算法，已知有基于質數(shù)因數(shù)分解問題的RSA、基于離散對數(shù)問題的DSA等。簽名619是通過使用CA的私鑰對簽名前證書611的消息摘要進行加密而形成的。
[0044]因此，通過使用CA的公鑰對該公鑰證書的簽名619進行解密，可獲得消息摘要。公鑰證書的用戶通過自己創(chuàng)建簽名前證書611的消息摘要并將創(chuàng)建的消息摘要與使用CA的公鑰進行解密而形成的消息摘要做比較，可以檢驗簽名前證書611的內(nèi)容是否被竄改。
[0045]圖2B是示出作為對象鑒別名616而保持的識別信息的項目的圖。在圖2B中，作為一個例子，顯示國名(C) 621、組織名(O) 622、組織的單位名(OU) 623、以及普通名(CN) 624。
[0046]國名621代表所有者的國籍。組織名622代表所有者所屬的組織的名稱。組織的單位名623代表所有者所屬的組織內(nèi)的部門的名稱。普通名624代表所有者的普通的名稱。例如，作為普通名624,可使用通信裝置的裝置名、統(tǒng)一資源定位器(URL,Uniform ResourceLocator)地址等。
[0047]圖3是示出本實施例中的訪問控制列表107的一個結構例子的圖。作為訪問控制列表107的各條目的項目，將識別信息712和認證可能性713的字段相互關聯(lián)地保持。
[0048]識別信息712是保持與該條目對應的裝置的識別信息的字段。在登記時，保持對象的公鑰證書610中所含的對象鑒別名616的全部要素或一部分要素。在該例子中，識別信息712包含賦予對象通信裝置的裝置名，例如“DSC-T9_002”。
[0049]認證可能性713是表示與該條目對應的裝置的認證是否可能，或是否應拒絕該認證的字段。
[0050]盡管在該例子中將認證可能性713與識別信息712關聯(lián)地保持，但訪問控制列表107的結構不限于此。例如，可不提供認證可能性713的字段，而是僅將可能認證的通信裝置的裝置名保持在識別信息712中，并且通信控制器101可許可裝置名被保持在識別信息712中的通信裝置的所有認證。
[0051]本實施例中的處理大致分為第一階段和第二階段。在第一階段中，通信裝置各自將對方通信裝置的識別信息登記在訪問控制列表中。在第二階段中，通信裝置通過確認公鑰證書的對象鑒別名是否與訪問控制列表的條目一致，從而相互認證。
[0052]為了在第一階段中登記識別信息，可以通過由鍵盤等輸入裝置直接輸入通信裝置的裝置名等，來編輯訪問控制列表107?？蛇x地，可以不使用這種輸入裝置而指定對方通信裝置?？衫酶鞣N方案作為指定對方通信裝置的方案，例如:帶內(nèi)(In-Band)方案，其使用作為原通信措施的無線LAN接口 ；以及帶外(Out-of-Band)方案，其使用近距離通信(NFC，Near-Field Communicat1n)、通用串行總線(USB, Universal Serial Bus)記憶棒(memorystick)或者有線電纜等其它網(wǎng)絡接口或外部存儲器。以下將對基于采用同步按鈕的帶內(nèi)方案的實現(xiàn)例進行說明。以下所述方案與日本特開2004-328093號公報所公開的方法類似，因此將僅說明其概要。
[0053]圖4是示出登記本實施例中的無線通信系統(tǒng)的通信裝置的識別信息的圖。將“DSC-T9_001”提供給通信裝置A 110作為其裝置名，并將“DSC_T9_002”提供給通信裝置B120作為其裝置名。此外，將同步按鈕119和129分別提供給通信裝置A 110以及B 120。
[0054]對各通信裝置，從特定的認證機構(CA)發(fā)行并提供X.509格式的公鑰證書。為了能夠檢驗相互的公鑰證書的有效性，通信裝置還具有發(fā)行公鑰證書的認證機構(CA)的服務器公鑰證書以及對該服務器公鑰證書進行密鑰鏈認證所需的更高等級的認證機構的公鑰證書。
[0055]在圖4A的初始狀態(tài)中，在各訪問控制列表117和127中未登記通信裝置。當如圖4B所示，當通信裝置A 110和B 120在彼此相距一定距離內(nèi)的狀態(tài)下按下同步按鈕119和129時，如圖4C所示，將彼此的裝置名保持在訪問控制列表117和127中。具體地，將通信裝置B 120的裝置名“DSC-T9_002”保持在通信裝置A 110的訪問控制列表117中，并將通信裝置A 110的裝置名“DSC-T9_001”保持在通信裝置B 120的訪問控制列表127中。
[0056]圖5是示出登記本實施例中的無線通信系統(tǒng)的通信裝置的識別信息過程例子的圖。在該例子中，在從時刻Tl到時刻T2期間按下通信裝置A 110的同步按鈕119。響應該操作，將時間T( = Τ2-Τ1)以及通信裝置A 110的裝置名(=“DSC-T9_001”)發(fā)送至通信裝置B 120。通信裝置B 120接收到這些所發(fā)送的信息的時刻被定義為S3。
[0057]另一方面，在從時刻SI到時刻S2期間按下通信裝置B 120的同步按鈕129。響應該操作，將時間S( = S2-S1)以及通信裝置B 120的裝置名(=“DSC-T9_002”)發(fā)送至通信裝置A 110。通信裝置A 110接收到這些所發(fā)送的信息的時刻被定義為T3。
[0058]如果滿足關系“ I T3-T2 I < C2”且“ | T-S | < Cl”，則通信裝置A 110許可通信裝置B 120的認證(311)，并將通信裝置B 120的裝置名添加至訪問控制列表117(312)。具體地，如果從放開同步按鈕119起預定期間C2內(nèi)，通信裝置A 110從通信裝置B 120接收到同步按鈕129的按下的信息，且按下期間的差處于預定長度Cl以內(nèi)，則通信裝置A 110判斷為大致在同一時刻按下兩個同步按鈕。
[0059]類似地，如果滿足關系“ |S3_S2| <C2”且“|T_S| <C1”，則通信裝置B 120許可通信裝置A 110的認證(321)，并將通信裝置A 110的裝置名添加至訪問控制列表127(322)。
[0060]盡管在該例子中采用同時按下按鈕作為登記裝置名的條件，但登記條件不限于此。例如，通過使用電波強度判斷器，可以將電波強度判斷器判斷為來自一個通信裝置的認證請求的電波強度等于或大于閾值的狀況作為登記條件。可選地，通過使用測量絕對方向的電子羅盤，可以采用電子羅盤判斷為通信裝置向著預定方向(例如，正對著對方通信裝置的狀態(tài))的狀況作為登記條件。
[0061]下面將說明本發(fā)明第一實施例中的第二階段的相互認證。該階段中的處理在以往已制定標準的IBSS無線LAN系統(tǒng)和當前在例如IEEE802.1ls中正在進行標準化的網(wǎng)狀無線LAN系統(tǒng)中有部分區(qū)別。因此將分開地對在這些網(wǎng)絡中每個的處理進行說明。
[0062](a) IBSS無線LAN系統(tǒng)中的處理
[0063]圖6是示出本發(fā)明第一實施例中的IBSS無線LAN系統(tǒng)的通信裝置之間相互認證過程例子的圖。在IEEE802.1li所定義的IBSS無線LAN系統(tǒng)中，當由EAP-TLS認證來實現(xiàn)IEEE802.1X的認證處理時，在通信裝置之間互換懇求者和認證者/認證服務器兩個角色以進行相互認證。具體地，第一認證處理后，將在第一認證處理中作為認證者/認證服務器的通信裝置作為懇求者，并將在第一認證處理中作為懇求者的通信裝置作為認證者/認證服務器，以這種方式再度執(zhí)行認證處理，使得通信裝置互相認證。
[0064]更具體地,首先通信裝置A 110作為懇求者而通信裝置B 120作為認證者/認證服務器，以這種方式進行認證序列510。此后，通信裝置A 110作為認證者/認證服務器而通信裝置B 120作為懇求者，以這種方式進行認證序列530。
[0065]圖7是示出本發(fā)明第一實施例中的IBSS無線LAN系統(tǒng)中的認證序列(510)的過程例子的圖。在該例子中，如上所述，通信裝置A 110作為懇求者，而通信裝置B 120作為認證者/認證服務器。
[0066]最初，具有認證者/認證服務器的角色的通信裝置B 120基于IEEE802.1X的幀體和EAP協(xié)議、對具有懇求者的角色的通信裝置A 110請求發(fā)送通信裝置A 110的識別信息(511)。響應該請求，通信裝置A 110將自身的識別信息(MyID)返送給通信裝置B120(512)。
[0067]當確認了通信裝置A 110的識別信息時，通信裝置B 120基于TLS將加密協(xié)議的開始通知給通信裝置A 110(513)。響應該通知，通信裝置A 110將TLS “客戶機問候”(ClientHell0)消息發(fā)送至通信裝置B 120(514)。該“客戶機問候”消息包含將作為后續(xù)密鑰交換時的密鑰種子的28字節(jié)隨機數(shù)(ClientHell0.random)。
[0068]當確認了來自通信裝置A 110的“客戶機問候”消息時，通信裝置B 120將TLS“服務器問候”(ServerHello)消息發(fā)送至通信裝置A 110(515)。該“服務器問候”消息包含將作為后續(xù)密鑰交換時的密鑰種子的28字節(jié)隨機數(shù)(ServerHell0.random)。
[0069]在“服務器問候”消息后，通信裝置B 120將TLS “服務器證書”(ServerCertificate)消息發(fā)送至通信裝置A 110。該服務器證書消息包含通信裝置B120的公鑰證書。
[0070]在服務器證書消息后，通信裝置B 120將TLS服務器密鑰交換(ServerKeyExchange)消息發(fā)送至通信裝置A 110。該服務器密鑰交換消息將發(fā)送由通信裝置A 110創(chuàng)建預主密鑰(premaster_key)所需的加密信息。
[0071]在服務器密鑰交換消息后，通信裝置B 120將TLS證書請求(CertificateRequest)消息發(fā)送至通信裝置A 110。該證書請求消息對通信裝置A 110請求發(fā)送公鑰證書。
[0072]在證書請求消息后，通信裝置B 120將“服務器問候結束”(ServerHelloDone)消息發(fā)送至通信裝置A 110。該“服務器問候結束”消息將向通信裝置A 110通知“服務器問候”消息以及與其相關的消息的結束。
[0073]此后，通信裝置A 110以及B 120基于如上述交換的隨機數(shù)以及預主密鑰而各自創(chuàng)建主密鑰(521)。
[0074]隨后，通信裝置A 110將TLS客戶機證書(ClientCertificate)消息發(fā)送至通信裝置B 120(516)。該客戶機證書消息包含通信裝置A 110的公鑰證書。
[0075]在客戶機證書消息后，通信裝置A 110將TLS客戶機密鑰交換(ClientKeyExchange)消息發(fā)送至通信裝置B 120。該客戶機密鑰交換消息將設置預主密鑰。
[0076]在客戶機密鑰交換消息后，通信裝置A 110將TLS證書檢驗(CertificateVerify)消息發(fā)送至通信裝置B 120。該證書檢驗消息將檢驗通信裝置A 110的公鑰證書。
[0077]在證書檢驗消息后,通信裝置A 110將TLS改變密碼規(guī)格(ChangeCipherSpec)消息發(fā)送至通信裝置B 120。該改變密碼規(guī)格消息將通知通信裝置B 120使用新的加密策略以及新的密鑰來發(fā)送后續(xù)數(shù)據(jù)。
[0078]在改變密碼規(guī)格消息后，通信裝置A 110將TLS完成(Finished)消息發(fā)送至通信裝置B 120。該完成消息將向通信裝置B 120通知密鑰交換和認證處理的成功。
[0079]響應來自通信裝置A 110的完成消息，通信裝置B 120將TLS改變密碼規(guī)格(ChangeCipherSpec)消息發(fā)送至通信裝置A 110(517)。隨后，通信裝置B 120將TLS完成消息發(fā)送至通信裝置A 110。響應該發(fā)送，通信裝置A 110返送EAP協(xié)議的響應(518)。
[0080]此后，通信裝置A 110以及B 120基于如上述交換的隨機數(shù)以及主密鑰而各自創(chuàng)建成對主鑰(PMK，Pairwise Master Key) (522)。隨后，將表示EAP協(xié)議的成功的信息從通信裝置B 120發(fā)送到通信裝置A 110 (519)，從而結束EAP-TLS認證。
[0081]隨后，作為由IEEE802.1li定義的處理，進行四次握手(523)。該四次握手是基于由EAP-TLS認證而創(chuàng)建的？1?、作為IEEE802.1li而創(chuàng)建所需的密鑰的處理。該四次握手是由通信裝置B 120啟動的。
[0082]圖7的認證序列對應于圖6的認證序列510。在圖7的認證序列結束后，在通信裝置A 110和通信裝置B 120之間交換角色而執(zhí)行類似的認證序列530。
[0083]圖8是示出本發(fā)明第一實施例中的公鑰證書的接收時的處理過程例子的圖。當在圖7的認證序列中，通信裝置A 110從通信裝置B 120經(jīng)由服務器證書(ServerCertificate)消息而接收公鑰證書時(515),或當通信裝置B 120從通信裝置A 110經(jīng)由客戶機證書(ClientCertificate)消息而接收公鑰證書時(516)執(zhí)行該處理。
[0084]最初，通信控制器101從認證對象的公鑰證書獲取對象鑒別名616 (步驟S911)。如果在訪問控制列表107的識別信息712中存在與該對象鑒別名616 —致的條目(步驟S912)，則基于認證對象的認證可能性713而判斷認證對象的認證是否可能(步驟S913)。如果認證對象的認證是可能的，則繼續(xù)剩余的認證序列(步驟S914)。
[0085]另一方面，如果在訪問控制列表107的識別信息712中不存在與對象鑒別名616一致的條目(步驟S912)，或即使條目存在但認證可能性713表明認證對象的認證是不可能的(步驟S913)，則基于判斷為認證已失敗而終止該認證序列(步驟S915)。
[0086](b)網(wǎng)狀無線LAN系統(tǒng)中的處理
[0087]圖9是示出本發(fā)明第一實施例中的網(wǎng)狀無線LAN系統(tǒng)的通信裝置之間相互認證過程例子的圖。在當前正進行標準化的IEEE802.1ls提出的網(wǎng)狀無線LAN系統(tǒng)中，當由EAP-TLS認證方式來實現(xiàn)IEEE802.1X的認證處理時，該處理基于以下假定:在實際認證處理之前執(zhí)行的掃描階段中，進行與懇求者和認證者的角色有關的交涉，因此在認證處理前確定角色。因此，不需要像IBSS無線LAN系統(tǒng)那樣互換懇求者和認證者/認證服務器的角色而執(zhí)行兩次認證處理。
[0088]在圖9的該認證序列中，數(shù)據(jù)的發(fā)送方向與圖7的認證序列的發(fā)送方向相反。具體地，具有懇求者的角色的通信裝置A 110基于IEEE802.1X的幀體和EAP協(xié)議、對具有認證者/認證服務器的角色的通信裝置B 120請求發(fā)送通信裝置B 120的識別信息(551)，從而開始了認證序列。在后續(xù)的步驟中，所有數(shù)據(jù)的發(fā)送方向也是相反的。
[0089]在這種情況下，在⑴作為懇求者的通信裝置A 110和(ii)作為認證者以及認證服務器的通信裝置B 120中，也都執(zhí)行與上述圖8的處理類似的處理。在懇求者終端(通信裝置A 110)中，在圖9的步驟555中接收數(shù)據(jù)的時刻執(zhí)行圖8的處理。在認證者/認證服務器終端(通信裝置B 120)中，在圖9的步驟556中接收數(shù)據(jù)的時刻執(zhí)行圖8的處理。
[0090]如上所述，在本發(fā)明第一實施例中，各通信裝置將認證對象的識別信息保持在其訪問控制列表107中，并將所保持的信息與在相互認證時交換的公鑰證書中的對象鑒別名做比較。因此有可能單獨地判斷是否對每通信裝置許可認證。
[0091](1-1)第一實施例的變形例
[0092]下面將說明本發(fā)明第一實施例的變形例。
[0093]圖10是示出作為本發(fā)明第一實施例中通信裝置的變形例的移動電話終端200的一個結構例子的圖。該移動電話終端200包括通信控制器201、無線網(wǎng)絡接口 202、無線通信數(shù)據(jù)保持器203、鄰近終端列表204、路由表205和電話簿208。該移動電話終端200經(jīng)由無線ad-hoc網(wǎng)絡290與另一通信裝置(移動電話終端)進行通信。
[0094]因為移動電話終端200包括無線網(wǎng)絡接口 202，所以其實現(xiàn)無線LAN上的語音(VoffLAN, Voice over Wireless LAN)。具體地,經(jīng)由無線ad_hoc網(wǎng)絡290,移動電話終端200能夠連接固定電話、IP電話等并可與之通話。此外，移動電話終端200能夠作為室外普通的移動電話而使用。移動電話和固定電話之間的這種結合被稱為固定移動融合(FMC，F(xiàn)ixed Mobile Convergence)。
[0095]在該移動電話終端200中，通信控制器201、無線網(wǎng)絡接口 202、無線通信數(shù)據(jù)保持器203、鄰近終端列表204以及路由表205與圖1的通信裝置100中的相應物具有相同的功倉泛。
[0096]電話簿208是用于撥叫電話的電話號碼的列表。在該變形例中，不是像圖1的例子那樣明確地預先將識別信息登記在訪問控制列表107中，而是將電話簿208作為訪問控制列表107而使用。因此，通過不進行識別信息的明確登記而是利用已積累有電話號碼的電話簿，簡化了相互認證的準備。具體地，將所有者的電話號碼保持在公鑰證書的對象鑒別名616的普通名624中。從而有可能從電話簿208中搜索相互認證時交換的公鑰證書所含的電話號碼(普通名624)。
[0097]為了將對方的移動電話終端的電話號碼登記在移動電話的電話簿中，可應用普通使用模式。例如，移動電話用戶可以口頭詢問對方的電話號碼并通過撥盤輸入而保存。此夕卜，還有這樣的方法:通過從用戶的移動電話終端撥叫到對方的移動電話終端，從而將用戶的移動電話號碼登記在對方的移動電話終端中。
[0098]圖11是示出本變形例中的電話簿208的一個結構例子的圖。作為該電話簿208的各條目的項目，將姓名821、電話號碼822以及認證可能性823的字段相互關聯(lián)地保持。
[0099]姓名821代表與該條目對應的人物的姓名?？墒褂眯蘸兔麅烧叩慕M合作為該姓名821?？蛇x地，可以使用其中的一個?？蛇x地，只要能夠指定該人物，還可使用昵稱。
[0100]電話號碼822代表與該條目對應的人物的電話號碼。
[0101]認證可能性823是表示與該條目對應的人物的認證是否可能，或是否應拒絕該認證的字段。
[0102]進行登記以使基本上基于登記在電話簿中的熟人是可信賴的人的假設而許可該熟人的認證。然而，對于不希望許可經(jīng)無線網(wǎng)絡接口 202而連接的人物，將認證可能性823設為“拒絕認證”，從而有可能控制是否許可認證。
[0103]在該變形例中，基于EAP-TLS認證的相互認證是根據(jù)圖7或圖9的認證序列而進行的。在認證序列中，當一個通信裝置從其它通信裝置經(jīng)由服務器證書(ServerCertificate)消息而接收公鑰證書時,或當一個通信裝置從其它通信裝置經(jīng)由客戶機證書(ClientCertificate)消息而接收公鑰證書時，與圖8的序列類似地檢查公鑰證書。
[0104]公鑰證書可在移動電話終端出貨時設置。將該移動電話終端的電話號碼保持在公鑰證書的對象鑒別名616的普通名624中，從而可將公鑰證書用于判斷相互認證時是否許可認證。
[0105]圖12是示出本變形例中的接收公鑰證書時的處理過程例子的圖。
[0106]最初，通信控制器201從認證對象的公鑰證書獲取對象鑒別名616 (步驟S921)。如果在電話簿208的電話號碼822中存在與該對象鑒別名616所含的電話號碼(普通名624)一致的條目(步驟S922)，則基于認證對象的認證可能性823而判斷認證對象的認證是否可能(步驟S923)。如果認證對象的認證是可能的，則繼續(xù)剩余的認證序列(步驟S924)。
[0107]另一方面，如果在電話簿208的電話號碼822中不存在與對象鑒別名616所含的電話號碼一致的條目(步驟S922)，或即使條目存在但認證可能性823表明認證對象的認證是不可能的(步驟S923)，則基于判斷為認證已失敗而終止該認證序列(步驟S925)。
[0108]如上所述，在本發(fā)明第一實施例的變形例中，將在相互認證時交換的公鑰證書中的對象鑒別名所含的電話號碼與移動電話終端的電話簿208所含的電話號碼做比較。從而有可能單獨地判斷對各移動電話終端是否許可認證。
[0109](2)第二實施例
[0110]下面將說明本發(fā)明的第二實施例。
[0111]在上述第一實施例中，通信裝置A 110(或通信裝置B 120)如果發(fā)生以下任一狀況則判斷為認證處理失敗，基于該判斷而終止認證序列。
[0112](狀況I):識別信息原先未被存儲在訪問控制列表107中(圖8的步驟S912中“否”)。
[0113](狀況2):存儲在訪問控制列表107的認證可能性713中的狀態(tài)表明“拒絕認證”(圖8的步驟S913中“否”)。
[0114]這些狀況是基于訪問控制列表107內(nèi)的信息而發(fā)生的。原先，提供該列表107是旨在使用戶僅與被用戶真正選擇作為通信對方的實體進行通信，從而防止個人信息的泄漏等。因此，當用戶基于用戶自己的判斷而希望與認證對象的通信裝置進行通信時，即使用戶不管存儲在訪問控制列表107中的信息而繼續(xù)認證序列，也不會產(chǎn)生任何問題。相反，在這種情況下強制終止認證序列甚至可能會降低用戶的便利性。
[0115]針對這一點，本實施例提供附加功能。具體地，由于該功能，在圖8的處理中，在強制終止認證序列前核實用戶的意圖。如果用戶判斷為不必終止序列，則該功能繼續(xù)認證序列。
[0116]然而，如果采用這種方案，則有可能由于例如用戶未注意到信息提示等原因而在等待用戶選擇期間EAP-TLS超時。因此，希望預先實施在發(fā)生這種狀況時的解決方案。作為具體的解決方案，可使用任意方案。例如，可以在發(fā)生超時時強制終止認證序列。以下將對這樣的例子進行說明:在超時時再試圖7所示的認證序列，并再次核實用戶的意圖。
[0117]圖13示出了為了實現(xiàn)上述功能，由根據(jù)本實施例的通信裝置的通信控制器101執(zhí)行的接收公鑰證書時的處理過程例子。
[0118]該處理是(a)在IBSS無線LAN系統(tǒng)的情況下圖7的認證序列的步驟515或516或(b)在網(wǎng)狀無線LAN系統(tǒng)的情況下圖9的認證序列的步驟555或556而執(zhí)行的。在圖13中，與上述圖8中相同的步驟被標以相同的步驟標號。
[0119]在圖13的處理中，通信控制器101最初執(zhí)行步驟S911的處理。如果在訪問控制列表107的識別信息712中存在與從認證對象的公鑰證書而獲取的對象者鑒別名616 —致的條目(步驟S912中“是”)，且如果認證可能性713表明該認證對象的認證是可能的(步驟S913中“是”)，則繼續(xù)剩余的認證序列(步驟S914)。
[0120]相反，如果發(fā)生上述狀況I或2( S卩，步驟S912或S913中做出判定“否”)，則通信控制器101輸出用于使用戶選擇是否繼續(xù)認證序列的信息(步驟S9110)。可使用任意方法作為顯示該信息的方法。例如，對象通信終端的信息可以與“認證失敗。您繼續(xù)認證嗎？”等文本一起而顯示在顯示單元(未示出)上。可選地，也可以從揚聲器(未示出)輸出聲音。可選地，可以通過點亮發(fā)光二極管等來顯示該信息。
[0121]在該信息顯示后的預定時間，通信控制器101處在等待用戶輸入的狀態(tài)中(步驟S9120中“否”以及步驟S9130中“否”)。當EAP-TLS超時時，在步驟S9130中判斷為“是”。結果，通信控制器101終止認證序列，然后執(zhí)行處理以從頭開始再試圖7的認證序列(步驟S9140)，隨后處理結束。
[0122]另一方面，如果用戶根據(jù)該信息顯示而進行了輸入操作，則通信控制器101在步驟S9120中做出判斷為“是”，然后判斷該輸入操作是否為許可認證(步驟S9150)。如果用戶輸入表明不許可認證，則通信控制器101在步驟S9150中判斷為“否”，隨后處理結束。相反，如果用戶進行了旨在表明許可認證處理的輸入操作(步驟S9150中“是”)，則通信控制器101將表示“許可認證”的信息(例如，標識)存儲在與通信對象對應的訪問控制列表107的認證可能性字段713中(步驟S9160)，然后將處理前進至步驟S914。結果，在系統(tǒng)內(nèi)繼續(xù)認證序列。
[0123]這種請求用戶判斷的方案不僅適用于圖8的處理，也同樣適用于類似上述圖12的處理。圖14示出了當將請求用戶判斷的方法適用于圖12的處理時的處理例子。在圖14中，與圖12中相同的步驟被標以相同的標號。
[0124]如圖14所示，在該處理例子中，如果在步驟S922或S923中做出判斷“否”，則通信控制器201與圖13的步驟S9110類似地向用戶顯示用于核實用戶的意圖的信息(步驟S9210)。隨后，在預定的時間內(nèi)，通信控制器201等待用戶輸入(步驟S9220中“否”以及步驟S9230中“否”)。當EAP-TLS超時時，在步驟S9230中判斷為“是”。結果，通信控制器201終止認證序列，然后執(zhí)行處理以再試認證序列(步驟S9240)，隨后處理結束。
[0125]相反，如果用戶進行了輸入操作，則通信控制器201在步驟S9220中做出判斷為“是”，然后執(zhí)行步驟S9250的處理。如果用戶進行了旨在終止認證的輸入操作(步驟S9250中“否”)，則通信控制器201結束認證序列。相反，如果用戶進行了旨在許可認證的輸入操作(步驟S9250中“是”)，則通信控制器201將表示“許可認證”的信息(例如，標識)存儲在與通信對象對應的電話簿208的認證可能性字段713中(步驟S9260)，然后將處理前進至步驟S924。結果，在系統(tǒng)內(nèi)繼續(xù)認證序列。
[0126]如上所述，在本發(fā)明的第二實施例中，即使當存儲在通信裝置內(nèi)的訪問控制列表或電話簿內(nèi)的信息表明不需要繼續(xù)認證處理時，也有可能基于用戶的意圖而繼續(xù)認證處理。因此能夠實現(xiàn)更加用戶友好的認證處理。
[0127]本發(fā)明的第一和第二實施例僅僅是用于實施本發(fā)明的例子。實施例中的要素與在所附權利要求書提出的發(fā)明特定項具有對應關系。然而，本發(fā)明不限于這些要素，可進行各種變形而不脫離本發(fā)明的精神和范圍。
[0128]具體地，在權利要求1和2中，識別信息獲取器對應于例如無線網(wǎng)絡接口 102或202。此外，識別信息保持器對應于例如訪問控制列表107或電話簿208。另外，認證單元對應于例如通信控制器101或201。
[0129]在權利要求3中，認證可能性信息對應于例如認證可能性713或823。
[0130]在權利要求5中，公鑰證書對應于例如X.509格式的公鑰證書610。
[0131]在權利要求6中，保持在識別信息保持器中的電話號碼對應于例如電話號碼822。
[0132]在權利要求7和8中，獲取識別信息的步驟對應于例如過程311或321。此外，保持識別信息的步驟對應于例如過程312或322。另外，繼續(xù)認證的步驟對應于例如步驟S911至S915或步驟S921至S925。
[0133]在本發(fā)明的第一和第二實施例中說明的處理過程可作為包含該一系列過程的方法。此外，該處理過程也可作為用于使計算機執(zhí)行這一系列過程的程序或存儲該程序的記錄介質。
[0134]應當理解，本發(fā)明不限于上述實施例，而是還涵蓋了落入所附權利要求書的精神和范圍內(nèi)的變化。
[0135]本發(fā)明包含與2006年9月14日向日本專利局提交的日本JP2006-250131號專利申請和2007年7月30日向日本專利局提交的日本JP2007-196837號專利申請相關的主題，其全部內(nèi)容通過引用而包含于此。
【權利要求】
1.一種無線通信系統(tǒng)，其中多個無線通信裝置以分布式自主方式而形成網(wǎng)絡，所述多個無線通信裝置中的每一個包括: 識別信息獲取器，其被配置為從滿足預定條件的另一無線通信裝置獲取所述另一通信裝置的識別信息； 識別信息保持器，其被配置為保持所獲取的所述另一無線通信裝置的識別信息；以及 認證單元，其被配置為在所述另一無線通信裝置的認證中，如果所述另一無線通信裝置的證書中的識別信息保持在所述識別信息保持器中，則繼續(xù)所述認證。
2.一種無線通信系統(tǒng)中的無線通信裝置，在所述無線通信系統(tǒng)中，多個無線通信裝置以分布式自主方式而形成網(wǎng)絡，所述裝置包括: 識別信息獲取器，其被配置為從滿足預定條件的另一無線通信裝置獲取所述另一通信裝置的識別信息； 識別信息保持器，其被配置為保持所獲取的所述另一無線通信裝置的識別信息；以及 認證單元，其被配置為在所述另一無線通信裝置的認證中，如果所述另一無線通信裝置的證書中的識別信息保持在所述識別信息保持器中，則繼續(xù)所述認證。
3.根據(jù)權利要求2所述的無線通信裝置，其特征在于， 所述識別信息保持器將與所述另一無線通信裝置的認證可能性相關的信息保持為認證可能性信息，從而將所述認證可能性信息與所獲取的所述另一無線通信裝置的識別信息關聯(lián)，以及 在所述另一無線通信裝置的認證中，如果所述另一無線通信裝置的證書中的識別信息與保持在所述識別信息保持器中的識別信息一致，且所述認證可能性信息表示所述認證是可能的，則所述認證單元繼續(xù)所述認證。
4.根據(jù)權利要求3所述的無線通信裝置，其特征在于， 在對用戶顯示了用于提示用戶判斷是否許可繼續(xù)所述認證的信息后，如果用戶做出了指示所述認證單元繼續(xù)所述認證的輸入，則即使所述認證可能性信息表示不許可所述認證，所述認證單元也繼續(xù)所述認證，而與是否滿足所述條件無關。
5.根據(jù)權利要求2所述的無線通信裝置，其特征在于， 所述另一無線通信裝置的證書是所述另一無線通信裝置的公鑰證書，所述證書中的識別信息是所述公鑰證書的所有者的識別信息。
6.根據(jù)權利要求2所述的無線通信裝置，其特征在于， 保持在所述識別信息保持器中的所述另一通信裝置的識別信息包括所述另一通信裝置的電話號碼，所述證書中的識別信息包括所述另一通信裝置的電話號碼。
7.一種無線通信裝置的認證方法，所述無線通信裝置包括識別信息保持器，所述識別信息保持器保持由多個無線通信裝置以分布式自主方式而形成網(wǎng)絡的無線通信系統(tǒng)中的另一無線通信裝置的識別信息，所述方法包括以下步驟: 從滿足預定條件的另一無線通信裝置獲取所述另一通信裝置的識別信息； 將所獲取的所述另一無線通信裝置的識別信息保持在所述識別信息保持器中；以及 在所述另一無線通信裝置的認證中，如果所述另一無線通信裝置的證書中的識別信息保持在所述識別信息保持器中，則繼續(xù)所述認證。
8.一種在無線通信裝置上運行的程序，所述無線通信裝置包括識別信息保持器，所述識別信息保持器保持由多個無線通信裝置以分布式自主方式而形成網(wǎng)絡的無線通信系統(tǒng)中的另一無線通信裝置的識別信息，所述程序使計算機執(zhí)行以下步驟: 從滿足預定條件的另一無線通信裝置獲取所述另一通信裝置的識別信息； 將所獲取的所述另一無線通信裝置的識別信息保持在所述識別信息保持器中；以及在所述另一無線通信裝置的認證中，如果所述另一無線通信裝置的證書中的識別信息保持在所述識別信息保持器中，則 繼續(xù)所述認證。
【文檔編號】H04W12/08GK104079564SQ201410263749
【公開日】2014年10月1日 申請日期:2007年9月14日 優(yōu)先權日:2006年9月14日
【發(fā)明者】鈴木英之 申請人:索尼株式會社