通信装置、及び通信方法
【課題】ユーザの利便性、及びセキュリティの高い接続認証方式を提供すること。
【解決手段】通信可能距離が互いに異なる第1及び第2の通信部により通信する通信装置が提供される。当該通信装置は、比較的通信可能距離が短い第1の通信部を介して、接続毎に生成される乱数と、当該乱数により算出される証明書と、第2の通信部の認証方式が公開鍵方式に対応するか否かを示す認証方式情報と、が含まれる通信パケットを受信する受信部と、通信パケットに含まれる認証方式情報に基づいて当該通信パケットの送信元が公開鍵暗号に対応するか否かを判別する方式判別部とを備え、方式判別部により通信パケットの送信元が公開鍵方式に非対応であると判別された場合に、自装置の識別情報として通信パケットに含まれる乱数を返信する。
【解決手段】通信可能距離が互いに異なる第1及び第2の通信部により通信する通信装置が提供される。当該通信装置は、比較的通信可能距離が短い第1の通信部を介して、接続毎に生成される乱数と、当該乱数により算出される証明書と、第2の通信部の認証方式が公開鍵方式に対応するか否かを示す認証方式情報と、が含まれる通信パケットを受信する受信部と、通信パケットに含まれる認証方式情報に基づいて当該通信パケットの送信元が公開鍵暗号に対応するか否かを判別する方式判別部とを備え、方式判別部により通信パケットの送信元が公開鍵方式に非対応であると判別された場合に、自装置の識別情報として通信パケットに含まれる乱数を返信する。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、通信装置、及び通信方法に関する。
【背景技術】
【0002】
近年、多くの電子機器が無線通信機能を有するようになってきており、それに応じて、様々な無線通信規格が制定されている。個人向け無線技術の代表例として、例えば、無線LAN(以下、WLAN)やBluetooth(登録商標)(以下、BT)が挙げられる。これらの無線技術は、パーソナルコンピュータ(以下PC)、携帯電話、電子手帳(以下、PDA)等の多機能電化製品を中心に様々な機器に搭載されている。最近では、デジタルカメラやプリンタ等の小型組み込み機器においても、こうした無線技術が利用されるようになってきている。以下、無線技術を搭載した機器のことを無線デバイスと呼ぶ。
【0003】
これらの無線デバイスが広く普及し、多くの場面で使用されることでユーザの利便性が向上する一方で、ネットワークを介して無線デバイスへ侵入される被害や、クレジットカード情報やパスワード等の個人情報が流出する被害等が報告されている。こうした被害が社会問題化しており、無線デバイスにおけるセキュリティの強化が強く望まれている。
【0004】
BTの場合、現状、最大16バイトの鍵情報(パスキー)を用いた認証技術が採用されており、さらに、伝送路の暗号化技術がセキュリティ機能に盛り込まれている。ところが、実際、4文字程度のパスキーが使われている場合が多い。このような運用方法では、パスワードの組み合わせ数が少ないため、不正に認証されてしまう危険性が高い。一方、WLANの場合、当初WEPと呼ばれる暗号化方式が実装されていた。しかし、この暗号方式が比較的短時間で解読できることが公表され、その後、改善策としてWEP−TKIP方式、WPA、WPA2等の強固な暗号化技術が規格に盛り込まれることになった。
【0005】
セキュリティ機能について多数の方式が提供される一方で、こうした技術に関する専門知識がない一般のユーザにとっては、接続機器に応じた適切な暗号化方式を選択したり、選択した方式に応じた適切な設定をすること自体が非常に大きな負担である。多くの場合、ユーザは、メーカーの技術サポート窓口に相談するか、或いは、無線デバイスの設定自体を諦めてしまう。その結果、セキュリティが十分に機能していない無線デバイスが利用されていたり、無線デバイスが家電製品等に普及しにくい土壌が作られている。
【0006】
上記のような現状に鑑み、セキュリティの強化に関する技術、及びネットワーク設定を簡単化する技術の研究開発が鋭意進められている。こうした技術に関し、例えば、下記の特許文献1には、WLANのセットアップ方式に関する技術が開示されている。同文献には、電波強度を弱めて電波到達範囲を絞り込むことで、アクセスポイントとWLAN端末間の通信範囲を狭め、セキュリティを向上させる技術が開示されている。さらに、同文献には、アクセスポイント及びWLAN端末上に設けられたボタンが同時に押下されることで、ネットワークのセットアップが完了できる接続手段が開示されている。また、BTに関して、下記の特許文献2には、接続機器の双方に設けられたボタンを押下するだけで接続設定が完了する方法に関する技術が開示されている。これらの技術を用いることで、セキュリティの高いネットワーク設定が簡単操作で実現される。
【0007】
【特許文献1】特開2004−215232号公報
【特許文献2】特許第3928489号公報
【発明の開示】
【発明が解決しようとする課題】
【0008】
上記の各文献に加え、各種の無線技術に関する規格団体は、セットアップ手順の簡単化とセキュリティの強化とを両立させるための規格を発表している。BTの規格団体であるBluetooth SIGは、Core規格のバージョン2.1において、Secured Simple Pairing(以下、SSP)と呼ばれる技術を必須実装項目として挙げている。さらに、WLANの認証団体であるWiFi Allianceは、WiFi Protected Setup(以下、WPS)と呼ばれる技術を発表している。
【0009】
これらの規格は、設定情報を暗号化して送受信する際に公開鍵暗号技術を利用する方式を採用している。そのため、従来よりもセキュリティを強化できると共に、ユーザによるセットアップ作業の負担を低減させることができる。この方式は、公開鍵によって暗号化された伝送路上で設定情報が安全に交換されるように設計されている。そのため、これら規格に対応した製品が早急に市場に普及することが期待されている。
【0010】
しかしながら、公開鍵方式の演算ロジックは、秘密鍵方式の演算ロジックと比較して計算量が多く、専用に設計されたハードウェアロジック回路が必要とされる。そのため、公開鍵方式を採用した機器における回路規模の増大、及びコストアップが懸念されている。2006年の時点で、従来規格の製品出荷台数は5億1500万台と言われ、非常に巨大な市場が既に形成されている。つまり、廉価な製品の提供が可能な大量供給体制が整備されてしまっている。そのため、安全性、及び利便性の面で優れている上記のような新規格に対応したデバイスが登場しても、旧規格のデバイス生産が継続され、新旧両規格の製品が市場に並存することが予想される。
【0011】
こうした状況において、新規格による簡単でセキュアなネットワーク設定が可能な無線デバイスをユーザが保持していても、その接続先機器が旧規格にしか対応していないことで、ユーザは、従来の煩雑で低セキュリティのネットワーク設定を行う必要に迫られてしまう。また、ユーザには、新規格のデバイスと旧規格のデバイスとで異なる設定方法を使い分けることが要求される。そのため、却ってネットワークの設定方法が煩雑になり、ユーザの負担を増大させてしまうのである。
【0012】
そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、公開鍵方式を利用する認証方式、及び非公開鍵方式による認証方式に対応し、いずれの認証方式のデバイスに接続される場合でも、ユーザに掛かる設定の負担を低減させることが可能な、新規かつ改良された通信装置、及び通信方法を提供することにある。
【課題を解決するための手段】
【0013】
上記課題を解決するために、本発明のある観点によれば、通信可能距離が互いに異なる第1及び第2の通信部により通信する次のような通信装置が提供される。当該通信装置は、比較的通信可能距離が短い第1の通信部を介して、接続毎に生成される乱数と、当該乱数により算出される証明書と、前記第2の通信部の認証方式を示す認証方式情報と、が含まれる通信パケットを受信する受信部と、前記通信パケットに含まれる認証方式情報に基づいて当該通信パケットの送信元が対応する認証方式を判別する方式判別部とを備え、前記方式判別部による判別結果に応じて前記通信パケットに含まれる乱数を前記第2の通信部の認証処理に用いる識別情報として利用するものである。
【0014】
また、前記認証方式情報は、前記第2の通信部の認証方式が公開鍵方式に対応するか否かを示す情報であってもよく、前記方式判別部は、前記通信パケットに含まれる認証方式情報に基づいて当該通信パケットの送信元が公開鍵方式に対応するか否かを判別するように構成されていてもよい。この場合、上記の通信装置は、前記方式判別部により前記通信パケットの送信元が公開鍵方式に非対応であると判別された場合に、自装置の識別情報として前記通信パケットに含まれる情報を返信するように構成される。
【0015】
上記の通信装置は、受信部により、比較的通信可能距離が短い第1の通信部を介して、接続毎に生成される乱数と、当該乱数により算出される証明書と、第2の通信部の認証方式が公開鍵方式に対応するか否かを示す認証方式情報と、が含まれる通信パケットを受信する。そのため、証明書、及び乱数を用いて当該通信パケットに含まれる情報の送信元が正当であることを確かめることができる。このとき、乱数が接続毎に生成されているため、証明書の有効期限が接続毎に設定される。その結果、通信パケットに含まれる情報を他人が傍受し、後ほど利用しようとした際に、その不正行為を検知できる。
【0016】
また、上記の通信装置は、方式判別部により、通信パケットに含まれる認証方式情報に基づいて当該通信パケットの送信元が公開鍵方式に対応するか否かを判別する。さらに、方式判別部により通信パケットの送信元が公開鍵方式に非対応であると判別された場合に、自装置の識別情報として通信パケットに含まれる情報を返信する。通信パケットの送信元が公開鍵方式に対応していれば、公開鍵方式に基づいてセキュアに認証情報を送ることができる。しかし、公開鍵方式に非対応の場合は、セキュリティを確保できない。そのため、上記の通信装置は、接続毎に生成される乱数(一時値)を用いることでセキュリティを確保している。このような構成を適用することで、通信相手が公開鍵方式に対応するか、非対応かに関わらず、セキュリティを確保しながら接続設定をすることができるようになる。
【0017】
また、前記通信パケットには、前記送信元を識別するための識別情報と、当該識別情報に有効期限が設定されているか否かを示す期限情報がさらに含まれていてもよい。その場合、上記の通信装置は、前記期限情報が有効期限の設定有りを示す場合に、前記有効期限が経過した後で、前記通信パケットに含まれる設定情報に基づいて生成された情報を全て破棄するように構成されていてもよい。このような構成にすることで、識別情報、及びそれから派生的に生成された全ての情報に有効期限が設定され、よりセキュリティを向上させることができる。
【0018】
また、上記の通信装置は、所定の確認情報が表示される表示部と、前記確認情報に対する承認を示す情報を入力するための入力部と、をさらに備えていてもよい。この場合において、前記通信パケットに含まれる識別情報を有効にするか否かの承認要求が前記表示部に表示され、前記入力部により承認を示す情報が入力された場合に、当該識別情報が有効化されるように構成することができる。その結果、ユーザによる承認工程を踏む分だけ、セキュリティを向上させることができる。
【0019】
また、前記通信パケットに含まれる情報を返信するか否かの承認要求が前記表示部に表示され、前記入力部により承認を示す情報が入力された場合に、当該識別情報に基づいて前記第2の通信部による通信が開始されるように構成することもできる。この場合にも、ユーザによる承認工程を踏む分だけ、セキュリティを向上させることができる。
【0020】
また、前記通信パケットには、前記受信パケットの送信元を特定するためのアドレス情報がさらに含まれている。そのため、前記第2の通信部は、前記アドレス情報で特定される前記受信パケットの送信元との間のみで通信するように構成することができる。このように、通信相手を制限することで、セキュリティを向上させることができる。
【0021】
また、前記通信パケットには、前記第2の通信方式により形成可能なネットワーク構成を示す構成情報が含まれる場合がある。その場合、所定の属性の中から、前記構成情報に基づいてネットワーク内における自装置の属性が決定されるように構成することができる。その結果、ネットワーク構成をユーザが意識することなく、専門知識のない一般ユーザであっても、容易にネットワーク設定できるようになる。
【0022】
また、上記課題を解決するために、本発明の別の観点によれば、通信可能距離が互いに異なる第1及び第2の通信部を有する通信装置による次のような通信方法が提供される。当該通信方法は、比較的通信可能距離が短い第1の通信部を介して、接続毎に生成される乱数と、当該乱数により算出される証明書と、前記第2の通信部の認証方式を示す認証方式情報と、が含まれる通信パケットが受信される受信ステップと、前記通信パケットに含まれる認証方式情報に基づいて当該通信パケットの送信元が対応する認証方式が判別される方式判別ステップと、前記方式判別ステップにおける判別結果に応じて前記通信パケットに含まれる乱数を識別情報として利用することで前記第2の通信部の認証処理がされる認証ステップとを含むものである。
【0023】
また、通信可能距離が互いに異なる第1及び第2の通信部を有する通信装置による次のような通信方法が提供されてもよい。この通信方法は、比較的通信可能距離が短い第1の通信部を介して、接続毎に生成される乱数と、当該乱数により算出される証明書と、前記第2の通信部の認証方式が公開鍵方式に対応するか否かを示す認証方式情報と、が含まれる通信パケットが受信される受信ステップと、前記通信パケットに含まれる認証方式情報に基づいて当該通信パケットの送信元が公開鍵暗号に対応するか否かが判別される方式判別ステップと、前記方式判別ステップで前記通信パケットの送信元が公開鍵方式に非対応であると判別された場合に、自装置の識別情報として前記通信パケットに含まれる乱数が返信される識別情報返信ステップとを含むことを特徴とする。
【0024】
上記の通信方法では、受信ステップにより、比較的通信可能距離が短い第1の通信部を介して、接続毎に生成される乱数と、当該乱数により算出される証明書と、前記第2の通信部の認証方式が公開鍵方式に対応するか否かを示す認証方式情報と、が含まれる通信パケットが受信される。そのため、証明書、及び乱数を用いて当該通信パケットに含まれる情報の送信元が正当であることを確かめることができる。このとき、乱数が接続毎に生成されているため、証明書の有効期限が接続毎に設定される。その結果、通信パケットに含まれる情報を他人が傍受し、後ほど利用しようとした際に、その不正行為を検知できる。
【0025】
また、上記の通信方法では、方式判別ステップにより、通信パケットに含まれる認証方式情報に基づいて当該通信パケットの送信元が公開鍵方式に対応するか否かが判別される。さらに、方式判別ステップにより通信パケットの送信元が公開鍵方式に非対応であると判別された場合に、自装置の識別情報として通信パケットに含まれる乱数が返信される。通信パケットの送信元が公開鍵方式に対応していれば、公開鍵方式に基づいてセキュアに認証情報を送ることができる。しかし、公開鍵方式に非対応の場合は、セキュリティを確保できない。そのため、上記の通信方法では、接続毎に生成される乱数(一時値)を用いることでセキュリティを確保している。このような構成を適用することで、通信相手が公開鍵方式に対応するか、非対応かに関わらず、セキュリティを確保しながら接続設定をすることができるようになる。
【発明の効果】
【0026】
以上説明したように本発明によれば、公開鍵方式を利用する認証方式、及び非公開鍵方式による認証方式に対応し、いずれの認証方式のデバイスに接続される場合でも、ユーザに掛かる設定の負担を低減させることができる。
【発明を実施するための最良の形態】
【0027】
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【0028】
<第1実施形態>
まず、本発明の第1実施形態について説明する。本実施形態は、本発明に係る技術をBT認証方式(補遺1を参照)に適用するケースを一例として示したものである。
【0029】
以下、次に示す順番で説明する。まず、本実施形態に係る通信方法が適用可能な通信システム10のシステム構成例について説明する。次いで、NFCデバイスを用いてBT認証方式を実現することが可能な通信装置100、200の機能構成について説明する。次いで、SSP方式の1つであるOut Of Band(OOB)方式について説明する。次いで、NFC通信パケットのパケット構成について説明する。次いで、非公開鍵方式に相当するBT認証方式(Core規格のバージョン2.0以前の認証方式)、及びOOB方式の手順について説明する。その中で、本実施形態に係る認証方式の選択手段について説明する。その他にも、本実施形態に係る一時パスキー方式、BTデバイス(以下、BD)のアドレス(以下、BDアドレス)に基づく通信対象の制限方式、及びユーザインターフェースによる認証方式等について説明する。
【0030】
(課題の整理)
既に述べた通り、新旧の規格が混在する状況では、新規格が簡単且つセキュアな設定方式に対応していても、ユーザに対し、旧規格の煩雑で低セキュリティの設定手順を要求してしまうことがある。新規格のBDでは、NFCを利用して簡単且つセキュアな設定方式を実現する。一方、旧規格のBDは、NFCの伝送フォーマットに互換性が無いばかりか、そもそも、NFCデバイスを認証に利用するように設計されていない。そのため、新旧規格のデバイスが混在した状況にある場合、ユーザは、新規格に対応するデバイスを保持していても、NFCを使った認証を断念し、従来の煩雑な手順を踏んでセットアップを行なう必要が生じてしまう。
【0031】
そこで、本実施形態は、NFCデバイスを用いたBT認証方式における次のような認証設定機能の提供を目指している。つまり、当該認証設定機能は、公開鍵ロジックが含まれる認証方式(例えば、OOB方式)と、公開鍵ロジックが含まれない認証方式(例えば、Core2.0以前の方式)とが並存する状況においても、互換性を保持しながら、簡単且つ高いセキュリティ強度を実現することができるものである。
【0032】
[通信システム10のシステム構成例]
まず、図1を参照しながら、本実施形態に係る通信システム10のシステム構成の一例について説明する。図1は、本実施形態に係る通信システム10のシステム構成例を示す説明図である。
【0033】
図1に示すように、通信システム10は、2つの通信装置100、200により構成されている。これらの通信装置100、200は、2種類の通信方式で通信できるように構成されている。その1つの通信方式(第1通信方式)は、近接通信方式(以下、NFC方式)である。NFC方式は、10cm程度の非常に短い距離間で通信するための通信方式であり、所謂、非接触通信と呼ばれる通信方式である。一方、他の通信方式(第2通信方式)は、第1通信方式よりも長い距離間で通信可能な通信方式である。また、第2通信方式は、第1通信方式に比べて帯域幅が広く、比較的高速な通信が可能な通信方式である。本実施形態の場合、第2通信方式にはBTが適用される。
【0034】
上記のようなシステム構成において、通信装置100、200間では、まず、第1通信方式により、第2通信方式による通信用の設定情報が交換され、認証処理が実行される。認証処理が完了すると、通信装置100、200間でペアリングが成立し、サービス毎の接続認証無しに、第2通信方式でサービスが提供されるようになる。旧規格の場合、この相互認証に際し、個々の装置を識別するためのパスキー(PINコード)をユーザが通信装置100、200に手入力していた。また、パスキーには、1〜16桁までの英数字が利用可能であるが、現状、ユーザが管理しやすいように4桁程度の短いものが用いられることが多い。そのため、パスキーが推測され易く、セキュリティの低下を招いていた。
【0035】
そこで、本実施形態では、第1通信方式の通信手段を利用してパスキー等の認証情報を相互に交換する認証方式を採用し、セキュリティの向上を図っている。このとき、通信装置100、200のいずれかが、認証情報を第1通信方式で交換する認証方式に対応していないと、この認証方式によるセキュアな認証設定が実現されない。そのため、本実施形態は、こうした互換性の問題に対しても解決手段を提供する。
【0036】
[通信装置100、200の機能構成]
次に、図2を参照しながら、本実施形態に係る通信装置100、200の機能構成について説明する。図2は、本実施形態に係る通信装置100、200の機能構成を示す説明図である。
【0037】
図2に示すように、通信装置100、200は、主に、アンテナ102、106と、近接通信部104と、近距離通信部108と、制御部110と、RAM(Random Access Memory)112と、ROM(Read Only Memory)114と、フラッシュメモリ116と、入力部118と、表示部120とにより構成される。尚、アンテナ102、近接通信部104は、図23に示すハードウェア資源のうち、ICカード、又はリーダ/ライタを構成する要素の一部又は全部により実現される。アンテナ106、近距離通信部108は、図24に示すハードウェア資源のうち、例えば、通信部926により実現される。制御部110の機能は、例えば、制御回路712、コントローラ722、又はCPU902により実現される。
【0038】
(近接通信部104)
近接通信部104は、アンテナ102に接続されており、第1通信方式(NFC方式)に従ってデータを送受信することができる。近接通信部104は、例えば、13.56MHz帯の周波数を利用し、10cm程度の非常に短い距離間において最大424Kビット/秒の通信レートで通信することができる。尚、近接通信部104の通信距離、通信速度、及び利用周波数帯域は、上記の例に限定されず、任意に設定され得る。
【0039】
(近距離通信部108)
近距離通信部108は、近接通信部104よりも長い距離間で通信することが可能な通信手段である。また、近距離通信部108は、アンテナ106に接続されており、近接通信部104よりも広い帯域幅を利用し、高速にデータを送受信することができる。さらに、近距離通信部108は、第2通信方式としてBTに対応し、例えば、2.4GHz帯の通信帯域を利用して最大3Mビット/秒の通信速度で通信することができる。尚、通信帯域、及び通信速度は、BT規格のCore2.0+EDRで規定されたもの以外にも、これ以降のバージョンや他の規格が適用されてもよく、実施の態様に応じて適宜変更可能である。
【0040】
(制御部110)
制御部110は、通信装置100、200の各構成要素の動作を制御する手段である。また、制御部110は、主に、鍵ペア生成機能と、共有鍵算出機能と、乱数生成機能と、証明書算出機能と、設定情報付加機能と、設定情報抽出機能と、認証値算出機能と、リンクキー算出機能と、認証レコード付加機能と、認証レコード抽出機能と、認証方式判定機能と、パスキー設定機能と、表示制御機能と、通信制御機能とを有する。
【0041】
鍵ペア生成機能は、ペアを成す公開鍵(PKa,PKb)と秘密鍵(SKa,SKb)を生成する機能である。鍵ペア生成機能は、例えば、Diffie−Hellmanにより公表された鍵生成アルゴリズムに基づいて公開鍵/秘密鍵のペアを生成する機能である。尚、秘密鍵(SKa,SKb)は、RAM112、又はフラッシュメモリ116に格納される。共有鍵算出機能は、取得した公開鍵(PKa,PKb)と自装置の公開鍵(PKb,PKa)とを利用して共有鍵(DHKey)を算出する機能である。
【0042】
乱数生成機能は、物理的な乱数生成器から乱数を取得するか、或いは、所定の乱数生成アルゴリズムを利用して疑似乱数を生成する機能である。所定の乱数生成アルゴリズムとしては、例えば、線形合同法やメルセンヌ・ツイスター法等、種々の方法が利用可能である。但し、その性質上、より良いアルゴリズムが用いられることが好ましい。以下、乱数発生器による乱数であるか、疑似乱数であるかを表現上区別せず、単に乱数と呼ぶ。
【0043】
証明書算出機能は、乱数生成機能により生成された乱数(ra,rb,Na,Nb)等に基づき、所定のハッシュ関数を利用して証明書(Ca,Cb)を算出する機能である。設定情報付加機能は、近接通信部104により送信される通信パケットに設定情報を付加する機能である。設定情報には、例えば、自装置のBDアドレス、乱数(ra,rb)、及び証明書(Ca,Cb)等が含まれる。尚、証明書(Ca、Cb)は、図27に示すロジック(f1)により生成されてもよい。
【0044】
設定情報抽出機能は、近接通信部104により受信された通信パケットに付加された設定情報を抽出する機能である。認証値算出機能は、リンクキーを算出する前段で相互認証するための認証値(Ea,Eb)を乱数(Na、Nb)、及び所定の関数(f2)を用いて算出する機能である。リンクキー算出機能は、共有鍵(DHKey)等に基づいてリンクキー(LK)を算出する機能である。
【0045】
認証レコード付加機能は、後述するNDEFメッセージに認証フラグを示すNDEF Recordを付加する機能である。この認証フラグには、認証方式のRecordであることを示す識別子と、認証方式を示す識別子と、BTネットワークの構成を示す識別子とが含まれる。これらの識別子については、後段において詳述する。認証レコード抽出機能は、後述するNDEFメッセージに付加された認証フラグを示すNDEF Recordを抽出する機能である。
【0046】
認証方式判定機能は、認証レコード抽出機能により抽出されたNDEF Recordの認証フラグを参照し、NDEFメッセージの送信元装置が対応する認証方式を判定する機能である。また、認証方式判定機能は、送信元装置が対応する認証方式と、自装置が対応する認証方式とを比較し、より適した認証方式を選択する機能を含む。
【0047】
パスキー設定機能は、認証方式判定機能により、後述する一時パスキー方式が選択された場合に、証明書の発行に用いられる乱数をパスキーに設定する機能である。さらに、パスキー設定機能は、パスキーの有効期限を管理し、有効期限が経過した後で、フラッシュメモリ116等に格納されたパスキー及び設定情報を消去する機能を含む。また、パスキー設定機能は、パスキーの有効/無効を管理する機能を含む。
【0048】
表示制御機能は、例えば、表示部120に対し、パスキー等の設定情報をNFC通信で送信するか否かの許諾をユーザに求める表示をさせたり、NFC通信により受信したパスキーを有効にするか否かをユーザに確認する表示をさせる機能である。通信制御機能は、NFC通信により受信したBDアドレスが示す接続先のみにBTによる通信相手を制限するように近距離通信部108を制御する機能である。
【0049】
(その他)
RAM112は、例えば、制御部110による演算処理の際に、スタック領域、又はヒープ領域として利用される。ROM114には、例えば、制御部110の機能を実現するためのプログラムの実行バイナリコードが格納されている。但し、制御部110の機能を実現するためのプログラムのバイナリコードは、フラッシュメモリ116に格納されていてもよい。
【0050】
[OOB方式による認証方法]
次に、図3を参照しながら、OOB方式に係る認証方法について説明する。図3は、OOB方式に係る認証処理の流れを示す説明図である。上記の通り、OOB方式はSSP認証方式の一例である。この流れの中で、通信装置100、200は、ユーザにより近接された状態で近接通信部104によりNFC通信を実行し、その後、近距離通信部108によりBTによる認証処理を実行する。
【0051】
まず、通信装置100、200が十分に近接され、NFC通信による通信可能範囲まで近づくと、近接通信部104を介して設定情報(BDアドレス、証明書等)が交換される(S102)。次いで、設定情報に含まれるBDアドレスに基づいて相互に公開鍵(PKa,PKb)が交換される(S104)。このとき、制御部110により、取得した公開鍵(PKb,PKa)、及び自装置の秘密鍵(SKa,SKb)に基づいて共有鍵(DHKey)が生成される(S104)。
【0052】
次いで、通信装置100、200は、それぞれ、受信した設定情報に含まれる乱数(ra,rb)、及び証明書(Ca,Cb)等を利用して第1の認証処理(図26の認証処理に相当)を実行する(S106)。但し、図26における第1の認証処理の場合、証明書の発行に公開鍵を利用しているため、NFC通信の開始以前に公開鍵が交換されていることが前提となるが、本実施形態は、このような方式にも適用可能である。
【0053】
第1の認証処理が成功裏に完了すると、通信装置100、200の制御部110により、それぞれ、乱数(Na,Nb)が生成され、近距離通信部108を介して交換される。また、制御部110により、共有鍵(DHKey)、取得した乱数(Na,Nb,ra,rb)、及びBDアドレス等が利用され、所定の認証関数(f3)に基づいて認証値(Ea,Eb)が算出される。そして、これらの認証値(Ea,Eb)が互いに交換され、通信装置100、200において、それぞれ第2の認証処理(図28の認証処理に相当)が実行される(S106)。次いで、通信装置100、200の制御部110により、それぞれ、リンクキー(LK)が算出される(S108)(図25を参照)。
【0054】
以上、OOB方式による認証方法について簡単に説明した。上記のように、NFC通信による設定情報の交換、及び公開鍵暗号による伝送路の暗号化が施されることで、中間者攻撃のような認証情報の盗聴等に対して高い耐性が実現される。
【0055】
[NFC通信パケットの構成例]
次に、図4を参照しながら、NFC通信に利用される通信パケットの構成例について説明する。図4は、NFC通信に利用される通信パケットの構成例を示す説明図である。
【0056】
上記のようなNFC通信は、NFC Forumで規定されたNFC Data Exchange Format(以下、NDEF)に則って行なわれる。NFC通信におけるパケットは、図4に示すようなNDEF Recordと呼ばれる単位で構成される。NDEF Recordは、大きく分けてRecord Type部分D5、Record ID部分D6、Payload部分D7により構成される。
【0057】
また、NDEF Recordの先頭部分D1には、そのRecordがメッセージの最初のレコードであるか否かを示す識別子MBと、そのRecordがメッセージの最後のレコードであるか否かを示す識別子MEが含まれる。さらに、この先頭部分D1には、Payload部分D7のデータ長が1バイト長であるか、4バイト長であるかを示す識別子SR(A1)が含まれる。さらに、この先頭部分D1には、Record ID部分D6の有無を示す識別子IL(A2)、及びRecord Type部分D5のフォーマットを指定する識別子TNF(A3)が含まれる。また、NDEF Recordのヘッダ部分D2、D3、D4には、それぞれ、Record Type部分D5、Record ID部分D6、Payload部分D7のデータ長が格納される。
【0058】
Record Type部分D5は、Payload部分D7に格納されるデータの識別子として利用される。そのため、Record Type部分D5は、Payload部分D7に格納されたデータのフォーマットが特定される際に参照される。例えば、Record Type部分D5により、Payload部分D7の構造、及び意味が決定される(A4)。また、Record ID部分D6は、Payloadを同定するためのURI(Uniform Resource Identifier)が格納される(A5)。尚、Record Typeの定義は、NFCForumが規定する場合と、ユーザが独自に定義する場合とがある。
【0059】
さらに、図5を参照する。図5は、NDEFメッセージの構成例を示す説明図である。NDEFメッセージは、図4に示すNDEF Recordが集まって構成される。尚、NDEF Recordの先頭部分D1に含まれる識別子MB=1のレコードから、識別子ME=1のレコードまでが1つのNDEFメッセージを構成する。
【0060】
[NDEFメッセージの構成例]
次に、図6を参照しながら、OOB認証方式に適用可能な本実施形態に係るNDEFメッセージの構成例について説明する。図6は、OOB認証方式に適用可能な本実施形態に係るNDEFメッセージの構成例を示す説明図である。
【0061】
図6に示すように、NDEFメッセージは、例えば、3つのNDEF Recordにより構成される。第1のNDEF Record(Record1)には、このNDEFメッセージがハンドオーバー用であることを示すハンドオーバー用Record Typeが格納されている。尚、ハンドオーバーとは、第1通信方式であるNFC通信から、第2通信方式(セカンドキャリア)に通信方式を切り替える行為を意味している。第2のNDEF Record(Record2)には、例えば、Record TypeがBTであることを示す“bluetooth.org.sp”が格納されいる。さらに、そのペイロードには、BTの設定情報として、自装置のBDアドレス、乱数、ハッシュ値等が格納される。
【0062】
さらに、本実施形態に係るNDEFメッセージには、第3のNDEF Record(Record3)が付加される。この第3のNDEF Recordには、認証方式を示すRecordであることを識別するための第1識別子と、認証方式を示す第2識別子と、BTネットワーク構成を示す第3識別子とが含まれる。本実施形態において、第2識別子は、自装置がOOB方式の認証処理(Core 2.1)に対応するか否かを示すフラグ(a)と、後述する一時パスキー方式による認証処理(Core 2.0以前)に対応するか否かを示すフラグ(b)とにより構成される。第3識別子は、BT通信で形成されるネットワーク上において、自装置の役割がMasterになれるか否かを示すフラグ(a)、Slaveになれるか否かを示すフラグ(b)により構成されている。これらのフラグは、認証方式を決定するための判断に利用される。
【0063】
[NDEFメッセージを用いた認証方法]
次に、図7を参照しながら、本実施形態に係るNDEFメッセージを用いた認証方法の流れについて説明する。図7は、本実施形態に係るNDEFメッセージを用いた認証方法の流れを示す説明図である。
【0064】
図7に示すように、まず、通信装置100、200は、NFC通信により設定情報を交換する。例えば、NFC通信によりBDアドレスが交換される(S102)。このとき、NFC通信パケットには、BDアドレス、乱数、証明書等のSSP規定情報の他に、制御部110により付加された認証フラグ(第3のNDEF Record)が含まれる。NFC通信パケットが受信されると、制御部110により、第3のNDEF Recordが抽出され、NFC通信パケットの送信元装置が対応する認証方式が判定される(S132)。さらに、制御部110により、その送信元装置の認証方式と、自装置が対応する認証方式とを比較し、より適した認証方式が選択される。
【0065】
例えば、制御部110により、通信装置100、200が共にCore 2.1の認証方式(OOB方式)に対応していると判定された場合、OOB方式に則った認証方法が選択される。その場合、公開鍵の交換、証明書等による認証処理、及びリンクキーの生成処理が実行される。一方、通信装置100、200のいずれかがCore 2.1の認証方式に対応しておらず、且つ、いずれの装置も一時パスキー方式に対応している場合、一時パスキー方式による認証方法(Core 2.0以前の認証方式)が選択される。このとき、制御部110は、証明書の発行に用いるための16バイトの乱数列をパスキーに設定する(S134、S135)。このパスキーが交換され(S138)、これを用いて初期化キー、リンクキーが生成される(S140、S142)。
【0066】
ここで、図8を参照しながら、本実施形態に係るNDEFメッセージを用いた認証方法の流れについて簡単に整理する。図8は、本実施形態に係るNDEFメッセージを用いた認証方法の流れを示す説明図である。
【0067】
図8に示すように、まず、NFC通信によりNDEFメッセージが伝送される(S102)。次いで、NDEFメッセージに含まれる認証フラグが抽出され、その認証フラグに基づいて認証方法が選択される(S132)。認証方法がOOB方式であると判断された場合、ステップS104の処理に進行し、公開鍵の交換(S104)、認証処理(S106)、リンクキーの生成(S108)が順次実行される。一方、認証方法がOOB方式以外の方式であると判断された場合、ステップS134、S136の処理に進行し、証明書に用いる乱数に基づいてパスキーが生成され、ステップS140、S142の処理に進行する。ステップS140、S142では、初期化キー、リンクキーが順次生成される。
【0068】
このように、本実施形態に係るNDEFメッセージの構成が適用されることで、認証方式の選択処理が可能になり、さらに、証明書に用いる乱数に基づいてパスキーが生成されるため、そのパスキーを利用してOOB方式以外の認証方式にも適応できるようになる。元々、OOB方式を採用していないCore 2.0以前の認証方式では、BDアドレスが検索(S12)された後で、ユーザにパスキーの手入力(S14)が求められ、入力されたパスキーに基づいて初期化キー、リンクキーの生成が行われていた。本実施形態に係る認証方法を適用すると、OOB方式に対応していないデバイスに対しても、このようなパスキーの手入力を避けることができるため、セキュリティの向上に寄与する。
【0069】
[認証処理の流れと機能ブロックとの関係]
次に、図9を参照しながら、本実施形態に係る認証処理と、通信装置100、200が備える機能ブロックとの対応関係について説明する。図9は、本実施形態に係る認証処理と、通信装置100、200が備える機能ブロックとの対応関係を示す説明図である。
【0070】
BT Core規格のバージョン2.0以前のBT接続処理では、BDの「探索」処理が実行され、接続可能な通信機器の一覧が取得される。次いで、取得された通信機器の一覧の中から、ユーザにより所望の接続先が指定される。その後、パスキーがROM114、フラッシュメモリ116、又はキーボード等の入力部118から取得されることにより、接続相手の機器と同じパスキーが共有される。
【0071】
次いで、BT通信により、乱数やハッシュ値を通信相手との間で相互に交換し合うことにより、初期化キー、リンクキーが生成されて認証処理が完了する。但し、一度接続が確立された通信相手先については、BDアドレス、リンクキーをセットにしてフラッシュメモリ116内のセキュリティデータベース(以下、DB)内に保存しておき、次回接続時に、DBから読み出したリンクキーを用いて接続処理が行われる。
【0072】
本実施形態に係る技術は、こうしたBT Core規格のバージョン2.0以前の接続処理に対し、次のようにして互換性を確保している。
【0073】
まず、NFC通信により接続相手先のBDアドレス、及び16バイトの乱数が取得される(S202)。次いで、制御部110によりNFCパケットが分析され、認証方式が一時パスキー方式であると判断された場合に、16バイトの乱数をパスキーに置き換える。次いで、BTデバイス(近距離通信部108)に対して接続依頼が行われる(S206)。次いで、BDアドレスとリンクキーのセットが格納されているDB(フラッシュメモリ116)が参照され、接続先(取得したBDアドレスの対象装置)のリンクキーが既に存在するか否かが確認される(S208)。
【0074】
次いで、DB内に接続先のリンクキーが存在している場合、そのリンクキーを利用して接続される(S210、S212(YES))。一方、DB内に接続先のリンクキーが存在しない場合、制御部110に対してパスキーが要求される(S210、S212(NO))。接続先との間で相互に乱数、ハッシュ値等の交換が行われた後で、初期化キーが生成され(S214)、最終的にリンクキーが生成される。
【0075】
[一時パスキー方式の詳細]
次に、図10、及び図11を参照しながら、本実施形態に係る一時パスキー方式の詳細について説明する。図10には、通信装置200により生成されるパスキーの更新処理が示されている。一方、図11には、GUIによる認証許可方式が示されている。
【0076】
(有効期限付きパスキー設定について)
まず、図10を参照する。上記の通り、パスキーに設定される16バイトのデータ列は、平文のまま伝送されるため、NFC通信を受信可能な他の機器により盗聴される可能性がある。しかしながら、図10に示すように、パスキーに設定される乱数は、接続の度に新たに生成される(S134)。そのため、接続毎に異なるパスキーが生成される(S142)。こうした理由から、本実施形態に係る一時パスキー方式は、そのままでも比較的セキュリティが高いと言える。
【0077】
しかしながら、よりセキュリティを高めるためには、パスキーに有効期限を設定するのが好ましい。そこで、本実施形態では、パスキーに有効期限を設定し、そのパスキーを一時的な使い捨てキーとして取り扱う方法を採用する。このとき、パスキーの有効期間が失効するタイミングとして、次の3通りを考える。(1)認証が成功し、接続先と接続元の双方においてリンクキーが生成された時点、(2)NFC通信後、何らかの理由で認証が失敗したと判断された時点、(3)NFC通信後、認証開始から所定期間が経過した時点がパスキー失効のタイミングに設定される。
【0078】
この場合、上記(1)〜(3)のいずれかの条件が検出された場合に、制御部110は、NFCメッセージにより交換されたパスキーをフラッシュメモリ116から削除する。このように、パスキーに有効期限を設けることで、NFC通信の際に何者かによってパスキーが盗聴されたとしても、上記(1)〜(3)のいずれかの条件が成立した後で、このパスキーが無効化されるため、盗聴されたパスキーにより認証される確率が格段に低減される。
【0079】
(GUIによる認証許可について)
次に、図11を参照する。上記のように、パスキーに有効期限を設定することで、セキュリティを高めることができるが、本実施形態では、ユーザのGUI操作による認証許可を求めることで、更なるセキュリティの向上を図る方法を提案する。尚、図11では、通信装置100が通信装置200に認証許可を求めるケースが示されている。
【0080】
図11に示すように、認証を開始しようとする通信装置100の表示部120には、パスキーの送信確認を促す画面が表示される。例えば、表示部120には、「Touch」等の認証開始を促す画面が表示される。入力部118(例えば、表示部120上のタッチパネル)を介してユーザの通信許可が得られると、NFC通信によりパスキーが通信装置200に伝送される。
【0081】
一方、接続先の通信装置200には、表示部120に次処理の許可/不許可を指定するユーザインターフェースが表示される。例えば、この表示部120には、「Accept」等の認証受け入れ許可の確認表示がされる。このとき、通信装置200は、ユーザによる許可が得られるまで、受信したパスキーを有効化せず、ユーザによる許可入力が行われた場合にパスキーを有効化する。
【0082】
この方式を採用すると、両者のユーザがGUI経由で認証を許可した時点から、パスキーの有効期間が経過するまでの間だけが、BTによる通信可能な認証期間となる。その結果、ユーザが関知していない期間において、不正な侵入者により認証処理が進められないことになる。その結果、よりセキュリティを向上させることができる。
【0083】
さらに、パスキーの有効期間内において、NFC通信パケットから取得したBDアドレスが示す接続相手に対してのみ通信を許可する設定とすることで、更なるセキュリティの向上が見込める。この方式を採用すると、平文で伝送されるパスキーを盗聴したデバイスが認証を試みた場合に、BTにおける認証用の通信がブロックされ、認証処理を進めることができなくなる。その結果、更にセキュリティを向上させることが可能になる。
【0084】
[BTネットワークの構成例]
次に、図12を参照しながら、本実施形態に係るBTネットワークの構成例について説明する。図12は、本実施形態に係るBTネットワークの構成例を示す説明図である。
【0085】
BTの仕様によると、BTネットワークを形成する上で、通信装置100、200は、master、又はslaveのどちらかの役割が割り当てられる。さらに、masterとslaveとの間のみで通信が許されており、master同士、又はslave同士の接続は許されていない。このような制約内で、ピコネット、及びスキャタネットと呼ばれるネットワーク形態が実現される。
【0086】
ピコネットとは、1つのmasterが中心となり、最大8台のslaveがmasterに接続されるネットワークのことを言う。一方、スキャタネットとは、時分割でmasterとslaveとを切り替えることが可能なmaster/slaveに対し、slaveと別のmasterとが接続されることで、複数のピコネットが接続される形態のことを言う。このとき、master/slaveは、ある特定の時間帯でピコネット上のmasterとして振る舞い、他の時間帯で他のピコネットのslaveとして動作している。そのため、同時に複数のmasterがピコネット内に存在することがない。
【0087】
既に述べた通り、本実施形態に係るNDEFメッセージの第3のNDEF Recordには、BTネットワーク構成情報が含まれる。この部分には、その装置がmasterに対応可能か否か、及びslaveに対応可能か否かが示されている。そのため、このBTネットワーク構成情報が交換されることにより、適切なネットワークが形成される。
【0088】
(具体例)
例えば、何のネットワークにも所属していない接続元デバイスがmasterとなり、既にピコネットを形成している接続先デバイスに接続する場合について考える。
【0089】
1つのケース(Case.1)として、接続先デバイスがmaster可、slave不可であり、接続元デバイスがmaster/slave可の場合が考えられる。尚、NDEFメッセージの交換により、両者が役割の可否を認識しているものとする。この場合、接続先デバイスの役割がmasterで固定されているため、接続元デバイスがslaveになる。その結果、新しいネットワークは、接続先デバイスをmasterとし、接続元デバイスを含む複数のデバイスがslaveである単一のピコネットが形成される。
【0090】
一方、接続元デバイスがmaster可、slave不可であり、接続先デバイスがmaster/slave可のケース(Case.2)も考えられる。この場合、接続元デバイスの役割がmasterで固定されているため、接続先デバイスがslaveになる。その結果、接続先デバイスは、新しく生成されたネットワークのslaveとなり、同時に、既存のピコネットのmasterとなるため、スキャタネットが形成される。
【0091】
以上、本発明の第1実施形態について説明した。本実施形態に係る技術を適用することにより、BT Core規格のバージョン2.1、及びそれ以前の規格に準じて設計されたデバイスに対しても、ユーザがネットワークの設定を簡単に実現することが可能になる。また、ユーザがパスキー等の認証情報を手入力する必要が無いため、セキュリティの向上が見込める。さらに、パスキーに有効期限を設定したり、GUIによるユーザ認証を組み合わせることで、さらにセキュリティを向上させることができる。また、NFC通信パケットにネットワーク構成用の役割情報が含まれ、その役割情報が交換されることで、適切なネットワーク構成が容易に設定されるようになる。
【0092】
<第2実施形態>
次に、本発明の第2実施形態について説明する。本実施形態は、本発明に係る技術をWLAN認証方式に適用するケースを一例として示したものである。上記の第1実施形態ではBTの場合を例に挙げて説明したが、本実施形態ではWLANの場合を例に挙げて説明する。
【0093】
BT Core規格のバージョン2.1に含まれるOOB方式の認証方法と、WPSに含まれるOOB方式の認証方法とは、技術的な側面において、公開鍵方式による設定情報の安全なパケット交換が共通点として挙げられる。一方、ユーザビリティの観点においては、「NFCデバイスを近づけるだけで認証が終了する」という利便性が共通点として挙げられる。一方で、両規格における大きな相違点としては、ネットワーク構成の形態が異なることが挙げられる。そこで、本実施形態では、WLANのネットワーク構成に適用するための仕組みについて、重点的に説明する。
【0094】
[WLANにおけるネットワーク形態]
まず、図13を参照しながら、WLANのネットワーク形態について説明する。図13は、WLANのネットワーク形態の一例を示す説明図である。
【0095】
WLANにおけるネットワーク形態には、インフラストラクチャモード(以下、Infraモード)と、アドホック(Ad−hoc)モードとがある。多くの場合、1つのアクセスポイント(以下、AP)に複数のベースステーション(以下、BS)が接続されるInfraモードが多く使われる。Infraモードの場合、APは、有線又は無線で構築されたローカルエリアネットワークに属している。また、APは、各種のローカルサーバに接続される。
【0096】
さらに、ローカルエリアネットワークは、ゲートウェイを経由して、インターネット等の広域ネットワークに接続される。AP、BS、及び各種のサーバを含む各接続機器には、個々にIPアドレスが割り振られている。そのため、通信プロトコルであるTCP/IPに基づいてIPアドレスが割り振られた任意の接続機器に対してパケットの送受信ができる。こうした仕組みにより、Webサーバによる大規模なWebサービスの提供やメールサーバによるメール配信サービス等が実現されている。
【0097】
さて、WiFi Allianceは、WLANに関し、簡単且つセキュリティ強度の高い認証仕様を規定している。この規定は、WPSと呼ばれる。WPSのversion1.0h(以下、WPS1.0h)では、上記のInfraモードが想定されている。さらに、WPS1.0hでは、その他にも、いくつかの認証方式が規定されている。本実施形態では、その中の1つであるNFC通信を利用したOOB方式に着目する。
【0098】
WPS1.0hによると、認証処理に関係する機器(AP又はBS)の役割としては、認証情報の制御や管理を行うRegistrar、及び新規にネットワークへの接続を要求するEnrollerが規定されている。但し、APは接続先になる。以下の説明においては、図13に示すように、APがRegistrarの役割を果たす場合を想定して説明する。もちろん、本実施形態に係る技術は、これに限定されない。
【0099】
以下、図13の構成を例に挙げて認証処理の流れについて簡単に説明する。まず、Enrollerの役割を有するBS(以下、BS/Enroller)は、Registrar機能を有するAP(以下、AP/Registrar)に接続要求を送信する。このとき、ユーザは、BS/EnrollerとAP/Registrarとを十分に近づけ、NFC通信により必要な設定情報を交換させる。設定情報が交換されると、BS/EnrollerとAP/Registrarとは接続される。その結果、BS/Enrollerは、Infraモードで形成されたネットワークの1構成単位となる。尚、NFC通信による設定情報の交換は、WPS1.0hに準拠した方式で実現可能である。
【0100】
[NFC通信の形態]
次に、図14を参照しながら、本実施形態に適用可能なNFC通信の形態について説明する。図14は、本実施形態に適用可能なNFC通信の一形態を示す説明図である。
【0101】
本実施形態では、NFC通信をトリガーとしてWLAN通信経路が接続される形態を想定している。NFC通信パケットには、NFCの通信規格で規定された設定情報以外にも、例えば、「接続後にどのような通信処理が実行されるか」といった他の設定情報が格納できる。そのため、NFC通信パケットに格納された設定情報には種々の使い道が考えられる。例えば、NFC通信をトリガーとする接続の後で、インターネット上に存在するWebサーバにアクセスさせるような使い方が考えられる。
【0102】
このように、NFC通信パケットには多種多様な用途が想定されるが、本実施形態では、ユーザによりNFC通信が可能な距離まで2つのNFCデバイスが近づけられた際に、NFC通信パケットに格納された設定情報を利用して、WLAN通信に必要な認証処理が実現されるような使い方を想定する。特に、図14に示す通信装置100、200のようにNFCデバイスを搭載した機器間で、NFC通信により交換された設定情報に基づいて認証処理が実行され、通信装置100、200間がWLANで接続されるようなケースを想定する。
【0103】
(変形例)
尚、NFC通信による設定情報の交換は、図15に示すように、NFCデバイスを備えた通信媒介端末を介して交換されてもよい。この例は、通信装置100、200が備えるNFCデバイスが相互に離れた場所に設置され、互いに近接できないような場合等において利用される。また、NFCデバイスの通信特性に応じて、この例のような形態が採用されてもよい。この例の場合、例えば、通信装置100に翳された通信媒介端末にNFC通信で設定情報が一旦格納され、その後、この通信媒介端末が通信装置200のNFCデバイスに翳されることで、一旦格納された設定情報が通信装置200に読み取られる。また、逆の操作により、通信装置200の設定情報が通信装置100に伝達される。
【0104】
[通信装置100、200の機能構成]
次に、図16を参照しながら、本実施形態に係る通信装置100、200の機能構成について説明する。図16は、本実施形態に係る通信装置100、200の機能構成を示す説明図である。
【0105】
図16に示すように、通信装置100、200は、主に、アンテナ102、106と、近接通信部104と、近距離通信部158と、制御部160と、RAM112と、ROM114と、フラッシュメモリ116と、入力部118と、表示部120とにより構成される。尚、アンテナ106、近距離通信部158は、図23に示すハードウェア資源のうち、例えば、通信部926により実現される。制御部160の機能は、例えば、図23、又は図24に示された、制御回路712、コントローラ722、又はCPU902により実現される。
【0106】
上記の第1実施形態に係る通信装置100、200との主な相違点は、近距離通信部158、及び制御部160の機能構成にある。そこで、近距離通信部158、及び制御部160の機能構成について詳細に説明する。
【0107】
(近距離通信部158)
近距離通信部158は、近接通信部104よりも長い距離間で通信することが可能な通信手段である。また、近距離通信部158は、アンテナ106に接続されており、近接通信部104よりも広い帯域幅を利用し、高速にデータを送受信することができる。さらに、近距離通信部158は、第2通信方式としてWLANに対応している。
【0108】
(制御部160)
制御部110は、通信装置100、200の各構成要素の動作を制御する手段である。また、制御部160は、主に、鍵ペア生成機能と、乱数生成機能と、証明書算出機能と、設定情報付加機能と、設定情報抽出機能と、認証レコード付加機能と、認証レコード抽出機能と、認証方式判定機能と、を有する。
【0109】
鍵ペア生成機能は、ペアを成す公開鍵と秘密鍵を生成する機能である。鍵ペア生成機能は、例えば、Diffie−Hellmanにより公表された鍵生成アルゴリズムに基づいて公開鍵/秘密鍵のペアを生成する機能である。尚、秘密鍵は、RAM112、又はフラッシュメモリ116に格納される。
【0110】
乱数生成機能は、物理的な乱数生成器から乱数を取得するか、或いは、所定の乱数生成アルゴリズムを利用して疑似乱数を生成する機能である。所定の乱数生成アルゴリズムとしては、例えば、線形合同法やメルセンヌ・ツイスター法等、種々の方法が利用可能である。但し、その性質上、より良いアルゴリズムが用いられることが好ましい。
【0111】
証明書算出機能は、乱数生成機能により生成された乱数、及び、所定のハッシュ関数を利用して証明書を算出する機能である。設定情報付加機能は、近接通信部104により送信される通信パケットに設定情報を付加する機能である。設定情報には、例えば、自装置のIPアドレス、乱数、及び証明書等が含まれる。設定情報抽出機能は、近接通信部104の受信パケットに付加された設定情報を抽出する機能である。
【0112】
認証レコード付加機能は、後述するNDEFメッセージに認証フラグを示すNDEF Recordを付加する機能である。この認証フラグには、認証方式のRecordであることを示す識別子と、認証方式を示す識別子と、WLANネットワークの構成を示す識別子とが含まれる。これらの識別子については、後段において詳述する。認証レコード抽出機能は、後述するNDEFメッセージに付加された認証フラグを示すNDEF Recordを抽出する機能である。
【0113】
認証方式判定機能は、認証レコード抽出機能により抽出されたNDEF Recordの認証フラグを参照し、NDEFメッセージの送信元装置が対応する認証方式を判定する機能である。また、認証方式判定機能は、送信元装置が対応する認証方式と、自装置が対応する認証方式とを比較し、より適した認証方式を選択する機能を含む。
【0114】
[NDEFメッセージの構成例]
次に、図17を参照しながら、OOB認証方式に適用可能な本実施形態に係るNDEFメッセージの構成例について説明する。図17は、OOB認証方式に適用可能な本実施形態に係るNDEFメッセージの構成例を示す説明図である。
【0115】
上記の通り、WLANのOOB方式による認証処理においても、BTのOOB方式による認証処理の場合と同様に、図4、及び図5に示すNDEFメッセージを用いて設定情報が交換される。但し、本実施形態に係るNDEFメッセージは、図17に示すような構成を有する。
【0116】
図17に示すように、NDEFメッセージは、例えば、3つのNDEF Recordにより構成される。第1のNDEF Record(Record1)には、このNDEFメッセージがハンドオーバー用であることを示すハンドオーバー用Record Typeが格納されている。第2のNDEF Record(Record2)には、例えば、Record TypeがWLANであることを示す“application/vnd.wfa.wsc”が格納されており、そのペイロードにWLANの設定情報が格納されることが示されている。
【0117】
ペイロードの種類には、「OOB Device Password」、「Credential」、又は「空」がある。「OOB Device Password」としては、WPSの仕様中で規定された32バイトの公開鍵(Device Password)、又は証明書の生成に利用される20バイトのハッシュ値(Hash)等が格納される。「Credential」としては、APの設定に必要なSSID、伝送路の暗号化に利用される暗号鍵(NetworkKey)等の情報が格納される。これらの情報は、Type、Length、Value(TLV)方式にて格納される。一方、自装置に設定情報が存在せず、相手装置に設定情報を要求する場合、ペイロードは「空」になる。
【0118】
さらに、本実施形態に係るNDEFメッセージには、第3のNDEF Record(Record3)が付加される。この第3のNDEF Recordには、認証方式を示すRecordであることを識別するための第1識別子と、認証方式を示す第2識別子と、WLANネットワーク構成を示す第3識別子とが含まれる。
【0119】
本実施形態において、第2識別子は、自装置がWPSにより規定された「OOB Device Password」に対応するか否かを示すフラグ(a)と、「Credential」に対応するか否かを示すフラグ(b)と、認証設定情報の時限設定が可能か否かを示すフラグ(c)とにより構成される。この認証設定情報の時限設定とは、認証により設定された情報がWLAN接続が確立された段階で消去できるようにする設定である。また、第3識別子は、WLANで形成されるネットワーク構成として、ad−hocネットワークに対応するか否かを示すフラグ(a)と、自装置に割り当てられるIPアドレス(b)と、接続先に接続許可を与えるポート番号(c)と、FTPユーザ名/パスワード(d,e)とが含まれる。但し、FTPユーザ名/パスワードは、FTPサービスが提供される場合に含まれる。
【0120】
[認証処理の流れ]
次に、図18、及び図19を参照しながら、本実施形態に係る認証処理の流れについて説明する。図18、及び図19は、本実施形態に係る認証処理の流れを示す説明図である。この認証処理の中で、上記構成のNDEFメッセージが利用される。
【0121】
図18を参照する。まず、自装置(Enroller)がWPSの認証方式に対応するか否か、且つ、APの通信圏内(電波到達範囲内)か否かが判定される(S202)。自装置がWPSの認証方式に対応し、且つ、APの通信圏内である場合、ステップS204の処理に進行する。一方、両条件のいずれかが満たされない場合、ステップS220の処理に進行する。
【0122】
ステップS204において、自装置及び接続先装置の双方がWPS Password(公開鍵暗号方式)に対応するか否かが判定される(S204)。双方がWPS Passwordに対応している場合、ステップS206の処理に進行する。一方、双方がWPS Passwordに対応していない場合、ステップS214の処理に進行する。
【0123】
この判定処理において、自装置の制御部160により、WPSにおける公開鍵方式の設定パラメータ「OOB Device Password」に対応可否を示すフラグ(第2識別子)が設定される。また、自装置の制御部160により、上記の第3識別子にWLANのネットワーク構成情報が設定される。そして、自装置の制御部160により、第2及び第3識別子が設定された第3のNDEF RecordがNDEFメッセージ内に付加され、NFC通信にて接続先装置に送信される。さらに、NFC通信パケットを受信した接続先装置は、制御部160により、Enrollerの認証フラグ(第3のNDEF Record)が抽出されて、EnrollerがWPS Passwordに対応するか否かが判定される。
【0124】
ステップS206以降において、図20に示すようなAP−BS間通信によるInfraネットワークが形成される。このケースは、接続先装置がRegistrar機能を有している場合に対応している。
【0125】
ステップS206では、AP/RegistrarとBS/Enrollerとの間において、NFC通信により公開鍵、及び証明書が交換される(S206)。NFC通信で交換された証明書により、通信相手が互いに不正者か否かが判断される。互いに不正者でないと判断されると、交換された公開鍵により暗号化された設定情報がWLAN通信にて交換される(S208)。次いで、交換された設定情報に基づいてAP/RegistrarにBS/Enrollerが登録される(S210)。その後、BS/Enrollerは、NFC通信パケットのNDEFメッセージに含まれるAPのIPアドレス、及び公開ポート番号に基づいてWLANによる通信処理が実現される(S212)。
【0126】
次に、ステップS204において、いずれか一方又は両方の装置がWPS Passwordに対応していないと判断された場合について説明する。ステップS214において、双方がWPS Credentialに対応しているか否かが判定される。双方がWPS Credentialに対応している場合、ステップS216の処理に進行する。一方、いずれか一方又は両方がWPS Credentialに対応していない場合、ステップS220の処理に進行する。
【0127】
ステップS216以降において、BS−BS間でNFC通信が実現され、図21に示すようなRegistrarを経由しないInfraネットワークが形成される場合のセットアップ手順が示される。
【0128】
ステップS216では、Infraネットワークに接続されているBS間でNFC通信により、APの設定情報が交換される(S216)。このとき、APの設定情報は、暗号化されていない平文で送信される。次いで、BS/Enrollerは、NFC通信で取得したAPの設定情報に基づいてWLANの接続認証を要求する(S218)。APとBS/Enrollerとの間で接続が確立されると、BS/Enrollerは、NFC通信で既に取得していたAPのIPアドレス、及び公開ポートに基づいて接続相手先のBSとの間でIPパケットの送受信を行う(S212)。
【0129】
次に、ステップS214において、いずれか一方又は両方の装置がWPS Credentialに対応していないと判断された場合、或いは、ステップS202において自装置がWPSに非対応、又はAPの通信圏内にないと判断された場合について説明する。いずれの場合においても、Infraモードでの接続ができないため、図22に示すようなad−hocモードのネットワーク構成が選択される。
【0130】
ステップS220において、BS/Enrollerがad−hocモードに対応可能か否かが判断される(S220)。BS/Enrollerがad−hocモードに対応可能である場合、ステップS224の処理に進行する。一方、BS/Enrollerがad−hocモードに対応不可能である場合、ネットワークの形成処理が失敗し(S222)、一連の処理が終了する。この処理において、接続先のBSは、NDEFメッセージに基づいてBS/Enrollerがad−hocモードに対応可能な否かを判断する。
【0131】
ステップS224以降において、BS/Enroller、及び接続先のBSがad−hocモードに対応可能であることを前提としてセットアップ手順が示される。
【0132】
ステップS224において、接続先のBSは、ad−hocモードのネットワーク形成に必要な設定情報として、SSID、Network Key等の設定情報をNFC通信によってBS/Enrollerに送信する。このとき、接続先のBSは、NFC通信を介してIPアドレス、公開ポート等のネットワーク設定情報も送信する(S224)。
【0133】
このとき、接続先のBSとAPとの間でInfraモードのネットワークが形成されている場合、このネットワーク接続が切断される。ad−hocネットワークの生成に必要な情報が共有されると、双方のBSが接続され(S226)、NFC通信で取得されたIPアドレスに基づいて互いにIPパケットの送受信が可能な状態になる(S212)。
【0134】
本実施形態に係るNFCパケットの構成を適用すると、上記のような手順により、図20、図21、図22のいずれかの形態を有するネットワークが形成される。次に、図19を参照しながら、上記の手順で形成されたネットワークが切断された後の処理について説明する。図19は、ネットワーク切断後の処理の流れを示す説明図である。
【0135】
図19に示すように、上記の手順でネットワーク接続が確立されると、双方が既に取得しているIPアドレス又は特定のURLを用いて相互に通信することができる(S214)。その後、ネットワークが切断されると(S216)、ステップS218の処理に進行する。ステップS218では、双方が一時接続に対応しているか否かが判断される(S218)。双方が一時接続に対応している場合、ステップS222の処理に進行する。一方、一方又は双方が一時接続に対応していない場合、ステップS220の処理に進行する。
【0136】
既に述べた通り、NDEFメッセージに含まれる第3のNDEF Record中には、認証フラグの1つとして一時接続対応フラグが含まれていた(図17を参照)。上記の判定処理は、この一時接続対応フラグに基づいて実行される。もし、接続元、及び接続先のいずれにおいても、このフラグが無効になっていた場合、互いのネットワーク設定情報が保存され、次回の接続時にも設定情報が有効であるため(S220)、新たな認証処理の必要が無くなる。
【0137】
逆に、双方の機器が一時接続に対応している場合、双方の機器に格納されていたSSID、Network Keyが削除される(S222、S224)。さらに、接続先のMACアドレスが削除されて不許可に設定される(S226)。このように、設定情報が無効にされるため(S228)、次回、再接続する際には、これらの設定パラメータを再度交換する必要がある。このような設定にすると、ネットワーク設定情報が一時的の使い捨て情報となり、ad−hocモードの場合、ネットワークが形成される度にSSID、ネットワークキーが交換されるため、セキュリティ強度が向上する。
【0138】
尚、上記の第1実施形態の場合と同様に、認証時に毎回、GUI経由でユーザの承認を得る工程(図11を参照)が追加されることにより、不正者が関知しない期間にネットワークに接続する機会が低減され、よりセキュリティの向上が図れる。
【0139】
以上、本発明に係る2つの実施形態について説明した。これらのNFC通信を用いたBT及びWLANの簡単セットアップ方式を採用することで、設定情報を平文でNFC伝送するような場合であっても、認証受け入れ期間、及び認証許可アドレスの制限により、盗聴者によるネットワークへの進入可能性が低減される。
【0140】
また、表示デバイスを経由した承認手順を設けることにより、不正者が許可なく認証作業を開始することが防止される。そのため、公開鍵暗号化ロジックを搭載しない製品構成であっても、制御ソフトウェアの変更だけで安全且つ簡単なセットアップが実現される。
【0141】
また、標準化された簡単セットアップ規格(BT Core規格のバージョン2.1、又はWLANのWPS方式)に準拠した製品と、未対応の既存製品が並存する場合であっても、上記の実施形態に例示したNFC通信パケットのフォーマットを利用することで、互いの規格対応状況を交換し、実施の態様に適した方式を選択することができるようになる。その結果、NFC通信を使った認証方式において、これらの異なる認証方式間における互換性を維持することができるようになる。
【0142】
さらに、NFC通信パケットの中に、認証後に形成されるネットワークの構成情報を格納して交換することにより、所定のネットワーク構成の中で、より適したネットワーク内の役割分担、又は接続モードの選択が可能になる。
【0143】
[非接触通信装置の装置構成例]
ここで、図23を参照しながら、上記の装置が有する機能の一部又は全部を実現することが可能な非接触型の通信装置の装置構成例について簡単に説明する。図23は、非接触通信装置の装置構成例を示す説明図である。尚、上記の装置が有する機能は、この非接触通信装置が有する構成要素の一部のみを利用して実現してもよい。また、重複する符号が付された構成要素は、一体のハードウェア資源により構成されていてもよい。
【0144】
図23に示すように、この通信装置は、主に、ICカード部分と、リーダ/ライタ部分と、コントローラ722とにより構成される。
【0145】
(ICカード部分)
ICカード部分は、例えば、アンテナ702と、フロントエンド回路704と、変調器706と、コマンド再生器708と、クロック再生器710と、制御回路712と、暗号化回路714と、メモリ716と、有線インターフェース回路718とで構成される。
【0146】
アンテナ702は、ループ・アンテナにより構成され、リーダ/ライタが有するループ・アンテナと磁気的に結合してコマンドや電力を受け取る。フロントエンド回路704は、リーダ/ライタから送出された搬送波を整流して直流電源を再生する。また、フロントエンド回路704は、取得した13.56MHzの搬送波を分周してコマンド再生器708、及びクロック再生器710に入力する。コマンド再生器708は、入力された搬送波からコマンドを再生して制御回路712に入力する。クロック再生器710は、入力された搬送波からロジック回路を駆動するためのクロックを再生して制御回路712に入力する。また、フロントエンド回路704は、再生した電源を制御回路712(CPU)に供給する。
【0147】
全ての回路に電源が供給されると、制御回路712は、再生されたコマンドに応じて各回路を駆動する。尚、制御回路712から出力されたデータは、暗号化回路714により暗号化されてメモリ716に格納される。尚、メモリ716は、例えば、磁気的、光学的、又は光磁気的に情報を記録する記憶装置であってもよいし、ROMやRAM等に利用される半導体記憶装置であってもよい。
【0148】
一方、メモリ716内に格納された暗号化データを送信する場合、フロントエンド回路704は、変調器706により変調された暗号化データに基づいてアンテナ702の給電点にある負荷インピーダンスを変化させ、その変化によりアンテナ702によって誘起される磁界を変化させる。この磁界変化により、磁気的に結合したリーダ/ライタのアンテナを流れる電流変化が誘起されて暗号化データが伝送される。
【0149】
また、制御回路712は、有線インターフェース回路718を介してコントローラ722により制御されてもよい。また、ICカード部分は、インターフェースI/F(未図示)を介して、後述のリーダ/ライタ部分との間で情報を送受信し、相互に又は一方から他方を制御することが可能であってもよい。
【0150】
(リーダ/ライタ部分)
リーダ/ライタ部分は、例えば、アンテナ702と、フィルタ732と、受信アンプ734と、周波数変換器736と、識別器738と、ロジック回路740と、制御回路712と、メモリ716と、有線インターフェース回路742と、変調器746と、局部発振器750と、送信アンプ748とにより構成される。
【0151】
リーダ/ライタ部分は、非接触ICカード等との磁気的な結合を利用してコマンドや電力を供給する。このリーダ/ライタ部分は、制御部712(CPU)の制御により、非接触ICカード等に電力を供給して活性化させてから、所定の伝送プロトコルに従って通信を開始する。このとき、リーダ/ライタ部分は、通信接続の確立、アンチコリジョン処理、及び認証処理等を行う。
【0152】
リーダ/ライタ部分は、局部発振器750を利用して搬送波を生成する。情報を送信する場合、まず、制御回路712は、メモリ716からデータを読み出してロジック回路740に伝送する。そして、変調器746は、ロジック回路740から出力された信号に基づいて局部発振器750により生成された搬送波を変調する。さらに、送信アンプ748は、変調器746から出力された変調波を増幅し、アンテナ702を介して送信する。
【0153】
一方、情報を受信する場合、まず、アンテナ702を介して受信された変調波は、フィルタ732を通した上で受信アンプ734に入力される。そして、受信アンプ734により増幅された信号は、周波数変換器736により周波数変換されてロジック回路740に入力される。さらに、ロジック回路740から出力された信号は、制御回路712によりメモリ716に記録される。或いは、当該信号は、有線インターフェース回路742を介して外部のコントローラ722に伝送される。
【0154】
以上、非接触通信装置の装置構成例について説明した。当該非接触通信装置は、例えば、携帯電話、携帯情報端末、各種の通信機器、パーソナルコンピュータ等の情報処理装置、或いは、ゲーム機や情報家電等であってもよい。また、上記の非接触通信装置が有する機能又は構成要素の一部又は全部を内蔵した各種の機器についても、上記実施形態の技術的範囲に含まれる。
【0155】
[ハードウェア構成(情報処理装置)]
上記装置が有する各構成要素の機能は、例えば、図24に示すハードウェア構成を有する情報処理装置により、上記の機能を実現するためのコンピュータプログラムを用いて実現することが可能である。図24は、上記装置の各構成要素が有する機能を実現することが可能な情報処理装置のハードウェア構成を示す説明図である。
【0156】
図24に示すように、前記の情報処理装置は、主に、CPU(Central Processing Unit)902と、ROM904と、RAM906と、ホストバス908と、ブリッジ910と、外部バス912と、インターフェース914と、入力部916と、出力部918と、記憶部920と、ドライブ922と、接続ポート924と、通信部926とにより構成される。
【0157】
CPU902は、例えば、演算処理装置又は制御装置として機能し、ROM904、RAM906、記憶部920、又はリムーバブル記録媒体928に記録された各種プログラムに基づいて各構成要素の動作全般又はその一部を制御する。ROM904は、例えば、CPU902に読み込まれるプログラムや演算に用いるデータ等を格納する。RAM906は、例えば、CPU902に読み込まれるプログラムや、そのプログラムを実行する際に適宜変化する各種パラメータ等を一時的又は永続的に格納する。これらの構成要素は、例えば、高速なデータ伝送が可能なホストバス908によって相互に接続されている。また、ホストバス908は、例えば、ブリッジ910を介して比較的データ伝送速度が低速な外部バス912に接続されている。
【0158】
入力部916は、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチ、及びレバー等の操作手段である。また、入力部916は、赤外線やその他の電波を利用して制御信号を送信することが可能なリモートコントロール手段(所謂、リモコン)であってもよい。なお、入力部916は、上記の操作手段を用いて入力された情報を入力信号としてCPU902に伝送するための入力制御回路等により構成されている。
【0159】
出力部918は、例えば、CRT(Cathode Ray Tube)、LCD(Liquid Crystal Display)、PDP(Plasma DisplayPanel)、又はELD(Electro−Luminescence Display)等のディスプレイ装置、スピーカ、ヘッドホン等のオーディオ出力装置、プリンタ、携帯電話、又はファクシミリ等、取得した情報を利用者に対して視覚的又は聴覚的に通知することが可能な装置である。
【0160】
記憶部920は、各種のデータを格納するための装置であり、例えば、ハードディスクドライブ(HDD;Hard Disk Drive)等の磁気記憶デバイス、半導体記憶デバイス、光記憶デバイス、又は光磁気記憶デバイス等により構成される。
【0161】
ドライブ922は、例えば、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリ等のリムーバブル記録媒体928に記録された情報を読み出し、又はリムーバブル記録媒体928に情報を書き込む装置である。リムーバブル記録媒体928は、例えば、DVDメディア、Blu−rayメディア、HD−DVDメディア、コンパクトフラッシュ(登録商標)(CF;CompactFlash)、メモリースティック、又はSDメモリカード(Secure Digital memory card)等である。もちろん、リムーバブル記録媒体928は、例えば、非接触型ICチップを搭載したICカード、又は電子機器等であってもよい。
【0162】
接続ポート924は、例えば、USB(Universal Serial Bus)ポート、IEEE1394ポート、SCSI(Small Computer System Interface)、RS−232Cポート、又は光オーディオ端子等のような外部接続機器930を接続するためのポートである。外部接続機器930は、例えば、プリンタ、携帯音楽プレーヤ、デジタルカメラ、デジタルビデオカメラ、又はICレコーダ等である。
【0163】
通信部926は、ネットワーク932に接続するための通信デバイスであり、例えば、有線又は無線LAN(Local Area Network)、Bluetooth(登録商標)、又はWUSB(Wireless USB)用の通信カード、光通信用のルータ、ADSL(Asymmetric Digital Subscriber Line)用のルータ、又は各種通信用のモデム等である。また、通信部926に接続されるネットワーク932は、有線又は無線により接続されたネットワークにより構成され、例えば、インターネット、家庭内LAN、赤外線通信、可視光通信、放送、又は衛星通信等である。尚、通信部926の機能に上記の非接触通信装置が備える非接触通信機能を含めてもよい。
【0164】
[補遺1:<SSP方式について>]
上記の第1実施形態に係る技術は、以下で説明するSSP方式に対し、好適に適用することが可能である。そこで、SSP方式に係る認証方法について、以下で詳細に説明する。尚、上記の第1実施形態の説明において記載されたパラメータは、その表記が対応するように同じ記号で表現されている。そのため、上記の第1実施形態に係る技術を下記のSSP方式に適用する際には、パラメータ表記の対応関係を意識することで、技術的な対応関係が容易に把握されるであろう。
【0165】
[1:SSP方式の提案モデル]
SSP方式には、4つのモデルが提案されている。これらの4つのモデルは、それぞれ、数字比較モデル、JW(Just Work)モデル、OOBモデル、パスキー入力モデルと呼ばれる。以下、これらの提案モデルについて簡単に説明する。
【0166】
(1−1:数字比較モデル)
数字比較モデルは、次のようなシナリオを想定している。(1)互いに通信するデバイスの両方が6桁の数字を表示できるものとする。(2)これらの両方のデバイスには、”Yes”又は”No”のユーザ入力が可能であるとする。このシナリオには、例えば、セルラーフォンやパーソナルコンピュータが適用される。
【0167】
(ペアリングの確立手順について)
まず、ユーザは、両方のデバイスが備えるディスプレイ上に表示された6桁の数字(”000000”から”999999”まで)を視認する。それから、ユーザは、両方のデバイスに表示された数字が同じであるか否かを尋ねられる。そこで、ユーザは、両方のデバイスに”YES”又は”NO”を入力する。もし、”YES”が両方のデバイスに入力されたならば、ペアリングが成立する。
【0168】
(数字比較モデルの目的)
この数字比較モデルには2つの目的がある。1つ目の目的は、個々のデバイスに固有の名前を持っていない場合に、正しいデバイスがそれぞれ接続されたという承認をユーザに対して与えるということである。2つ目の目的は、中間者攻撃(man−in−the−middle attack)に対する防衛手段を提供することである。
【0169】
尚、Core Specifications 2.0+EDR以前の規格で利用されるPIN入力モデルと、この数字比較モデルとの間には、暗号化技術に係る観点から重大な相違があるという点に注意が必要である。この数字比較モデルで利用される6桁の数字は、人工的なセキュリティアルゴリズムに基づくものであり、現行のセキュリティモデルのようなユーザの手で入力されるものではない。当然の事ながら、表示された数字が知されることにより、両方のデバイス間で交換される暗号データが復号される危険性が高まるため、これを避けるように構成されているのである。
【0170】
(1−2:JWモデル)
JWモデルでは、次のようなシナリオが想定されている。このシナリオでは、少なくとも1つのデバイスが、6桁の数字が表示できるディスプレイを備えていないか、或いは、6桁の数字を入力するためのキーボードを備えていないということが想定されている。このシナリオには、例えば、携帯電話や単体のハンドセットが適用される。現状、大部分のハンドセットはディスプレイを持っていないからである。
【0171】
JWモデルは、数字比較方式を利用する。しかし、ユーザには、数字が表示されることはない。また、アプリケーションは、ユーザに対して単に接続の承認を尋ねるだけである。JWモデルは、受動的な盗聴に対して上記の数字比較モデルと同等の耐性を備えた防御手段を提供する。但し、中間者攻撃に対する防御手段を提供するものではない。
【0172】
一般的なハンドセット等による4桁の数字(固定PIN)を利用したセキュリティモデルと比較するとき、JWモデルのセキュリティレベルは比較的高いと考えられる。その理由は、受動的な盗聴に対する高い耐性が実現されているためである。
【0173】
(1−3:OOBモデル)
OOB(Out Of Band)モデルは、次のようなシナリオを想定している。まず、OOBの技術は、ペアリングの工程で暗号数字を交換する際又は送信する際に、両方のデバイスを発見するために用いられる。但し、このOOBチャネルは、セキュリティに関する効果を期待して、デバイスの発見とは異なる目的でも提供されるべきである。例えば、OOBチャネルは、BTの通信チャネルにおけるセキュリティを高めるために提供されるべきである。OOBチャネルは、中間者攻撃、及びプライバシーの侵害に対する防御手段を提供する。
【0174】
尚、ユーザの操作はOOBの機構に依存して異なるかもしれない。例えば、OOBとして近接場通信(Near Field Communication;NFC)を適用する場合、ユーザは、はじめに2つのデバイスを互いにタッチさせる。それから、ユーザは、他のデバイスとペアリングを構成したいか否かを尋ねられる。そこで、ユーザは、”YES”又は”NO”を入力する。”Yes”が入力されると、ペアリングが形成される。
【0175】
上記の操作は、デバイス間で情報を交換するためのシングルタッチの操作である。この交換される情報には、BDの発見に利用されるBDアドレスのようなデバイス情報と、暗号化に利用されるセキュリティ情報とが含まれる。デバイスの一方は、受信したBDアドレスを他のデバイスとの間の接続を確立するために利用することができる。一方、交換されたセキュリティ情報は、認証処理において利用される。尚、OOBの機構が有する特徴に依存して、1方向、又は双方向の認証処理が実現される。
【0176】
OOB方式は、次のような場合にのみ選択される。例えば、OOBによる情報交換によりペアリングが既に有効化されていた場合や、一方又は両方のデバイスが入出力機能の有無(IO Capability;Input/Output Capability)を応答する際にOOB方式に対応可能であることを通知した場合である。
【0177】
OOB方式では、ユーザに対して単に接続の承認を尋ねるための情報が利用される。尚、OOBモデルには、暗号化に必要な情報、及びBDアドレスを交換可能な機構であれば、任意のOOB機構を適用することができる。また、このOOBモデルでは、ユーザがBT通信を利用して既に接続を有効にした手段をサポートせず、接続に際して認証処理のためにOOBチャネルが利用される。
【0178】
(1−4:パスキー入力モデル)
パスキー入力モデルは、次のようなシナリオを想定している。(1)一方のデバイスは、入力機能を備えており、かつ、6桁の数字を表示する機能を備えていない。(2)そして、他方のデバイスは、出力機能を備えている。このシナリオは、例えば、パーソナルコンピュータとキーボードの組み合わせに適用される。
【0179】
まず、ユーザに対し、一方のデバイスが備えるディスプレイ上に6桁の数字(”000000”から”999999”まで)が表示される。それから、ユーザは、他方のデバイスにより表示された数字を入力するように求められる。表示された数字が他方のデバイスに正しく入力された場合にペアリングが形成される。
【0180】
[2:セキュリティ確立手段]
SSP方式のセキュリティ確立手段は、次のような5つのフェーズにより構成される。
フェーズ1:公開鍵の交換
フェーズ2:認証ステージ1
フェース3:認証ステージ2
フェーズ4:リンクキーの算出
フェーズ5:LMP認証、及び暗号化
【0181】
フェーズ1、3、4、5は、上記の全てのモデルで同じである。但し、フェーズ2(認証ステージ1)に関しては、適用するモデルに依存して若干異なる。尚、以下の説明において、下表1で定義される表現([Term])が用いられる。
【0182】
(2−1:フェーズ1<公開鍵の交換>(図25(A)を参照))
まず、各デバイスがECDH(Elliptic Curve Diffie−Hellman)方式に基づいて自身の公開鍵/秘密鍵のペア(PK,SK)を生成する(ステップ1)。この鍵ペアは、デバイスの組毎に1度だけ生成される。この鍵ペアは、ペアリング処理の開始前に算出されていてもよい。また、任意の時点で、その鍵ペアはデバイスにより放棄され、新たな鍵ペアが生成されることがある。
【0183】
ペアリングは、初期化デバイス(Initiating Device A)により、受信側のデバイス(以下、応答デバイス(Non−initiating Device B))に公開鍵が送信されることで開始される(ステップ1a)。応答デバイスは、初期化デバイスによる公開鍵の送信に応じて、自身の公開鍵を初期化デバイスに送信する(ステップ1b)。双方の公開鍵(PKa,PKb)は、たとえ、デバイスを認証するものであろうとも、秘密のものと見なされない。尚、ステップ1a、1bは、上記の全てのモデルで共通である。
【0184】
(2−2:フェーズ2<認証ステージ1>(図26〜図28を参照))
認証ステージ1は、上記の3つのモデル(数字比較モデル、OOBモデル、パスキー入力モデル)の間で処理が異なる。いずれのモデルを選択するかは、両方のデバイスの入出力機能の有無に基づいて決定される。尚、図25〜図28の中で、文頭に記載された数字はステップを表す。
【0185】
(2−2−1:認証ステージ1(数字比較モデル/図26))
数字比較モデルは、効果的な中間者攻撃に対して一定の耐性を有する防御手段を提供する。1度の中間者攻撃に対し、0.000001程度の確率でしか攻撃が成功しないであろう。もし、ペアリングされている時点で中間者攻撃がないならば、共有されているリンクキーは、計算上、ペアリングされている間の受動的な盗聴に対しても安全である。
【0186】
以下、暗号化の観点から、数字比較モデルにおける認証ステージ1(Authentication Stage 1)のシーケンスダイアグラムについて説明する。
【0187】
公開鍵が交換された後で、各デバイスは、一時的な128ビットの疑似乱数(Na,Nb)を生成する(ステップ2a,2b)。この疑似乱数値は、反復攻撃を避けるために利用される。また、この疑似乱数値は、ペアリングが形成される毎に新規に生成されなければならない。さらに、この疑似乱数値は、物理的な乱数発生源、又は物理的な発生源による乱数値をシードとする良い疑似乱数発生器から直接生成されるべきである。
【0188】
次いで、対向するデバイスは、双方の公開鍵に対応した証明書(Ca,Cb)を算出する。この証明書は、一時的な疑似乱数を用いて生成されているため、それ自体が一時値である(ステップ3c)。この証明書は、その証明書の算出に利用されるパラメータの入力に対して1方向性を有する関数(f1)によって算出される。次いで、この証明書は、初期化デバイスに送信される(ステップ4)。尚、この証明書は、一時期間を経過した後で攻撃者によりパラメータが変更されるのを避けるために利用される。
【0189】
次いで、初期化デバイス、及び応答デバイスは、上記の一時値(疑似乱数値(Na,Nb))を交換する(ステップ5、6)。次いで、初期化デバイスは、その証明書が正しいか否かを確認する(ステップ6a)。ステップ6aにおける確認の失敗は、攻撃者の存在、又は他の送信エラーが存在することを示すものである。もし、失敗したならば、このモデルにおけるペアリングの形成処理は破棄される。尚、これらのステップは、新たな鍵ペアが生成された際に、又は、新たな鍵ペアが生成されていなくても繰り返し実行されることがある。しかし、そうしたステップが繰り返されるならば、新たな一時値が生成されねばならない。
【0190】
さて、証明書のチェックが成功した場合、双方のデバイスは、6桁の数字(認証値(Va,Vb))をそれぞれ算出する。この認証値は、ユーザに提示されるために、各デバイスが備えるディスプレイ上に表示される(ステップ7a、7b、8)。ユーザには、これらの6桁の認証値が一致しているか否か、或いは、一致しているものがあるか否かの確認が期待される。もし、一致しているものがないならば、その認証ステップは破棄される。さらに、その認証ステップが繰り返されるならば、新たな一時値が生成されねばならない。
【0191】
尚、狡猾な中間者によりサービス否認以外の任意の影響が及ばないように、認証プロセスにおいて自身のデバイスに関する鍵の情報が認証の際に利用される。単純な中間者攻撃であれば、0.999999の確率で異なる2組の6桁の表示値に帰着するであろう。より洗練された攻撃であれば、技術者に対し、表示値を一致させるように試みるかもしれないが、上記の認証処理シーケンスにより防ぐことができる。
【0192】
(2−2−2:認証ステージ1<OOBモデル>(図27))
OOBモデルは、LMP入出力機能の可否に関する情報を交換するシーケンスの中で、認証に利用されるセキュリティ情報が少なくとも一方のデバイスによって受信され、その中にOOB認証データ存在パラメータ(OOB Authentication Data Present parameter)が含まれる場合に選択される。
【0193】
両方のデバイスがOOBチャネルを介してデータを送信及び/又は受信できるならば、相互認証は、OOB公開鍵(PKa,PKb)に基づく証明書(Ca,Cb)が認証ステージの中で交換されることにより実現されることになる。
【0194】
1.OOB通信が1方向でのみ可能である場合(例えば、受動的なNFCタグ等で構成されるデバイスを適用する場合、又は一方のデバイスが読み込み専用のものである場合)、OOB通信における受信デバイスの認証は、OOB通信を介して送信された乱数rを知っているデバイスにより実現される。このケースにおいて、乱数rは、秘密でなければならない。また、乱数rが毎回新たに生成されるか、或いは、乱数rを送信するデバイスへのアクセスが制限されていなければならない。もし、乱数rがデバイスに送られなかったならば、ステップ4a、4bの中でOOB情報(A,B,ra,rb,Ca,Cb)を受信したデバイスにより、rが0であると設定される。
【0195】
もし、OOB通信が堅牢なものであるならば(例えば、中間者攻撃を防御可能であるならば)、OOBモデルは、中間者攻撃による影響を受けにくいものであると言える。また、OOBモデルの中で、認証に利用されるパラメータ(Ca、Cb、ra、rb)のサイズは、ユーザが読み易いか、或いは、手入力し易いかということに配慮して制限されることがない。こうした理由により、OOBモデルは、数字比較モデル、又はパスキー入力モデルよりも、よりセキュアにすることができる。しかしながら、両方のデバイスが相互に対応するOOBインターフェースを有することが必要となる。
【0196】
デバイスA、Bの役割:OOBモデルにおいて、デバイスAとデバイスBには、その役割に関して対称性がある。まず、デバイスAがいつもペアリングを開始することは要求されない。例えば、一方のデバイスがNFCタグを備え、OOB情報の送信のみができる場合、OOB通信の中で自動的に非対称性が解決される。
【0197】
しかしながら、ステップ12(図25(B))でリンクキー(LK)が計算される際、双方のデバイス群は、同じオーダー(秩序)のパラメータを入力しなければならない。但し、各デバイスにより異なる鍵が算出される。このオーダーとは、例えば、「デバイスA´のパラメータがピコネットマスターのパラメータであり、デバイスB´のパラメータがピコネットスレーブのパラメータである」といったものである。
【0198】
ステップの順序:公開鍵の交換は、認証処理のステップ(ステップ5)よりも以前に実行されなければならない。ダイアグラムの中で、デバイス間におけるBTバンド内での公開鍵の交換(ステップ1)は、OOB通信(ステップ4)の以前に実行される。しかし、OOBインターフェースによりペアリングを開始しようとすると、公開鍵の交換はOOB通信の後になってしまう(ステップ1がステップ4とステップ5との間になろう)。
【0199】
ra,rbの値:OOB通信が実行される以前には対向するデバイスのOOBインターフェースの方向性が確認できないため、デバイスによりra、rbの値がいつも生成される。そして、可能ならば、OOBインターフェースを通じて対向するデバイスに乱数rが送信される。各デバイスは、自身のrの値、及び対向するデバイスのrの値をローカルで設定するために、次のようなルールを適用する。
【0200】
1.最初、デバイスのrが乱数に設定され、対向するデバイスのrが0に設定される(ステップ2)。
2.デバイスがOOBで情報を受信したならば、対向するデバイスにより送信されたr値を設定する(ステップ5)。
3.デバイスがOOB認証データを受信したと示さなければ、自身のr値を0に設定する(ステップ5)。
【0201】
これらのルールにより、認証ステージ2でOOB通信が行われた際に、入力されたra、rbに関し、両方のデバイスA、Bが同じ値を持つことが確認される。
【0202】
(2−2−2−1:OOB機構の一例であるNFC)
NFC(Near Field Communication;近接場通信)デバイスは、異なるデータレート(106kbps、212kbps、424kbps)にそれぞれ対応するモードや、異なるオペレーション(有効/無効)に対応するモードをサポートしている。
【0203】
さらに、いくつかのNFCデバイスは、初期化(初期化/リーダモード)の機能を有しており、接続(タグ/ターゲットモード)を許可する機能を有している。一方、他のデバイスは、接続を受け付ける能力のみを有している。例えば、OOBーIO NFCデバイスは、他のNFCデバイスに対し、データを送信したり、データを受信したりする機能を有すると共に、BT通信するための機能を有している。
【0204】
OOB機構に適用される場合、NFCデバイスに対して、デバイスA、Bが次の組み合わせとなるような3つのシナリオが想定されている。
(1)デバイスA:OOB−IO NFCデバイス、かつ、デバイスB:OOB−O NFCデバイスである場合、(2)デバイスA:OOB−O NFCデバイス、かつ、デバイスB:OOB−IO NFCデバイスである場合、(3)デバイスA:OOB−IO NFCデバイス、かつ、デバイスB:OOB−IO NFCデバイスである場合である(但し、OOB−O:アウトプットのみ、OOB−IO:インプット/アウトプット対応)。つまり、OOB−O/OOB−O(tag/tag)のケースが存在せず、一方のデバイスがリーダと成り得ることが求められる。
【0205】
(2−2−3:認証ステージ1<パスキー入力モデル>(図28))
パスキー入力モデルに関し、認証ステージ1におけるシーケンスダイアグラムについて説明する。
【0206】
ユーザにより両方のデバイスに個々のパスキーが入力される代わりに、パスキー(ra,rb)が生成され、一方のデバイスに表示される。そして、ユーザは、表示されたパスキーを他方のデバイスに入力する(ステップ2)。この短い共有値(ra,rb)により、デバイス間の相互認証が実現される。ステップ3〜8は、kビットのパスキーに対し、k回繰り返される。例えば、6桁の数字に対するパスキー(999999=0xF423F)は、k=20である。
【0207】
ステップ3〜8において、各デバイスは、長い一時値(128ビット)を用いて、パスキーの各ビットを送る。さらに、一時値のハッシュ、パスキーのビット、及び他方のデバイスの公開鍵を送信する。
【0208】
次いで、各デバイスは、互いの証明書を確認すべく、パスキーが相互に開示されるまで返信する。与えられたパスキーのビットについて証明書を折り返す最初のデバイスは、そのプロセスの中でパスキーのビットを効果的に返信する。しかし、他のデバイスは、与えられたパスキーのビットと同じ値を示すビットの証明書を返信するか、或いは、パスキーのビットが更に返信されなかった場合に、この認証ステップが破棄される。
【0209】
この”漸次的な開示”は、中間者攻撃によりパスキーの情報が推測されないように1ビット以上の漏洩を避けるためのものである。パスキーの部分的な知識のみを有する中間者攻撃者は、この認証ステップが失敗する以前の不確かなパスキーの受信ビットしか推定できないことになる。ゆえに、0.000001の確率で成功する単純なBlute−force攻撃者のような中間者攻撃者に対して、最大で2ビットの分の推測困難性を加えることができる。また、長い一時値には、認証ステップが失敗した後でさえも、brute−force攻撃を困難にさせるための証明書のハッシュが含まれる。
【0210】
標準的な中間者攻撃はECDHを交換する両サイドで攻撃者の公開鍵を置き換えることから、中間者攻撃を避けるために、オリジナルのECDH鍵の交換に際してパスキー入力モデルのセキュリティを厳しくするために公開Diffie−Hellman値が含まれる。このステージの最後において、認証ステージ2で利用されるNaにNa20が設定され、NbにNb20が設定される。
【0211】
(2−3:フェーズ3<認証ステージ2>(図29を参照))
認証ステージ2では両方のデバイスが認証情報の交換を成功裏に完了したことが確かめられる。このステージは、上記の3つのモデルにおいて共通である。
【0212】
まず、各デバイスは、新たに認証値(Ea,Eb)を算出する。この認証値は、既に交換されたパラメータに基づいて算出される。また、この認証値は共有される(ステップ9)。次いで、初期化デバイスにより、対向する応答デバイスに認証値が送信される。次いで、送信された認証値は、応答デバイスにより確認される(ステップ10)。もし、この確認が失敗であれば、初期化デバイスがペアリングを認証しなかったことが示される。その場合、この認証ステップが破棄される。
【0213】
次いで、応答デバイスは、自身が算出した認証値を初期化デバイスに送信する。この認証値は、初期化デバイスにより確認される(ステップ11)。この確認が失敗であれば、応答デバイスがペアリングを認証しなかったことが示される。その場合、この認証ステップが破棄される。
【0214】
(2−4:フェース4:リンクキーの算出(図25(B)を参照))
両方のサイドでペアリングが認証されると、共有鍵(DHKey)等によりリンクキー(LK)が算出され、このリンクキーを用いて公にデータが交換されるようになる(ステップ12)。このとき利用される一時値は、リンクキーの新しさを示す。たとえ、長文のECDH値が両サイドで利用される場合であっても、このリンクキーは、ペアリングを管理するために利用される。
【0215】
リンクキーを算出する際に、両方のデバイスはパラメータを入力する。これらのパラメータは、両方のデバイスが同じリンクキーを算出したことを確かめるために、同じオーダー(順序)で入力される。また、パラメータには、「デバイスA´のパラメータはピコネットマスターのものであり、デバイスB´のパラメータはピコネットスレーブのものである」といったことを示す情報も含まれる。
【0216】
(2−5:フェーズ5:LMP認証、及び暗号化)
シンプルペアリングの最終フェーズは、暗号鍵を生成することである。これは、従来のペアリングの最終ステップと同じように実行される。
【0217】
[3:暗号化に用いる関数群]
(3−1:楕円曲線の定義)
SSP方式は、「FIPS(Federal Information Processing Standards Publication) P−192 curve」の楕円曲線を暗号化に利用している。この楕円曲線Eは、下記の式(1)に示すようにパラメータp、a、bを引数として値が決定されるものである。
【0218】
【数1】
【0219】
但し、パラメータbの値に対して一意に曲線が決定される。「NIST(National Institute of Standards and Technology) P−192」において、パラメータaは下記の式(2)により定義されている。
【0220】
【数2】
【0221】
一方、パラメータbは定義されおり、その生成の方法はSHA−1(シード値sに対し、b2s=−27(mod p)を利用する。)を用いて確かめられる。また、次のようなパラメータが与えられる。
【0222】
主なパラメータは、第1の係数(絶対値)p、オーダーr、基準となるx座標Gx、基準となるy座標Gyである。また、整数p、rは、10進法の形式で与えられる。そして、ビット列、フィールド要素はhex(16進数)の形式で与えられる。これらのパラメータは、例えば、次のような数値(#1〜#5)で与えられる。
【0223】
(#1) p=6277101735386680763835789423207666416083908700390324961279
(#2) r=6277101735386680763835789423176059013767194773182842284081
(#3) b=64210519 e59c80e7 0fa7e9ab 72243049 feb8deec c146b9b1
(#4) Gx=188da80e b03090f6 7cbf20eb 43a18800 f4ff0afd 82ff1012
(#5) Gy=07192b95 ffc8da78 631011ed 6b24cdd5 73f977a1 1e794811
【0224】
関数P192()は次のように定義されている。整数u(0<u<r)、曲線E上の点Vが与えられると、点Vのu倍であるuVをx座標値とする値P192(u,V)が算出される。秘密鍵は、1〜r/2の間になる。ここで、rは、楕円曲線上のアーベル群のオーダーである(例えば、1〜2192/2)。
【0225】
(3−2:暗号化関数の定義)
楕円曲線Diffie−Hellman鍵の算出に加え、数字比較モデル、OOBモデル、パスキー入力モデルの各プロトコルには、4つの暗号化関数が必要とされる。これらの関数は、後述する関数f1,g,f2,f3である。
【0226】
f1は、128ビットの証明書の値Ca、Cbを生成するために利用される。gは、認証値を算出するために利用される。f2は、リンクキー、及び、DHKeyや一時乱数値を用いて導出される他の鍵を算出するために利用される。f3は、認証ステージ2における認証値Ea、Ebを算出するために利用される。これらの関数の基本的な構成はSHAー256に基づいている。
【0227】
(3−2−1:SSP方式における証明書生成関数f1)
証明書は、関数f1により算出される。SSP方式の証明書用関数の定義は、SHA−256に基づくMAC関数(HMAC)を用いている。このHMACは128ビット鍵の場合に、HMAC−SHA−256Xと表記されるものである。SSP方式の関数f1には、次のような形式のパラメータ(U,V,X,Z)が入力される。
【0228】
Uは192ビット値である。Vは192ビット値である。Xは128ビット値である。Zは8ビット値である。
【0229】
Zは、数字比較モデル、及びOOBモデルの各プロトコルにおいて0である(即ち、8ビットの0)。パスキー入力モデルのプロトコルの中で、Zの最も重要なビットは1に設定され、そして、少なくとも重要なビットはパスキーの1ビット目に生成される。例えば、パスキーが”1”である場合、Z=0x81に設定され、パスキーが”0”である場合、Z=0x80に設定される。
【0230】
SSP方式の関数f1の出力は、下記の式(3)のようになる。
【0231】
【数3】
【0232】
関数f1の入力は、下表2に示すようにプロトコルに依存して異なる。
【0233】
ここで、PKaxは、デバイスAの公開鍵PKaに対するx座標値を示す。同様に、PKbxは、デバイスBの公開鍵PKbに対するx座標値を示す。Naiは、i番目の繰り返し処理における一時値を示す。繰り返し処理の各工程において、Naiの値は、あたらな128ビット数となる。同様に、raiは、8ビットに拡張されたパスキーの1ビット値(例えば、0x80、又は0x81)である。
【0234】
(3−2−2:SSP方式における数値認証関数g)
SSP方式の関数gは、次のように定義される。SSP方式の関数gの入力(U,V,X,Y)の形式は次の通りである。
【0235】
Uは192ビット値である。Vは192ビット値である。Xは128ビット値である。Yは128ビット値である。
【0236】
SSP方式の関数gの出力は、下記の式(4)のようになる。
【0237】
【数4】
【0238】
数値認証値は、32ビット整数g(PKax,PKbx,Na,Nb)の中で、6つの少なくとも重要なビットが取り出される。ここで、PKaxはデバイスAの公開鍵PKaに対するx座標値を示し、PKbxはデバイスBの公開鍵PKbに対するx座標値を示す。
【0239】
SHA−256の出力は、SHA−256の出力に対応する少なくとも重要な32ビットを取り出すことによって32ビットに切りつめられる。この値は、10進数形式の数値に変換される。数字比較モデルで利用されるチェックサムは、少なくとも重要な6桁である。比較結果(Compare Value)は、下記の式(5)のようになる。
【0240】
【数5】
【0241】
例えば、出力が0x 01 2e b7 2aであった場合、10進数形式の数値は19838762になる。そして、数字比較のためのチェックサムとして、838762が取り出される。
【0242】
(3−2−3:SSP方式における鍵導出関数f2)
SSP方式の鍵導出関数には、SHA−256に基づくMAC関数(HMAC)が用いられる。このHMACは、192ビット鍵Wに対してHMAC−SHA−256Wと表現される。SSP方式の関数f2に対する入力(W,N1,N2,KeyID,A1,A2)の形式は次のようになる。
【0243】
Wは192ビット値である。N1は128ビット値である。N2は128ビット値である。KeyIDは32ビット値である。A1は48ビット値である。A2は48ビット値である。
【0244】
文字列”btlk”は拡張ASCIIコードにより、次のようにKeyIDに対してマッピングされている。
【0245】
KeyID[0]=0110 1011 (lsb)
KeyID[1]=0110 1100
KeyID[2]=0111 0100
KeyID[3]=0110 0010
KeyID=0x62746c6b
【0246】
SSP方式の関数f2の出力は、下記の式(6)のようになる。
【0247】
【数6】
【0248】
関数f2の出力としては、HMAC−SHA−256の出力の中で、128の最も重要な(最左の)ビットが取り出される。また、リンクキーは、下記の式(7)により算出される。
【0249】
【数7】
【0250】
(3−2−4:SSP方式におけるチェックサム関数f3)
SSP方式のチェックサム関数f3の定義には、SHA−256に基づくMAC関数(HMAC)が用いられる。このHMACは、192ビット鍵Wに対してHMAC−SHA−256Wと表現される。SSP方式の関数f3の入力(W,N1,N2,R,IOcap,A1,A2)の形式は次の通りである。
【0251】
Wは192ビット値である。N1は128ビット値である。N2は128ビット値である。Rは128ビット値である。IOcapは16ビット値である。A1は48ビット値である。A2は48ビット値である。
【0252】
IOcapは、LMP OOB認証データとして最も重要なオクテット(8桁)、及びLMP入出力機能の可否を示す最小の重要度のオクテットで構成されるオクテットの組である。SSP方式の関数f3の出力は、下記の式(8)の通りである。
【0253】
【数8】
【0254】
関数f3の出力には、HMAC−SHA−256の出力の中で128の最も重要な(最左の)ビットが取り出される。認証値は、関数f3により算出される。関数f3の入力は、下表3のように、プロトコル毎に異なる。
【0255】
DHKeyは、デバイスAによりP192(SKa,PKb)として、そして、デバイスBによりP192(SKb,PKa)として、算出された共有された秘密のDiffe−Hellman鍵である。AデータはデバイスAの機能を示すデータであり、BデータはデバイスBの機能を示すデータである。パスキー入力モデルにおいて、データra、rbは6桁のパスキーの値であり、128ビットの整数値により表現される。例えば、raの6桁の値が131313であったならば、R=0x00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 f1となる。入力AはデバイスAのBDアドレスである。入力BはデバイスBのBDアドレスである。
【0256】
【表1】
【0257】
【表2】
【0258】
【表3】
【0259】
[補遺2:<WPS1.0hについて>]
上記の第2実施形態に係る技術は、以下で説明するWPS1.0h方式に対し、好適に適用することが可能である。そこで、WPS1.0h方式に係る認証方法について、以下で詳細に説明する。尚、ここで用いられる用語の意味、及び表現については、後段で示す表5〜表10を参照されたい。
【0260】
[WPS(Wi−Fi Protected Setup)について]
WPSは、Wi−Fi Allianceにより独立に構築された1つの規格である。また、WPSは、Wi−Fi CERTIFIED(WFC)の802.11デバイスをサポートするようにデザインされている。このデバイスの形態としては、コンシューマ向けの電化プロダクトや電話機等が含まれる。これらのWFCデバイスは、コンピュータ(PC)やアクセスポイント(AP)と同等の通信機能を有している。この通信機能は、家庭や小規模オフィス等に設置された802.11デバイスにて利用されているようなものである。
【0261】
これらのデバイスには、802.11b、802.11a、802.11gを用いて通信するマルチバンドデバイスと同様の拡張機能を有しているものもある。こうした拡張機能は、WFCプログラムのオプションとして提供される。このオプションは、802.11n規格のプレ標準プロダクトに関するものである。このプレ標準プロダクトは、2008年に予定している最終的な802.11nの標準プロダクトに認定される予定にものである。尚、Wi−Fi Allianceは、WPSに準拠した最初のプロダクトを2007年の1月に承認している。
【0262】
WPSは、コンシューマに対し、Wi−Fiネットワークの有効化する際に行うセキュリティ設定に関して、購入したWFCデバイスがより簡単に設定されるものであることを確信させるためのものである。また、WPSにより、既に構築されたネットワークに対して新たなWPSデバイスを追加する際にも、従来より遥かに容易に追加設定ができるようになるのである。
【0263】
尚、WPSは、オプション的な認証事項である。つまり、全てのプロダクトにその認証が与えられるわけではない。特に、SOHO市場における利用を想定しており、エンタープライズ環境における使用を目的にしたものではない。こうしたエンタープライズ環境では、分散して設置されたネットワークサーバ群がネットワークアクセスの制御用に設けられていたり、暗号化技術により厳重に情報が管理されていたりする。そこで、コンシューマは、購入するデバイスにWPS−WFCプロダクトの認定マークが存在するか否かを確認すればよい。このWPS認定マークは、プロダクト、パッケージ、ユーザドキュメントに表示されている。
【0264】
WPSは、典型的な家庭用ネットワークに適用される。その中で、デバイスは、アクセスポイント(AP)、又はルータを介して通信する。こうした通信環境では、”アドホック”ネットワークがサポートされていないことが多い。この”アドホック”ネットワークとは、各デバイスがAPから独立して直接的に他のデバイスと通信するネットワークである。
【0265】
典型的な通信環境では、ネットワーク上で、ネットワークネーム(SSID)、及びWPA2セキュリティキーがAP、及びWPSクライアントデバイスに設定される。WPSの標準化されたアプローチによると、典型的なWi−Fiユーザにより簡単にWi−Fiネットワークが設定可能になり、セキュリティが有効化されたネットワークが構築できるようになる。このとき、Wi−Fiユーザは、セキュリティやネットワークに関する基盤の技術、及び、その設定に含まれるプロセスについて理解していなくともよい。即ち、ユーザは、SSIDがネットワークの名前を参照することや、WPA2がセキュリティ機構を参照することを知る必要すらないのである。
【0266】
WPSはWPA2の個人向け技術を利用する。この技術は、レガシーデバイスとの互換性がある。WPA/WPA2 Personalに関してWFCが認定を与えるのである。WPAとWPA2はWi−Fi技術に関するセキュリティに関して最新のものである。ユーザは、レガシーデバイス(即ち、WPA/WPA2 Personalに関するWFCでないデバイス)を利用することが、WLANが弱点を有する状態にあるということを認識しておかなければならない。2003年9月以後に認定された全てのWFCプロダクトは、WPA又はWPA2のいずれかをサポートしている。つまり、2006年3月以降に認定されるプロダクトには、WPA2のサポートが要求されるのである。
【0267】
WPSで認定されたプロダクトでは、ユーザに2つの簡単な設定方法を提供している。個人識別数字(PIN)による設定方法、及びプッシュボタン認証設定(PBC)方法である。もちろん、WPSは、他の方法に対する拡張性も考慮してデザインされている。近接場通信(NFC)カードやUSBフラッシュデバイスを利用した認証方法についても、2007年の後半にテストプログラムに追加されることが予定されている。
【0268】
尚、ユーザは、レガシーデバイスが含まれるWiーFiネットワークにWPSーWFCデバイスを加えるかもしれない。このネットワークは、デバイスの設計者により提供されるマニュアルの手順に従ってユーザが以前に構築したものである。
【0269】
WPSーWFCプロダクトは、APにおいてPINによる認証設定、又はPBC設定の両方が可能なようにテストされてから認定される。クライアントデバイスでは、少なくとも、PINによる認証設定がテストされてから認定される。
【0270】
レジスタラ(Registrar)は、新しいクライアントをネットワークに登録するのに必要な証明書を発行する。このレジスタラは、AP又はクライアント等の様々なデバイスに設定できる。ユーザが様々な環境や場所にデバイスを加えることができるように、仕様書では、1つのネットワーク内に多重のレジスタラが含まれることをサポートしている。但し、レジスタラの機能は、APの管轄内に限定される。
【0271】
PIN設定に関し、PINは、ネットワークに接続しようとする個々のデバイスに対して与えられる。通常、ユーザがPINを認識できるように、デバイス上に固定ラベルやステッカーが設けられている。また、動的なPINが生成される場合、そのPINは、例えば、デバイスに設置されたTVスクリーンやモニターのようなディスプレイに表示される。PINは、他者による事故や悪意の企てによりネットワークに意図しないデバイスが加えられないように、ユーザがネットワークに加えようと考えるデバイスであるか否かを確かめるために利用される。
【0272】
まず、ユーザはPINをレジスタラに入力する。例えば、PINは、APのGUIを介して入力されるか、或いは、ネットワーク上の他のデバイスに設けられたオンスクリーンインターフェースを介して管理ページにアクセスすることにより入力される。
【0273】
PBC設定に関し、ユーザは、デバイスをネットワークに接続し、APとクライアントデバイスのボタンを押下することによりデータの暗号化を有効にする。このとき、ユーザは、APとクライアントのボタンを押下する間に、意図しないデバイスがとても簡単にネットワークに接続することが可能な期間があることを意識しておく必要がある。
【0274】
(設定ステップの比較)
表4は、PINによる認証設定とPBCによる認証設定との間の操作ステップの比較を示した図表である。また、参考までに、WPS以前の方法によるWLAN上の設定、及びセキュリティの有効化に要求されるステップも併せて掲載している。これによると、WPS以前の方法は多数のステップを有する。
【0275】
WPS以前の方法において、ユーザは、デバイスを電源に接続し、有線ネットワークに接続した上でAPを有効化する(ステップ1)。次いで、ユーザは、有線ネットワークに接続されたコンピュータからウェブブラウザを立ち上げ、管理ページにログインしてAPにアクセスする(ステップ2)。次いで、ユーザは、ネットワークネーム(SSID)を選択し、それをAPに入力する(ステップ3)。
【0276】
次いで、ユーザは、セキュリティ設定ページに導かれれる。そこで、ユーザは、利用するセキュリティタイプを選択し、セキュリティ設定を有効にする(ステップ4)。セキュリティ設定が有効化された後で、ユーザは、APがセキュリティキーを生成するために利用されるパスフレーズの入力を促される。そこで、ユーザは、パスフレーズをAPに設定し、セキュリティキーを設定する。(ステップ5)。ユーザは、コントロールパネルを用いてネットワークに登録されるクライアントデバイスを設定する。このとき、ユーザは、デバイスの無線インターフェースを有効化し、WLAN接続を有効化する(ステップ6)。
【0277】
次いで、クライアントデバイスは、ユーザに対し、周囲に発見される全てのWLANのネットワークネーム(SSID)を提示する。そこで、ユーザは、(ステップ3で選択した)適切なネットワークネームを選択し、ネットワークに接続する(ステップ7)。次いで、ユーザは、ステップ5で設定したパスフレーズを入力するように促される。そこで、ユーザは、クライアントデバイスにパスフレーズを入力する(ステップ8)。その後、クライアント、及びAPは、セキュリティ証明書を交換し、新たなデバイスがセキュアにWLANに接続される。
【0278】
多くの場合、WPSを適用することにより、上記のステップ2〜5の手順が省略される。加えて、ユーザに要求されるいくつかの作業(例えば、パスフレーズの設定等)が簡単化される。
【0279】
WPSにおいて、ユーザは、単にAPとクライアントデバイスを有効化する。そして、APの生成手段により提供されたPINを入力するか(PINによる認証設定の場合)、或いは、セキュリティの設定を開始するために、APとクライアントデバイスのボタンを押下する(PBCによる認証設定の場合)。このとき、ユーザには、パスフレーズの設定が要求されない。つまり、セキュリティコードが自動的に有効化されて通信されるのである。
【0280】
SSIDとWPA2セキュリティキーが適切に設定されるのを保証するのに加え、WPSは、空間に伝播する情報セキュリティを確保するための技術を提供する。つまり、WPSは、ネットワークにアクセスするために不正なPINを入力するユーザを排除する。また、WPSには、認証に用いる証明書を一時的な証明書にすることで、その時点で転送されたものでないときに設定プロセスをキャンセルするタイムアウト機能も提供する。
【0281】
また、WPSでは、ユーザが生成したパスフレーズを消去することにより、セキュリティを向上させる。WPS以前、ユーザは、AP上でパスフレーズを生成し、入力することを要求されていた。彼らは、任意の新たなデバイスをネットワークに追加する際に、ネットワークをセキュアにするためのパスフレーズを再利用していた。さらに、そのパスフレーズの多くは、短く、子供やペットの名前のような覚えやすく、外部の人に容易に推測されるような分かり易いパスフレーズであった。
【0282】
(WPSのオプション)
WPSのオプションとして、NFCやUSBを利用した認証方法がある。これらの方法は、PBCによる認証方法やPINによる方法のようにユーザの手入力を要求せずにデバイスをネットワークに参加させるものである。
【0283】
WPSのNFCによる設定方法を適用すると、新たなデバイスをAP又はレジスタラ機能を有する他のデバイスにタッチすることで簡単にセキュアなネットワークが有効化される。WPSのUSBによる設定方法では、証明書をUSBフラッシュドライブ(UFD)を介して転送する。これらの方法は、意図しないデバイスがネットワークに加入することに対して強固な防御効果を与える。
【0284】
しかしながら、USBによる方法やNFCによる方法は、2007年の第1四半期後半でWFSに対するWFCプログラムに予定されている。他の方法についても、後日、認定プログラムに加えられるかもしれない。WPSは、こうした方法についても、他の技術に対する拡張性を考慮してデザインされている。
【0285】
(WPSの機能について)
詳細な設定手段とWPSデバイスのセキュリティとは、従来のホームセキュリティに関する馴染み深い比喩”lock and key”に対比される。WPSの仕様は、新たなデバイスが探索プロトコルに基づいて構築されたWi−Fiネットワークに加入される際に、シンプルで矛盾しない手順を提供している。また、このプロトコルは、ベンダー間で整合している。
【0286】
この手順では、ネットワークに登録されるデバイスの証明書を自動的に発行するためにレジスタラが利用される。WPSーWFCデバイスのAPにはレジスタラ機能が搭載されている。さらに、レジスタラは、WLAN上の任意のデバイスに駐在することができる。AP上に駐在するレジスタラは、内部のレジスタラとして参照される。ネットワーク上の他のデバイスに駐在するレジスタラは、外部のレジスタラとして参照される。WPSネットワークでは、1つのWLAN上における多重のレジスタラがサポートされている。
【0287】
ユーザがWLAN上に新たなデバイスを追加設定するプロセスは、鍵を錠に挿入する工程と対比される次のようなアクションによって開始される。このプロセスでは、設定ウィザードが起動され、PINが入力されるか、又はPBCボタンが押下される。この時点で、アクセスが検出される。
【0288】
WPSデバイスは、レジスタラとの間で情報の交換を開始する。次いで、レジスタラは、ネットワーク証明書を発行する。ネットワーク証明書は、クライアントがWLANに加入するのを認証するためのネットワークネーム、及びセキュリティキーを含むものである。錠と鍵の比喩において、このネットワーク証明書の交換は、アクセスが受け入れられるように錠の中でキーを回す動作に似ている。その後、新たなデバイスは、ネットワークを介し、侵入者による非認証アクセスに対してセキュアにデータを通信することができる。
【0289】
新たにWPS−WFCデバイスは、有効なAPの範囲内に入ったときに存在が検出される。その後、WPS−WFCデバイスは、レジスタラに通信し、ユーザに証明書の発行を認証する行為を促す。
【0290】
WPSネットワークでは、各デバイスを認証する際にデータが暗号化される。つまり、情報とネットワーク証明書は、拡張認証プロトコル(EAP)を利用して空間内でセキュアに交換される。認証プロトコルにはWPA2が使われる。デバイスにより相互に認証が実行され、クライアントがネットワーク上で許容された場合に接続が行われる。レジスタラは、セキュリティを有効にするためにネットワークネーム(SSID)、及びWPA2の”Pre−Shared Key(PSK)”を通知する。ランダムなPSKの使用は、予測可能なパスフレーズの使用を避けることでセキュリティが向上する。
【0291】
WPS以前の設定方法では、ユーザに対し、APがPSKをサポートするように手動で設定すること、及び、SSIDとPSKを手動で入力することが要求されていた。SSIDやPSKの入力は、APとクライアントの両方で行われる。このアプローチは、ユーザによるエラーの原因の大部分を占めていた。ユーザエラーとしては、ミスタイピング、及びPSKとSSIDの混同である。ところが、WPSを用いた場合、証明書の交換プロセスは、初期の設定処理が完了した後において、ユーザによる僅かな介在を要求するのみである。例えば、PINの入力、又はPBCボタンの押下だけである。このとき、ネットワークネームとPSKは自動的に発行されているのである。
【0292】
次に、証明書の交換、及びデバイスの追加に関するダイアグラムを示す。つまり、WPSデバイスにより、どのようにしてネットワークが設定されるかについて説明する。
【0293】
(証明書の交換について)
WPSでは、レジスタラデバイスがネットワーク上の他のデバイスに対して識別情報を発行するように促し、さらに、証明書を発行する。このとき、各種の情報は、Wi−Fiネットワークを介して交換される。1つのシナリオとして、レジスタラがAPに設定される。証明書の交換は、クライアント、及びAPに設けられたボタンを押下することで行われてもよい(PBC方式)。また、クライアントデバイスを用いたPINの入力により行われてもよい(PIN方式)。例えば、PIN入力は、PIN方式用のGUIにユーザがPINを入力する形式で行われる。
【0294】
(デバイスの追加について)
新たなクライアントが既に存在するネットワークに加えられるものとする。このとき、PIN又はプッシュボタンにより設定されてもよい。例えば、既に存在するネットワークに新たなAPデバイスが加えられる場合にも、PIN又はプッシュボタンによる設定が可能である。PIN方式、及びPCB方式のいずれの方法が利用されるかは、どちらの設定方法がクライアントデバイスによりサポートされるかに依存して選択される。
【0295】
(WPSにおける設定オプション)
PBC方式やPIN方式の設定オプションは、WPSーWFCプロダクトに対して適用される。つまり、NFCやUSBによる設定方法は、オプションであり、Wi−Fi Allianceによりテスト及び認定されているものではない。しかしながら、製造者は、オプション的にこれらを提供することができる。NFCやUSBによる設定方法は、2007年のWPSに対するWFAの認定テストプログラムに含まれることが予定されている。
【0296】
(NFC設定の場合)
NFC設定は、タッチベースの相互作用を利用する。NFC設定では、AP又は他のレジスタラデバイスとクライアントとの間でNFCを利用してネットワーク証明書の交換を有効にする。証明書の交換は、NFCが有効なクライアントデバイスをAP(又は他のNFCが有効なレジスタラデバイス)上のNFCターゲットマークにタッチした時点で開始されるか、或いは、クライアントをその近接領域内に持っていくことで開始される。その距離は、およそ10cmである。
【0297】
レジスタラは、クライアント識別用の証明書をNFCを介して読み出す。NFCデバイスは、デバイスに埋め込まれている。そして、新たなデバイスをネットワークに接続するために、ネットワークSSIDとPSKセキュリティコードをクライアントに返信する。
【0298】
(USB設定の場合)
USB設定において、USBフラッシュドライブをレジスタラデバイス(この場合、AP)に接続することによって証明書が交換される。この証明書は、フラッシュドライブ上にコピーされる。一方、そのフラッシュドライブは、新たなデバイスに挿入されて証明書の交換が完了する。
【0299】
(WPSのまとめ)
WPSにより、ユーザに設定アプローチの統一的な枠組みが提供される。この枠組みには、PIN入力やプッシュボタンのシーケンスが含まれる。このシーケンスは、新たなWFCデバイスの設定をより容易にし、家庭又は小規模オフィスの環境においてWFCネットワークのセキュリティを簡単に有効にすることができる。
【0300】
WPSは、WFCデバイスに対するユーザのアウトオブボックス操作を改善するようにデザインされており、ベンダーの技術サポートに対する依存性を低減し、小売店によるプロダクト回収の数を低減すると共に、ユーザの技術に対する満足度を増大させるものである。特に、WPSは、ユーザにPSKやSSIDのようなコンセプトを理解させるような要求を排除し、誤入力が避けられないPSKの手入力プロセスを排除することで、ネットワーク設定をより容易にする。
【0301】
WPSは、802.11a,b,gのWFCデバイスがサポートする2.4GHzや5GHz周波数帯の両方をサポートできるように拡張可能にデザインされている。認定自体はオプション的な位置付けであるが、家庭又は小規模オフィスに存在するマルチバンド、マルチモードをサポートするデバイスに適用されるであろう。また、このオプションは、2007年の802.11nのプレスタンダードプロダクトに対するWFCプログラムへの適用が予定されている。また、2008年に予定されている最終的な802.11n標準で認定されるプロダクトに対しても同様である。
【0302】
【表4】
【0303】
【表5】
【0304】
【表6】
【0305】
【表7】
【0306】
【表8】
【0307】
【表9】
【0308】
【表10】
【0309】
以上、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明は係る例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
【0310】
上記の実施形態の説明においては、第1通信方式としてNFC通信を想定していたが、必ずしもこれに限定されるものではなく、例えば、赤外線通信、或いは、USBメモリによる設定情報の交換等も含まれる。
【0311】
上記の実施形態の説明においては、主に、PCや携帯電話を例に挙げて説明したが、上記の実施形態を適用できる範囲は、これに限定されない。例えば、テレビジョン等の映像機器、カーナビゲーション装置、オーディオ装置、決済端末、プリンタ等の電子機器、或いは、各種の情報家電等にも適用可能である。また、ICタグ等を備えることが可能なデバイス等に対しても適用される。このように、上記の実施形態に係る技術は、多種多様な電子機器に適用することが可能である。
【図面の簡単な説明】
【0312】
【図1】本発明の一実施形態に係る通信システムの構成例を示す説明図である。
【図2】本発明の第1実施形態に係る通信装置の機能構成を示す説明図である。
【図3】同実施形態に係る認証処理方法の流れを示す説明図である。
【図4】本発明の一実施形態に係るレコードの構成例を示す説明図である。
【図5】本発明の一実施形態に係るレコードの構成例を示す説明図である。
【図6】本発明の第1実施形態に係るレコードの構成例を示す説明図である。
【図7】同実施形態に係る認証処理方法の流れを示す説明図である。
【図8】同実施形態に係る認証処理方法の流れを示す説明図である。
【図9】同実施形態に係る認証処理方法の一例を示す説明図である。
【図10】同実施形態に係る認証処理方法の一例を示す説明図である。
【図11】同実施形態に係る認証処理方法の一例を示す説明図である。
【図12】同実施形態に係るネットワーク形成方法の一例を示す説明図である。
【図13】同実施形態に係るネットワーク形成方法の一例を示す説明図である。
【図14】同実施形態に係るネットワーク形成方法の一例を示す説明図である。
【図15】同実施形態に係るネットワーク形成方法の一例を示す説明図である。
【図16】本発明の第2実施形態に係る通信装置の機能構成を示す説明図である。
【図17】同実施形態に係るレコードの構成例を示す説明図である。
【図18】同実施形態に係る認証処理方法の流れを示す説明図である。
【図19】同実施形態に係る認証処理方法の流れを示す説明図である。
【図20】同実施形態に係るネットワーク形成方法の一例を示す説明図である。
【図21】同実施形態に係るネットワーク形成方法の一例を示す説明図である。
【図22】同実施形態に係るネットワーク形成方法の一例を示す説明図である。
【図23】本発明の一実施形態に係る通信装置の装置構成例を示す説明図である。
【図24】本発明の一実施形態に係る通信装置の装置構成例を示す説明図である。
【図25】BTデバイスにおける認証処理方法の流れを示す説明図である。
【図26】BTデバイスにおける認証処理方法の流れを示す説明図である。
【図27】BTデバイスにおける認証処理方法の流れを示す説明図である。
【図28】BTデバイスにおける認証処理方法の流れを示す説明図である。
【図29】BTデバイスにおける認証処理方法の流れを示す説明図である。
【符号の説明】
【0313】
10 通信システム
100、200 通信装置
102、106 アンテナ
104 近接通信部
108、158 近距離通信部
110、160 制御部
112 RAM
114 ROM
116 フラッシュメモリ
118 入力部
120 表示部
【技術分野】
【0001】
本発明は、通信装置、及び通信方法に関する。
【背景技術】
【0002】
近年、多くの電子機器が無線通信機能を有するようになってきており、それに応じて、様々な無線通信規格が制定されている。個人向け無線技術の代表例として、例えば、無線LAN(以下、WLAN)やBluetooth(登録商標)(以下、BT)が挙げられる。これらの無線技術は、パーソナルコンピュータ(以下PC)、携帯電話、電子手帳(以下、PDA)等の多機能電化製品を中心に様々な機器に搭載されている。最近では、デジタルカメラやプリンタ等の小型組み込み機器においても、こうした無線技術が利用されるようになってきている。以下、無線技術を搭載した機器のことを無線デバイスと呼ぶ。
【0003】
これらの無線デバイスが広く普及し、多くの場面で使用されることでユーザの利便性が向上する一方で、ネットワークを介して無線デバイスへ侵入される被害や、クレジットカード情報やパスワード等の個人情報が流出する被害等が報告されている。こうした被害が社会問題化しており、無線デバイスにおけるセキュリティの強化が強く望まれている。
【0004】
BTの場合、現状、最大16バイトの鍵情報(パスキー)を用いた認証技術が採用されており、さらに、伝送路の暗号化技術がセキュリティ機能に盛り込まれている。ところが、実際、4文字程度のパスキーが使われている場合が多い。このような運用方法では、パスワードの組み合わせ数が少ないため、不正に認証されてしまう危険性が高い。一方、WLANの場合、当初WEPと呼ばれる暗号化方式が実装されていた。しかし、この暗号方式が比較的短時間で解読できることが公表され、その後、改善策としてWEP−TKIP方式、WPA、WPA2等の強固な暗号化技術が規格に盛り込まれることになった。
【0005】
セキュリティ機能について多数の方式が提供される一方で、こうした技術に関する専門知識がない一般のユーザにとっては、接続機器に応じた適切な暗号化方式を選択したり、選択した方式に応じた適切な設定をすること自体が非常に大きな負担である。多くの場合、ユーザは、メーカーの技術サポート窓口に相談するか、或いは、無線デバイスの設定自体を諦めてしまう。その結果、セキュリティが十分に機能していない無線デバイスが利用されていたり、無線デバイスが家電製品等に普及しにくい土壌が作られている。
【0006】
上記のような現状に鑑み、セキュリティの強化に関する技術、及びネットワーク設定を簡単化する技術の研究開発が鋭意進められている。こうした技術に関し、例えば、下記の特許文献1には、WLANのセットアップ方式に関する技術が開示されている。同文献には、電波強度を弱めて電波到達範囲を絞り込むことで、アクセスポイントとWLAN端末間の通信範囲を狭め、セキュリティを向上させる技術が開示されている。さらに、同文献には、アクセスポイント及びWLAN端末上に設けられたボタンが同時に押下されることで、ネットワークのセットアップが完了できる接続手段が開示されている。また、BTに関して、下記の特許文献2には、接続機器の双方に設けられたボタンを押下するだけで接続設定が完了する方法に関する技術が開示されている。これらの技術を用いることで、セキュリティの高いネットワーク設定が簡単操作で実現される。
【0007】
【特許文献1】特開2004−215232号公報
【特許文献2】特許第3928489号公報
【発明の開示】
【発明が解決しようとする課題】
【0008】
上記の各文献に加え、各種の無線技術に関する規格団体は、セットアップ手順の簡単化とセキュリティの強化とを両立させるための規格を発表している。BTの規格団体であるBluetooth SIGは、Core規格のバージョン2.1において、Secured Simple Pairing(以下、SSP)と呼ばれる技術を必須実装項目として挙げている。さらに、WLANの認証団体であるWiFi Allianceは、WiFi Protected Setup(以下、WPS)と呼ばれる技術を発表している。
【0009】
これらの規格は、設定情報を暗号化して送受信する際に公開鍵暗号技術を利用する方式を採用している。そのため、従来よりもセキュリティを強化できると共に、ユーザによるセットアップ作業の負担を低減させることができる。この方式は、公開鍵によって暗号化された伝送路上で設定情報が安全に交換されるように設計されている。そのため、これら規格に対応した製品が早急に市場に普及することが期待されている。
【0010】
しかしながら、公開鍵方式の演算ロジックは、秘密鍵方式の演算ロジックと比較して計算量が多く、専用に設計されたハードウェアロジック回路が必要とされる。そのため、公開鍵方式を採用した機器における回路規模の増大、及びコストアップが懸念されている。2006年の時点で、従来規格の製品出荷台数は5億1500万台と言われ、非常に巨大な市場が既に形成されている。つまり、廉価な製品の提供が可能な大量供給体制が整備されてしまっている。そのため、安全性、及び利便性の面で優れている上記のような新規格に対応したデバイスが登場しても、旧規格のデバイス生産が継続され、新旧両規格の製品が市場に並存することが予想される。
【0011】
こうした状況において、新規格による簡単でセキュアなネットワーク設定が可能な無線デバイスをユーザが保持していても、その接続先機器が旧規格にしか対応していないことで、ユーザは、従来の煩雑で低セキュリティのネットワーク設定を行う必要に迫られてしまう。また、ユーザには、新規格のデバイスと旧規格のデバイスとで異なる設定方法を使い分けることが要求される。そのため、却ってネットワークの設定方法が煩雑になり、ユーザの負担を増大させてしまうのである。
【0012】
そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、公開鍵方式を利用する認証方式、及び非公開鍵方式による認証方式に対応し、いずれの認証方式のデバイスに接続される場合でも、ユーザに掛かる設定の負担を低減させることが可能な、新規かつ改良された通信装置、及び通信方法を提供することにある。
【課題を解決するための手段】
【0013】
上記課題を解決するために、本発明のある観点によれば、通信可能距離が互いに異なる第1及び第2の通信部により通信する次のような通信装置が提供される。当該通信装置は、比較的通信可能距離が短い第1の通信部を介して、接続毎に生成される乱数と、当該乱数により算出される証明書と、前記第2の通信部の認証方式を示す認証方式情報と、が含まれる通信パケットを受信する受信部と、前記通信パケットに含まれる認証方式情報に基づいて当該通信パケットの送信元が対応する認証方式を判別する方式判別部とを備え、前記方式判別部による判別結果に応じて前記通信パケットに含まれる乱数を前記第2の通信部の認証処理に用いる識別情報として利用するものである。
【0014】
また、前記認証方式情報は、前記第2の通信部の認証方式が公開鍵方式に対応するか否かを示す情報であってもよく、前記方式判別部は、前記通信パケットに含まれる認証方式情報に基づいて当該通信パケットの送信元が公開鍵方式に対応するか否かを判別するように構成されていてもよい。この場合、上記の通信装置は、前記方式判別部により前記通信パケットの送信元が公開鍵方式に非対応であると判別された場合に、自装置の識別情報として前記通信パケットに含まれる情報を返信するように構成される。
【0015】
上記の通信装置は、受信部により、比較的通信可能距離が短い第1の通信部を介して、接続毎に生成される乱数と、当該乱数により算出される証明書と、第2の通信部の認証方式が公開鍵方式に対応するか否かを示す認証方式情報と、が含まれる通信パケットを受信する。そのため、証明書、及び乱数を用いて当該通信パケットに含まれる情報の送信元が正当であることを確かめることができる。このとき、乱数が接続毎に生成されているため、証明書の有効期限が接続毎に設定される。その結果、通信パケットに含まれる情報を他人が傍受し、後ほど利用しようとした際に、その不正行為を検知できる。
【0016】
また、上記の通信装置は、方式判別部により、通信パケットに含まれる認証方式情報に基づいて当該通信パケットの送信元が公開鍵方式に対応するか否かを判別する。さらに、方式判別部により通信パケットの送信元が公開鍵方式に非対応であると判別された場合に、自装置の識別情報として通信パケットに含まれる情報を返信する。通信パケットの送信元が公開鍵方式に対応していれば、公開鍵方式に基づいてセキュアに認証情報を送ることができる。しかし、公開鍵方式に非対応の場合は、セキュリティを確保できない。そのため、上記の通信装置は、接続毎に生成される乱数(一時値)を用いることでセキュリティを確保している。このような構成を適用することで、通信相手が公開鍵方式に対応するか、非対応かに関わらず、セキュリティを確保しながら接続設定をすることができるようになる。
【0017】
また、前記通信パケットには、前記送信元を識別するための識別情報と、当該識別情報に有効期限が設定されているか否かを示す期限情報がさらに含まれていてもよい。その場合、上記の通信装置は、前記期限情報が有効期限の設定有りを示す場合に、前記有効期限が経過した後で、前記通信パケットに含まれる設定情報に基づいて生成された情報を全て破棄するように構成されていてもよい。このような構成にすることで、識別情報、及びそれから派生的に生成された全ての情報に有効期限が設定され、よりセキュリティを向上させることができる。
【0018】
また、上記の通信装置は、所定の確認情報が表示される表示部と、前記確認情報に対する承認を示す情報を入力するための入力部と、をさらに備えていてもよい。この場合において、前記通信パケットに含まれる識別情報を有効にするか否かの承認要求が前記表示部に表示され、前記入力部により承認を示す情報が入力された場合に、当該識別情報が有効化されるように構成することができる。その結果、ユーザによる承認工程を踏む分だけ、セキュリティを向上させることができる。
【0019】
また、前記通信パケットに含まれる情報を返信するか否かの承認要求が前記表示部に表示され、前記入力部により承認を示す情報が入力された場合に、当該識別情報に基づいて前記第2の通信部による通信が開始されるように構成することもできる。この場合にも、ユーザによる承認工程を踏む分だけ、セキュリティを向上させることができる。
【0020】
また、前記通信パケットには、前記受信パケットの送信元を特定するためのアドレス情報がさらに含まれている。そのため、前記第2の通信部は、前記アドレス情報で特定される前記受信パケットの送信元との間のみで通信するように構成することができる。このように、通信相手を制限することで、セキュリティを向上させることができる。
【0021】
また、前記通信パケットには、前記第2の通信方式により形成可能なネットワーク構成を示す構成情報が含まれる場合がある。その場合、所定の属性の中から、前記構成情報に基づいてネットワーク内における自装置の属性が決定されるように構成することができる。その結果、ネットワーク構成をユーザが意識することなく、専門知識のない一般ユーザであっても、容易にネットワーク設定できるようになる。
【0022】
また、上記課題を解決するために、本発明の別の観点によれば、通信可能距離が互いに異なる第1及び第2の通信部を有する通信装置による次のような通信方法が提供される。当該通信方法は、比較的通信可能距離が短い第1の通信部を介して、接続毎に生成される乱数と、当該乱数により算出される証明書と、前記第2の通信部の認証方式を示す認証方式情報と、が含まれる通信パケットが受信される受信ステップと、前記通信パケットに含まれる認証方式情報に基づいて当該通信パケットの送信元が対応する認証方式が判別される方式判別ステップと、前記方式判別ステップにおける判別結果に応じて前記通信パケットに含まれる乱数を識別情報として利用することで前記第2の通信部の認証処理がされる認証ステップとを含むものである。
【0023】
また、通信可能距離が互いに異なる第1及び第2の通信部を有する通信装置による次のような通信方法が提供されてもよい。この通信方法は、比較的通信可能距離が短い第1の通信部を介して、接続毎に生成される乱数と、当該乱数により算出される証明書と、前記第2の通信部の認証方式が公開鍵方式に対応するか否かを示す認証方式情報と、が含まれる通信パケットが受信される受信ステップと、前記通信パケットに含まれる認証方式情報に基づいて当該通信パケットの送信元が公開鍵暗号に対応するか否かが判別される方式判別ステップと、前記方式判別ステップで前記通信パケットの送信元が公開鍵方式に非対応であると判別された場合に、自装置の識別情報として前記通信パケットに含まれる乱数が返信される識別情報返信ステップとを含むことを特徴とする。
【0024】
上記の通信方法では、受信ステップにより、比較的通信可能距離が短い第1の通信部を介して、接続毎に生成される乱数と、当該乱数により算出される証明書と、前記第2の通信部の認証方式が公開鍵方式に対応するか否かを示す認証方式情報と、が含まれる通信パケットが受信される。そのため、証明書、及び乱数を用いて当該通信パケットに含まれる情報の送信元が正当であることを確かめることができる。このとき、乱数が接続毎に生成されているため、証明書の有効期限が接続毎に設定される。その結果、通信パケットに含まれる情報を他人が傍受し、後ほど利用しようとした際に、その不正行為を検知できる。
【0025】
また、上記の通信方法では、方式判別ステップにより、通信パケットに含まれる認証方式情報に基づいて当該通信パケットの送信元が公開鍵方式に対応するか否かが判別される。さらに、方式判別ステップにより通信パケットの送信元が公開鍵方式に非対応であると判別された場合に、自装置の識別情報として通信パケットに含まれる乱数が返信される。通信パケットの送信元が公開鍵方式に対応していれば、公開鍵方式に基づいてセキュアに認証情報を送ることができる。しかし、公開鍵方式に非対応の場合は、セキュリティを確保できない。そのため、上記の通信方法では、接続毎に生成される乱数(一時値)を用いることでセキュリティを確保している。このような構成を適用することで、通信相手が公開鍵方式に対応するか、非対応かに関わらず、セキュリティを確保しながら接続設定をすることができるようになる。
【発明の効果】
【0026】
以上説明したように本発明によれば、公開鍵方式を利用する認証方式、及び非公開鍵方式による認証方式に対応し、いずれの認証方式のデバイスに接続される場合でも、ユーザに掛かる設定の負担を低減させることができる。
【発明を実施するための最良の形態】
【0027】
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【0028】
<第1実施形態>
まず、本発明の第1実施形態について説明する。本実施形態は、本発明に係る技術をBT認証方式(補遺1を参照)に適用するケースを一例として示したものである。
【0029】
以下、次に示す順番で説明する。まず、本実施形態に係る通信方法が適用可能な通信システム10のシステム構成例について説明する。次いで、NFCデバイスを用いてBT認証方式を実現することが可能な通信装置100、200の機能構成について説明する。次いで、SSP方式の1つであるOut Of Band(OOB)方式について説明する。次いで、NFC通信パケットのパケット構成について説明する。次いで、非公開鍵方式に相当するBT認証方式(Core規格のバージョン2.0以前の認証方式)、及びOOB方式の手順について説明する。その中で、本実施形態に係る認証方式の選択手段について説明する。その他にも、本実施形態に係る一時パスキー方式、BTデバイス(以下、BD)のアドレス(以下、BDアドレス)に基づく通信対象の制限方式、及びユーザインターフェースによる認証方式等について説明する。
【0030】
(課題の整理)
既に述べた通り、新旧の規格が混在する状況では、新規格が簡単且つセキュアな設定方式に対応していても、ユーザに対し、旧規格の煩雑で低セキュリティの設定手順を要求してしまうことがある。新規格のBDでは、NFCを利用して簡単且つセキュアな設定方式を実現する。一方、旧規格のBDは、NFCの伝送フォーマットに互換性が無いばかりか、そもそも、NFCデバイスを認証に利用するように設計されていない。そのため、新旧規格のデバイスが混在した状況にある場合、ユーザは、新規格に対応するデバイスを保持していても、NFCを使った認証を断念し、従来の煩雑な手順を踏んでセットアップを行なう必要が生じてしまう。
【0031】
そこで、本実施形態は、NFCデバイスを用いたBT認証方式における次のような認証設定機能の提供を目指している。つまり、当該認証設定機能は、公開鍵ロジックが含まれる認証方式(例えば、OOB方式)と、公開鍵ロジックが含まれない認証方式(例えば、Core2.0以前の方式)とが並存する状況においても、互換性を保持しながら、簡単且つ高いセキュリティ強度を実現することができるものである。
【0032】
[通信システム10のシステム構成例]
まず、図1を参照しながら、本実施形態に係る通信システム10のシステム構成の一例について説明する。図1は、本実施形態に係る通信システム10のシステム構成例を示す説明図である。
【0033】
図1に示すように、通信システム10は、2つの通信装置100、200により構成されている。これらの通信装置100、200は、2種類の通信方式で通信できるように構成されている。その1つの通信方式(第1通信方式)は、近接通信方式(以下、NFC方式)である。NFC方式は、10cm程度の非常に短い距離間で通信するための通信方式であり、所謂、非接触通信と呼ばれる通信方式である。一方、他の通信方式(第2通信方式)は、第1通信方式よりも長い距離間で通信可能な通信方式である。また、第2通信方式は、第1通信方式に比べて帯域幅が広く、比較的高速な通信が可能な通信方式である。本実施形態の場合、第2通信方式にはBTが適用される。
【0034】
上記のようなシステム構成において、通信装置100、200間では、まず、第1通信方式により、第2通信方式による通信用の設定情報が交換され、認証処理が実行される。認証処理が完了すると、通信装置100、200間でペアリングが成立し、サービス毎の接続認証無しに、第2通信方式でサービスが提供されるようになる。旧規格の場合、この相互認証に際し、個々の装置を識別するためのパスキー(PINコード)をユーザが通信装置100、200に手入力していた。また、パスキーには、1〜16桁までの英数字が利用可能であるが、現状、ユーザが管理しやすいように4桁程度の短いものが用いられることが多い。そのため、パスキーが推測され易く、セキュリティの低下を招いていた。
【0035】
そこで、本実施形態では、第1通信方式の通信手段を利用してパスキー等の認証情報を相互に交換する認証方式を採用し、セキュリティの向上を図っている。このとき、通信装置100、200のいずれかが、認証情報を第1通信方式で交換する認証方式に対応していないと、この認証方式によるセキュアな認証設定が実現されない。そのため、本実施形態は、こうした互換性の問題に対しても解決手段を提供する。
【0036】
[通信装置100、200の機能構成]
次に、図2を参照しながら、本実施形態に係る通信装置100、200の機能構成について説明する。図2は、本実施形態に係る通信装置100、200の機能構成を示す説明図である。
【0037】
図2に示すように、通信装置100、200は、主に、アンテナ102、106と、近接通信部104と、近距離通信部108と、制御部110と、RAM(Random Access Memory)112と、ROM(Read Only Memory)114と、フラッシュメモリ116と、入力部118と、表示部120とにより構成される。尚、アンテナ102、近接通信部104は、図23に示すハードウェア資源のうち、ICカード、又はリーダ/ライタを構成する要素の一部又は全部により実現される。アンテナ106、近距離通信部108は、図24に示すハードウェア資源のうち、例えば、通信部926により実現される。制御部110の機能は、例えば、制御回路712、コントローラ722、又はCPU902により実現される。
【0038】
(近接通信部104)
近接通信部104は、アンテナ102に接続されており、第1通信方式(NFC方式)に従ってデータを送受信することができる。近接通信部104は、例えば、13.56MHz帯の周波数を利用し、10cm程度の非常に短い距離間において最大424Kビット/秒の通信レートで通信することができる。尚、近接通信部104の通信距離、通信速度、及び利用周波数帯域は、上記の例に限定されず、任意に設定され得る。
【0039】
(近距離通信部108)
近距離通信部108は、近接通信部104よりも長い距離間で通信することが可能な通信手段である。また、近距離通信部108は、アンテナ106に接続されており、近接通信部104よりも広い帯域幅を利用し、高速にデータを送受信することができる。さらに、近距離通信部108は、第2通信方式としてBTに対応し、例えば、2.4GHz帯の通信帯域を利用して最大3Mビット/秒の通信速度で通信することができる。尚、通信帯域、及び通信速度は、BT規格のCore2.0+EDRで規定されたもの以外にも、これ以降のバージョンや他の規格が適用されてもよく、実施の態様に応じて適宜変更可能である。
【0040】
(制御部110)
制御部110は、通信装置100、200の各構成要素の動作を制御する手段である。また、制御部110は、主に、鍵ペア生成機能と、共有鍵算出機能と、乱数生成機能と、証明書算出機能と、設定情報付加機能と、設定情報抽出機能と、認証値算出機能と、リンクキー算出機能と、認証レコード付加機能と、認証レコード抽出機能と、認証方式判定機能と、パスキー設定機能と、表示制御機能と、通信制御機能とを有する。
【0041】
鍵ペア生成機能は、ペアを成す公開鍵(PKa,PKb)と秘密鍵(SKa,SKb)を生成する機能である。鍵ペア生成機能は、例えば、Diffie−Hellmanにより公表された鍵生成アルゴリズムに基づいて公開鍵/秘密鍵のペアを生成する機能である。尚、秘密鍵(SKa,SKb)は、RAM112、又はフラッシュメモリ116に格納される。共有鍵算出機能は、取得した公開鍵(PKa,PKb)と自装置の公開鍵(PKb,PKa)とを利用して共有鍵(DHKey)を算出する機能である。
【0042】
乱数生成機能は、物理的な乱数生成器から乱数を取得するか、或いは、所定の乱数生成アルゴリズムを利用して疑似乱数を生成する機能である。所定の乱数生成アルゴリズムとしては、例えば、線形合同法やメルセンヌ・ツイスター法等、種々の方法が利用可能である。但し、その性質上、より良いアルゴリズムが用いられることが好ましい。以下、乱数発生器による乱数であるか、疑似乱数であるかを表現上区別せず、単に乱数と呼ぶ。
【0043】
証明書算出機能は、乱数生成機能により生成された乱数(ra,rb,Na,Nb)等に基づき、所定のハッシュ関数を利用して証明書(Ca,Cb)を算出する機能である。設定情報付加機能は、近接通信部104により送信される通信パケットに設定情報を付加する機能である。設定情報には、例えば、自装置のBDアドレス、乱数(ra,rb)、及び証明書(Ca,Cb)等が含まれる。尚、証明書(Ca、Cb)は、図27に示すロジック(f1)により生成されてもよい。
【0044】
設定情報抽出機能は、近接通信部104により受信された通信パケットに付加された設定情報を抽出する機能である。認証値算出機能は、リンクキーを算出する前段で相互認証するための認証値(Ea,Eb)を乱数(Na、Nb)、及び所定の関数(f2)を用いて算出する機能である。リンクキー算出機能は、共有鍵(DHKey)等に基づいてリンクキー(LK)を算出する機能である。
【0045】
認証レコード付加機能は、後述するNDEFメッセージに認証フラグを示すNDEF Recordを付加する機能である。この認証フラグには、認証方式のRecordであることを示す識別子と、認証方式を示す識別子と、BTネットワークの構成を示す識別子とが含まれる。これらの識別子については、後段において詳述する。認証レコード抽出機能は、後述するNDEFメッセージに付加された認証フラグを示すNDEF Recordを抽出する機能である。
【0046】
認証方式判定機能は、認証レコード抽出機能により抽出されたNDEF Recordの認証フラグを参照し、NDEFメッセージの送信元装置が対応する認証方式を判定する機能である。また、認証方式判定機能は、送信元装置が対応する認証方式と、自装置が対応する認証方式とを比較し、より適した認証方式を選択する機能を含む。
【0047】
パスキー設定機能は、認証方式判定機能により、後述する一時パスキー方式が選択された場合に、証明書の発行に用いられる乱数をパスキーに設定する機能である。さらに、パスキー設定機能は、パスキーの有効期限を管理し、有効期限が経過した後で、フラッシュメモリ116等に格納されたパスキー及び設定情報を消去する機能を含む。また、パスキー設定機能は、パスキーの有効/無効を管理する機能を含む。
【0048】
表示制御機能は、例えば、表示部120に対し、パスキー等の設定情報をNFC通信で送信するか否かの許諾をユーザに求める表示をさせたり、NFC通信により受信したパスキーを有効にするか否かをユーザに確認する表示をさせる機能である。通信制御機能は、NFC通信により受信したBDアドレスが示す接続先のみにBTによる通信相手を制限するように近距離通信部108を制御する機能である。
【0049】
(その他)
RAM112は、例えば、制御部110による演算処理の際に、スタック領域、又はヒープ領域として利用される。ROM114には、例えば、制御部110の機能を実現するためのプログラムの実行バイナリコードが格納されている。但し、制御部110の機能を実現するためのプログラムのバイナリコードは、フラッシュメモリ116に格納されていてもよい。
【0050】
[OOB方式による認証方法]
次に、図3を参照しながら、OOB方式に係る認証方法について説明する。図3は、OOB方式に係る認証処理の流れを示す説明図である。上記の通り、OOB方式はSSP認証方式の一例である。この流れの中で、通信装置100、200は、ユーザにより近接された状態で近接通信部104によりNFC通信を実行し、その後、近距離通信部108によりBTによる認証処理を実行する。
【0051】
まず、通信装置100、200が十分に近接され、NFC通信による通信可能範囲まで近づくと、近接通信部104を介して設定情報(BDアドレス、証明書等)が交換される(S102)。次いで、設定情報に含まれるBDアドレスに基づいて相互に公開鍵(PKa,PKb)が交換される(S104)。このとき、制御部110により、取得した公開鍵(PKb,PKa)、及び自装置の秘密鍵(SKa,SKb)に基づいて共有鍵(DHKey)が生成される(S104)。
【0052】
次いで、通信装置100、200は、それぞれ、受信した設定情報に含まれる乱数(ra,rb)、及び証明書(Ca,Cb)等を利用して第1の認証処理(図26の認証処理に相当)を実行する(S106)。但し、図26における第1の認証処理の場合、証明書の発行に公開鍵を利用しているため、NFC通信の開始以前に公開鍵が交換されていることが前提となるが、本実施形態は、このような方式にも適用可能である。
【0053】
第1の認証処理が成功裏に完了すると、通信装置100、200の制御部110により、それぞれ、乱数(Na,Nb)が生成され、近距離通信部108を介して交換される。また、制御部110により、共有鍵(DHKey)、取得した乱数(Na,Nb,ra,rb)、及びBDアドレス等が利用され、所定の認証関数(f3)に基づいて認証値(Ea,Eb)が算出される。そして、これらの認証値(Ea,Eb)が互いに交換され、通信装置100、200において、それぞれ第2の認証処理(図28の認証処理に相当)が実行される(S106)。次いで、通信装置100、200の制御部110により、それぞれ、リンクキー(LK)が算出される(S108)(図25を参照)。
【0054】
以上、OOB方式による認証方法について簡単に説明した。上記のように、NFC通信による設定情報の交換、及び公開鍵暗号による伝送路の暗号化が施されることで、中間者攻撃のような認証情報の盗聴等に対して高い耐性が実現される。
【0055】
[NFC通信パケットの構成例]
次に、図4を参照しながら、NFC通信に利用される通信パケットの構成例について説明する。図4は、NFC通信に利用される通信パケットの構成例を示す説明図である。
【0056】
上記のようなNFC通信は、NFC Forumで規定されたNFC Data Exchange Format(以下、NDEF)に則って行なわれる。NFC通信におけるパケットは、図4に示すようなNDEF Recordと呼ばれる単位で構成される。NDEF Recordは、大きく分けてRecord Type部分D5、Record ID部分D6、Payload部分D7により構成される。
【0057】
また、NDEF Recordの先頭部分D1には、そのRecordがメッセージの最初のレコードであるか否かを示す識別子MBと、そのRecordがメッセージの最後のレコードであるか否かを示す識別子MEが含まれる。さらに、この先頭部分D1には、Payload部分D7のデータ長が1バイト長であるか、4バイト長であるかを示す識別子SR(A1)が含まれる。さらに、この先頭部分D1には、Record ID部分D6の有無を示す識別子IL(A2)、及びRecord Type部分D5のフォーマットを指定する識別子TNF(A3)が含まれる。また、NDEF Recordのヘッダ部分D2、D3、D4には、それぞれ、Record Type部分D5、Record ID部分D6、Payload部分D7のデータ長が格納される。
【0058】
Record Type部分D5は、Payload部分D7に格納されるデータの識別子として利用される。そのため、Record Type部分D5は、Payload部分D7に格納されたデータのフォーマットが特定される際に参照される。例えば、Record Type部分D5により、Payload部分D7の構造、及び意味が決定される(A4)。また、Record ID部分D6は、Payloadを同定するためのURI(Uniform Resource Identifier)が格納される(A5)。尚、Record Typeの定義は、NFCForumが規定する場合と、ユーザが独自に定義する場合とがある。
【0059】
さらに、図5を参照する。図5は、NDEFメッセージの構成例を示す説明図である。NDEFメッセージは、図4に示すNDEF Recordが集まって構成される。尚、NDEF Recordの先頭部分D1に含まれる識別子MB=1のレコードから、識別子ME=1のレコードまでが1つのNDEFメッセージを構成する。
【0060】
[NDEFメッセージの構成例]
次に、図6を参照しながら、OOB認証方式に適用可能な本実施形態に係るNDEFメッセージの構成例について説明する。図6は、OOB認証方式に適用可能な本実施形態に係るNDEFメッセージの構成例を示す説明図である。
【0061】
図6に示すように、NDEFメッセージは、例えば、3つのNDEF Recordにより構成される。第1のNDEF Record(Record1)には、このNDEFメッセージがハンドオーバー用であることを示すハンドオーバー用Record Typeが格納されている。尚、ハンドオーバーとは、第1通信方式であるNFC通信から、第2通信方式(セカンドキャリア)に通信方式を切り替える行為を意味している。第2のNDEF Record(Record2)には、例えば、Record TypeがBTであることを示す“bluetooth.org.sp”が格納されいる。さらに、そのペイロードには、BTの設定情報として、自装置のBDアドレス、乱数、ハッシュ値等が格納される。
【0062】
さらに、本実施形態に係るNDEFメッセージには、第3のNDEF Record(Record3)が付加される。この第3のNDEF Recordには、認証方式を示すRecordであることを識別するための第1識別子と、認証方式を示す第2識別子と、BTネットワーク構成を示す第3識別子とが含まれる。本実施形態において、第2識別子は、自装置がOOB方式の認証処理(Core 2.1)に対応するか否かを示すフラグ(a)と、後述する一時パスキー方式による認証処理(Core 2.0以前)に対応するか否かを示すフラグ(b)とにより構成される。第3識別子は、BT通信で形成されるネットワーク上において、自装置の役割がMasterになれるか否かを示すフラグ(a)、Slaveになれるか否かを示すフラグ(b)により構成されている。これらのフラグは、認証方式を決定するための判断に利用される。
【0063】
[NDEFメッセージを用いた認証方法]
次に、図7を参照しながら、本実施形態に係るNDEFメッセージを用いた認証方法の流れについて説明する。図7は、本実施形態に係るNDEFメッセージを用いた認証方法の流れを示す説明図である。
【0064】
図7に示すように、まず、通信装置100、200は、NFC通信により設定情報を交換する。例えば、NFC通信によりBDアドレスが交換される(S102)。このとき、NFC通信パケットには、BDアドレス、乱数、証明書等のSSP規定情報の他に、制御部110により付加された認証フラグ(第3のNDEF Record)が含まれる。NFC通信パケットが受信されると、制御部110により、第3のNDEF Recordが抽出され、NFC通信パケットの送信元装置が対応する認証方式が判定される(S132)。さらに、制御部110により、その送信元装置の認証方式と、自装置が対応する認証方式とを比較し、より適した認証方式が選択される。
【0065】
例えば、制御部110により、通信装置100、200が共にCore 2.1の認証方式(OOB方式)に対応していると判定された場合、OOB方式に則った認証方法が選択される。その場合、公開鍵の交換、証明書等による認証処理、及びリンクキーの生成処理が実行される。一方、通信装置100、200のいずれかがCore 2.1の認証方式に対応しておらず、且つ、いずれの装置も一時パスキー方式に対応している場合、一時パスキー方式による認証方法(Core 2.0以前の認証方式)が選択される。このとき、制御部110は、証明書の発行に用いるための16バイトの乱数列をパスキーに設定する(S134、S135)。このパスキーが交換され(S138)、これを用いて初期化キー、リンクキーが生成される(S140、S142)。
【0066】
ここで、図8を参照しながら、本実施形態に係るNDEFメッセージを用いた認証方法の流れについて簡単に整理する。図8は、本実施形態に係るNDEFメッセージを用いた認証方法の流れを示す説明図である。
【0067】
図8に示すように、まず、NFC通信によりNDEFメッセージが伝送される(S102)。次いで、NDEFメッセージに含まれる認証フラグが抽出され、その認証フラグに基づいて認証方法が選択される(S132)。認証方法がOOB方式であると判断された場合、ステップS104の処理に進行し、公開鍵の交換(S104)、認証処理(S106)、リンクキーの生成(S108)が順次実行される。一方、認証方法がOOB方式以外の方式であると判断された場合、ステップS134、S136の処理に進行し、証明書に用いる乱数に基づいてパスキーが生成され、ステップS140、S142の処理に進行する。ステップS140、S142では、初期化キー、リンクキーが順次生成される。
【0068】
このように、本実施形態に係るNDEFメッセージの構成が適用されることで、認証方式の選択処理が可能になり、さらに、証明書に用いる乱数に基づいてパスキーが生成されるため、そのパスキーを利用してOOB方式以外の認証方式にも適応できるようになる。元々、OOB方式を採用していないCore 2.0以前の認証方式では、BDアドレスが検索(S12)された後で、ユーザにパスキーの手入力(S14)が求められ、入力されたパスキーに基づいて初期化キー、リンクキーの生成が行われていた。本実施形態に係る認証方法を適用すると、OOB方式に対応していないデバイスに対しても、このようなパスキーの手入力を避けることができるため、セキュリティの向上に寄与する。
【0069】
[認証処理の流れと機能ブロックとの関係]
次に、図9を参照しながら、本実施形態に係る認証処理と、通信装置100、200が備える機能ブロックとの対応関係について説明する。図9は、本実施形態に係る認証処理と、通信装置100、200が備える機能ブロックとの対応関係を示す説明図である。
【0070】
BT Core規格のバージョン2.0以前のBT接続処理では、BDの「探索」処理が実行され、接続可能な通信機器の一覧が取得される。次いで、取得された通信機器の一覧の中から、ユーザにより所望の接続先が指定される。その後、パスキーがROM114、フラッシュメモリ116、又はキーボード等の入力部118から取得されることにより、接続相手の機器と同じパスキーが共有される。
【0071】
次いで、BT通信により、乱数やハッシュ値を通信相手との間で相互に交換し合うことにより、初期化キー、リンクキーが生成されて認証処理が完了する。但し、一度接続が確立された通信相手先については、BDアドレス、リンクキーをセットにしてフラッシュメモリ116内のセキュリティデータベース(以下、DB)内に保存しておき、次回接続時に、DBから読み出したリンクキーを用いて接続処理が行われる。
【0072】
本実施形態に係る技術は、こうしたBT Core規格のバージョン2.0以前の接続処理に対し、次のようにして互換性を確保している。
【0073】
まず、NFC通信により接続相手先のBDアドレス、及び16バイトの乱数が取得される(S202)。次いで、制御部110によりNFCパケットが分析され、認証方式が一時パスキー方式であると判断された場合に、16バイトの乱数をパスキーに置き換える。次いで、BTデバイス(近距離通信部108)に対して接続依頼が行われる(S206)。次いで、BDアドレスとリンクキーのセットが格納されているDB(フラッシュメモリ116)が参照され、接続先(取得したBDアドレスの対象装置)のリンクキーが既に存在するか否かが確認される(S208)。
【0074】
次いで、DB内に接続先のリンクキーが存在している場合、そのリンクキーを利用して接続される(S210、S212(YES))。一方、DB内に接続先のリンクキーが存在しない場合、制御部110に対してパスキーが要求される(S210、S212(NO))。接続先との間で相互に乱数、ハッシュ値等の交換が行われた後で、初期化キーが生成され(S214)、最終的にリンクキーが生成される。
【0075】
[一時パスキー方式の詳細]
次に、図10、及び図11を参照しながら、本実施形態に係る一時パスキー方式の詳細について説明する。図10には、通信装置200により生成されるパスキーの更新処理が示されている。一方、図11には、GUIによる認証許可方式が示されている。
【0076】
(有効期限付きパスキー設定について)
まず、図10を参照する。上記の通り、パスキーに設定される16バイトのデータ列は、平文のまま伝送されるため、NFC通信を受信可能な他の機器により盗聴される可能性がある。しかしながら、図10に示すように、パスキーに設定される乱数は、接続の度に新たに生成される(S134)。そのため、接続毎に異なるパスキーが生成される(S142)。こうした理由から、本実施形態に係る一時パスキー方式は、そのままでも比較的セキュリティが高いと言える。
【0077】
しかしながら、よりセキュリティを高めるためには、パスキーに有効期限を設定するのが好ましい。そこで、本実施形態では、パスキーに有効期限を設定し、そのパスキーを一時的な使い捨てキーとして取り扱う方法を採用する。このとき、パスキーの有効期間が失効するタイミングとして、次の3通りを考える。(1)認証が成功し、接続先と接続元の双方においてリンクキーが生成された時点、(2)NFC通信後、何らかの理由で認証が失敗したと判断された時点、(3)NFC通信後、認証開始から所定期間が経過した時点がパスキー失効のタイミングに設定される。
【0078】
この場合、上記(1)〜(3)のいずれかの条件が検出された場合に、制御部110は、NFCメッセージにより交換されたパスキーをフラッシュメモリ116から削除する。このように、パスキーに有効期限を設けることで、NFC通信の際に何者かによってパスキーが盗聴されたとしても、上記(1)〜(3)のいずれかの条件が成立した後で、このパスキーが無効化されるため、盗聴されたパスキーにより認証される確率が格段に低減される。
【0079】
(GUIによる認証許可について)
次に、図11を参照する。上記のように、パスキーに有効期限を設定することで、セキュリティを高めることができるが、本実施形態では、ユーザのGUI操作による認証許可を求めることで、更なるセキュリティの向上を図る方法を提案する。尚、図11では、通信装置100が通信装置200に認証許可を求めるケースが示されている。
【0080】
図11に示すように、認証を開始しようとする通信装置100の表示部120には、パスキーの送信確認を促す画面が表示される。例えば、表示部120には、「Touch」等の認証開始を促す画面が表示される。入力部118(例えば、表示部120上のタッチパネル)を介してユーザの通信許可が得られると、NFC通信によりパスキーが通信装置200に伝送される。
【0081】
一方、接続先の通信装置200には、表示部120に次処理の許可/不許可を指定するユーザインターフェースが表示される。例えば、この表示部120には、「Accept」等の認証受け入れ許可の確認表示がされる。このとき、通信装置200は、ユーザによる許可が得られるまで、受信したパスキーを有効化せず、ユーザによる許可入力が行われた場合にパスキーを有効化する。
【0082】
この方式を採用すると、両者のユーザがGUI経由で認証を許可した時点から、パスキーの有効期間が経過するまでの間だけが、BTによる通信可能な認証期間となる。その結果、ユーザが関知していない期間において、不正な侵入者により認証処理が進められないことになる。その結果、よりセキュリティを向上させることができる。
【0083】
さらに、パスキーの有効期間内において、NFC通信パケットから取得したBDアドレスが示す接続相手に対してのみ通信を許可する設定とすることで、更なるセキュリティの向上が見込める。この方式を採用すると、平文で伝送されるパスキーを盗聴したデバイスが認証を試みた場合に、BTにおける認証用の通信がブロックされ、認証処理を進めることができなくなる。その結果、更にセキュリティを向上させることが可能になる。
【0084】
[BTネットワークの構成例]
次に、図12を参照しながら、本実施形態に係るBTネットワークの構成例について説明する。図12は、本実施形態に係るBTネットワークの構成例を示す説明図である。
【0085】
BTの仕様によると、BTネットワークを形成する上で、通信装置100、200は、master、又はslaveのどちらかの役割が割り当てられる。さらに、masterとslaveとの間のみで通信が許されており、master同士、又はslave同士の接続は許されていない。このような制約内で、ピコネット、及びスキャタネットと呼ばれるネットワーク形態が実現される。
【0086】
ピコネットとは、1つのmasterが中心となり、最大8台のslaveがmasterに接続されるネットワークのことを言う。一方、スキャタネットとは、時分割でmasterとslaveとを切り替えることが可能なmaster/slaveに対し、slaveと別のmasterとが接続されることで、複数のピコネットが接続される形態のことを言う。このとき、master/slaveは、ある特定の時間帯でピコネット上のmasterとして振る舞い、他の時間帯で他のピコネットのslaveとして動作している。そのため、同時に複数のmasterがピコネット内に存在することがない。
【0087】
既に述べた通り、本実施形態に係るNDEFメッセージの第3のNDEF Recordには、BTネットワーク構成情報が含まれる。この部分には、その装置がmasterに対応可能か否か、及びslaveに対応可能か否かが示されている。そのため、このBTネットワーク構成情報が交換されることにより、適切なネットワークが形成される。
【0088】
(具体例)
例えば、何のネットワークにも所属していない接続元デバイスがmasterとなり、既にピコネットを形成している接続先デバイスに接続する場合について考える。
【0089】
1つのケース(Case.1)として、接続先デバイスがmaster可、slave不可であり、接続元デバイスがmaster/slave可の場合が考えられる。尚、NDEFメッセージの交換により、両者が役割の可否を認識しているものとする。この場合、接続先デバイスの役割がmasterで固定されているため、接続元デバイスがslaveになる。その結果、新しいネットワークは、接続先デバイスをmasterとし、接続元デバイスを含む複数のデバイスがslaveである単一のピコネットが形成される。
【0090】
一方、接続元デバイスがmaster可、slave不可であり、接続先デバイスがmaster/slave可のケース(Case.2)も考えられる。この場合、接続元デバイスの役割がmasterで固定されているため、接続先デバイスがslaveになる。その結果、接続先デバイスは、新しく生成されたネットワークのslaveとなり、同時に、既存のピコネットのmasterとなるため、スキャタネットが形成される。
【0091】
以上、本発明の第1実施形態について説明した。本実施形態に係る技術を適用することにより、BT Core規格のバージョン2.1、及びそれ以前の規格に準じて設計されたデバイスに対しても、ユーザがネットワークの設定を簡単に実現することが可能になる。また、ユーザがパスキー等の認証情報を手入力する必要が無いため、セキュリティの向上が見込める。さらに、パスキーに有効期限を設定したり、GUIによるユーザ認証を組み合わせることで、さらにセキュリティを向上させることができる。また、NFC通信パケットにネットワーク構成用の役割情報が含まれ、その役割情報が交換されることで、適切なネットワーク構成が容易に設定されるようになる。
【0092】
<第2実施形態>
次に、本発明の第2実施形態について説明する。本実施形態は、本発明に係る技術をWLAN認証方式に適用するケースを一例として示したものである。上記の第1実施形態ではBTの場合を例に挙げて説明したが、本実施形態ではWLANの場合を例に挙げて説明する。
【0093】
BT Core規格のバージョン2.1に含まれるOOB方式の認証方法と、WPSに含まれるOOB方式の認証方法とは、技術的な側面において、公開鍵方式による設定情報の安全なパケット交換が共通点として挙げられる。一方、ユーザビリティの観点においては、「NFCデバイスを近づけるだけで認証が終了する」という利便性が共通点として挙げられる。一方で、両規格における大きな相違点としては、ネットワーク構成の形態が異なることが挙げられる。そこで、本実施形態では、WLANのネットワーク構成に適用するための仕組みについて、重点的に説明する。
【0094】
[WLANにおけるネットワーク形態]
まず、図13を参照しながら、WLANのネットワーク形態について説明する。図13は、WLANのネットワーク形態の一例を示す説明図である。
【0095】
WLANにおけるネットワーク形態には、インフラストラクチャモード(以下、Infraモード)と、アドホック(Ad−hoc)モードとがある。多くの場合、1つのアクセスポイント(以下、AP)に複数のベースステーション(以下、BS)が接続されるInfraモードが多く使われる。Infraモードの場合、APは、有線又は無線で構築されたローカルエリアネットワークに属している。また、APは、各種のローカルサーバに接続される。
【0096】
さらに、ローカルエリアネットワークは、ゲートウェイを経由して、インターネット等の広域ネットワークに接続される。AP、BS、及び各種のサーバを含む各接続機器には、個々にIPアドレスが割り振られている。そのため、通信プロトコルであるTCP/IPに基づいてIPアドレスが割り振られた任意の接続機器に対してパケットの送受信ができる。こうした仕組みにより、Webサーバによる大規模なWebサービスの提供やメールサーバによるメール配信サービス等が実現されている。
【0097】
さて、WiFi Allianceは、WLANに関し、簡単且つセキュリティ強度の高い認証仕様を規定している。この規定は、WPSと呼ばれる。WPSのversion1.0h(以下、WPS1.0h)では、上記のInfraモードが想定されている。さらに、WPS1.0hでは、その他にも、いくつかの認証方式が規定されている。本実施形態では、その中の1つであるNFC通信を利用したOOB方式に着目する。
【0098】
WPS1.0hによると、認証処理に関係する機器(AP又はBS)の役割としては、認証情報の制御や管理を行うRegistrar、及び新規にネットワークへの接続を要求するEnrollerが規定されている。但し、APは接続先になる。以下の説明においては、図13に示すように、APがRegistrarの役割を果たす場合を想定して説明する。もちろん、本実施形態に係る技術は、これに限定されない。
【0099】
以下、図13の構成を例に挙げて認証処理の流れについて簡単に説明する。まず、Enrollerの役割を有するBS(以下、BS/Enroller)は、Registrar機能を有するAP(以下、AP/Registrar)に接続要求を送信する。このとき、ユーザは、BS/EnrollerとAP/Registrarとを十分に近づけ、NFC通信により必要な設定情報を交換させる。設定情報が交換されると、BS/EnrollerとAP/Registrarとは接続される。その結果、BS/Enrollerは、Infraモードで形成されたネットワークの1構成単位となる。尚、NFC通信による設定情報の交換は、WPS1.0hに準拠した方式で実現可能である。
【0100】
[NFC通信の形態]
次に、図14を参照しながら、本実施形態に適用可能なNFC通信の形態について説明する。図14は、本実施形態に適用可能なNFC通信の一形態を示す説明図である。
【0101】
本実施形態では、NFC通信をトリガーとしてWLAN通信経路が接続される形態を想定している。NFC通信パケットには、NFCの通信規格で規定された設定情報以外にも、例えば、「接続後にどのような通信処理が実行されるか」といった他の設定情報が格納できる。そのため、NFC通信パケットに格納された設定情報には種々の使い道が考えられる。例えば、NFC通信をトリガーとする接続の後で、インターネット上に存在するWebサーバにアクセスさせるような使い方が考えられる。
【0102】
このように、NFC通信パケットには多種多様な用途が想定されるが、本実施形態では、ユーザによりNFC通信が可能な距離まで2つのNFCデバイスが近づけられた際に、NFC通信パケットに格納された設定情報を利用して、WLAN通信に必要な認証処理が実現されるような使い方を想定する。特に、図14に示す通信装置100、200のようにNFCデバイスを搭載した機器間で、NFC通信により交換された設定情報に基づいて認証処理が実行され、通信装置100、200間がWLANで接続されるようなケースを想定する。
【0103】
(変形例)
尚、NFC通信による設定情報の交換は、図15に示すように、NFCデバイスを備えた通信媒介端末を介して交換されてもよい。この例は、通信装置100、200が備えるNFCデバイスが相互に離れた場所に設置され、互いに近接できないような場合等において利用される。また、NFCデバイスの通信特性に応じて、この例のような形態が採用されてもよい。この例の場合、例えば、通信装置100に翳された通信媒介端末にNFC通信で設定情報が一旦格納され、その後、この通信媒介端末が通信装置200のNFCデバイスに翳されることで、一旦格納された設定情報が通信装置200に読み取られる。また、逆の操作により、通信装置200の設定情報が通信装置100に伝達される。
【0104】
[通信装置100、200の機能構成]
次に、図16を参照しながら、本実施形態に係る通信装置100、200の機能構成について説明する。図16は、本実施形態に係る通信装置100、200の機能構成を示す説明図である。
【0105】
図16に示すように、通信装置100、200は、主に、アンテナ102、106と、近接通信部104と、近距離通信部158と、制御部160と、RAM112と、ROM114と、フラッシュメモリ116と、入力部118と、表示部120とにより構成される。尚、アンテナ106、近距離通信部158は、図23に示すハードウェア資源のうち、例えば、通信部926により実現される。制御部160の機能は、例えば、図23、又は図24に示された、制御回路712、コントローラ722、又はCPU902により実現される。
【0106】
上記の第1実施形態に係る通信装置100、200との主な相違点は、近距離通信部158、及び制御部160の機能構成にある。そこで、近距離通信部158、及び制御部160の機能構成について詳細に説明する。
【0107】
(近距離通信部158)
近距離通信部158は、近接通信部104よりも長い距離間で通信することが可能な通信手段である。また、近距離通信部158は、アンテナ106に接続されており、近接通信部104よりも広い帯域幅を利用し、高速にデータを送受信することができる。さらに、近距離通信部158は、第2通信方式としてWLANに対応している。
【0108】
(制御部160)
制御部110は、通信装置100、200の各構成要素の動作を制御する手段である。また、制御部160は、主に、鍵ペア生成機能と、乱数生成機能と、証明書算出機能と、設定情報付加機能と、設定情報抽出機能と、認証レコード付加機能と、認証レコード抽出機能と、認証方式判定機能と、を有する。
【0109】
鍵ペア生成機能は、ペアを成す公開鍵と秘密鍵を生成する機能である。鍵ペア生成機能は、例えば、Diffie−Hellmanにより公表された鍵生成アルゴリズムに基づいて公開鍵/秘密鍵のペアを生成する機能である。尚、秘密鍵は、RAM112、又はフラッシュメモリ116に格納される。
【0110】
乱数生成機能は、物理的な乱数生成器から乱数を取得するか、或いは、所定の乱数生成アルゴリズムを利用して疑似乱数を生成する機能である。所定の乱数生成アルゴリズムとしては、例えば、線形合同法やメルセンヌ・ツイスター法等、種々の方法が利用可能である。但し、その性質上、より良いアルゴリズムが用いられることが好ましい。
【0111】
証明書算出機能は、乱数生成機能により生成された乱数、及び、所定のハッシュ関数を利用して証明書を算出する機能である。設定情報付加機能は、近接通信部104により送信される通信パケットに設定情報を付加する機能である。設定情報には、例えば、自装置のIPアドレス、乱数、及び証明書等が含まれる。設定情報抽出機能は、近接通信部104の受信パケットに付加された設定情報を抽出する機能である。
【0112】
認証レコード付加機能は、後述するNDEFメッセージに認証フラグを示すNDEF Recordを付加する機能である。この認証フラグには、認証方式のRecordであることを示す識別子と、認証方式を示す識別子と、WLANネットワークの構成を示す識別子とが含まれる。これらの識別子については、後段において詳述する。認証レコード抽出機能は、後述するNDEFメッセージに付加された認証フラグを示すNDEF Recordを抽出する機能である。
【0113】
認証方式判定機能は、認証レコード抽出機能により抽出されたNDEF Recordの認証フラグを参照し、NDEFメッセージの送信元装置が対応する認証方式を判定する機能である。また、認証方式判定機能は、送信元装置が対応する認証方式と、自装置が対応する認証方式とを比較し、より適した認証方式を選択する機能を含む。
【0114】
[NDEFメッセージの構成例]
次に、図17を参照しながら、OOB認証方式に適用可能な本実施形態に係るNDEFメッセージの構成例について説明する。図17は、OOB認証方式に適用可能な本実施形態に係るNDEFメッセージの構成例を示す説明図である。
【0115】
上記の通り、WLANのOOB方式による認証処理においても、BTのOOB方式による認証処理の場合と同様に、図4、及び図5に示すNDEFメッセージを用いて設定情報が交換される。但し、本実施形態に係るNDEFメッセージは、図17に示すような構成を有する。
【0116】
図17に示すように、NDEFメッセージは、例えば、3つのNDEF Recordにより構成される。第1のNDEF Record(Record1)には、このNDEFメッセージがハンドオーバー用であることを示すハンドオーバー用Record Typeが格納されている。第2のNDEF Record(Record2)には、例えば、Record TypeがWLANであることを示す“application/vnd.wfa.wsc”が格納されており、そのペイロードにWLANの設定情報が格納されることが示されている。
【0117】
ペイロードの種類には、「OOB Device Password」、「Credential」、又は「空」がある。「OOB Device Password」としては、WPSの仕様中で規定された32バイトの公開鍵(Device Password)、又は証明書の生成に利用される20バイトのハッシュ値(Hash)等が格納される。「Credential」としては、APの設定に必要なSSID、伝送路の暗号化に利用される暗号鍵(NetworkKey)等の情報が格納される。これらの情報は、Type、Length、Value(TLV)方式にて格納される。一方、自装置に設定情報が存在せず、相手装置に設定情報を要求する場合、ペイロードは「空」になる。
【0118】
さらに、本実施形態に係るNDEFメッセージには、第3のNDEF Record(Record3)が付加される。この第3のNDEF Recordには、認証方式を示すRecordであることを識別するための第1識別子と、認証方式を示す第2識別子と、WLANネットワーク構成を示す第3識別子とが含まれる。
【0119】
本実施形態において、第2識別子は、自装置がWPSにより規定された「OOB Device Password」に対応するか否かを示すフラグ(a)と、「Credential」に対応するか否かを示すフラグ(b)と、認証設定情報の時限設定が可能か否かを示すフラグ(c)とにより構成される。この認証設定情報の時限設定とは、認証により設定された情報がWLAN接続が確立された段階で消去できるようにする設定である。また、第3識別子は、WLANで形成されるネットワーク構成として、ad−hocネットワークに対応するか否かを示すフラグ(a)と、自装置に割り当てられるIPアドレス(b)と、接続先に接続許可を与えるポート番号(c)と、FTPユーザ名/パスワード(d,e)とが含まれる。但し、FTPユーザ名/パスワードは、FTPサービスが提供される場合に含まれる。
【0120】
[認証処理の流れ]
次に、図18、及び図19を参照しながら、本実施形態に係る認証処理の流れについて説明する。図18、及び図19は、本実施形態に係る認証処理の流れを示す説明図である。この認証処理の中で、上記構成のNDEFメッセージが利用される。
【0121】
図18を参照する。まず、自装置(Enroller)がWPSの認証方式に対応するか否か、且つ、APの通信圏内(電波到達範囲内)か否かが判定される(S202)。自装置がWPSの認証方式に対応し、且つ、APの通信圏内である場合、ステップS204の処理に進行する。一方、両条件のいずれかが満たされない場合、ステップS220の処理に進行する。
【0122】
ステップS204において、自装置及び接続先装置の双方がWPS Password(公開鍵暗号方式)に対応するか否かが判定される(S204)。双方がWPS Passwordに対応している場合、ステップS206の処理に進行する。一方、双方がWPS Passwordに対応していない場合、ステップS214の処理に進行する。
【0123】
この判定処理において、自装置の制御部160により、WPSにおける公開鍵方式の設定パラメータ「OOB Device Password」に対応可否を示すフラグ(第2識別子)が設定される。また、自装置の制御部160により、上記の第3識別子にWLANのネットワーク構成情報が設定される。そして、自装置の制御部160により、第2及び第3識別子が設定された第3のNDEF RecordがNDEFメッセージ内に付加され、NFC通信にて接続先装置に送信される。さらに、NFC通信パケットを受信した接続先装置は、制御部160により、Enrollerの認証フラグ(第3のNDEF Record)が抽出されて、EnrollerがWPS Passwordに対応するか否かが判定される。
【0124】
ステップS206以降において、図20に示すようなAP−BS間通信によるInfraネットワークが形成される。このケースは、接続先装置がRegistrar機能を有している場合に対応している。
【0125】
ステップS206では、AP/RegistrarとBS/Enrollerとの間において、NFC通信により公開鍵、及び証明書が交換される(S206)。NFC通信で交換された証明書により、通信相手が互いに不正者か否かが判断される。互いに不正者でないと判断されると、交換された公開鍵により暗号化された設定情報がWLAN通信にて交換される(S208)。次いで、交換された設定情報に基づいてAP/RegistrarにBS/Enrollerが登録される(S210)。その後、BS/Enrollerは、NFC通信パケットのNDEFメッセージに含まれるAPのIPアドレス、及び公開ポート番号に基づいてWLANによる通信処理が実現される(S212)。
【0126】
次に、ステップS204において、いずれか一方又は両方の装置がWPS Passwordに対応していないと判断された場合について説明する。ステップS214において、双方がWPS Credentialに対応しているか否かが判定される。双方がWPS Credentialに対応している場合、ステップS216の処理に進行する。一方、いずれか一方又は両方がWPS Credentialに対応していない場合、ステップS220の処理に進行する。
【0127】
ステップS216以降において、BS−BS間でNFC通信が実現され、図21に示すようなRegistrarを経由しないInfraネットワークが形成される場合のセットアップ手順が示される。
【0128】
ステップS216では、Infraネットワークに接続されているBS間でNFC通信により、APの設定情報が交換される(S216)。このとき、APの設定情報は、暗号化されていない平文で送信される。次いで、BS/Enrollerは、NFC通信で取得したAPの設定情報に基づいてWLANの接続認証を要求する(S218)。APとBS/Enrollerとの間で接続が確立されると、BS/Enrollerは、NFC通信で既に取得していたAPのIPアドレス、及び公開ポートに基づいて接続相手先のBSとの間でIPパケットの送受信を行う(S212)。
【0129】
次に、ステップS214において、いずれか一方又は両方の装置がWPS Credentialに対応していないと判断された場合、或いは、ステップS202において自装置がWPSに非対応、又はAPの通信圏内にないと判断された場合について説明する。いずれの場合においても、Infraモードでの接続ができないため、図22に示すようなad−hocモードのネットワーク構成が選択される。
【0130】
ステップS220において、BS/Enrollerがad−hocモードに対応可能か否かが判断される(S220)。BS/Enrollerがad−hocモードに対応可能である場合、ステップS224の処理に進行する。一方、BS/Enrollerがad−hocモードに対応不可能である場合、ネットワークの形成処理が失敗し(S222)、一連の処理が終了する。この処理において、接続先のBSは、NDEFメッセージに基づいてBS/Enrollerがad−hocモードに対応可能な否かを判断する。
【0131】
ステップS224以降において、BS/Enroller、及び接続先のBSがad−hocモードに対応可能であることを前提としてセットアップ手順が示される。
【0132】
ステップS224において、接続先のBSは、ad−hocモードのネットワーク形成に必要な設定情報として、SSID、Network Key等の設定情報をNFC通信によってBS/Enrollerに送信する。このとき、接続先のBSは、NFC通信を介してIPアドレス、公開ポート等のネットワーク設定情報も送信する(S224)。
【0133】
このとき、接続先のBSとAPとの間でInfraモードのネットワークが形成されている場合、このネットワーク接続が切断される。ad−hocネットワークの生成に必要な情報が共有されると、双方のBSが接続され(S226)、NFC通信で取得されたIPアドレスに基づいて互いにIPパケットの送受信が可能な状態になる(S212)。
【0134】
本実施形態に係るNFCパケットの構成を適用すると、上記のような手順により、図20、図21、図22のいずれかの形態を有するネットワークが形成される。次に、図19を参照しながら、上記の手順で形成されたネットワークが切断された後の処理について説明する。図19は、ネットワーク切断後の処理の流れを示す説明図である。
【0135】
図19に示すように、上記の手順でネットワーク接続が確立されると、双方が既に取得しているIPアドレス又は特定のURLを用いて相互に通信することができる(S214)。その後、ネットワークが切断されると(S216)、ステップS218の処理に進行する。ステップS218では、双方が一時接続に対応しているか否かが判断される(S218)。双方が一時接続に対応している場合、ステップS222の処理に進行する。一方、一方又は双方が一時接続に対応していない場合、ステップS220の処理に進行する。
【0136】
既に述べた通り、NDEFメッセージに含まれる第3のNDEF Record中には、認証フラグの1つとして一時接続対応フラグが含まれていた(図17を参照)。上記の判定処理は、この一時接続対応フラグに基づいて実行される。もし、接続元、及び接続先のいずれにおいても、このフラグが無効になっていた場合、互いのネットワーク設定情報が保存され、次回の接続時にも設定情報が有効であるため(S220)、新たな認証処理の必要が無くなる。
【0137】
逆に、双方の機器が一時接続に対応している場合、双方の機器に格納されていたSSID、Network Keyが削除される(S222、S224)。さらに、接続先のMACアドレスが削除されて不許可に設定される(S226)。このように、設定情報が無効にされるため(S228)、次回、再接続する際には、これらの設定パラメータを再度交換する必要がある。このような設定にすると、ネットワーク設定情報が一時的の使い捨て情報となり、ad−hocモードの場合、ネットワークが形成される度にSSID、ネットワークキーが交換されるため、セキュリティ強度が向上する。
【0138】
尚、上記の第1実施形態の場合と同様に、認証時に毎回、GUI経由でユーザの承認を得る工程(図11を参照)が追加されることにより、不正者が関知しない期間にネットワークに接続する機会が低減され、よりセキュリティの向上が図れる。
【0139】
以上、本発明に係る2つの実施形態について説明した。これらのNFC通信を用いたBT及びWLANの簡単セットアップ方式を採用することで、設定情報を平文でNFC伝送するような場合であっても、認証受け入れ期間、及び認証許可アドレスの制限により、盗聴者によるネットワークへの進入可能性が低減される。
【0140】
また、表示デバイスを経由した承認手順を設けることにより、不正者が許可なく認証作業を開始することが防止される。そのため、公開鍵暗号化ロジックを搭載しない製品構成であっても、制御ソフトウェアの変更だけで安全且つ簡単なセットアップが実現される。
【0141】
また、標準化された簡単セットアップ規格(BT Core規格のバージョン2.1、又はWLANのWPS方式)に準拠した製品と、未対応の既存製品が並存する場合であっても、上記の実施形態に例示したNFC通信パケットのフォーマットを利用することで、互いの規格対応状況を交換し、実施の態様に適した方式を選択することができるようになる。その結果、NFC通信を使った認証方式において、これらの異なる認証方式間における互換性を維持することができるようになる。
【0142】
さらに、NFC通信パケットの中に、認証後に形成されるネットワークの構成情報を格納して交換することにより、所定のネットワーク構成の中で、より適したネットワーク内の役割分担、又は接続モードの選択が可能になる。
【0143】
[非接触通信装置の装置構成例]
ここで、図23を参照しながら、上記の装置が有する機能の一部又は全部を実現することが可能な非接触型の通信装置の装置構成例について簡単に説明する。図23は、非接触通信装置の装置構成例を示す説明図である。尚、上記の装置が有する機能は、この非接触通信装置が有する構成要素の一部のみを利用して実現してもよい。また、重複する符号が付された構成要素は、一体のハードウェア資源により構成されていてもよい。
【0144】
図23に示すように、この通信装置は、主に、ICカード部分と、リーダ/ライタ部分と、コントローラ722とにより構成される。
【0145】
(ICカード部分)
ICカード部分は、例えば、アンテナ702と、フロントエンド回路704と、変調器706と、コマンド再生器708と、クロック再生器710と、制御回路712と、暗号化回路714と、メモリ716と、有線インターフェース回路718とで構成される。
【0146】
アンテナ702は、ループ・アンテナにより構成され、リーダ/ライタが有するループ・アンテナと磁気的に結合してコマンドや電力を受け取る。フロントエンド回路704は、リーダ/ライタから送出された搬送波を整流して直流電源を再生する。また、フロントエンド回路704は、取得した13.56MHzの搬送波を分周してコマンド再生器708、及びクロック再生器710に入力する。コマンド再生器708は、入力された搬送波からコマンドを再生して制御回路712に入力する。クロック再生器710は、入力された搬送波からロジック回路を駆動するためのクロックを再生して制御回路712に入力する。また、フロントエンド回路704は、再生した電源を制御回路712(CPU)に供給する。
【0147】
全ての回路に電源が供給されると、制御回路712は、再生されたコマンドに応じて各回路を駆動する。尚、制御回路712から出力されたデータは、暗号化回路714により暗号化されてメモリ716に格納される。尚、メモリ716は、例えば、磁気的、光学的、又は光磁気的に情報を記録する記憶装置であってもよいし、ROMやRAM等に利用される半導体記憶装置であってもよい。
【0148】
一方、メモリ716内に格納された暗号化データを送信する場合、フロントエンド回路704は、変調器706により変調された暗号化データに基づいてアンテナ702の給電点にある負荷インピーダンスを変化させ、その変化によりアンテナ702によって誘起される磁界を変化させる。この磁界変化により、磁気的に結合したリーダ/ライタのアンテナを流れる電流変化が誘起されて暗号化データが伝送される。
【0149】
また、制御回路712は、有線インターフェース回路718を介してコントローラ722により制御されてもよい。また、ICカード部分は、インターフェースI/F(未図示)を介して、後述のリーダ/ライタ部分との間で情報を送受信し、相互に又は一方から他方を制御することが可能であってもよい。
【0150】
(リーダ/ライタ部分)
リーダ/ライタ部分は、例えば、アンテナ702と、フィルタ732と、受信アンプ734と、周波数変換器736と、識別器738と、ロジック回路740と、制御回路712と、メモリ716と、有線インターフェース回路742と、変調器746と、局部発振器750と、送信アンプ748とにより構成される。
【0151】
リーダ/ライタ部分は、非接触ICカード等との磁気的な結合を利用してコマンドや電力を供給する。このリーダ/ライタ部分は、制御部712(CPU)の制御により、非接触ICカード等に電力を供給して活性化させてから、所定の伝送プロトコルに従って通信を開始する。このとき、リーダ/ライタ部分は、通信接続の確立、アンチコリジョン処理、及び認証処理等を行う。
【0152】
リーダ/ライタ部分は、局部発振器750を利用して搬送波を生成する。情報を送信する場合、まず、制御回路712は、メモリ716からデータを読み出してロジック回路740に伝送する。そして、変調器746は、ロジック回路740から出力された信号に基づいて局部発振器750により生成された搬送波を変調する。さらに、送信アンプ748は、変調器746から出力された変調波を増幅し、アンテナ702を介して送信する。
【0153】
一方、情報を受信する場合、まず、アンテナ702を介して受信された変調波は、フィルタ732を通した上で受信アンプ734に入力される。そして、受信アンプ734により増幅された信号は、周波数変換器736により周波数変換されてロジック回路740に入力される。さらに、ロジック回路740から出力された信号は、制御回路712によりメモリ716に記録される。或いは、当該信号は、有線インターフェース回路742を介して外部のコントローラ722に伝送される。
【0154】
以上、非接触通信装置の装置構成例について説明した。当該非接触通信装置は、例えば、携帯電話、携帯情報端末、各種の通信機器、パーソナルコンピュータ等の情報処理装置、或いは、ゲーム機や情報家電等であってもよい。また、上記の非接触通信装置が有する機能又は構成要素の一部又は全部を内蔵した各種の機器についても、上記実施形態の技術的範囲に含まれる。
【0155】
[ハードウェア構成(情報処理装置)]
上記装置が有する各構成要素の機能は、例えば、図24に示すハードウェア構成を有する情報処理装置により、上記の機能を実現するためのコンピュータプログラムを用いて実現することが可能である。図24は、上記装置の各構成要素が有する機能を実現することが可能な情報処理装置のハードウェア構成を示す説明図である。
【0156】
図24に示すように、前記の情報処理装置は、主に、CPU(Central Processing Unit)902と、ROM904と、RAM906と、ホストバス908と、ブリッジ910と、外部バス912と、インターフェース914と、入力部916と、出力部918と、記憶部920と、ドライブ922と、接続ポート924と、通信部926とにより構成される。
【0157】
CPU902は、例えば、演算処理装置又は制御装置として機能し、ROM904、RAM906、記憶部920、又はリムーバブル記録媒体928に記録された各種プログラムに基づいて各構成要素の動作全般又はその一部を制御する。ROM904は、例えば、CPU902に読み込まれるプログラムや演算に用いるデータ等を格納する。RAM906は、例えば、CPU902に読み込まれるプログラムや、そのプログラムを実行する際に適宜変化する各種パラメータ等を一時的又は永続的に格納する。これらの構成要素は、例えば、高速なデータ伝送が可能なホストバス908によって相互に接続されている。また、ホストバス908は、例えば、ブリッジ910を介して比較的データ伝送速度が低速な外部バス912に接続されている。
【0158】
入力部916は、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチ、及びレバー等の操作手段である。また、入力部916は、赤外線やその他の電波を利用して制御信号を送信することが可能なリモートコントロール手段(所謂、リモコン)であってもよい。なお、入力部916は、上記の操作手段を用いて入力された情報を入力信号としてCPU902に伝送するための入力制御回路等により構成されている。
【0159】
出力部918は、例えば、CRT(Cathode Ray Tube)、LCD(Liquid Crystal Display)、PDP(Plasma DisplayPanel)、又はELD(Electro−Luminescence Display)等のディスプレイ装置、スピーカ、ヘッドホン等のオーディオ出力装置、プリンタ、携帯電話、又はファクシミリ等、取得した情報を利用者に対して視覚的又は聴覚的に通知することが可能な装置である。
【0160】
記憶部920は、各種のデータを格納するための装置であり、例えば、ハードディスクドライブ(HDD;Hard Disk Drive)等の磁気記憶デバイス、半導体記憶デバイス、光記憶デバイス、又は光磁気記憶デバイス等により構成される。
【0161】
ドライブ922は、例えば、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリ等のリムーバブル記録媒体928に記録された情報を読み出し、又はリムーバブル記録媒体928に情報を書き込む装置である。リムーバブル記録媒体928は、例えば、DVDメディア、Blu−rayメディア、HD−DVDメディア、コンパクトフラッシュ(登録商標)(CF;CompactFlash)、メモリースティック、又はSDメモリカード(Secure Digital memory card)等である。もちろん、リムーバブル記録媒体928は、例えば、非接触型ICチップを搭載したICカード、又は電子機器等であってもよい。
【0162】
接続ポート924は、例えば、USB(Universal Serial Bus)ポート、IEEE1394ポート、SCSI(Small Computer System Interface)、RS−232Cポート、又は光オーディオ端子等のような外部接続機器930を接続するためのポートである。外部接続機器930は、例えば、プリンタ、携帯音楽プレーヤ、デジタルカメラ、デジタルビデオカメラ、又はICレコーダ等である。
【0163】
通信部926は、ネットワーク932に接続するための通信デバイスであり、例えば、有線又は無線LAN(Local Area Network)、Bluetooth(登録商標)、又はWUSB(Wireless USB)用の通信カード、光通信用のルータ、ADSL(Asymmetric Digital Subscriber Line)用のルータ、又は各種通信用のモデム等である。また、通信部926に接続されるネットワーク932は、有線又は無線により接続されたネットワークにより構成され、例えば、インターネット、家庭内LAN、赤外線通信、可視光通信、放送、又は衛星通信等である。尚、通信部926の機能に上記の非接触通信装置が備える非接触通信機能を含めてもよい。
【0164】
[補遺1:<SSP方式について>]
上記の第1実施形態に係る技術は、以下で説明するSSP方式に対し、好適に適用することが可能である。そこで、SSP方式に係る認証方法について、以下で詳細に説明する。尚、上記の第1実施形態の説明において記載されたパラメータは、その表記が対応するように同じ記号で表現されている。そのため、上記の第1実施形態に係る技術を下記のSSP方式に適用する際には、パラメータ表記の対応関係を意識することで、技術的な対応関係が容易に把握されるであろう。
【0165】
[1:SSP方式の提案モデル]
SSP方式には、4つのモデルが提案されている。これらの4つのモデルは、それぞれ、数字比較モデル、JW(Just Work)モデル、OOBモデル、パスキー入力モデルと呼ばれる。以下、これらの提案モデルについて簡単に説明する。
【0166】
(1−1:数字比較モデル)
数字比較モデルは、次のようなシナリオを想定している。(1)互いに通信するデバイスの両方が6桁の数字を表示できるものとする。(2)これらの両方のデバイスには、”Yes”又は”No”のユーザ入力が可能であるとする。このシナリオには、例えば、セルラーフォンやパーソナルコンピュータが適用される。
【0167】
(ペアリングの確立手順について)
まず、ユーザは、両方のデバイスが備えるディスプレイ上に表示された6桁の数字(”000000”から”999999”まで)を視認する。それから、ユーザは、両方のデバイスに表示された数字が同じであるか否かを尋ねられる。そこで、ユーザは、両方のデバイスに”YES”又は”NO”を入力する。もし、”YES”が両方のデバイスに入力されたならば、ペアリングが成立する。
【0168】
(数字比較モデルの目的)
この数字比較モデルには2つの目的がある。1つ目の目的は、個々のデバイスに固有の名前を持っていない場合に、正しいデバイスがそれぞれ接続されたという承認をユーザに対して与えるということである。2つ目の目的は、中間者攻撃(man−in−the−middle attack)に対する防衛手段を提供することである。
【0169】
尚、Core Specifications 2.0+EDR以前の規格で利用されるPIN入力モデルと、この数字比較モデルとの間には、暗号化技術に係る観点から重大な相違があるという点に注意が必要である。この数字比較モデルで利用される6桁の数字は、人工的なセキュリティアルゴリズムに基づくものであり、現行のセキュリティモデルのようなユーザの手で入力されるものではない。当然の事ながら、表示された数字が知されることにより、両方のデバイス間で交換される暗号データが復号される危険性が高まるため、これを避けるように構成されているのである。
【0170】
(1−2:JWモデル)
JWモデルでは、次のようなシナリオが想定されている。このシナリオでは、少なくとも1つのデバイスが、6桁の数字が表示できるディスプレイを備えていないか、或いは、6桁の数字を入力するためのキーボードを備えていないということが想定されている。このシナリオには、例えば、携帯電話や単体のハンドセットが適用される。現状、大部分のハンドセットはディスプレイを持っていないからである。
【0171】
JWモデルは、数字比較方式を利用する。しかし、ユーザには、数字が表示されることはない。また、アプリケーションは、ユーザに対して単に接続の承認を尋ねるだけである。JWモデルは、受動的な盗聴に対して上記の数字比較モデルと同等の耐性を備えた防御手段を提供する。但し、中間者攻撃に対する防御手段を提供するものではない。
【0172】
一般的なハンドセット等による4桁の数字(固定PIN)を利用したセキュリティモデルと比較するとき、JWモデルのセキュリティレベルは比較的高いと考えられる。その理由は、受動的な盗聴に対する高い耐性が実現されているためである。
【0173】
(1−3:OOBモデル)
OOB(Out Of Band)モデルは、次のようなシナリオを想定している。まず、OOBの技術は、ペアリングの工程で暗号数字を交換する際又は送信する際に、両方のデバイスを発見するために用いられる。但し、このOOBチャネルは、セキュリティに関する効果を期待して、デバイスの発見とは異なる目的でも提供されるべきである。例えば、OOBチャネルは、BTの通信チャネルにおけるセキュリティを高めるために提供されるべきである。OOBチャネルは、中間者攻撃、及びプライバシーの侵害に対する防御手段を提供する。
【0174】
尚、ユーザの操作はOOBの機構に依存して異なるかもしれない。例えば、OOBとして近接場通信(Near Field Communication;NFC)を適用する場合、ユーザは、はじめに2つのデバイスを互いにタッチさせる。それから、ユーザは、他のデバイスとペアリングを構成したいか否かを尋ねられる。そこで、ユーザは、”YES”又は”NO”を入力する。”Yes”が入力されると、ペアリングが形成される。
【0175】
上記の操作は、デバイス間で情報を交換するためのシングルタッチの操作である。この交換される情報には、BDの発見に利用されるBDアドレスのようなデバイス情報と、暗号化に利用されるセキュリティ情報とが含まれる。デバイスの一方は、受信したBDアドレスを他のデバイスとの間の接続を確立するために利用することができる。一方、交換されたセキュリティ情報は、認証処理において利用される。尚、OOBの機構が有する特徴に依存して、1方向、又は双方向の認証処理が実現される。
【0176】
OOB方式は、次のような場合にのみ選択される。例えば、OOBによる情報交換によりペアリングが既に有効化されていた場合や、一方又は両方のデバイスが入出力機能の有無(IO Capability;Input/Output Capability)を応答する際にOOB方式に対応可能であることを通知した場合である。
【0177】
OOB方式では、ユーザに対して単に接続の承認を尋ねるための情報が利用される。尚、OOBモデルには、暗号化に必要な情報、及びBDアドレスを交換可能な機構であれば、任意のOOB機構を適用することができる。また、このOOBモデルでは、ユーザがBT通信を利用して既に接続を有効にした手段をサポートせず、接続に際して認証処理のためにOOBチャネルが利用される。
【0178】
(1−4:パスキー入力モデル)
パスキー入力モデルは、次のようなシナリオを想定している。(1)一方のデバイスは、入力機能を備えており、かつ、6桁の数字を表示する機能を備えていない。(2)そして、他方のデバイスは、出力機能を備えている。このシナリオは、例えば、パーソナルコンピュータとキーボードの組み合わせに適用される。
【0179】
まず、ユーザに対し、一方のデバイスが備えるディスプレイ上に6桁の数字(”000000”から”999999”まで)が表示される。それから、ユーザは、他方のデバイスにより表示された数字を入力するように求められる。表示された数字が他方のデバイスに正しく入力された場合にペアリングが形成される。
【0180】
[2:セキュリティ確立手段]
SSP方式のセキュリティ確立手段は、次のような5つのフェーズにより構成される。
フェーズ1:公開鍵の交換
フェーズ2:認証ステージ1
フェース3:認証ステージ2
フェーズ4:リンクキーの算出
フェーズ5:LMP認証、及び暗号化
【0181】
フェーズ1、3、4、5は、上記の全てのモデルで同じである。但し、フェーズ2(認証ステージ1)に関しては、適用するモデルに依存して若干異なる。尚、以下の説明において、下表1で定義される表現([Term])が用いられる。
【0182】
(2−1:フェーズ1<公開鍵の交換>(図25(A)を参照))
まず、各デバイスがECDH(Elliptic Curve Diffie−Hellman)方式に基づいて自身の公開鍵/秘密鍵のペア(PK,SK)を生成する(ステップ1)。この鍵ペアは、デバイスの組毎に1度だけ生成される。この鍵ペアは、ペアリング処理の開始前に算出されていてもよい。また、任意の時点で、その鍵ペアはデバイスにより放棄され、新たな鍵ペアが生成されることがある。
【0183】
ペアリングは、初期化デバイス(Initiating Device A)により、受信側のデバイス(以下、応答デバイス(Non−initiating Device B))に公開鍵が送信されることで開始される(ステップ1a)。応答デバイスは、初期化デバイスによる公開鍵の送信に応じて、自身の公開鍵を初期化デバイスに送信する(ステップ1b)。双方の公開鍵(PKa,PKb)は、たとえ、デバイスを認証するものであろうとも、秘密のものと見なされない。尚、ステップ1a、1bは、上記の全てのモデルで共通である。
【0184】
(2−2:フェーズ2<認証ステージ1>(図26〜図28を参照))
認証ステージ1は、上記の3つのモデル(数字比較モデル、OOBモデル、パスキー入力モデル)の間で処理が異なる。いずれのモデルを選択するかは、両方のデバイスの入出力機能の有無に基づいて決定される。尚、図25〜図28の中で、文頭に記載された数字はステップを表す。
【0185】
(2−2−1:認証ステージ1(数字比較モデル/図26))
数字比較モデルは、効果的な中間者攻撃に対して一定の耐性を有する防御手段を提供する。1度の中間者攻撃に対し、0.000001程度の確率でしか攻撃が成功しないであろう。もし、ペアリングされている時点で中間者攻撃がないならば、共有されているリンクキーは、計算上、ペアリングされている間の受動的な盗聴に対しても安全である。
【0186】
以下、暗号化の観点から、数字比較モデルにおける認証ステージ1(Authentication Stage 1)のシーケンスダイアグラムについて説明する。
【0187】
公開鍵が交換された後で、各デバイスは、一時的な128ビットの疑似乱数(Na,Nb)を生成する(ステップ2a,2b)。この疑似乱数値は、反復攻撃を避けるために利用される。また、この疑似乱数値は、ペアリングが形成される毎に新規に生成されなければならない。さらに、この疑似乱数値は、物理的な乱数発生源、又は物理的な発生源による乱数値をシードとする良い疑似乱数発生器から直接生成されるべきである。
【0188】
次いで、対向するデバイスは、双方の公開鍵に対応した証明書(Ca,Cb)を算出する。この証明書は、一時的な疑似乱数を用いて生成されているため、それ自体が一時値である(ステップ3c)。この証明書は、その証明書の算出に利用されるパラメータの入力に対して1方向性を有する関数(f1)によって算出される。次いで、この証明書は、初期化デバイスに送信される(ステップ4)。尚、この証明書は、一時期間を経過した後で攻撃者によりパラメータが変更されるのを避けるために利用される。
【0189】
次いで、初期化デバイス、及び応答デバイスは、上記の一時値(疑似乱数値(Na,Nb))を交換する(ステップ5、6)。次いで、初期化デバイスは、その証明書が正しいか否かを確認する(ステップ6a)。ステップ6aにおける確認の失敗は、攻撃者の存在、又は他の送信エラーが存在することを示すものである。もし、失敗したならば、このモデルにおけるペアリングの形成処理は破棄される。尚、これらのステップは、新たな鍵ペアが生成された際に、又は、新たな鍵ペアが生成されていなくても繰り返し実行されることがある。しかし、そうしたステップが繰り返されるならば、新たな一時値が生成されねばならない。
【0190】
さて、証明書のチェックが成功した場合、双方のデバイスは、6桁の数字(認証値(Va,Vb))をそれぞれ算出する。この認証値は、ユーザに提示されるために、各デバイスが備えるディスプレイ上に表示される(ステップ7a、7b、8)。ユーザには、これらの6桁の認証値が一致しているか否か、或いは、一致しているものがあるか否かの確認が期待される。もし、一致しているものがないならば、その認証ステップは破棄される。さらに、その認証ステップが繰り返されるならば、新たな一時値が生成されねばならない。
【0191】
尚、狡猾な中間者によりサービス否認以外の任意の影響が及ばないように、認証プロセスにおいて自身のデバイスに関する鍵の情報が認証の際に利用される。単純な中間者攻撃であれば、0.999999の確率で異なる2組の6桁の表示値に帰着するであろう。より洗練された攻撃であれば、技術者に対し、表示値を一致させるように試みるかもしれないが、上記の認証処理シーケンスにより防ぐことができる。
【0192】
(2−2−2:認証ステージ1<OOBモデル>(図27))
OOBモデルは、LMP入出力機能の可否に関する情報を交換するシーケンスの中で、認証に利用されるセキュリティ情報が少なくとも一方のデバイスによって受信され、その中にOOB認証データ存在パラメータ(OOB Authentication Data Present parameter)が含まれる場合に選択される。
【0193】
両方のデバイスがOOBチャネルを介してデータを送信及び/又は受信できるならば、相互認証は、OOB公開鍵(PKa,PKb)に基づく証明書(Ca,Cb)が認証ステージの中で交換されることにより実現されることになる。
【0194】
1.OOB通信が1方向でのみ可能である場合(例えば、受動的なNFCタグ等で構成されるデバイスを適用する場合、又は一方のデバイスが読み込み専用のものである場合)、OOB通信における受信デバイスの認証は、OOB通信を介して送信された乱数rを知っているデバイスにより実現される。このケースにおいて、乱数rは、秘密でなければならない。また、乱数rが毎回新たに生成されるか、或いは、乱数rを送信するデバイスへのアクセスが制限されていなければならない。もし、乱数rがデバイスに送られなかったならば、ステップ4a、4bの中でOOB情報(A,B,ra,rb,Ca,Cb)を受信したデバイスにより、rが0であると設定される。
【0195】
もし、OOB通信が堅牢なものであるならば(例えば、中間者攻撃を防御可能であるならば)、OOBモデルは、中間者攻撃による影響を受けにくいものであると言える。また、OOBモデルの中で、認証に利用されるパラメータ(Ca、Cb、ra、rb)のサイズは、ユーザが読み易いか、或いは、手入力し易いかということに配慮して制限されることがない。こうした理由により、OOBモデルは、数字比較モデル、又はパスキー入力モデルよりも、よりセキュアにすることができる。しかしながら、両方のデバイスが相互に対応するOOBインターフェースを有することが必要となる。
【0196】
デバイスA、Bの役割:OOBモデルにおいて、デバイスAとデバイスBには、その役割に関して対称性がある。まず、デバイスAがいつもペアリングを開始することは要求されない。例えば、一方のデバイスがNFCタグを備え、OOB情報の送信のみができる場合、OOB通信の中で自動的に非対称性が解決される。
【0197】
しかしながら、ステップ12(図25(B))でリンクキー(LK)が計算される際、双方のデバイス群は、同じオーダー(秩序)のパラメータを入力しなければならない。但し、各デバイスにより異なる鍵が算出される。このオーダーとは、例えば、「デバイスA´のパラメータがピコネットマスターのパラメータであり、デバイスB´のパラメータがピコネットスレーブのパラメータである」といったものである。
【0198】
ステップの順序:公開鍵の交換は、認証処理のステップ(ステップ5)よりも以前に実行されなければならない。ダイアグラムの中で、デバイス間におけるBTバンド内での公開鍵の交換(ステップ1)は、OOB通信(ステップ4)の以前に実行される。しかし、OOBインターフェースによりペアリングを開始しようとすると、公開鍵の交換はOOB通信の後になってしまう(ステップ1がステップ4とステップ5との間になろう)。
【0199】
ra,rbの値:OOB通信が実行される以前には対向するデバイスのOOBインターフェースの方向性が確認できないため、デバイスによりra、rbの値がいつも生成される。そして、可能ならば、OOBインターフェースを通じて対向するデバイスに乱数rが送信される。各デバイスは、自身のrの値、及び対向するデバイスのrの値をローカルで設定するために、次のようなルールを適用する。
【0200】
1.最初、デバイスのrが乱数に設定され、対向するデバイスのrが0に設定される(ステップ2)。
2.デバイスがOOBで情報を受信したならば、対向するデバイスにより送信されたr値を設定する(ステップ5)。
3.デバイスがOOB認証データを受信したと示さなければ、自身のr値を0に設定する(ステップ5)。
【0201】
これらのルールにより、認証ステージ2でOOB通信が行われた際に、入力されたra、rbに関し、両方のデバイスA、Bが同じ値を持つことが確認される。
【0202】
(2−2−2−1:OOB機構の一例であるNFC)
NFC(Near Field Communication;近接場通信)デバイスは、異なるデータレート(106kbps、212kbps、424kbps)にそれぞれ対応するモードや、異なるオペレーション(有効/無効)に対応するモードをサポートしている。
【0203】
さらに、いくつかのNFCデバイスは、初期化(初期化/リーダモード)の機能を有しており、接続(タグ/ターゲットモード)を許可する機能を有している。一方、他のデバイスは、接続を受け付ける能力のみを有している。例えば、OOBーIO NFCデバイスは、他のNFCデバイスに対し、データを送信したり、データを受信したりする機能を有すると共に、BT通信するための機能を有している。
【0204】
OOB機構に適用される場合、NFCデバイスに対して、デバイスA、Bが次の組み合わせとなるような3つのシナリオが想定されている。
(1)デバイスA:OOB−IO NFCデバイス、かつ、デバイスB:OOB−O NFCデバイスである場合、(2)デバイスA:OOB−O NFCデバイス、かつ、デバイスB:OOB−IO NFCデバイスである場合、(3)デバイスA:OOB−IO NFCデバイス、かつ、デバイスB:OOB−IO NFCデバイスである場合である(但し、OOB−O:アウトプットのみ、OOB−IO:インプット/アウトプット対応)。つまり、OOB−O/OOB−O(tag/tag)のケースが存在せず、一方のデバイスがリーダと成り得ることが求められる。
【0205】
(2−2−3:認証ステージ1<パスキー入力モデル>(図28))
パスキー入力モデルに関し、認証ステージ1におけるシーケンスダイアグラムについて説明する。
【0206】
ユーザにより両方のデバイスに個々のパスキーが入力される代わりに、パスキー(ra,rb)が生成され、一方のデバイスに表示される。そして、ユーザは、表示されたパスキーを他方のデバイスに入力する(ステップ2)。この短い共有値(ra,rb)により、デバイス間の相互認証が実現される。ステップ3〜8は、kビットのパスキーに対し、k回繰り返される。例えば、6桁の数字に対するパスキー(999999=0xF423F)は、k=20である。
【0207】
ステップ3〜8において、各デバイスは、長い一時値(128ビット)を用いて、パスキーの各ビットを送る。さらに、一時値のハッシュ、パスキーのビット、及び他方のデバイスの公開鍵を送信する。
【0208】
次いで、各デバイスは、互いの証明書を確認すべく、パスキーが相互に開示されるまで返信する。与えられたパスキーのビットについて証明書を折り返す最初のデバイスは、そのプロセスの中でパスキーのビットを効果的に返信する。しかし、他のデバイスは、与えられたパスキーのビットと同じ値を示すビットの証明書を返信するか、或いは、パスキーのビットが更に返信されなかった場合に、この認証ステップが破棄される。
【0209】
この”漸次的な開示”は、中間者攻撃によりパスキーの情報が推測されないように1ビット以上の漏洩を避けるためのものである。パスキーの部分的な知識のみを有する中間者攻撃者は、この認証ステップが失敗する以前の不確かなパスキーの受信ビットしか推定できないことになる。ゆえに、0.000001の確率で成功する単純なBlute−force攻撃者のような中間者攻撃者に対して、最大で2ビットの分の推測困難性を加えることができる。また、長い一時値には、認証ステップが失敗した後でさえも、brute−force攻撃を困難にさせるための証明書のハッシュが含まれる。
【0210】
標準的な中間者攻撃はECDHを交換する両サイドで攻撃者の公開鍵を置き換えることから、中間者攻撃を避けるために、オリジナルのECDH鍵の交換に際してパスキー入力モデルのセキュリティを厳しくするために公開Diffie−Hellman値が含まれる。このステージの最後において、認証ステージ2で利用されるNaにNa20が設定され、NbにNb20が設定される。
【0211】
(2−3:フェーズ3<認証ステージ2>(図29を参照))
認証ステージ2では両方のデバイスが認証情報の交換を成功裏に完了したことが確かめられる。このステージは、上記の3つのモデルにおいて共通である。
【0212】
まず、各デバイスは、新たに認証値(Ea,Eb)を算出する。この認証値は、既に交換されたパラメータに基づいて算出される。また、この認証値は共有される(ステップ9)。次いで、初期化デバイスにより、対向する応答デバイスに認証値が送信される。次いで、送信された認証値は、応答デバイスにより確認される(ステップ10)。もし、この確認が失敗であれば、初期化デバイスがペアリングを認証しなかったことが示される。その場合、この認証ステップが破棄される。
【0213】
次いで、応答デバイスは、自身が算出した認証値を初期化デバイスに送信する。この認証値は、初期化デバイスにより確認される(ステップ11)。この確認が失敗であれば、応答デバイスがペアリングを認証しなかったことが示される。その場合、この認証ステップが破棄される。
【0214】
(2−4:フェース4:リンクキーの算出(図25(B)を参照))
両方のサイドでペアリングが認証されると、共有鍵(DHKey)等によりリンクキー(LK)が算出され、このリンクキーを用いて公にデータが交換されるようになる(ステップ12)。このとき利用される一時値は、リンクキーの新しさを示す。たとえ、長文のECDH値が両サイドで利用される場合であっても、このリンクキーは、ペアリングを管理するために利用される。
【0215】
リンクキーを算出する際に、両方のデバイスはパラメータを入力する。これらのパラメータは、両方のデバイスが同じリンクキーを算出したことを確かめるために、同じオーダー(順序)で入力される。また、パラメータには、「デバイスA´のパラメータはピコネットマスターのものであり、デバイスB´のパラメータはピコネットスレーブのものである」といったことを示す情報も含まれる。
【0216】
(2−5:フェーズ5:LMP認証、及び暗号化)
シンプルペアリングの最終フェーズは、暗号鍵を生成することである。これは、従来のペアリングの最終ステップと同じように実行される。
【0217】
[3:暗号化に用いる関数群]
(3−1:楕円曲線の定義)
SSP方式は、「FIPS(Federal Information Processing Standards Publication) P−192 curve」の楕円曲線を暗号化に利用している。この楕円曲線Eは、下記の式(1)に示すようにパラメータp、a、bを引数として値が決定されるものである。
【0218】
【数1】
【0219】
但し、パラメータbの値に対して一意に曲線が決定される。「NIST(National Institute of Standards and Technology) P−192」において、パラメータaは下記の式(2)により定義されている。
【0220】
【数2】
【0221】
一方、パラメータbは定義されおり、その生成の方法はSHA−1(シード値sに対し、b2s=−27(mod p)を利用する。)を用いて確かめられる。また、次のようなパラメータが与えられる。
【0222】
主なパラメータは、第1の係数(絶対値)p、オーダーr、基準となるx座標Gx、基準となるy座標Gyである。また、整数p、rは、10進法の形式で与えられる。そして、ビット列、フィールド要素はhex(16進数)の形式で与えられる。これらのパラメータは、例えば、次のような数値(#1〜#5)で与えられる。
【0223】
(#1) p=6277101735386680763835789423207666416083908700390324961279
(#2) r=6277101735386680763835789423176059013767194773182842284081
(#3) b=64210519 e59c80e7 0fa7e9ab 72243049 feb8deec c146b9b1
(#4) Gx=188da80e b03090f6 7cbf20eb 43a18800 f4ff0afd 82ff1012
(#5) Gy=07192b95 ffc8da78 631011ed 6b24cdd5 73f977a1 1e794811
【0224】
関数P192()は次のように定義されている。整数u(0<u<r)、曲線E上の点Vが与えられると、点Vのu倍であるuVをx座標値とする値P192(u,V)が算出される。秘密鍵は、1〜r/2の間になる。ここで、rは、楕円曲線上のアーベル群のオーダーである(例えば、1〜2192/2)。
【0225】
(3−2:暗号化関数の定義)
楕円曲線Diffie−Hellman鍵の算出に加え、数字比較モデル、OOBモデル、パスキー入力モデルの各プロトコルには、4つの暗号化関数が必要とされる。これらの関数は、後述する関数f1,g,f2,f3である。
【0226】
f1は、128ビットの証明書の値Ca、Cbを生成するために利用される。gは、認証値を算出するために利用される。f2は、リンクキー、及び、DHKeyや一時乱数値を用いて導出される他の鍵を算出するために利用される。f3は、認証ステージ2における認証値Ea、Ebを算出するために利用される。これらの関数の基本的な構成はSHAー256に基づいている。
【0227】
(3−2−1:SSP方式における証明書生成関数f1)
証明書は、関数f1により算出される。SSP方式の証明書用関数の定義は、SHA−256に基づくMAC関数(HMAC)を用いている。このHMACは128ビット鍵の場合に、HMAC−SHA−256Xと表記されるものである。SSP方式の関数f1には、次のような形式のパラメータ(U,V,X,Z)が入力される。
【0228】
Uは192ビット値である。Vは192ビット値である。Xは128ビット値である。Zは8ビット値である。
【0229】
Zは、数字比較モデル、及びOOBモデルの各プロトコルにおいて0である(即ち、8ビットの0)。パスキー入力モデルのプロトコルの中で、Zの最も重要なビットは1に設定され、そして、少なくとも重要なビットはパスキーの1ビット目に生成される。例えば、パスキーが”1”である場合、Z=0x81に設定され、パスキーが”0”である場合、Z=0x80に設定される。
【0230】
SSP方式の関数f1の出力は、下記の式(3)のようになる。
【0231】
【数3】
【0232】
関数f1の入力は、下表2に示すようにプロトコルに依存して異なる。
【0233】
ここで、PKaxは、デバイスAの公開鍵PKaに対するx座標値を示す。同様に、PKbxは、デバイスBの公開鍵PKbに対するx座標値を示す。Naiは、i番目の繰り返し処理における一時値を示す。繰り返し処理の各工程において、Naiの値は、あたらな128ビット数となる。同様に、raiは、8ビットに拡張されたパスキーの1ビット値(例えば、0x80、又は0x81)である。
【0234】
(3−2−2:SSP方式における数値認証関数g)
SSP方式の関数gは、次のように定義される。SSP方式の関数gの入力(U,V,X,Y)の形式は次の通りである。
【0235】
Uは192ビット値である。Vは192ビット値である。Xは128ビット値である。Yは128ビット値である。
【0236】
SSP方式の関数gの出力は、下記の式(4)のようになる。
【0237】
【数4】
【0238】
数値認証値は、32ビット整数g(PKax,PKbx,Na,Nb)の中で、6つの少なくとも重要なビットが取り出される。ここで、PKaxはデバイスAの公開鍵PKaに対するx座標値を示し、PKbxはデバイスBの公開鍵PKbに対するx座標値を示す。
【0239】
SHA−256の出力は、SHA−256の出力に対応する少なくとも重要な32ビットを取り出すことによって32ビットに切りつめられる。この値は、10進数形式の数値に変換される。数字比較モデルで利用されるチェックサムは、少なくとも重要な6桁である。比較結果(Compare Value)は、下記の式(5)のようになる。
【0240】
【数5】
【0241】
例えば、出力が0x 01 2e b7 2aであった場合、10進数形式の数値は19838762になる。そして、数字比較のためのチェックサムとして、838762が取り出される。
【0242】
(3−2−3:SSP方式における鍵導出関数f2)
SSP方式の鍵導出関数には、SHA−256に基づくMAC関数(HMAC)が用いられる。このHMACは、192ビット鍵Wに対してHMAC−SHA−256Wと表現される。SSP方式の関数f2に対する入力(W,N1,N2,KeyID,A1,A2)の形式は次のようになる。
【0243】
Wは192ビット値である。N1は128ビット値である。N2は128ビット値である。KeyIDは32ビット値である。A1は48ビット値である。A2は48ビット値である。
【0244】
文字列”btlk”は拡張ASCIIコードにより、次のようにKeyIDに対してマッピングされている。
【0245】
KeyID[0]=0110 1011 (lsb)
KeyID[1]=0110 1100
KeyID[2]=0111 0100
KeyID[3]=0110 0010
KeyID=0x62746c6b
【0246】
SSP方式の関数f2の出力は、下記の式(6)のようになる。
【0247】
【数6】
【0248】
関数f2の出力としては、HMAC−SHA−256の出力の中で、128の最も重要な(最左の)ビットが取り出される。また、リンクキーは、下記の式(7)により算出される。
【0249】
【数7】
【0250】
(3−2−4:SSP方式におけるチェックサム関数f3)
SSP方式のチェックサム関数f3の定義には、SHA−256に基づくMAC関数(HMAC)が用いられる。このHMACは、192ビット鍵Wに対してHMAC−SHA−256Wと表現される。SSP方式の関数f3の入力(W,N1,N2,R,IOcap,A1,A2)の形式は次の通りである。
【0251】
Wは192ビット値である。N1は128ビット値である。N2は128ビット値である。Rは128ビット値である。IOcapは16ビット値である。A1は48ビット値である。A2は48ビット値である。
【0252】
IOcapは、LMP OOB認証データとして最も重要なオクテット(8桁)、及びLMP入出力機能の可否を示す最小の重要度のオクテットで構成されるオクテットの組である。SSP方式の関数f3の出力は、下記の式(8)の通りである。
【0253】
【数8】
【0254】
関数f3の出力には、HMAC−SHA−256の出力の中で128の最も重要な(最左の)ビットが取り出される。認証値は、関数f3により算出される。関数f3の入力は、下表3のように、プロトコル毎に異なる。
【0255】
DHKeyは、デバイスAによりP192(SKa,PKb)として、そして、デバイスBによりP192(SKb,PKa)として、算出された共有された秘密のDiffe−Hellman鍵である。AデータはデバイスAの機能を示すデータであり、BデータはデバイスBの機能を示すデータである。パスキー入力モデルにおいて、データra、rbは6桁のパスキーの値であり、128ビットの整数値により表現される。例えば、raの6桁の値が131313であったならば、R=0x00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 f1となる。入力AはデバイスAのBDアドレスである。入力BはデバイスBのBDアドレスである。
【0256】
【表1】
【0257】
【表2】
【0258】
【表3】
【0259】
[補遺2:<WPS1.0hについて>]
上記の第2実施形態に係る技術は、以下で説明するWPS1.0h方式に対し、好適に適用することが可能である。そこで、WPS1.0h方式に係る認証方法について、以下で詳細に説明する。尚、ここで用いられる用語の意味、及び表現については、後段で示す表5〜表10を参照されたい。
【0260】
[WPS(Wi−Fi Protected Setup)について]
WPSは、Wi−Fi Allianceにより独立に構築された1つの規格である。また、WPSは、Wi−Fi CERTIFIED(WFC)の802.11デバイスをサポートするようにデザインされている。このデバイスの形態としては、コンシューマ向けの電化プロダクトや電話機等が含まれる。これらのWFCデバイスは、コンピュータ(PC)やアクセスポイント(AP)と同等の通信機能を有している。この通信機能は、家庭や小規模オフィス等に設置された802.11デバイスにて利用されているようなものである。
【0261】
これらのデバイスには、802.11b、802.11a、802.11gを用いて通信するマルチバンドデバイスと同様の拡張機能を有しているものもある。こうした拡張機能は、WFCプログラムのオプションとして提供される。このオプションは、802.11n規格のプレ標準プロダクトに関するものである。このプレ標準プロダクトは、2008年に予定している最終的な802.11nの標準プロダクトに認定される予定にものである。尚、Wi−Fi Allianceは、WPSに準拠した最初のプロダクトを2007年の1月に承認している。
【0262】
WPSは、コンシューマに対し、Wi−Fiネットワークの有効化する際に行うセキュリティ設定に関して、購入したWFCデバイスがより簡単に設定されるものであることを確信させるためのものである。また、WPSにより、既に構築されたネットワークに対して新たなWPSデバイスを追加する際にも、従来より遥かに容易に追加設定ができるようになるのである。
【0263】
尚、WPSは、オプション的な認証事項である。つまり、全てのプロダクトにその認証が与えられるわけではない。特に、SOHO市場における利用を想定しており、エンタープライズ環境における使用を目的にしたものではない。こうしたエンタープライズ環境では、分散して設置されたネットワークサーバ群がネットワークアクセスの制御用に設けられていたり、暗号化技術により厳重に情報が管理されていたりする。そこで、コンシューマは、購入するデバイスにWPS−WFCプロダクトの認定マークが存在するか否かを確認すればよい。このWPS認定マークは、プロダクト、パッケージ、ユーザドキュメントに表示されている。
【0264】
WPSは、典型的な家庭用ネットワークに適用される。その中で、デバイスは、アクセスポイント(AP)、又はルータを介して通信する。こうした通信環境では、”アドホック”ネットワークがサポートされていないことが多い。この”アドホック”ネットワークとは、各デバイスがAPから独立して直接的に他のデバイスと通信するネットワークである。
【0265】
典型的な通信環境では、ネットワーク上で、ネットワークネーム(SSID)、及びWPA2セキュリティキーがAP、及びWPSクライアントデバイスに設定される。WPSの標準化されたアプローチによると、典型的なWi−Fiユーザにより簡単にWi−Fiネットワークが設定可能になり、セキュリティが有効化されたネットワークが構築できるようになる。このとき、Wi−Fiユーザは、セキュリティやネットワークに関する基盤の技術、及び、その設定に含まれるプロセスについて理解していなくともよい。即ち、ユーザは、SSIDがネットワークの名前を参照することや、WPA2がセキュリティ機構を参照することを知る必要すらないのである。
【0266】
WPSはWPA2の個人向け技術を利用する。この技術は、レガシーデバイスとの互換性がある。WPA/WPA2 Personalに関してWFCが認定を与えるのである。WPAとWPA2はWi−Fi技術に関するセキュリティに関して最新のものである。ユーザは、レガシーデバイス(即ち、WPA/WPA2 Personalに関するWFCでないデバイス)を利用することが、WLANが弱点を有する状態にあるということを認識しておかなければならない。2003年9月以後に認定された全てのWFCプロダクトは、WPA又はWPA2のいずれかをサポートしている。つまり、2006年3月以降に認定されるプロダクトには、WPA2のサポートが要求されるのである。
【0267】
WPSで認定されたプロダクトでは、ユーザに2つの簡単な設定方法を提供している。個人識別数字(PIN)による設定方法、及びプッシュボタン認証設定(PBC)方法である。もちろん、WPSは、他の方法に対する拡張性も考慮してデザインされている。近接場通信(NFC)カードやUSBフラッシュデバイスを利用した認証方法についても、2007年の後半にテストプログラムに追加されることが予定されている。
【0268】
尚、ユーザは、レガシーデバイスが含まれるWiーFiネットワークにWPSーWFCデバイスを加えるかもしれない。このネットワークは、デバイスの設計者により提供されるマニュアルの手順に従ってユーザが以前に構築したものである。
【0269】
WPSーWFCプロダクトは、APにおいてPINによる認証設定、又はPBC設定の両方が可能なようにテストされてから認定される。クライアントデバイスでは、少なくとも、PINによる認証設定がテストされてから認定される。
【0270】
レジスタラ(Registrar)は、新しいクライアントをネットワークに登録するのに必要な証明書を発行する。このレジスタラは、AP又はクライアント等の様々なデバイスに設定できる。ユーザが様々な環境や場所にデバイスを加えることができるように、仕様書では、1つのネットワーク内に多重のレジスタラが含まれることをサポートしている。但し、レジスタラの機能は、APの管轄内に限定される。
【0271】
PIN設定に関し、PINは、ネットワークに接続しようとする個々のデバイスに対して与えられる。通常、ユーザがPINを認識できるように、デバイス上に固定ラベルやステッカーが設けられている。また、動的なPINが生成される場合、そのPINは、例えば、デバイスに設置されたTVスクリーンやモニターのようなディスプレイに表示される。PINは、他者による事故や悪意の企てによりネットワークに意図しないデバイスが加えられないように、ユーザがネットワークに加えようと考えるデバイスであるか否かを確かめるために利用される。
【0272】
まず、ユーザはPINをレジスタラに入力する。例えば、PINは、APのGUIを介して入力されるか、或いは、ネットワーク上の他のデバイスに設けられたオンスクリーンインターフェースを介して管理ページにアクセスすることにより入力される。
【0273】
PBC設定に関し、ユーザは、デバイスをネットワークに接続し、APとクライアントデバイスのボタンを押下することによりデータの暗号化を有効にする。このとき、ユーザは、APとクライアントのボタンを押下する間に、意図しないデバイスがとても簡単にネットワークに接続することが可能な期間があることを意識しておく必要がある。
【0274】
(設定ステップの比較)
表4は、PINによる認証設定とPBCによる認証設定との間の操作ステップの比較を示した図表である。また、参考までに、WPS以前の方法によるWLAN上の設定、及びセキュリティの有効化に要求されるステップも併せて掲載している。これによると、WPS以前の方法は多数のステップを有する。
【0275】
WPS以前の方法において、ユーザは、デバイスを電源に接続し、有線ネットワークに接続した上でAPを有効化する(ステップ1)。次いで、ユーザは、有線ネットワークに接続されたコンピュータからウェブブラウザを立ち上げ、管理ページにログインしてAPにアクセスする(ステップ2)。次いで、ユーザは、ネットワークネーム(SSID)を選択し、それをAPに入力する(ステップ3)。
【0276】
次いで、ユーザは、セキュリティ設定ページに導かれれる。そこで、ユーザは、利用するセキュリティタイプを選択し、セキュリティ設定を有効にする(ステップ4)。セキュリティ設定が有効化された後で、ユーザは、APがセキュリティキーを生成するために利用されるパスフレーズの入力を促される。そこで、ユーザは、パスフレーズをAPに設定し、セキュリティキーを設定する。(ステップ5)。ユーザは、コントロールパネルを用いてネットワークに登録されるクライアントデバイスを設定する。このとき、ユーザは、デバイスの無線インターフェースを有効化し、WLAN接続を有効化する(ステップ6)。
【0277】
次いで、クライアントデバイスは、ユーザに対し、周囲に発見される全てのWLANのネットワークネーム(SSID)を提示する。そこで、ユーザは、(ステップ3で選択した)適切なネットワークネームを選択し、ネットワークに接続する(ステップ7)。次いで、ユーザは、ステップ5で設定したパスフレーズを入力するように促される。そこで、ユーザは、クライアントデバイスにパスフレーズを入力する(ステップ8)。その後、クライアント、及びAPは、セキュリティ証明書を交換し、新たなデバイスがセキュアにWLANに接続される。
【0278】
多くの場合、WPSを適用することにより、上記のステップ2〜5の手順が省略される。加えて、ユーザに要求されるいくつかの作業(例えば、パスフレーズの設定等)が簡単化される。
【0279】
WPSにおいて、ユーザは、単にAPとクライアントデバイスを有効化する。そして、APの生成手段により提供されたPINを入力するか(PINによる認証設定の場合)、或いは、セキュリティの設定を開始するために、APとクライアントデバイスのボタンを押下する(PBCによる認証設定の場合)。このとき、ユーザには、パスフレーズの設定が要求されない。つまり、セキュリティコードが自動的に有効化されて通信されるのである。
【0280】
SSIDとWPA2セキュリティキーが適切に設定されるのを保証するのに加え、WPSは、空間に伝播する情報セキュリティを確保するための技術を提供する。つまり、WPSは、ネットワークにアクセスするために不正なPINを入力するユーザを排除する。また、WPSには、認証に用いる証明書を一時的な証明書にすることで、その時点で転送されたものでないときに設定プロセスをキャンセルするタイムアウト機能も提供する。
【0281】
また、WPSでは、ユーザが生成したパスフレーズを消去することにより、セキュリティを向上させる。WPS以前、ユーザは、AP上でパスフレーズを生成し、入力することを要求されていた。彼らは、任意の新たなデバイスをネットワークに追加する際に、ネットワークをセキュアにするためのパスフレーズを再利用していた。さらに、そのパスフレーズの多くは、短く、子供やペットの名前のような覚えやすく、外部の人に容易に推測されるような分かり易いパスフレーズであった。
【0282】
(WPSのオプション)
WPSのオプションとして、NFCやUSBを利用した認証方法がある。これらの方法は、PBCによる認証方法やPINによる方法のようにユーザの手入力を要求せずにデバイスをネットワークに参加させるものである。
【0283】
WPSのNFCによる設定方法を適用すると、新たなデバイスをAP又はレジスタラ機能を有する他のデバイスにタッチすることで簡単にセキュアなネットワークが有効化される。WPSのUSBによる設定方法では、証明書をUSBフラッシュドライブ(UFD)を介して転送する。これらの方法は、意図しないデバイスがネットワークに加入することに対して強固な防御効果を与える。
【0284】
しかしながら、USBによる方法やNFCによる方法は、2007年の第1四半期後半でWFSに対するWFCプログラムに予定されている。他の方法についても、後日、認定プログラムに加えられるかもしれない。WPSは、こうした方法についても、他の技術に対する拡張性を考慮してデザインされている。
【0285】
(WPSの機能について)
詳細な設定手段とWPSデバイスのセキュリティとは、従来のホームセキュリティに関する馴染み深い比喩”lock and key”に対比される。WPSの仕様は、新たなデバイスが探索プロトコルに基づいて構築されたWi−Fiネットワークに加入される際に、シンプルで矛盾しない手順を提供している。また、このプロトコルは、ベンダー間で整合している。
【0286】
この手順では、ネットワークに登録されるデバイスの証明書を自動的に発行するためにレジスタラが利用される。WPSーWFCデバイスのAPにはレジスタラ機能が搭載されている。さらに、レジスタラは、WLAN上の任意のデバイスに駐在することができる。AP上に駐在するレジスタラは、内部のレジスタラとして参照される。ネットワーク上の他のデバイスに駐在するレジスタラは、外部のレジスタラとして参照される。WPSネットワークでは、1つのWLAN上における多重のレジスタラがサポートされている。
【0287】
ユーザがWLAN上に新たなデバイスを追加設定するプロセスは、鍵を錠に挿入する工程と対比される次のようなアクションによって開始される。このプロセスでは、設定ウィザードが起動され、PINが入力されるか、又はPBCボタンが押下される。この時点で、アクセスが検出される。
【0288】
WPSデバイスは、レジスタラとの間で情報の交換を開始する。次いで、レジスタラは、ネットワーク証明書を発行する。ネットワーク証明書は、クライアントがWLANに加入するのを認証するためのネットワークネーム、及びセキュリティキーを含むものである。錠と鍵の比喩において、このネットワーク証明書の交換は、アクセスが受け入れられるように錠の中でキーを回す動作に似ている。その後、新たなデバイスは、ネットワークを介し、侵入者による非認証アクセスに対してセキュアにデータを通信することができる。
【0289】
新たにWPS−WFCデバイスは、有効なAPの範囲内に入ったときに存在が検出される。その後、WPS−WFCデバイスは、レジスタラに通信し、ユーザに証明書の発行を認証する行為を促す。
【0290】
WPSネットワークでは、各デバイスを認証する際にデータが暗号化される。つまり、情報とネットワーク証明書は、拡張認証プロトコル(EAP)を利用して空間内でセキュアに交換される。認証プロトコルにはWPA2が使われる。デバイスにより相互に認証が実行され、クライアントがネットワーク上で許容された場合に接続が行われる。レジスタラは、セキュリティを有効にするためにネットワークネーム(SSID)、及びWPA2の”Pre−Shared Key(PSK)”を通知する。ランダムなPSKの使用は、予測可能なパスフレーズの使用を避けることでセキュリティが向上する。
【0291】
WPS以前の設定方法では、ユーザに対し、APがPSKをサポートするように手動で設定すること、及び、SSIDとPSKを手動で入力することが要求されていた。SSIDやPSKの入力は、APとクライアントの両方で行われる。このアプローチは、ユーザによるエラーの原因の大部分を占めていた。ユーザエラーとしては、ミスタイピング、及びPSKとSSIDの混同である。ところが、WPSを用いた場合、証明書の交換プロセスは、初期の設定処理が完了した後において、ユーザによる僅かな介在を要求するのみである。例えば、PINの入力、又はPBCボタンの押下だけである。このとき、ネットワークネームとPSKは自動的に発行されているのである。
【0292】
次に、証明書の交換、及びデバイスの追加に関するダイアグラムを示す。つまり、WPSデバイスにより、どのようにしてネットワークが設定されるかについて説明する。
【0293】
(証明書の交換について)
WPSでは、レジスタラデバイスがネットワーク上の他のデバイスに対して識別情報を発行するように促し、さらに、証明書を発行する。このとき、各種の情報は、Wi−Fiネットワークを介して交換される。1つのシナリオとして、レジスタラがAPに設定される。証明書の交換は、クライアント、及びAPに設けられたボタンを押下することで行われてもよい(PBC方式)。また、クライアントデバイスを用いたPINの入力により行われてもよい(PIN方式)。例えば、PIN入力は、PIN方式用のGUIにユーザがPINを入力する形式で行われる。
【0294】
(デバイスの追加について)
新たなクライアントが既に存在するネットワークに加えられるものとする。このとき、PIN又はプッシュボタンにより設定されてもよい。例えば、既に存在するネットワークに新たなAPデバイスが加えられる場合にも、PIN又はプッシュボタンによる設定が可能である。PIN方式、及びPCB方式のいずれの方法が利用されるかは、どちらの設定方法がクライアントデバイスによりサポートされるかに依存して選択される。
【0295】
(WPSにおける設定オプション)
PBC方式やPIN方式の設定オプションは、WPSーWFCプロダクトに対して適用される。つまり、NFCやUSBによる設定方法は、オプションであり、Wi−Fi Allianceによりテスト及び認定されているものではない。しかしながら、製造者は、オプション的にこれらを提供することができる。NFCやUSBによる設定方法は、2007年のWPSに対するWFAの認定テストプログラムに含まれることが予定されている。
【0296】
(NFC設定の場合)
NFC設定は、タッチベースの相互作用を利用する。NFC設定では、AP又は他のレジスタラデバイスとクライアントとの間でNFCを利用してネットワーク証明書の交換を有効にする。証明書の交換は、NFCが有効なクライアントデバイスをAP(又は他のNFCが有効なレジスタラデバイス)上のNFCターゲットマークにタッチした時点で開始されるか、或いは、クライアントをその近接領域内に持っていくことで開始される。その距離は、およそ10cmである。
【0297】
レジスタラは、クライアント識別用の証明書をNFCを介して読み出す。NFCデバイスは、デバイスに埋め込まれている。そして、新たなデバイスをネットワークに接続するために、ネットワークSSIDとPSKセキュリティコードをクライアントに返信する。
【0298】
(USB設定の場合)
USB設定において、USBフラッシュドライブをレジスタラデバイス(この場合、AP)に接続することによって証明書が交換される。この証明書は、フラッシュドライブ上にコピーされる。一方、そのフラッシュドライブは、新たなデバイスに挿入されて証明書の交換が完了する。
【0299】
(WPSのまとめ)
WPSにより、ユーザに設定アプローチの統一的な枠組みが提供される。この枠組みには、PIN入力やプッシュボタンのシーケンスが含まれる。このシーケンスは、新たなWFCデバイスの設定をより容易にし、家庭又は小規模オフィスの環境においてWFCネットワークのセキュリティを簡単に有効にすることができる。
【0300】
WPSは、WFCデバイスに対するユーザのアウトオブボックス操作を改善するようにデザインされており、ベンダーの技術サポートに対する依存性を低減し、小売店によるプロダクト回収の数を低減すると共に、ユーザの技術に対する満足度を増大させるものである。特に、WPSは、ユーザにPSKやSSIDのようなコンセプトを理解させるような要求を排除し、誤入力が避けられないPSKの手入力プロセスを排除することで、ネットワーク設定をより容易にする。
【0301】
WPSは、802.11a,b,gのWFCデバイスがサポートする2.4GHzや5GHz周波数帯の両方をサポートできるように拡張可能にデザインされている。認定自体はオプション的な位置付けであるが、家庭又は小規模オフィスに存在するマルチバンド、マルチモードをサポートするデバイスに適用されるであろう。また、このオプションは、2007年の802.11nのプレスタンダードプロダクトに対するWFCプログラムへの適用が予定されている。また、2008年に予定されている最終的な802.11n標準で認定されるプロダクトに対しても同様である。
【0302】
【表4】
【0303】
【表5】
【0304】
【表6】
【0305】
【表7】
【0306】
【表8】
【0307】
【表9】
【0308】
【表10】
【0309】
以上、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明は係る例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。
【0310】
上記の実施形態の説明においては、第1通信方式としてNFC通信を想定していたが、必ずしもこれに限定されるものではなく、例えば、赤外線通信、或いは、USBメモリによる設定情報の交換等も含まれる。
【0311】
上記の実施形態の説明においては、主に、PCや携帯電話を例に挙げて説明したが、上記の実施形態を適用できる範囲は、これに限定されない。例えば、テレビジョン等の映像機器、カーナビゲーション装置、オーディオ装置、決済端末、プリンタ等の電子機器、或いは、各種の情報家電等にも適用可能である。また、ICタグ等を備えることが可能なデバイス等に対しても適用される。このように、上記の実施形態に係る技術は、多種多様な電子機器に適用することが可能である。
【図面の簡単な説明】
【0312】
【図1】本発明の一実施形態に係る通信システムの構成例を示す説明図である。
【図2】本発明の第1実施形態に係る通信装置の機能構成を示す説明図である。
【図3】同実施形態に係る認証処理方法の流れを示す説明図である。
【図4】本発明の一実施形態に係るレコードの構成例を示す説明図である。
【図5】本発明の一実施形態に係るレコードの構成例を示す説明図である。
【図6】本発明の第1実施形態に係るレコードの構成例を示す説明図である。
【図7】同実施形態に係る認証処理方法の流れを示す説明図である。
【図8】同実施形態に係る認証処理方法の流れを示す説明図である。
【図9】同実施形態に係る認証処理方法の一例を示す説明図である。
【図10】同実施形態に係る認証処理方法の一例を示す説明図である。
【図11】同実施形態に係る認証処理方法の一例を示す説明図である。
【図12】同実施形態に係るネットワーク形成方法の一例を示す説明図である。
【図13】同実施形態に係るネットワーク形成方法の一例を示す説明図である。
【図14】同実施形態に係るネットワーク形成方法の一例を示す説明図である。
【図15】同実施形態に係るネットワーク形成方法の一例を示す説明図である。
【図16】本発明の第2実施形態に係る通信装置の機能構成を示す説明図である。
【図17】同実施形態に係るレコードの構成例を示す説明図である。
【図18】同実施形態に係る認証処理方法の流れを示す説明図である。
【図19】同実施形態に係る認証処理方法の流れを示す説明図である。
【図20】同実施形態に係るネットワーク形成方法の一例を示す説明図である。
【図21】同実施形態に係るネットワーク形成方法の一例を示す説明図である。
【図22】同実施形態に係るネットワーク形成方法の一例を示す説明図である。
【図23】本発明の一実施形態に係る通信装置の装置構成例を示す説明図である。
【図24】本発明の一実施形態に係る通信装置の装置構成例を示す説明図である。
【図25】BTデバイスにおける認証処理方法の流れを示す説明図である。
【図26】BTデバイスにおける認証処理方法の流れを示す説明図である。
【図27】BTデバイスにおける認証処理方法の流れを示す説明図である。
【図28】BTデバイスにおける認証処理方法の流れを示す説明図である。
【図29】BTデバイスにおける認証処理方法の流れを示す説明図である。
【符号の説明】
【0313】
10 通信システム
100、200 通信装置
102、106 アンテナ
104 近接通信部
108、158 近距離通信部
110、160 制御部
112 RAM
114 ROM
116 フラッシュメモリ
118 入力部
120 表示部
【特許請求の範囲】
【請求項1】
通信可能距離が互いに異なる第1及び第2の通信部により通信する通信装置であって、
比較的通信可能距離が短い第1の通信部を介して、接続毎に生成される乱数と、当該乱数により算出される証明書と、前記第2の通信部の認証方式を示す認証方式情報と、が含まれる通信パケットを受信する受信部と、
前記通信パケットに含まれる認証方式情報に基づいて当該通信パケットの送信元が対応する認証方式を判別する方式判別部と、
を備え、
前記方式判別部による判別結果に応じて前記通信パケットに含まれる乱数を前記第2の通信部の認証処理に用いる識別情報として利用することを特徴とする、通信装置。
【請求項2】
前記認証方式情報は、前記第2の通信部の認証方式が公開鍵方式に対応するか否かを示す情報であり、
前記方式判別部は、前記通信パケットに含まれる認証方式情報に基づいて当該通信パケットの送信元が公開鍵方式に対応するか否かを判別し、
前記方式判別部により前記通信パケットの送信元が公開鍵方式に非対応であると判別された場合に、自装置の識別情報として前記通信パケットに含まれる情報を返信することを特徴とする、請求項1に記載の通信装置。
【請求項3】
前記通信パケットには、前記送信元を識別するための識別情報と、当該識別情報に有効期限が設定されているか否かを示す期限情報がさらに含まれており、
前記期限情報が有効期限の設定有りを示す場合に、前記有効期限が経過した後で、前記通信パケットに含まれる設定情報に基づいて生成された情報を全て破棄することを特徴とする、請求項2に記載の通信装置。
【請求項4】
所定の確認情報が表示される表示部と、
前記確認情報に対する承認を示す情報を入力するための入力部と、
をさらに備え、
前記通信パケットに含まれる識別情報を有効にするか否かの承認要求が前記表示部に表示され、前記入力部により承認を示す情報が入力された場合に、当該識別情報が有効化されることを特徴とする、請求項3に記載の通信装置。
【請求項5】
所定の確認情報が表示される表示部と、
前記確認情報に対する承認を示す情報を入力するための入力部と、
をさらに備え、
前記通信パケットに含まれる情報を返信するか否かの承認要求が前記表示部に表示され、前記入力部により承認を示す情報が入力された場合に、当該識別情報に基づいて前記第2の通信部による通信が開始されることを特徴とする、請求項1に記載の通信装置。
【請求項6】
前記通信パケットには、前記受信パケットの送信元を特定するためのアドレス情報がさらに含まれており、
前記第2の通信部は、前記アドレス情報で特定される前記受信パケットの送信元との間のみで通信することを特徴とする、請求項1に記載の通信装置。
【請求項7】
前記通信パケットには、前記第2の通信方式により形成可能なネットワーク構成を示す構成情報がさらに含まれており、
所定の属性の中から、前記構成情報に基づいてネットワーク内における自装置の属性が決定されることを特徴とする、請求項1に記載の通信装置。
【請求項8】
通信可能距離が互いに異なる第1及び第2の通信部を有する通信装置による通信方法であって、
比較的通信可能距離が短い第1の通信部を介して、接続毎に生成される乱数と、当該乱数により算出される証明書と、前記第2の通信部の認証方式を示す認証方式情報と、が含まれる通信パケットが受信される受信ステップと、
前記通信パケットに含まれる認証方式情報に基づいて当該通信パケットの送信元が対応する認証方式が判別される方式判別ステップと、
前記方式判別ステップにおける判別結果に応じて前記通信パケットに含まれる乱数を識別情報として利用することで前記第2の通信部の認証処理がされる認証ステップと、
を含むことを特徴とする、通信方法。
【請求項1】
通信可能距離が互いに異なる第1及び第2の通信部により通信する通信装置であって、
比較的通信可能距離が短い第1の通信部を介して、接続毎に生成される乱数と、当該乱数により算出される証明書と、前記第2の通信部の認証方式を示す認証方式情報と、が含まれる通信パケットを受信する受信部と、
前記通信パケットに含まれる認証方式情報に基づいて当該通信パケットの送信元が対応する認証方式を判別する方式判別部と、
を備え、
前記方式判別部による判別結果に応じて前記通信パケットに含まれる乱数を前記第2の通信部の認証処理に用いる識別情報として利用することを特徴とする、通信装置。
【請求項2】
前記認証方式情報は、前記第2の通信部の認証方式が公開鍵方式に対応するか否かを示す情報であり、
前記方式判別部は、前記通信パケットに含まれる認証方式情報に基づいて当該通信パケットの送信元が公開鍵方式に対応するか否かを判別し、
前記方式判別部により前記通信パケットの送信元が公開鍵方式に非対応であると判別された場合に、自装置の識別情報として前記通信パケットに含まれる情報を返信することを特徴とする、請求項1に記載の通信装置。
【請求項3】
前記通信パケットには、前記送信元を識別するための識別情報と、当該識別情報に有効期限が設定されているか否かを示す期限情報がさらに含まれており、
前記期限情報が有効期限の設定有りを示す場合に、前記有効期限が経過した後で、前記通信パケットに含まれる設定情報に基づいて生成された情報を全て破棄することを特徴とする、請求項2に記載の通信装置。
【請求項4】
所定の確認情報が表示される表示部と、
前記確認情報に対する承認を示す情報を入力するための入力部と、
をさらに備え、
前記通信パケットに含まれる識別情報を有効にするか否かの承認要求が前記表示部に表示され、前記入力部により承認を示す情報が入力された場合に、当該識別情報が有効化されることを特徴とする、請求項3に記載の通信装置。
【請求項5】
所定の確認情報が表示される表示部と、
前記確認情報に対する承認を示す情報を入力するための入力部と、
をさらに備え、
前記通信パケットに含まれる情報を返信するか否かの承認要求が前記表示部に表示され、前記入力部により承認を示す情報が入力された場合に、当該識別情報に基づいて前記第2の通信部による通信が開始されることを特徴とする、請求項1に記載の通信装置。
【請求項6】
前記通信パケットには、前記受信パケットの送信元を特定するためのアドレス情報がさらに含まれており、
前記第2の通信部は、前記アドレス情報で特定される前記受信パケットの送信元との間のみで通信することを特徴とする、請求項1に記載の通信装置。
【請求項7】
前記通信パケットには、前記第2の通信方式により形成可能なネットワーク構成を示す構成情報がさらに含まれており、
所定の属性の中から、前記構成情報に基づいてネットワーク内における自装置の属性が決定されることを特徴とする、請求項1に記載の通信装置。
【請求項8】
通信可能距離が互いに異なる第1及び第2の通信部を有する通信装置による通信方法であって、
比較的通信可能距離が短い第1の通信部を介して、接続毎に生成される乱数と、当該乱数により算出される証明書と、前記第2の通信部の認証方式を示す認証方式情報と、が含まれる通信パケットが受信される受信ステップと、
前記通信パケットに含まれる認証方式情報に基づいて当該通信パケットの送信元が対応する認証方式が判別される方式判別ステップと、
前記方式判別ステップにおける判別結果に応じて前記通信パケットに含まれる乱数を識別情報として利用することで前記第2の通信部の認証処理がされる認証ステップと、
を含むことを特徴とする、通信方法。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】
【図8】
【図9】
【図10】
【図11】
【図12】
【図13】
【図14】
【図15】
【図16】
【図17】
【図18】
【図19】
【図20】
【図21】
【図22】
【図23】
【図24】
【図25】
【図26】
【図27】
【図28】
【図29】
【公開番号】特開2009−212732(P2009−212732A)
【公開日】平成21年9月17日(2009.9.17)
【国際特許分類】
【出願番号】特願2008−52732(P2008−52732)
【出願日】平成20年3月3日(2008.3.3)
【出願人】(000002185)ソニー株式会社 (34,172)
【Fターム(参考)】
【公開日】平成21年9月17日(2009.9.17)
【国際特許分類】
【出願日】平成20年3月3日(2008.3.3)
【出願人】(000002185)ソニー株式会社 (34,172)
【Fターム(参考)】
[ Back to top ]