JP2009212732A5 - - Google Patents

Description

通信装置、及び通信方法

本発明は、通信装置、及び通信方法に関する。

近年、多くの電子機器が無線通信機能を有するようになってきた。そして、それに応じて、様々な無線通信規格が制定されている。個人向け無線技術の代表例として、例えば、無線ＬＡＮ（以下、ＷＬＡＮ）やＢｌｕｅｔｏｏｔｈ（登録商標）（以下、ＢＴ）が挙げられる。これらの無線技術は、パーソナルコンピュータ（以下ＰＣ）、携帯電話、電子手帳（以下、ＰＤＡ）等の多機能電化製品を中心に様々な機器に搭載されている。最近では、デジタルカメラやプリンタ等の小型組み込み機器においても、こうした無線技術が利用されるようになってきている。以下、無線技術を搭載した機器のことを無線デバイスと呼ぶ。

これらの無線デバイスが広く普及し、多くの場面で使用されることでユーザの利便性が
向上した。その一方で、ネットワークを介して無線デバイスへ侵入される被害や、クレジットカード情報やパスワード等の個人情報が流出する被害等が報告されている。こうした被害が社会問題化しており、無線デバイスにおけるセキュリティの強化が強く望まれている。

ＢＴの場合、現状、最大１６バイトの鍵情報（パスキー）を用いた認証技術が採用されており、さらに、伝送路の暗号化技術がセキュリティ機能に盛り込まれている。ところが、実際、４文字程度のパスキーが使われている場合が多い。このような運用方法では、パスワードの組み合わせ数が少ないため、不正な認証が行われる危険性が高い。一方、ＷＬＡＮの場合、当初ＷＥＰと呼ばれる暗号化方式が実装されていた。しかし、この暗号方式が比較的短時間で解読できることが公表され、その後、改善策としてＷＥＰ−ＴＫＩＰ方式、ＷＰＡ、ＷＰＡ２等の強固な暗号化技術が規格に盛り込まれることになった。

セキュリティ機能について多数の方式が提供されている。その一方で、こうした技術に関する専門知識がない一般のユーザにとっては、接続機器に応じた適切な暗号化方式を選択したり、選択した方式に応じた適切な設定をすること自体が非常に大きな負担である。多くの場合、ユーザは、メーカーの技術サポート窓口に相談するか、或いは、無線デバイスの設定自体を諦めてしまう。その結果、セキュリティが十分に機能していない無線デバイスが利用されていたり、無線デバイスが家電製品等に普及しにくい土壌が作られている。

上記のような現状に鑑み、セキュリティの強化に関する技術、及びネットワーク設定を簡単化する技術の研究開発が鋭意進められている。こうした技術に関し、例えば、下記の特許文献１には、ＷＬＡＮのセットアップ方式に関する技術が開示されている。同文献には、電波強度を弱めて電波到達範囲を絞り込むことで、アクセスポイントとＷＬＡＮ端末間の通信範囲を狭め、セキュリティを向上させる技術が開示されている。さらに、同文献には、アクセスポイント及びＷＬＡＮ端末上に設けられたボタンが同時に押下されることで、ネットワークのセットアップが完了できる接続手段が開示されている。また、ＢＴに関して、下記の特許文献２には、接続機器の双方に設けられたボタンを押下するだけで接続設定が完了する方法に関する技術が開示されている。これらの技術を用いることで、セキュリティの高いネットワーク設定が簡単操作で実現される。

特開２００４−２１５２３２号公報 特許第３９２８４８９号公報

上記の各文献に加え、各種の無線技術に関する規格団体は、セットアップ手順の簡単化とセキュリティの強化とを両立させるための規格を発表している。ＢＴの規格団体であるＢｌｕｅｔｏｏｔｈ ＳＩＧは、Ｃｏｒｅ規格のバージョン２．１において、Ｓｅｃｕｒｅｄ Ｓｉｍｐｌｅ Ｐａｉｒｉｎｇ（以下、ＳＳＰ）と呼ばれる技術を必須実装項目として挙げている。さらに、ＷＬＡＮの認証団体であるＷｉＦｉ Ａｌｌｉａｎｃｅは、ＷｉＦｉ Ｐｒｏｔｅｃｔｅｄ Ｓｅｔｕｐ（以下、ＷＰＳ）と呼ばれる技術を発表している。

これらの規格は、設定情報を暗号化して送受信する際に公開鍵暗号技術を利用する方式を採用している。そのため、従来よりもセキュリティを強化できると共に、ユーザによるセットアップ作業の負担を低減させることができる。この方式は、公開鍵によって暗号化された伝送路上で設定情報が安全に交換されるように設計されている。そのため、これら規格に対応した製品が早急に市場に普及することが期待されている。

しかしながら、公開鍵方式の演算ロジックは、秘密鍵方式の演算ロジックと比較して計算量が多く、専用に設計されたハードウェアロジック回路が必要とされる。そのため、公開鍵方式を採用した機器における回路規模の増大、及びコストアップが懸念されている。２００６年の時点で、従来規格の製品出荷台数は５億１５００万台と言われ、非常に巨大な市場が既に形成されている。つまり、廉価な製品の提供が可能な大量供給体制が整備されてしまっている。そのため、安全性、及び利便性の面で優れている上記のような新規格に対応したデバイスが登場しても、旧規格のデバイス生産が継続され、新旧両規格の製品が市場に並存することが予想される。

こうした状況において、新規格による簡単でセキュアなネットワーク設定が可能な無線デバイスをユーザが保持していても、その接続先機器が旧規格にしか対応していないことで、ユーザは、従来の煩雑で低セキュリティのネットワーク設定を行う必要に迫られてしまう。また、ユーザには、新規格のデバイスと旧規格のデバイスとで異なる設定方法を使い分けることが要求される。そのため、却ってネットワークの設定方法が煩雑になり、ユーザの負担を増大させてしまうのである。

そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、公開鍵方式を利用する認証方式、及び非公開鍵方式による認証方式に対応し、いずれの認証方式のデバイスに接続される場合でも、ユーザに掛かる設定の負担を低減させることが可能な、新規かつ改良された通信装置、及び通信方法を提供することにある。

上記課題を解決するために、本発明のある観点によれば、第１及び第２の通信部により通信する次のような通信装置が提供される。当該通信装置は、第１の通信部を介して、他の通信装置との接続毎に生成される乱数と、当該乱数により算出される証明書と、前記第２の通信部での認証方式を示す認証方式情報と、が含まれる通信データを受信する受信部と、前記通信データに含まれる認証方式情報に基づいて当該通信データの送信元が対応する認証方式を判別する方式判別部とを備え、前記方式判別部による判別結果に応じて前記通信データに含まれる乱数を前記第２の通信部での認証処理に用いる識別情報として利用するものである。

また、前記認証方式情報は、前記第２の通信部での認証方式が公開鍵方式に対応するか否かを示す情報であってもよく、前記方式判別部は、前記通信データに含まれる認証方式情報に基づいて当該通信データの送信元が公開鍵方式に対応するか否かを判別するように構成されていてもよい。この場合、上記の通信装置は、前記方式判別部により前記通信データの送信元が公開鍵方式に非対応であると判別された場合に、自装置の識別情報として前記通信データに含まれる情報を返信するように構成される。

上記の通信装置は、受信部により、第１の通信部を介して、
他の通信装置との接続毎に生成される乱数と、当該乱数により算出される証明書と、第２の通信部での認証方式が公開鍵方式に対応するか否かを示す認証方式情報と、が含まれる通信データを受信する。そのため、上記の通信装置は、証明書、及び乱数を用いて当該通信データに含まれる情報の送信元が正当であることを確かめることができる。このとき、乱数が他の通信装置との接続毎に生成されているため、証明書の有効期限が他の通信装置との接続毎に設定される。その結果、通信データに含まれる情報を他人が傍受し、後ほど利用しようとした際に、その不正行為を検知できる。

また、上記の通信装置は、方式判別部により、通信データに含まれる認証方式情報に基づいて当該通信データの送信元が公開鍵方式に対応するか否かを判別する。さらに、方式判別部により通信データの送信元が公開鍵方式に非対応であると判別された場合に、上記の通信装置は自装置の識別情報として通信データに含まれる情報を返信する。通信データの送信元が公開鍵方式に対応していれば、公開鍵方式に基づいてセキュアに認証情報を送ることができる。しかし、公開鍵方式に非対応の場合は、セキュリティを確保できない。そのため、上記の通信装置は、接続毎に生成される乱数（一時値）を用いることでセキュリティを確保している。このような構成を適用することで、通信相手が公開鍵方式に対応するか、非対応かに関わらず、セキュリティを確保しながら他の通信装置との接続設定をすることができるようになる。

また、前記通信データには、前記送信元を識別するための識別情報と、当該識別情報に有効期限が設定されているか否かを示す期限情報がさらに含まれていてもよい。その場合、上記の通信装置は、前記期限情報が有効期限の設定有りを示す場合に、前記有効期限が経過した後で、前記通信データに含まれる設定情報に基づいて生成された情報を全て破棄するように構成されていてもよい。このような構成にすることで、識別情報、及びそれから派生的に生成された全ての情報に有効期限が設定され、よりセキュリティを向上させることができる。

また、上記の通信装置は、所定の確認情報が表示する表示部と、前記確認情報に対する承認を示す情報を入力するための入力部と、をさらに備えていてもよい。この場合において、前記通信データに含まれる識別情報を有効にすることの承認要求を前記表示部に表示し、前記入力部により承認を示す情報が入力された場合に、当該識別情報を有効化するように構成することができる。その結果、ユーザによる承認工程を踏む分だけ、セキュリティを向上させることができる。

また、前記通信データに含まれる情報を返信することの承認要求を前記表示部に表示し、前記入力部により承認を示す情報が入力された場合に、当該識別情報に基づいて前記第２の通信部による通信が開始されるように構成することもできる。この場合にも、ユーザによる承認工程を踏む分だけ、セキュリティを向上させることができる。

また、前記通信データには、受信データの送信元を特定するためのアドレス情報がさらに含まれている。そのため、前記第２の通信部は、前記アドレス情報で特定される前記受信データの送信元との間のみで通信するように構成することができる。このように、通信相手を制限することで、セキュリティを向上させることができる。

また、前記通信データには、前記第２の通信部により形成可能なネットワーク構成を示す構成情報が含まれる場合がある。その場合、所定の属性の中から、前記構成情報に基づいてネットワーク内における自装置の属性を決定するように構成することができる。その結果、ネットワーク構成をユーザが意識する必要がなく、専門知識のない一般ユーザであっても、容易にネットワーク設定ができるようになる。

また、上記課題を解決するために、本発明の別の観点によれば、第１及び第２の通信部を有する通信装置による次のような通信方法が提供される。
当該通信方法は、第１の通信部を介して、他の通信装置との接続毎に生成される乱数と、当該乱数により算出される証明書と、前記第２の通信部の認証方式を示す認証方式情報と、が含まれる通信データが受信される受信ステップと、前記通信データに含まれる認証方式情報に基づいて当該通信データの送信元が対応している認証方式を判別する方式判別ステップと、前記方式判別ステップにおける判別結果に応じて前記通信データに含まれる乱数を識別情報として利用することで前記第２の通信部での認証処理がされる認証ステップとを含むものである。

また、第１及び第２の通信部を有する通信装置による次のような通信方法が提供されてもよい。この通信方法は、第１の通信部を介して、他の通信装置との接続毎に生成される乱数と、当該乱数により算出される証明書と、前記第２の通信部での認証方式が公開鍵方式に対応するか否かを示す認証方式情報と、が含まれる通信データが受信される受信ステップと、前記通信データに含まれる認証方式情報に基づいて当該通信データの送信元が公開鍵暗号に対応するか否かが判別される方式判別ステップと、前記方式判別ステップで前記通信データの送信元が公開鍵方式に非対応であると判別された場合に、自装置の識別情報として前記通信データに含まれる乱数が返信される識別情報返信ステップとを含むことを特徴とする。

上記の通信方法では、受信ステップにより、第１の通信部を介して、他の通信装置との接続毎に生成される乱数と、当該乱数により算出される証明書と、前記第２の通信部での認証方式が公開鍵方式に対応するか否かを示す認証方式情報と、が含まれる通信データが受信される。そのため、証明書、及び乱数を用いて当該通信データに含まれる情報の送信元が正当であることを確かめることができる。このとき、乱数が他の通信装置との接続毎に生成されているため、証明書の有効期限が他の通信装置との接続毎に設定される。その結果、通信データに含まれる情報を他人が傍受し、後ほど利用しようとした際に、その不正行為を検知できる。

また、上記の通信方法では、方式判別ステップにより、通信データに含まれる認証方式情報に基づいて当該通信データの送信元が公開鍵方式に対応するか否かが判別される。さらに、方式判別ステップにより通信データの送信元が公開鍵方式に非対応であると判別された場合に、自装置の識別情報として通信データに含まれる乱数が返信される。通信データの送信元が公開鍵方式に対応していれば、公開鍵方式に基づいてセキュアに認証情報を送ることができる。しかし、公開鍵方式に非対応の場合は、セキュリティを確保できない。そのため、上記の通信方法では、他の通信装置との接続毎に生成される乱数（一時値）を用いることでセキュリティを確保している。このような構成を適用することで、通信相手が公開鍵方式に対応するか、非対応かに関わらず、セキュリティを確保しながら接続設定をすることができるようになる。

以上説明したように本発明によれば、公開鍵方式を利用する認証方式、及び非公開鍵方式による認証方式に対応し、いずれの認証方式のデバイスに接続される場合でも、ユーザに掛かる設定の負担を低減させることができる。

以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。

＜第１実施形態＞
まず、本発明の第１実施形態について説明する。本実施形態は、本発明に係る技術をＢＴ認証方式（補遺１を参照）に適用するケースを一例として示したものである。

以下、次に示す順番で説明する。まず、本実施形態に係る通信方法が適用可能な通信システム１０のシステム構成例について説明する。次いで、ＮＦＣデバイスを用いてＢＴ認証方式を実現することが可能な通信装置１００、２００の機能構成について説明する。次いで、ＳＳＰ方式の１つであるＯｕｔ Ｏｆ Ｂａｎｄ（ＯＯＢ）方式について説明する。次いで、ＮＦＣ通信パケットのパケット構成について説明する。次いで、非公開鍵方式に相当するＢＴ認証方式（Ｃｏｒｅ規格のバージョン２．０以前の認証方式）、及びＯＯＢ方式の手順について説明する。その中で、本実施形態に係る認証方式の選択手段について説明する。その他にも、本実施形態に係る一時パスキー方式、ＢＴデバイス（以下、ＢＤ）のアドレス（以下、ＢＤアドレス）に基づく通信対象の制限方式、及びユーザインターフェースによる認証方式等について説明する。

（課題の整理）
既に述べた通り、新旧の規格が混在する状況では、新規格が簡単且つセキュアな設定方式に対応していても、ユーザに対し、旧規格の煩雑で低セキュリティの設定手順を要求してしまうことがある。新規格のＢＤでは、ＮＦＣを利用して簡単且つセキュアな設定方式を実現する。一方、旧規格のＢＤは、ＮＦＣの伝送フォーマットに互換性が無いばかりか、そもそも、ＮＦＣデバイスを認証に利用するように設計されていない。そのため、新旧規格のデバイスが混在した状況にある場合、ユーザは、新規格に対応するデバイスを保持していても、ＮＦＣを使った認証を断念し、従来の煩雑な手順を踏んでセットアップを行なう必要が生じてしまう。

そこで、本実施形態は、ＮＦＣデバイスを用いたＢＴ認証方式における次のような認証設定機能の提供を目指している。つまり、当該認証設定機能は、公開鍵ロジックが含まれる認証方式（例えば、ＯＯＢ方式）と、公開鍵ロジックが含まれない認証方式（例えば、Ｃｏｒｅ２．０以前の方式）とが並存する状況においても、互換性を保持しながら、簡単且つ高いセキュリティ強度を実現することができるものである。

［通信システム１０のシステム構成例］
まず、図１を参照しながら、本実施形態に係る通信システム１０のシステム構成の一例について説明する。図１は、本実施形態に係る通信システム１０のシステム構成例を示す説明図である。

図１に示すように、通信システム１０は、２つの通信装置１００、２００により構成されている。これらの通信装置１００、２００は、２種類の通信方式で通信できるように構成されている。その１つの通信方式（第１通信方式）は、近接通信方式（以下、ＮＦＣ方式）である。ＮＦＣ方式は、１０ｃｍ程度の非常に短い距離間で通信するための通信方式であり、所謂、非接触通信と呼ばれる通信方式である。一方、他の通信方式（第２通信方式）は、第１通信方式よりも長い距離間で通信可能な通信方式である。また、第２通信方式は、第１通信方式に比べて帯域幅が広く、比較的高速な通信が可能な通信方式である。本実施形態の場合、第２通信方式にはＢＴが適用される。

上記のようなシステム構成において、通信装置１００、２００間では、まず、第１通信方式により、第２通信方式による通信用の設定情報が交換され、認証処理が実行される。認証処理が完了すると、通信装置１００、２００間でペアリングが成立する。これによりサービス毎の接続認証無しに、第２通信方式でサービスが提供されるようになる。旧規格の場合、この相互認証に際し、個々の装置を識別するためのパスキー（ＰＩＮコード）をユーザが通信装置１００、２００に手入力していた。また、パスキーには、１〜１６桁までの英数字が利用可能であるが、現状、ユーザが管理しやすいように４桁程度の短いものが用いられることが多い。そのため、パスキーが推測され易く、セキュリティの低下を招いていた。

そこで、本実施形態では、第１通信方式の通信手段を利用してパスキー等の認証情報を相互に交換する認証方式を採用し、セキュリティの向上を図っている。このとき、通信装置１００、２００のいずれかが、認証情報を第１通信方式で交換する認証方式に対応していないと、この認証方式によるセキュアな認証設定が実現されない。そのため、本実施形態は、こうした互換性の問題に対しても解決手段を提供する。

［通信装置１００、２００の機能構成］
次に、図２を参照しながら、本実施形態に係る通信装置１００、２００の機能構成について説明する。図２は、本実施形態に係る通信装置１００、２００の機能構成を示す説明図である。

図２に示すように、通信装置１００、２００は、主に、アンテナ１０２、１０６と、近接通信部１０４と、近距離通信部１０８と、制御部１１０と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１１２と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１１４と、フラッシュメモリ１１６と、入力部１１８と、表示部１２０とにより構成される。尚、アンテナ１０２、近接通信部１０４は、図２３に示すハードウェア資源のうち、ＩＣカード、又はリーダ／ライタを構成する要素の一部又は全部により実現される。アンテナ１０６、近距離通信部１０８は、図２４に示すハードウェア資源のうち、例えば、通信部９２６により実現される。制御部１１０の機能は、例えば、制御回路７１２、コントローラ７２２、又はＣＰＵ９０２により実現される。

（近接通信部１０４）
近接通信部１０４は、アンテナ１０２に接続されており、第１通信方式（ＮＦＣ方式）に従ってデータを送受信することができる。近接通信部１０４は、例えば、１３．５６ＭＨｚ帯の周波数を利用し、１０ｃｍ程度の非常に短い距離間において最大４２４Ｋビット／秒の通信レートで通信することができる。尚、近接通信部１０４の通信距離、通信速度、及び利用周波数帯域は、上記の例に限定されず、任意に設定され得る。

（近距離通信部１０８）
近距離通信部１０８は、近接通信部１０４よりも長い距離の通信が可能な通信手段である。また、近距離通信部１０８は、アンテナ１０６に接続されており、近接通信部１０４よりも広い帯域幅を利用し、高速にデータを送受信することができる。さらに、近距離通信部１０８は、第２通信方式としてＢＴに対応し、例えば、２．４ＧＨｚ帯の通信帯域を利用して最大３Ｍビット／秒の通信速度で通信することができる。尚、通信帯域、及び通信速度は、ＢＴ規格のＣｏｒｅ２．０＋ＥＤＲで規定されたもの以外にも、これ以降のバージョンや他の規格が適用されてもよく、実施の態様に応じて適宜変更可能である。

（制御部１１０）
制御部１１０は、通信装置１００、２００の各構成要素の動作を制御する手段である。また、制御部１１０は、主に、鍵ペア生成機能と、共有鍵算出機能と、乱数生成機能と、証明書算出機能と、設定情報付加機能と、設定情報抽出機能と、認証値算出機能と、リンクキー算出機能と、認証レコード付加機能と、認証レコード抽出機能と、認証方式判定機能と、パスキー設定機能と、表示制御機能と、通信制御機能とを有する。

鍵ペア生成機能は、ペアを成す公開鍵（ＰＫａ，ＰＫｂ）と秘密鍵（ＳＫａ，ＳＫｂ）を生成する機能である。鍵ペア生成機能は、例えば、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎにより公表された鍵生成アルゴリズムに基づいて公開鍵／秘密鍵のペアを生成する機能である。尚、秘密鍵（ＳＫａ，ＳＫｂ）は、ＲＡＭ１１２、又はフラッシュメモリ１１６に格納される。共有鍵算出機能は、取得した公開鍵（ＰＫａ，ＰＫｂ）と自装置の公開鍵（ＰＫｂ，ＰＫａ）とを利用して共有鍵（ＤＨＫｅｙ）を算出する機能である。

乱数生成機能は、物理的な乱数生成器から乱数を取得するか、或いは、所定の乱数生成アルゴリズムを利用して疑似乱数を生成する機能である。所定の乱数生成アルゴリズムとしては、例えば、線形合同法やメルセンヌ・ツイスター法等、種々の方法が利用可能である。但し、その性質上、より良いアルゴリズムが用いられることが好ましい。以下、乱数発生器による乱数であるか、疑似乱数であるかを表現上区別せず、単に乱数と呼ぶ。

証明書算出機能は、乱数生成機能により生成された乱数（ｒａ，ｒｂ，Ｎａ，Ｎｂ）等に基づき、所定のハッシュ関数を利用して証明書（Ｃａ，Ｃｂ）を算出する機能である。設定情報付加機能は、近接通信部１０４により送信される通信パケットに設定情報を付加する機能である。設定情報には、例えば、自装置のＢＤアドレス、乱数（ｒａ，ｒｂ）、及び証明書（Ｃａ，Ｃｂ）等が含まれる。尚、証明書（Ｃａ、Ｃｂ）は、図２７に示すロジック（ｆ１）により生成されてもよい。

設定情報抽出機能は、近接通信部１０４により受信された通信パケットに付加された設定情報を抽出する機能である。認証値算出機能は、リンクキーを算出する前段で相互認証するための認証値（Ｅａ，Ｅｂ）を乱数（Ｎａ、Ｎｂ）、及び所定の関数（ｆ２）を用いて算出する機能である。リンクキー算出機能は、共有鍵（ＤＨＫｅｙ）等に基づいてリンクキー（ＬＫ）を算出する機能である。

認証レコード付加機能は、後述するＮＤＥＦメッセージに認証フラグを示すＮＤＥＦ Ｒｅｃｏｒｄを付加する機能である。この認証フラグには、認証方式のＲｅｃｏｒｄであることを示す識別子と、認証方式を示す識別子と、ＢＴネットワークの構成を示す識別子とが含まれる。これらの識別子については、後段において詳述する。認証レコード抽出機能は、後述するＮＤＥＦメッセージに付加された認証フラグを示すＮＤＥＦ Ｒｅｃｏｒｄを抽出する機能である。

認証方式判定機能は、認証レコード抽出機能により抽出されたＮＤＥＦ Ｒｅｃｏｒｄの認証フラグを参照し、ＮＤＥＦメッセージの送信元装置が対応する認証方式を判定する機能である。また、認証方式判定機能は、送信元装置が対応する認証方式と、自装置が対応する認証方式とを比較し、より適した認証方式を選択する機能を含む。

パスキー設定機能は、認証方式判定機能により、後述する一時パスキー方式が選択された場合に、証明書の発行に用いられる乱数をパスキーに設定する機能である。さらに、パスキー設定機能は、パスキーの有効期限を管理し、有効期限が経過した後で、フラッシュメモリ１１６等に格納されたパスキー及び設定情報を消去する機能を含む。また、パスキー設定機能は、パスキーの有効／無効を管理する機能を含む。

表示制御機能は、例えば、表示部１２０に対し、パスキー等の設定情報をＮＦＣ通信で送信するか否かの許諾をユーザに求める表示をさせたり、ＮＦＣ通信により受信したパスキーを有効にするか否かをユーザに確認する表示をさせる機能である。通信制御機能は、ＮＦＣ通信により受信したＢＤアドレスが示す接続先のみにＢＴによる通信相手を制限するように近距離通信部１０８を制御する機能である。

（その他）
ＲＡＭ１１２は、例えば、制御部１１０による演算処理の際に、スタック領域、又はヒープ領域として利用される。ＲＯＭ１１４には、例えば、制御部１１０の機能を実現するためのプログラムの実行バイナリコードが格納されている。但し、制御部１１０の機能を実現するためのプログラムのバイナリコードは、フラッシュメモリ１１６に格納されていてもよい。

［ＯＯＢ方式による認証方法］
次に、図３を参照しながら、ＯＯＢ方式に係る認証方法について説明する。図３は、ＯＯＢ方式に係る認証処理の流れを示す説明図である。上記の通り、ＯＯＢ方式はＳＳＰ認証方式の一例である。この流れの中で、通信装置１００、２００は、ユーザにより近接された状態で近接通信部１０４によりＮＦＣ通信を実行し、その後、近距離通信部１０８によりＢＴによる認証処理を実行する。

まず、通信装置１００、２００が十分に近接し、ＮＦＣ通信による通信可能範囲まで近づくと、近接通信部１０４を介して設定情報（ＢＤアドレス、証明書等）を交換する（Ｓ１０２）。次いで、通信装置１００、２００は設定情報に含まれるＢＤアドレスに基づいて相互に公開鍵（ＰＫａ，ＰＫｂ）を交換する（Ｓ１０４）。このとき、制御部１１０により、取得した公開鍵（ＰＫｂ，ＰＫａ）、及び自装置の秘密鍵（ＳＫａ，ＳＫｂ）に基づいて共有鍵（ＤＨＫｅｙ）が生成される（Ｓ１０４）。

次いで、通信装置１００、２００は、それぞれ、受信した設定情報に含まれる乱数（ｒａ，ｒｂ）、及び証明書（Ｃａ，Ｃｂ）等を利用して第１の認証処理（図２６の認証処理に相当）を実行する（Ｓ１０６）。但し、図２６における第１の認証処理の場合、証明書の発行に公開鍵を利用しているため、ＮＦＣ通信の開始以前に公開鍵が交換されていることが前提となるが、本実施形態は、このような方式にも適用可能である。

第１の認証処理が成功裏に完了すると、通信装置１００、２００の制御部１１０により、それぞれ、乱数（Ｎａ，Ｎｂ）が生成され、近距離通信部１０８を介して交換される。また、制御部１１０により、共有鍵（ＤＨＫｅｙ）、取得した乱数（Ｎａ，Ｎｂ，ｒａ，ｒｂ）、及びＢＤアドレス等が利用され、所定の認証関数（ｆ３）に基づいて認証値（Ｅａ，Ｅｂ）が算出される。そして、これらの認証値（Ｅａ，Ｅｂ）が互いに交換される。そして、通信装置１００、２００において、それぞれ第２の認証処理（図２８の認証処理に相当）が実行される（Ｓ１０６）。次いで、通信装置１００、２００の制御部１１０により、それぞれ、リンクキー（ＬＫ）が算出される（Ｓ１０８）（図２５を参照）。

以上、ＯＯＢ方式による認証方法について簡単に説明した。上記のように、ＮＦＣ通信による設定情報の交換、及び公開鍵暗号による伝送路の暗号化が施されることで、中間者攻撃のような認証情報の盗聴等に対して高い耐性が実現される。

［ＮＦＣ通信パケットの構成例］
次に、図４を参照しながら、ＮＦＣ通信に利用される通信パケットの構成例について説明する。図４は、ＮＦＣ通信に利用される通信パケットの構成例を示す説明図である。

上記のようなＮＦＣ通信は、ＮＦＣ Ｆｏｒｕｍで規定されたＮＦＣ Ｄａｔａ Ｅｘｃｈａｎｇｅ Ｆｏｒｍａｔ（以下、ＮＤＥＦ）に則って行なわれる。ＮＦＣ通信におけるパケットは、図４に示すようなＮＤＥＦ Ｒｅｃｏｒｄと呼ばれる単位で構成される。ＮＤＥＦ Ｒｅｃｏｒｄは、大きく分けてＲｅｃｏｒｄ Ｔｙｐｅ部分Ｄ５、Ｒｅｃｏｒｄ ＩＤ部分Ｄ６、Ｐａｙｌｏａｄ部分Ｄ７により構成される。

また、ＮＤＥＦ Ｒｅｃｏｒｄの先頭部分Ｄ１には、そのＲｅｃｏｒｄがメッセージの最初のレコードであるか否かを示す識別子ＭＢと、そのＲｅｃｏｒｄがメッセージの最後のレコードであるか否かを示す識別子ＭＥが含まれる。さらに、この先頭部分Ｄ１には、Ｐａｙｌｏａｄ部分Ｄ７のデータ長が１バイト長であるか、４バイト長であるかを示す識別子ＳＲ（Ａ１）が含まれる。さらに、この先頭部分Ｄ１には、Ｒｅｃｏｒｄ ＩＤ部分Ｄ６の有無を示す識別子ＩＬ（Ａ２）、及びＲｅｃｏｒｄ Ｔｙｐｅ部分Ｄ５のフォーマットを指定する識別子ＴＮＦ（Ａ３）が含まれる。また、ＮＤＥＦ Ｒｅｃｏｒｄのヘッダ部分Ｄ２、Ｄ３、Ｄ４には、それぞれ、Ｒｅｃｏｒｄ Ｔｙｐｅ部分Ｄ５、Ｒｅｃｏｒｄ ＩＤ部分Ｄ６、Ｐａｙｌｏａｄ部分Ｄ７のデータ長が格納される。

Ｒｅｃｏｒｄ Ｔｙｐｅ部分Ｄ５は、Ｐａｙｌｏａｄ部分Ｄ７に格納されるデータの識別子として利用される。そのため、Ｒｅｃｏｒｄ Ｔｙｐｅ部分Ｄ５は、Ｐａｙｌｏａｄ部分Ｄ７に格納されたデータのフォーマットが特定される際に参照される。例えば、Ｒｅｃｏｒｄ Ｔｙｐｅ部分Ｄ５により、Ｐａｙｌｏａｄ部分Ｄ７の構造、及び意味が決定される（Ａ４）。また、Ｒｅｃｏｒｄ ＩＤ部分Ｄ６には、Ｐａｙｌｏａｄを同定するためのＵＲＩ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｉｄｅｎｔｉｆｉｅｒ）が格納される（Ａ５）。尚、Ｒｅｃｏｒｄ Ｔｙｐｅの定義は、ＮＦＣＦｏｒｕｍが規定する場合と、ユーザが独自に定義する場合とがある。

さらに、図５を参照する。図５は、ＮＤＥＦメッセージの構成例を示す説明図である。ＮＤＥＦメッセージは、図４に示すＮＤＥＦ Ｒｅｃｏｒｄが集まって構成される。尚、ＮＤＥＦ Ｒｅｃｏｒｄの先頭部分Ｄ１に含まれる識別子ＭＢ＝１のレコードから、識別子ＭＥ＝１のレコードまでが１つのＮＤＥＦメッセージを構成する。

［ＮＤＥＦメッセージの構成例］
次に、図６を参照しながら、ＯＯＢ認証方式に適用可能な本実施形態に係るＮＤＥＦメッセージの構成例について説明する。図６は、ＯＯＢ認証方式に適用可能な本実施形態に係るＮＤＥＦメッセージの構成例を示す説明図である。

図６に示すように、ＮＤＥＦメッセージは、例えば、３つのＮＤＥＦ Ｒｅｃｏｒｄにより構成される。第１のＮＤＥＦ Ｒｅｃｏｒｄ（Ｒｅｃｏｒｄ１）には、このＮＤＥＦメッセージがハンドオーバー用であることを示すハンドオーバー用Ｒｅｃｏｒｄ Ｔｙｐｅが格納されている。尚、ハンドオーバーとは、第１通信方式であるＮＦＣ通信から、第２通信方式（セカンドキャリア）に通信方式を切り替える行為を意味している。第２のＮＤＥＦ Ｒｅｃｏｒｄ（Ｒｅｃｏｒｄ２）には、例えば、Ｒｅｃｏｒｄ ＴｙｐｅがＢＴであることを示す“ｂｌｕｅｔｏｏｔｈ．ｏｒｇ．ｓｐ”が格納される。さらに、そのペイロードには、ＢＴの設定情報として、自装置のＢＤアドレス、乱数、ハッシュ値等が格納される。

さらに、本実施形態に係るＮＤＥＦメッセージには、第３のＮＤＥＦ Ｒｅｃｏｒｄ（Ｒｅｃｏｒｄ３）が付加される。この第３のＮＤＥＦ Ｒｅｃｏｒｄには、認証方式を示すＲｅｃｏｒｄであることを識別するための第１識別子と、認証方式を示す第２識別子と、ＢＴネットワーク構成を示す第３識別子とが含まれる。本実施形態において、第２識別子は、自装置がＯＯＢ方式の認証処理（Ｃｏｒｅ ２．１）に対応するか否かを示すフラグ（ａ）と、後述する一時パスキー方式による認証処理（Ｃｏｒｅ ２．０以前）に対応するか否かを示すフラグ（ｂ）とにより構成される。第３識別子は、ＢＴ通信で形成されるネットワーク上において、自装置の役割がＭａｓｔｅｒになれるか否かを示すフラグ（ａ）、Ｓｌａｖｅになれるか否かを示すフラグ（ｂ）により構成されている。これらのフラグは、認証方式を決定するための判断に利用される。

［ＮＤＥＦメッセージを用いた認証方法］
次に、図７を参照しながら、本実施形態に係るＮＤＥＦメッセージを用いた認証方法の流れについて説明する。図７は、本実施形態に係るＮＤＥＦメッセージを用いた認証方法の流れを示す説明図である。

図７に示すように、まず、通信装置１００、２００は、ＮＦＣ通信により設定情報を交換する。例えば、ＮＦＣ通信によりＢＤアドレスが交換される（Ｓ１０２）。このとき、ＮＦＣ通信パケットには、ＢＤアドレス、乱数、証明書等のＳＳＰ規定情報の他に、制御部１１０により付加された認証フラグ（第３のＮＤＥＦ Ｒｅｃｏｒｄ）が含まれる。通信装置はＮＦＣ通信パケットを受信すると、制御部１１０により、第３のＮＤＥＦ Ｒｅｃｏｒｄが抽出し、ＮＦＣ通信パケットの送信元装置が対応する認証方式を判定する（Ｓ１３２）。さらに、制御部１１０が、その送信元装置の認証方式と、自装置が対応する認証方式とを比較し、より適した認証方式を選択する。

例えば、制御部１１０が、通信装置１００、２００が共にＣｏｒｅ ２．１の認証方式（ＯＯＢ方式）に対応していると判定した場合、ＯＯＢ方式に則った認証方法が選択される。その場合、公開鍵の交換、証明書等による認証処理、及びリンクキーの生成処理が実行される。一方、通信装置１００、２００のいずれかがＣｏｒｅ ２．１の認証方式に対応しておらず、且つ、いずれの装置も一時パスキー方式に対応している場合、一時パスキー方式による認証方法（Ｃｏｒｅ ２．０以前の認証方式）が選択される。このとき、制御部１１０は、証明書の発行に用いるための１６バイトの乱数列をパスキーに設定する（Ｓ１３４、Ｓ１３６）。通信装置１００、２００間でこのパスキーが交換され（Ｓ１３８）、これを用いて初期化キー、リンクキーが生成される（Ｓ１４０、Ｓ１４２）。

ここで、図８を参照しながら、本実施形態に係るＮＤＥＦメッセージを用いた認証方法の流れについて簡単に整理する。図８は、本実施形態に係るＮＤＥＦメッセージを用いた認証方法の流れを示す説明図である。

図８に示すように、まず、ＮＦＣ通信によりＮＤＥＦメッセージが伝送される（Ｓ１０２）。次いで、ＮＤＥＦメッセージに含まれる認証フラグが抽出される。そして、その認証フラグに基づいて認証方法が選択される（Ｓ１３２）。認証方法がＯＯＢ方式であると判断された場合、ステップＳ１０４の処理に進行し、公開鍵の交換（Ｓ１０４）、認証処理（Ｓ１０６）、リンクキーの生成（Ｓ１０８）が順次実行される。一方、認証方法がＯＯＢ方式以外の方式であると判断された場合、ステップＳ１３４、Ｓ１３６の処理に進行し、証明書に用いる乱数に基づいてパスキーが生成される。次いで、ステップＳ１４０、Ｓ１４２の処理に進行する。ステップＳ１４０、Ｓ１４２では、初期化キー、リンクキーが順次生成される。

このように、本実施形態に係るＮＤＥＦメッセージの構成が適用されることで、認証方式の選択処理が可能になる。さらに、証明書に用いる乱数に基づいてパスキーが生成されるため、そのパスキーを利用してＯＯＢ方式以外の認証方式にも適応できるようになる。元々、ＯＯＢ方式を採用していないＣｏｒｅ ２．０以前の認証方式では、ＢＤアドレスが検索（Ｓ１２）された後で、ユーザにパスキーの手入力（Ｓ１４）が求められ、入力されたパスキーに基づいて初期化キー、リンクキーの生成が行われていた。本実施形態に係る認証方法を適用すると、ＯＯＢ方式に対応していないデバイスに対しても、このようなパスキーの手入力を避けることができるため、セキュリティの向上に寄与する。

［認証処理の流れと機能ブロックとの関係］
次に、図９を参照しながら、本実施形態に係る認証処理と、通信装置１００、２００が備える機能ブロックとの対応関係について説明する。図９は、本実施形態に係る認証処理と、通信装置１００、２００が備える機能ブロックとの対応関係を示す説明図である。

ＢＴ Ｃｏｒｅ規格のバージョン２．０以前のＢＴ接続処理では、ＢＤの「探索」処理が実行され、接続可能な通信機器の一覧が取得される。次いで、取得された通信機器の一覧の中から、ユーザが所望の接続先を指定する。その後、パスキーがＲＯＭ１１４、フラッシュメモリ１１６、又はキーボード等の入力部１１８から取得されることにより、接続相手の機器と同じパスキーが共有される。

次いで、ＢＴ通信により、乱数やハッシュ値を通信相手との間で相互に交換し合うことにより、初期化キー、リンクキーが生成されて認証処理が完了する。但し、一度接続が確立された通信相手先については、ＢＤアドレス、リンクキーをセットにしてフラッシュメモリ１１６内のセキュリティデータベース（以下、ＤＢ）内に保存しておき、次回接続時に、ＤＢから読み出したリンクキーを用いて接続処理が行われる。

本実施形態に係る技術は、こうしたＢＴ Ｃｏｒｅ規格のバージョン２．０以前の接続処理に対し、次のようにして互換性を確保している。

まず、通信装置はＮＦＣ通信により接続相手のＢＤアドレス、及び１６バイトの乱数を取得する（Ｓ２０２）。次いで、制御部１１０によりＮＦＣパケットが分析され、認証方式が一時パスキー方式であると判断された場合に、１６バイトの乱数をパスキーに置き換える。次いで、ＢＴデバイス（近距離通信部１０８）に対して接続依頼が行われる（Ｓ２０６）。次いで、ＢＤアドレスとリンクキーのセットが格納されているＤＢ（フラッシュメモリ１１６）が参照され、接続先（取得したＢＤアドレスの対象装置）のリンクキーが既に存在するか否かが確認される（Ｓ２０８）。

次いで、ＤＢ内に接続先のリンクキーが存在している場合、通信装置はそのリンクキーを利用して接続先と接続される（Ｓ２１０、Ｓ２１２（ＹＥＳ））。一方、ＤＢ内に接続先のリンクキーが存在しない場合、制御部１１０に対してパスキーが要求される（Ｓ２１０、Ｓ２１２（ＮＯ））。接続先との間で相互に乱数、ハッシュ値等の交換が行われた後で、初期化キーが生成され（Ｓ２１４）、最終的にリンクキーが生成される。

［一時パスキー方式の詳細］
次に、図１０、及び図１１を参照しながら、本実施形態に係る一時パスキー方式の詳細について説明する。図１０には、通信装置２００により生成されるパスキーの更新処理が示されている。一方、図１１には、ＧＵＩによる認証許可方式が示されている。

（有効期限付きパスキー設定について）
まず、図１０を参照する。上記の通り、パスキーに設定される１６バイトのデータ列は、平文のまま伝送されるため、ＮＦＣ通信を受信可能な他の機器により盗聴される可能性がある。しかしながら、図１０に示すように、パスキーに設定される乱数は、接続の度に新たに生成される（Ｓ１３４）。そのため、接続毎に異なるパスキーが生成される（Ｓ１４２）。こうした理由から、本実施形態に係る一時パスキー方式は、そのままでも比較的セキュリティが高いと言える。

しかしながら、よりセキュリティを高めるためには、パスキーに有効期限を設定するのが好ましい。そこで、本実施形態では、パスキーに有効期限を設定し、そのパスキーを一時的な使い捨てキーとして取り扱う方法を採用する。このとき、パスキーの有効期間が失効するタイミングとして、次の３通りを考える。（１）認証が成功し、接続先と接続元の双方においてリンクキーが生成された時点、（２）ＮＦＣ通信後、何らかの理由で認証が失敗したと判断された時点、（３）ＮＦＣ通信後、認証開始から所定期間が経過した時点がパスキー失効のタイミングに設定される。

この場合、上記（１）〜（３）のいずれかの条件が検出された場合に、制御部１１０は、ＮＦＣメッセージにより交換されたパスキーをフラッシュメモリ１１６から削除する。このように、パスキーに有効期限を設けることで、ＮＦＣ通信の際に何者かによってパスキーが盗聴されたとしても、上記（１）〜（３）のいずれかの条件が成立した後で、このパスキーが無効化される。このため、盗聴者を盗聴されたパスキーにより認証する確率が格段に低減される。

（ＧＵＩによる認証許可について）
次に、図１１を参照する。上記のように、パスキーに有効期限を設定することで、セキュリティを高めることができるが、本実施形態では、ユーザのＧＵＩ操作による認証許可を求めることで、更なるセキュリティの向上を図る方法を提案する。尚、図１１では、通信装置１００が通信装置２００に認証許可を求めるケースが示されている。

図１１に示すように、認証を開始しようとする通信装置１００の表示部１２０には、パスキーの送信確認を促す画面が表示される。例えば、表示部１２０には、「Ｔｏｕｃｈ」等の認証開始を促す画面が表示される。入力部１１８（例えば、表示部１２０上のタッチパネル）を介してユーザの通信許可が得られると、ＮＦＣ通信によりパスキーが通信装置２００に伝送される。

一方、接続先の通信装置２００には、表示部１２０に次処理の許可／不許可を指定するユーザインターフェースが表示される。例えば、この表示部１２０には、「Ａｃｃｅｐｔ」等の認証受け入れ許可の確認表示がされる。このとき、通信装置２００は、ユーザによる許可が得られるまで、受信したパスキーを有効化せず、ユーザによる許可入力が行われた場合にパスキーを有効化する。

この方式を採用すると、両者のユーザがＧＵＩ経由で認証を許可した時点から、パスキーの有効期間が経過するまでの間だけが、ＢＴによる通信可能な認証期間となる。その結果、ユーザが関知していない期間において、不正な侵入者により認証処理が進められないことになる。その結果、よりセキュリティを向上させることができる。

さらに、パスキーの有効期間内において、ＮＦＣ通信パケットから取得したＢＤアドレスが示す接続相手に対してのみ通信を許可する設定とすることで、更なるセキュリティの向上が見込める。この方式を採用すると、平文で伝送されるパスキーを盗聴したデバイスが認証を試みた場合に、ＢＴにおける認証用の通信がブロックされる。このため、盗聴したデバイスは認証処理を進めることができなくなる。その結果、更にセキュリティを向上させることが可能になる。

［ＢＴネットワークの構成例］
次に、図１２を参照しながら、本実施形態に係るＢＴネットワークの構成例について説明する。図１２は、本実施形態に係るＢＴネットワークの構成例を示す説明図である。

ＢＴの仕様によると、ＢＴネットワークを形成する上で、通信装置１００、２００は、ｍａｓｔｅｒ、又はｓｌａｖｅのどちらかの役割が割り当てられる。さらに、ｍａｓｔｅｒとｓｌａｖｅとの間のみで通信が許されており、ｍａｓｔｅｒ同士、又はｓｌａｖｅ同士の接続は許されていない。このような制約内で、ピコネット、及びスキャタネットと呼ばれるネットワーク形態が実現される。

ピコネットとは、１つのｍａｓｔｅｒが中心となり、最大８台のｓｌａｖｅがｍａｓｔｅｒに接続されるネットワークのことを言う。一方、スキャタネットとは、時分割でｍａｓｔｅｒとｓｌａｖｅとを切り替えることが可能なｍａｓｔｅｒ／ｓｌａｖｅに対し、ｓｌａｖｅと別のｍａｓｔｅｒとが接続されることで、複数のピコネットが接続される形態のことを言う。このとき、ｍａｓｔｅｒ／ｓｌａｖｅは、ある特定の時間帯でピコネット上のｍａｓｔｅｒとして振る舞い、他の時間帯で他のピコネットのｓｌａｖｅとして動作している。そのため、同時に複数のｍａｓｔｅｒがピコネット内に存在することがない。

既に述べた通り、本実施形態に係るＮＤＥＦメッセージの第３のＮＤＥＦ Ｒｅｃｏｒｄには、ＢＴネットワーク構成情報が含まれる。この部分には、その装置がｍａｓｔｅｒに対応可能か否か、及びｓｌａｖｅに対応可能か否かが示されている。そのため、このＢＴネットワーク構成情報が交換されることにより、適切なネットワークが形成される。

（具体例）
例えば、何のネットワークにも所属していない接続元デバイスがｍａｓｔｅｒとなり、既にピコネットを形成している接続先デバイスに接続する場合について考える。

１つのケース（Ｃａｓｅ．１）として、接続先デバイスがｍａｓｔｅｒ可、ｓｌａｖｅ不可であり、接続元デバイスがｍａｓｔｅｒ／ｓｌａｖｅ可の場合が考えられる。尚、ＮＤＥＦメッセージの交換により、両者が役割の可否を認識しているものとする。この場合、接続先デバイスの役割がｍａｓｔｅｒで固定されているため、接続元デバイスがｓｌａｖｅになる。その結果、新しいネットワークは、接続先デバイスをｍａｓｔｅｒとし、接続元デバイスを含む複数のデバイスがｓｌａｖｅである単一のピコネットが形成される。

一方、接続元デバイスがｍａｓｔｅｒ可、ｓｌａｖｅ不可であり、接続先デバイスがｍａｓｔｅｒ／ｓｌａｖｅ可のケース（Ｃａｓｅ．２）も考えられる。この場合、接続元デバイスの役割がｍａｓｔｅｒで固定されているため、接続先デバイスがｓｌａｖｅになる。その結果、接続先デバイスは、新しく生成されたネットワークのｓｌａｖｅとなる。また、同時に、接続先デバイスは既存のピコネットのｍａｓｔｅｒとなるため、スキャタネットが形成される。

以上、本発明の第１実施形態について説明した。本実施形態に係る技術を適用することにより、ＢＴ Ｃｏｒｅ規格のバージョン２．１、及びそれ以前の規格に準じて設計されたデバイスに対しても、ユーザがネットワークの設定を簡単に実現することが可能になる。また、ユーザがパスキー等の認証情報を手入力する必要が無いため、セキュリティの向上が見込める。さらに、パスキーに有効期限を設定したり、ＧＵＩによるユーザ認証を組み合わせることで、さらにセキュリティを向上させることができる。また、ＮＦＣ通信パケットにネットワーク構成用の役割情報が含まれ、その役割情報が交換されることで、適切なネットワーク構成が容易に設定されるようになる。

＜第２実施形態＞
次に、本発明の第２実施形態について説明する。本実施形態は、本発明に係る技術をＷＬＡＮ認証方式に適用するケースを一例として示したものである。上記の第１実施形態ではＢＴの場合を例に挙げて説明したが、本実施形態ではＷＬＡＮの場合を例に挙げて説明する。

ＢＴ Ｃｏｒｅ規格のバージョン２．１に含まれるＯＯＢ方式の認証方法と、ＷＰＳに含まれるＯＯＢ方式の認証方法とは、技術的な側面において、公開鍵方式による設定情報の安全なパケット交換が共通点として挙げられる。一方、ユーザビリティの観点においては、「ＮＦＣデバイスを近づけるだけで認証が終了する」という利便性が共通点として挙げられる。一方で、両規格における大きな相違点としては、ネットワーク構成の形態が異なることが挙げられる。そこで、本実施形態では、ＷＬＡＮのネットワーク構成に適用するための仕組みについて、重点的に説明する。

［ＷＬＡＮにおけるネットワーク形態］
まず、図１３を参照しながら、ＷＬＡＮのネットワーク形態について説明する。図１３は、ＷＬＡＮのネットワーク形態の一例を示す説明図である。

ＷＬＡＮにおけるネットワーク形態には、インフラストラクチャモード（以下、Ｉｎｆｒａモード）と、アドホック（Ａｄ−ｈｏｃ）モードとがある。多くの場合、１つのアクセスポイント（以下、ＡＰ）に複数のベースステーション（以下、ＢＳ）が接続されるＩｎｆｒａモードが多く使われる。Ｉｎｆｒａモードの場合、ＡＰは、有線又は無線で構築されたローカルエリアネットワークに属している。また、ＡＰは、各種のローカルサーバに接続される。

さらに、ローカルエリアネットワークは、ゲートウェイを経由して、インターネット等の広域ネットワークに接続される。ＡＰ、ＢＳ、及び各種のサーバを含む各接続機器には、個々にＩＰアドレスが割り振られている。そのため、各接続機器は通信プロトコルであるＴＣＰ／ＩＰに基づいてＩＰアドレスが割り振られた任意の接続機器に対してパケットの送受信ができる。こうした仕組みにより、Ｗｅｂサーバによる大規模なＷｅｂサービスの提供やメールサーバによるメール配信サービス等が実現されている。

さて、Ｗｉ−Ｆｉ Ａｌｌｉａｎｃｅは、ＷＬＡＮに関し、簡単且つセキュリティ強度の高い認証仕様を規定している。この規定は、ＷＰＳと呼ばれる。ＷＰＳのｖｅｒｓｉｏｎ１．０ｈ（以下、ＷＰＳ１．０ｈ）では、上記のＩｎｆｒａモードが想定されている。さらに、ＷＰＳ１．０ｈでは、その他にも、いくつかの認証方式が規定されている。本実施形態では、その中の１つであるＮＦＣ通信を利用したＯＯＢ方式に着目する。

ＷＰＳ１．０ｈによると、認証処理に関係する機器（ＡＰ又はＢＳ）の役割は、認証情報の制御や管理を行うＲｅｇｉｓｔｒａｒ、及び新規にネットワークへの接続を要求するＥｎｒｏｌｌｅｅが規定されている。但し、ＡＰは接続先になる。以下の説明においては、図１３に示すように、ＡＰがＲｅｇｉｓｔｒａｒの役割を果たす場合を想定して説明する。もちろん、本実施形態に係る技術は、これに限定されない。

以下、図１３の構成を例に挙げて認証処理の流れについて簡単に説明する。まず、Ｅｎｒｏｌｌｅｅの役割を有するＢＳ（以下、ＢＳ／Ｅｎｒｏｌｌｅｅ）は、Ｒｅｇｉｓｔｒａｒ機能を有するＡＰ（以下、ＡＰ／Ｒｅｇｉｓｔｒａｒ）に接続要求を送信する。このとき、ユーザは、ＢＳ／ＥｎｒｏｌｌｅｅとＡＰ／Ｒｅｇｉｓｔｒａｒとを十分に近づけ、ＮＦＣ通信により必要な設定情報を交換させる。設定情報が交換されると、ＢＳ／ＥｎｒｏｌｌｅｅとＡＰ／Ｒｅｇｉｓｔｒａｒとは接続される。その結果、ＢＳ／Ｅｎｒｏｌｌｅｅは、Ｉｎｆｒａモードで形成されたネットワークの１構成単位となる。尚、ＮＦＣ通信による設定情報の交換は、ＷＰＳ１．０ｈに準拠した方式で実現可能である。

［ＮＦＣ通信の形態］
次に、図１４を参照しながら、本実施形態に適用可能なＮＦＣ通信の形態について説明する。図１４は、本実施形態に適用可能なＮＦＣ通信の一形態を示す説明図である。

本実施形態では、ＮＦＣ通信をトリガーとしてＷＬＡＮ通信経路が接続される形態を想定している。ＮＦＣ通信パケットには、ＮＦＣの通信規格で規定された設定情報以外にも、例えば、「接続後にどのような通信処理が実行されるか」といった他の設定情報が格納できる。そのため、ＮＦＣ通信パケットに格納された設定情報には種々の使い道が考えられる。例えば、ＮＦＣ通信をトリガーとする接続の後で、インターネット上に存在するＷｅｂサーバにアクセスさせるような使い方が考えられる。

このように、ＮＦＣ通信パケットには多種多様な用途が想定されるが、本実施形態では、ユーザによりＮＦＣ通信が可能な距離まで２つのＮＦＣデバイスが近づけられた際に、ＮＦＣ通信パケットに格納された設定情報を利用して、ＷＬＡＮ通信に必要な認証処理が実現されるような使い方を想定する。特に、図１４に示す通信装置１００、２００のようにＮＦＣデバイスを搭載した機器間で、ＮＦＣ通信により交換された設定情報に基づいて認証処理が実行され、通信装置１００、２００間がＷＬＡＮで接続されるようなケースを想定する。

（変形例）
尚、ＮＦＣ通信による設定情報の交換は、図１５に示すように、ＮＦＣデバイスを備えた通信媒介端末を介して交換されてもよい。この例は、通信装置１００、２００が備えるＮＦＣデバイスが相互に離れた場所に設置され、互いに近接できないような場合等において利用される。また、ＮＦＣデバイスの通信特性に応じて、この例のような形態が採用されてもよい。この例の場合、例えば、通信装置１００に翳された通信媒介端末がＮＦＣ通信で設定情報を一旦格納する。そして、その後、この通信媒介端末が通信装置２００のＮＦＣデバイスに翳されることで、一旦格納された設定情報が通信装置２００に読み取られる。また、逆の操作により、通信装置２００の設定情報が通信装置１００に伝達される。

［通信装置１００、２００の機能構成］
次に、図１６を参照しながら、本実施形態に係る通信装置１００、２００の機能構成について説明する。図１６は、本実施形態に係る通信装置１００、２００の機能構成を示す説明図である。

図１６に示すように、通信装置１００、２００は、主に、アンテナ１０２、１０６と、近接通信部１０４と、近距離通信部１５８と、制御部１６０と、ＲＡＭ１１２と、ＲＯＭ１１４と、フラッシュメモリ１１６と、入力部１１８と、表示部１２０とにより構成される。尚、アンテナ１０６、近距離通信部１５８は、図２３に示すハードウェア資源のうち、例えば、通信部９２６により実現される。制御部１６０の機能は、例えば、図２３、又は図２４に示された、制御回路７１２、コントローラ７２２、又はＣＰＵ９０２により実現される。

上記の第１実施形態に係る通信装置１００、２００との主な相違点は、近距離通信部１５８、及び制御部１６０の機能構成にある。そこで、近距離通信部１５８、及び制御部１６０の機能構成について詳細に説明する。

（近距離通信部１５８）
近距離通信部１５８は、近接通信部１０４よりも長い距離間で通信することが可能な通信手段である。また、近距離通信部１５８は、アンテナ１０６に接続されており、近接通信部１０４よりも広い帯域幅を利用し、高速にデータを送受信することができる。さらに、近距離通信部１５８は、第２通信方式としてＷＬＡＮに対応している。

（制御部１６０）
制御部１６０は、通信装置１００、２００の各構成要素の動作を制御する手段である。また、制御部１６０は、主に、鍵ペア生成機能と、乱数生成機能と、証明書算出機能と、設定情報付加機能と、設定情報抽出機能と、認証レコード付加機能と、認証レコード抽出機能と、認証方式判定機能と、を有する。

鍵ペア生成機能は、ペアを成す公開鍵と秘密鍵を生成する機能である。鍵ペア生成機能は、例えば、Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎにより公表された鍵生成アルゴリズムに基づいて公開鍵／秘密鍵のペアを生成する機能である。尚、秘密鍵は、ＲＡＭ１１２、又はフラッシュメモリ１１６に格納される。

乱数生成機能は、物理的な乱数生成器から乱数を取得するか、或いは、所定の乱数生成アルゴリズムを利用して疑似乱数を生成する機能である。所定の乱数生成アルゴリズムとしては、例えば、線形合同法やメルセンヌ・ツイスター法等、種々の方法が利用可能である。但し、その性質上、より良いアルゴリズムが用いられることが好ましい。

証明書算出機能は、乱数生成機能により生成された乱数、及び、所定のハッシュ関数を利用して証明書を算出する機能である。設定情報付加機能は、近接通信部１０４により送信される通信パケットに設定情報を付加する機能である。設定情報には、例えば、自装置のＩＰアドレス、乱数、及び証明書等が含まれる。設定情報抽出機能は、近接通信部１０４の受信パケットに付加された設定情報を抽出する機能である。

認証レコード付加機能は、後述するＮＤＥＦメッセージに認証フラグを示すＮＤＥＦ Ｒｅｃｏｒｄを付加する機能である。この認証フラグには、認証方式のＲｅｃｏｒｄであることを示す識別子と、認証方式を示す識別子と、ＷＬＡＮネットワークの構成を示す識別子とが含まれる。これらの識別子については、後段において詳述する。認証レコード抽出機能は、後述するＮＤＥＦメッセージに付加された認証フラグを示すＮＤＥＦ Ｒｅｃｏｒｄを抽出する機能である。

認証方式判定機能は、認証レコード抽出機能により抽出されたＮＤＥＦ Ｒｅｃｏｒｄの認証フラグを参照し、ＮＤＥＦメッセージの送信元装置が対応する認証方式を判定する機能である。また、認証方式判定機能は、送信元装置が対応する認証方式と、自装置が対応する認証方式とを比較し、より適した認証方式を選択する機能を含む。

［ＮＤＥＦメッセージの構成例］
次に、図１７を参照しながら、ＯＯＢ認証方式に適用可能な本実施形態に係るＮＤＥＦメッセージの構成例について説明する。図１７は、ＯＯＢ認証方式に適用可能な本実施形態に係るＮＤＥＦメッセージの構成例を示す説明図である。

上記の通り、ＷＬＡＮのＯＯＢ方式による認証処理においても、ＢＴのＯＯＢ方式による認証処理の場合と同様に、図４、及び図５に示すＮＤＥＦメッセージを用いて設定情報が交換される。但し、本実施形態に係るＮＤＥＦメッセージは、図１７に示すような構成を有する。

図１７に示すように、ＮＤＥＦメッセージは、例えば、３つのＮＤＥＦ Ｒｅｃｏｒｄにより構成される。第１のＮＤＥＦ Ｒｅｃｏｒｄ（Ｒｅｃｏｒｄ１）には、このＮＤＥＦメッセージがハンドオーバー用であることを示すハンドオーバー用Ｒｅｃｏｒｄ Ｔｙｐｅが格納されている。第２のＮＤＥＦ Ｒｅｃｏｒｄ（Ｒｅｃｏｒｄ２）には、例えば、Ｒｅｃｏｒｄ ＴｙｐｅがＷＬＡＮであることを示す“ａｐｐｌｉｃａｔｉｏｎ／ｖｎｄ．ｗｆａ．ｗｓｃ”が格納されており、そのペイロードにＷＬＡＮの設定情報が格納されることが示されている。

ペイロードの種類には、「ＯＯＢ Ｄｅｖｉｃｅ Ｐａｓｓｗｏｒｄ」、「Ｃｒｅｄｅｎｔｉａｌ」、又は「空」がある。「ＯＯＢ Ｄｅｖｉｃｅ Ｐａｓｓｗｏｒｄ」としては、ＷＰＳの仕様中で規定された３２バイトの公開鍵（Ｄｅｖｉｃｅ Ｐａｓｓｗｏｒｄ）、又は証明書の生成に利用される２０バイトのハッシュ値（Ｈａｓｈ）等が格納される。「Ｃｒｅｄｅｎｔｉａｌ」としては、ＡＰの設定に必要なＳＳＩＤ、伝送路の暗号化に利用される暗号鍵（ＮｅｔｗｏｒｋＫｅｙ）等の情報が格納される。これらの情報は、Ｔｙｐｅ、Ｌｅｎｇｔｈ、Ｖａｌｕｅ（ＴＬＶ）方式にて格納される。一方、自装置に設定情報が存在せず、相手装置に設定情報を要求する場合、ペイロードは「空」になる。

さらに、本実施形態に係るＮＤＥＦメッセージには、第３のＮＤＥＦ Ｒｅｃｏｒｄ（Ｒｅｃｏｒｄ３）が付加される。この第３のＮＤＥＦ Ｒｅｃｏｒｄには、認証方式を示すＲｅｃｏｒｄであることを識別するための第１識別子と、認証方式を示す第２識別子と、ＷＬＡＮネットワーク構成を示す第３識別子とが含まれる。

本実施形態において、第２識別子は、自装置がＷＰＳにより規定された「ＯＯＢ Ｄｅｖｉｃｅ Ｐａｓｓｗｏｒｄ」に対応するか否かを示すフラグ（ａ）と、「Ｃｒｅｄｅｎｔｉａｌ」に対応するか否かを示すフラグ（ｂ）と、認証設定情報の時限設定が可能か否かを示すフラグ（ｃ）とにより構成される。この認証設定情報の時限設定とは、認証により設定された情報がＷＬＡＮ接続が確立された段階で消去できるようにする設定である。また、第３識別子は、ＷＬＡＮで形成されるネットワーク構成として、ａｄ−ｈｏｃネットワークに対応するか否かを示すフラグ（ａ）と、自装置に割り当てられるＩＰアドレス（ｂ）と、接続先に接続許可を与えるポート番号（ｃ）と、ＦＴＰユーザ名／パスワード（ｄ，ｅ）とが含まれる。但し、ＦＴＰユーザ名／パスワードは、ＦＴＰサービスが提供される場合に含まれる。

［認証処理の流れ］
次に、図１８、及び図１９を参照しながら、本実施形態に係る認証処理の流れについて説明する。図１８、及び図１９は、本実施形態に係る認証処理の流れを示す説明図である。この認証処理の中で、上記構成のＮＤＥＦメッセージが利用される。

図１８を参照する。まず、自装置（Ｅｎｒｏｌｌｅｅ）がＷＰＳの認証方式に対応するか否か、且つ、ＡＰの通信圏内（電波到達範囲内）か否かが判定される（Ｓ２０２）。自装置がＷＰＳの認証方式に対応し、且つ、ＡＰの通信圏内である場合、ステップＳ２０４の処理に進行する。一方、両条件のいずれかが満たされない場合、ステップＳ２２０の処理に進行する。

ステップＳ２０４において、自装置及び接続先装置の双方がＷＰＳ Ｐａｓｓｗｏｒｄ（公開鍵暗号方式）に対応するか否かが判定される（Ｓ２０４）。双方がＷＰＳ Ｐａｓｓｗｏｒｄに対応している場合、ステップＳ２０６の処理に進行する。一方、双方がＷＰＳ Ｐａｓｓｗｏｒｄに対応していない場合、ステップＳ２１４の処理に進行する。

この判定処理において、自装置の制御部１６０により、ＷＰＳにおける公開鍵方式の設定パラメータ「ＯＯＢ Ｄｅｖｉｃｅ Ｐａｓｓｗｏｒｄ」に対応可否を示すフラグ（第２識別子）が設定される。また、自装置の制御部１６０により、上記の第３識別子にＷＬＡＮのネットワーク構成情報が設定される。そして、自装置の制御部１６０により、第２及び第３識別子が設定された第３のＮＤＥＦ ＲｅｃｏｒｄがＮＤＥＦメッセージ内に付加され、ＮＦＣ通信にて接続先装置に送信される。さらに、ＮＦＣ通信パケットを受信した接続先装置は、制御部１６０により、Ｅｎｒｏｌｌｅｅの認証フラグ（第３のＮＤＥＦ Ｒｅｃｏｒｄ）が抽出されて、ＥｎｒｏｌｌｅｅがＷＰＳ Ｐａｓｓｗｏｒｄに対応するか否かが判定される。

ステップＳ２０６以降において、図２０に示すようなＡＰ−ＢＳ間通信によるＩｎｆｒａネットワークが形成される。このケースは、接続先装置がＲｅｇｉｓｔｒａｒ機能を有している場合に対応している。

ステップＳ２０６では、ＡＰ／ＲｅｇｉｓｔｒａｒとＢＳ／Ｅｎｒｏｌｌｅｅとの間において、ＮＦＣ通信により公開鍵、及び証明書が交換される（Ｓ２０６）。ＮＦＣ通信で交換された証明書により、通信相手が互いに不正者か否かが判断される。互いに不正者でないと判断されると、交換された公開鍵により暗号化された設定情報がＷＬＡＮ通信にて交換される（Ｓ２０８）。次いで、交換された設定情報に基づいてＡＰ／ＲｅｇｉｓｔｒａｒにＢＳ／Ｅｎｒｏｌｌｅｅが登録される（Ｓ２１０）。その後、ＢＳ／Ｅｎｒｏｌｌｅｅは、ＮＦＣ通信パケットのＮＤＥＦメッセージに含まれるＡＰのＩＰアドレス、及び公開ポート番号に基づいてＷＬＡＮによる通信処理を実現する（Ｓ２１２）。

次に、ステップＳ２０４において、いずれか一方又は両方の装置がＷＰＳ Ｐａｓｓｗｏｒｄに対応していないと判断された場合について説明する。ステップＳ２１４において、双方がＷＰＳ Ｃｒｅｄｅｎｔｉａｌに対応しているか否かが判定される。双方がＷＰＳ Ｃｒｅｄｅｎｔｉａｌに対応している場合、ステップＳ２１６の処理に進行する。一方、いずれか一方又は両方がＷＰＳ Ｃｒｅｄｅｎｔｉａｌに対応していない場合、ステップＳ２２０の処理に進行する。

ステップＳ２１６以降において、ＢＳ−ＢＳ間でＮＦＣ通信が実現され、図２１に示すようなＲｅｇｉｓｔｒａｒを経由しないＩｎｆｒａネットワークが形成される場合のセットアップ手順が示される。

ステップＳ２１６では、Ｉｎｆｒａネットワークに接続されているＢＳ間でＮＦＣ通信により、ＡＰの設定情報が交換される（Ｓ２１６）。このとき、ＡＰの設定情報は、暗号化されていない平文で送信される。次いで、ＢＳ／Ｅｎｒｏｌｌｅｅは、ＮＦＣ通信で取得したＡＰの設定情報に基づいてＷＬＡＮの接続認証を要求する（Ｓ２１８）。ＡＰとＢＳ／Ｅｎｒｏｌｌｅｅとの間で接続が確立されると、ＢＳ／Ｅｎｒｏｌｌｅｅは、ＮＦＣ通信で既に取得していたＡＰのＩＰアドレス、及び公開ポートに基づいて接続相手先のＢＳとの間でＩＰパケットの送受信を行う（Ｓ２１２）。

次に、ステップＳ２１４において、いずれか一方又は両方の装置がＷＰＳ Ｃｒｅｄｅｎｔｉａｌに対応していないと判断された場合、或いは、ステップＳ２０２において自装置がＷＰＳに非対応、又はＡＰの通信圏内にないと判断された場合について説明する。いずれの場合においても、Ｉｎｆｒａモードでの接続ができないため、図２２に示すようなａｄ−ｈｏｃモードのネットワーク構成が選択される。

ステップＳ２２０において、ＢＳ／Ｅｎｒｏｌｌｅｅがａｄ−ｈｏｃモードに対応可能か否かが判断される（Ｓ２２０）。ＢＳ／Ｅｎｒｏｌｌｅｅがａｄ−ｈｏｃモードに対応可能である場合、ステップＳ２２４の処理に進行する。一方、ＢＳ／Ｅｎｒｏｌｌｅｅがａｄ−ｈｏｃモードに対応不可能である場合、ネットワークの形成処理が失敗し（Ｓ２２２）、一連の処理が終了する。この処理において、接続先のＢＳは、ＮＤＥＦメッセージに基づいてＢＳ／Ｅｎｒｏｌｌｅｅがａｄ−ｈｏｃモードに対応可能な否かを判断する。

ステップＳ２２４以降において、ＢＳ／Ｅｎｒｏｌｌｅｅ、及び接続先のＢＳがａｄ−ｈｏｃモードに対応可能であることを前提としてセットアップ手順が示される。

ステップＳ２２４において、接続先のＢＳは、ａｄ−ｈｏｃモードのネットワーク形成に必要な設定情報として、ＳＳＩＤ、Ｎｅｔｗｏｒｋ Ｋｅｙ等の設定情報をＮＦＣ通信によってＢＳ／Ｅｎｒｏｌｌｅｅに送信する。このとき、接続先のＢＳは、ＮＦＣ通信を介してＩＰアドレス、公開ポート等のネットワーク設定情報も送信する（Ｓ２２４）。

このとき、接続先のＢＳとＡＰとの間でＩｎｆｒａモードのネットワークが形成されている場合、このネットワーク接続が切断される。ａｄ−ｈｏｃネットワークの生成に必要な情報が共有されると、双方のＢＳが接続され（Ｓ２２６）、ＮＦＣ通信で取得されたＩＰアドレスに基づいて互いにＩＰパケットの送受信が可能な状態になる（Ｓ２１２）。

本実施形態に係るＮＦＣパケットの構成を適用すると、上記のような手順により、図２０、図２１、図２２のいずれかの形態を有するネットワークが形成される。次に、図１９を参照しながら、上記の手順で形成されたネットワークが切断された後の処理について説明する。図１９は、ネットワーク切断後の処理の流れを示す説明図である。

図１９に示すように、上記の手順でネットワーク接続が確立されると、双方が既に取得しているＩＰアドレス又は特定のＵＲＬを用いて、相互に通信することができる（Ｓ２１４）。その後、ネットワークが切断されると（Ｓ２１６）、ステップＳ２１８の処理に進行
する。ステップＳ２１８では、双方が一時接続に対応しているか否かが判断される（Ｓ２１８）。双方が一時接続に対応している場合、ステップＳ２２２の処理に進行する。一方、一方又は双方が一時接続に対応していない場合、ステップＳ２２０の処理に進行する。

既に述べた通り、ＮＤＥＦメッセージに含まれる第３のＮＤＥＦ Ｒｅｃｏｒｄ中には、認証フラグの１つとして一時接続対応フラグが含まれていた（図１７を参照）。上記の判定処理は、この一時接続対応フラグに基づいて実行される。もし、接続元、及び接続先のいずれにおいても、このフラグが無効になっていた場合、互いのネットワーク設定情報が保存され、次回の接続時にも設定情報が有効であるため（Ｓ２２０）、新たな認証処理の必要が無くなる。

逆に、双方の機器が一時接続に対応している場合、双方の機器に格納されていたＳＳＩＤ、Ｎｅｔｗｏｒｋ Ｋｅｙが削除される（Ｓ２２２、Ｓ２２４）。さらに、接続先のＭＡＣアドレスが削除される（Ｓ２２６）。このように、設定情報が無効にされるため（Ｓ２２８）、次回、再接続する際には、双方の機器はこれらの設定パラメータを再度交換する必要がある。このような設定にすると、ネットワーク設定情報が一時的な使い捨て情報となる。このため、ａｄ−ｈｏｃモードの場合、ネットワークが形成される度にＳＳＩＤ、ネットワークキーが交換されるため、セキュリティ強度が向上する。

尚、上記の第１実施形態の場合と同様に、認証時に毎回、ＧＵＩ経由でユーザの承認を得る工程（図１１を参照）が追加されることにより、不正者が関知しない期間にネットワークに接続する機会が低減され、よりセキュリティの向上が図れる。

以上、本発明に係る２つの実施形態について説明した。これらのＮＦＣ通信を用いたＢＴ及びＷＬＡＮの簡単セットアップ方式を採用することで、設定情報を平文でＮＦＣ伝送するような場合であっても、認証受け入れ期間、及び認証許可アドレスの制限により、盗聴者によるネットワークへの進入可能性が低減される。

また、表示デバイスを経由した承認手順を設けることにより、不正者が許可なく認証作業を開始することが防止される。そのため、公開鍵暗号化ロジックを搭載しない製品構成であっても、制御ソフトウェアの変更だけで安全且つ簡単なセットアップが実現される。

また、標準化された簡単セットアップ規格（ＢＴ Ｃｏｒｅ規格のバージョン２．１、又はＷＬＡＮのＷＰＳ方式）に準拠した製品と、未対応の既存製品が並存する場合であっても、上記の実施形態に例示したＮＦＣ通信パケットのフォーマットを利用することで、互いの規格対応状況を交換し、実施の態様に適した方式を選択することができるようになる。その結果、ＮＦＣ通信を使った認証方式において、これらの異なる認証方式間における互換性を維持することができるようになる。

さらに、ＮＦＣ通信パケットの中に、認証後に形成されるネットワークの構成情報を格納して通信装置間で交換することにより、所定のネットワーク構成の中で、より適したネットワーク内の役割分担、又は接続モードの選択が可能になる。

［非接触通信装置の装置構成例］
ここで、図２３を参照しながら、上記の装置が有する機能の一部又は全部を実現することが可能な非接触型の通信装置の装置構成例について簡単に説明する。図２３は、非接触通信装置の装置構成例を示す説明図である。尚、上記の装置が有する機能は、この非接触通信装置が有する構成要素の一部のみを利用して実現してもよい。また、重複する符号が付された構成要素は、一体のハードウェア資源により構成されていてもよい。

図２３に示すように、この通信装置は、主に、ＩＣカード部分と、リーダ／ライタ部分と、コントローラ７２２とにより構成される。

（ＩＣカード部分）
ＩＣカード部分は、例えば、アンテナ７０２と、フロントエンド回路７０４と、変調器７０６と、コマンド再生器７０８と、クロック再生器７１０と、制御回路７１２と、暗号化回路７１４と、メモリ７１６と、有線インターフェース回路７１８とで構成される。

アンテナ７０２は、ループ・アンテナにより構成され、リーダ／ライタが有するループ・アンテナと磁気的に結合してコマンドや電力を受け取る。フロントエンド回路７０４は、リーダ／ライタから送出された搬送波を整流して直流電源を再生する。また、フロントエンド回路７０４は、取得した１３．５６ＭＨｚの搬送波を分周してコマンド再生器７０８、及びクロック再生器７１０に入力する。コマンド再生器７０８は、入力された搬送波からコマンドを再生して制御回路７１２に入力する。クロック再生器７１０は、入力された搬送波からロジック回路を駆動するためのクロックを再生して制御回路７１２に入力する。また、フロントエンド回路７０４は、再生した電源を制御回路７１２（ＣＰＵ）に供給する。

全ての回路に電源が供給されると、制御回路７１２は、再生されたコマンドに応じて各回路を駆動する。尚、制御回路７１２から出力されたデータは、暗号化回路７１４により暗号化されてメモリ７１６に格納される。尚、メモリ７１６は、例えば、磁気的、光学的、又は光磁気的に情報を記録する記憶装置であってもよいし、ＲＯＭやＲＡＭ等に利用される半導体記憶装置であってもよい。

一方、メモリ７１６内に格納された暗号化データを送信する場合、フロントエンド回路７０４は、変調器７０６により変調された暗号化データに基づいてアンテナ７０２の給電点にある負荷インピーダンスを変化させ、その変化によりアンテナ７０２によって誘起される磁界を変化させる。この磁界変化により、磁気的に結合したリーダ／ライタのアンテナを流れる電流変化が誘起されて暗号化データが伝送される。

また、制御回路７１２は、有線インターフェース回路７１８を介してコントローラ７２２により制御されてもよい。また、ＩＣカード部分は、インターフェースＩ／Ｆ（未図示）を介して、後述のリーダ／ライタ部分との間で情報を送受信し、相互に又は一方から他方を制御することが可能であってもよい。

（リーダ／ライタ部分）
リーダ／ライタ部分は、例えば、アンテナ７０２と、フィルタ７３２と、受信アンプ７３４と、周波数変換器７３６と、識別器７３８と、ロジック回路７４０と、制御回路７１２と、メモリ７１６と、有線インターフェース回路７４２と、変調器７４６と、局部発振器７５０と、送信アンプ７４８とにより構成される。

リーダ／ライタ部分は、非接触ＩＣカード等との磁気的な結合を利用してコマンドや電力を供給する。このリーダ／ライタ部分は、制御回路７１２（ＣＰＵ）の制御により、非接触ＩＣカード等に電力を供給して活性化させてから、所定の伝送プロトコルに従って通信を開始する。このとき、リーダ／ライタ部分は、通信接続の確立、アンチコリジョン処理、及び認証処理等を行う。

リーダ／ライタ部分は、局部発振器７５０を利用して搬送波を生成する。リーダ／ライタ部分が情報を送信する場合、まず、制御回路７１２は、メモリ７１６からデータを読み出してロジック回路７４０に伝送する。そして、変調器７４６は、ロジック回路７４０から出力された信号に基づいて局部発振器７５０により生成された搬送波を変調する。さらに、送信アンプ７４８は、変調器７４６から出力された変調波を増幅し、アンテナ７０２を介して送信する。

一方、リーダ／ライタ部分が情報を受信する場合、まず、アンテナ７０２を介して受信された変調波は、フィルタ７３２を通した上で受信アンプ７３４に入力される。そして、受信アンプ７３４により増幅された信号は、周波数変換器７３６により周波数変換されてロジック回路７４０に入力される。さらに、ロジック回路７４０から出力された信号は、制御回路７１２によりメモリ７１６に記録される。或いは、当該信号は、有線インターフェース回路７４２を介して外部のコントローラ７２２に伝送される。

以上、非接触通信装置の装置構成例について説明した。当該非接触通信装置は、例えば、携帯電話、携帯情報端末、各種の通信機器、パーソナルコンピュータ等の情報処理装置、或いは、ゲーム機や情報家電等であってもよい。また、上記の非接触通信装置が有する機能又は構成要素の一部又は全部を内蔵した各種の機器についても、上記実施形態の技術的範囲に含まれる。

［ハードウェア構成（情報処理装置）］
上記装置が有する各構成要素の機能は、例えば、図２４に示すハードウェア構成を有する情報処理装置により、上記の機能を実現するためのコンピュータプログラムを用いて実現することが可能である。図２４は、上記装置の各構成要素が有する機能を実現することが可能な情報処理装置のハードウェア構成を示す説明図である。

図２４に示すように、前記の情報処理装置は、主に、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）９０２と、ＲＯＭ９０４と、ＲＡＭ９０６と、ホストバス９０８と、ブリッジ９１０と、外部バス９１２と、インターフェース９１４と、入力部９１６と、出力部９１８と、記憶部９２０と、ドライブ９２２と、接続ポート９２４と、通信部９２６とにより構成される。

ＣＰＵ９０２は、例えば、演算処理装置又は制御装置として機能し、ＲＯＭ９０４、ＲＡＭ９０６、記憶部９２０、又はリムーバブル記録媒体９２８に記録された各種プログラムに基づいて各構成要素の動作全般又はその一部を制御する。ＲＯＭ９０４は、例えば、ＣＰＵ９０２に読み込まれるプログラムや演算に用いるデータ等を格納する。ＲＡＭ９０６は、例えば、ＣＰＵ９０２に読み込まれるプログラムや、そのプログラムを実行する際に適宜変化する各種パラメータ等を一時的又は永続的に格納する。これらの構成要素は、例えば、高速なデータ伝送が可能なホストバス９０８によって相互に接続されている。また、ホストバス９０８は、例えば、ブリッジ９１０を介して比較的データ伝送速度が低速な外部バス９１２に接続されている。

入力部９１６は、例えば、マウス、キーボード、タッチパネル、ボタン、スイッチ、及びレバー等の操作手段である。また、入力部９１６は、赤外線やその他の電波を利用して制御信号を送信することが可能なリモートコントロール手段（所謂、リモコン）であってもよい。なお、入力部９１６は、上記の操作手段を用いて入力された情報を入力信号としてＣＰＵ９０２に伝送するための入力制御回路等により構成されている。

出力部９１８は、例えば、ＣＲＴ（Ｃａｔｈｏｄｅ Ｒａｙ Ｔｕｂｅ）、ＬＣＤ（Ｌｉｑｕｉｄ Ｃｒｙｓｔａｌ Ｄｉｓｐｌａｙ）、ＰＤＰ（Ｐｌａｓｍａ ＤｉｓｐｌａｙＰａｎｅｌ）、又はＥＬＤ（Ｅｌｅｃｔｒｏ−Ｌｕｍｉｎｅｓｃｅｎｃｅ Ｄｉｓｐｌａｙ）等のディスプレイ装置、スピーカ、ヘッドホン等のオーディオ出力装置、プリンタ、携帯電話、又はファクシミリ等、取得した情報を利用者に対して視覚的又は聴覚的に通知することが可能な装置である。

記憶部９２０は、各種のデータを格納するための装置であり、例えば、ハードディスクドライブ（ＨＤＤ；Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）等の磁気記憶デバイス、半導体記憶デバイス、光記憶デバイス、又は光磁気記憶デバイス等により構成される。

ドライブ９２２は、例えば、磁気ディスク、光ディスク、光磁気ディスク、又は半導体メモリ等のリムーバブル記録媒体９２８に記録された情報を読み出し、又はリムーバブル記録媒体９２８に情報を書き込む装置である。リムーバブル記録媒体９２８は、例えば、ＤＶＤメディア、Ｂｌｕ−ｒａｙメディア、ＨＤ−ＤＶＤメディア、コンパクトフラッシュ（登録商標）（ＣＦ；ＣｏｍｐａｃｔＦｌａｓｈ）、メモリースティック、又はＳＤメモリカード（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ ｍｅｍｏｒｙ ｃａｒｄ）等である。もちろん、リムーバブル記録媒体９２８は、例えば、非接触型ＩＣチップを搭載したＩＣカード、又は電子機器等であってもよい。

接続ポート９２４は、例えば、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）ポート、ＩＥＥＥ１３９４ポート、ＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）、ＲＳ−２３２Ｃポート、又は光オーディオ端子等のような外部接続機器９３０を接続するためのポートである。外部接続機器９３０は、例えば、プリンタ、携帯音楽プレーヤ、デジタルカメラ、デジタルビデオカメラ、又はＩＣレコーダ等である。

通信部９２６は、ネットワーク９３２に接続するための通信デバイスであり、例えば、有線又は無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、Ｂｌｕｅｔｏｏｔｈ（登録商標）、又はＷＵＳＢ（Ｗｉｒｅｌｅｓｓ ＵＳＢ）用の通信カード、光通信用のルータ、ＡＤＳＬ（Ａｓｙｍｍｅｔｒｉｃ Ｄｉｇｉｔａｌ Ｓｕｂｓｃｒｉｂｅｒ Ｌｉｎｅ）用のルータ、又は各種通信用のモデム等である。また、通信部９２６に接続されるネットワーク９３２は、有線又は無線により接続されたネットワークにより構成され、例えば、インターネット、家庭内ＬＡＮ、赤外線通信、可視光通信、放送、又は衛星通信等である。尚、通信部９２６の機能に上記の非接触通信装置が備える非接触通信機能を含めてもよい。

［補遺１：＜ＳＳＰ方式について＞］
上記の第１実施形態に係る技術は、以下で説明するＳＳＰ方式に対し、好適に適用することが可能である。そこで、ＳＳＰ方式に係る認証方法について、以下で詳細に説明する。尚、上記の第１実施形態の説明において記載されたパラメータは、その表記が対応するように同じ記号で表現されている。そのため、上記の第１実施形態に係る技術を下記のＳＳＰ方式に適用する際には、パラメータ表記の対応関係を意識することで、技術的な対応関係が容易に把握されるであろう。

［１：ＳＳＰ方式の提案モデル］
ＳＳＰ方式には、４つのモデルが提案されている。これらの４つのモデルは、それぞれ、数字比較モデル、ＪＷ（Ｊｕｓｔ Ｗｏｒｋ）モデル、ＯＯＢモデル、パスキー入力モデルと呼ばれる。以下、これらの提案モデルについて簡単に説明する。

（１−１：数字比較モデル）
数字比較モデルは、次のようなシナリオを想定している。（１）互いに通信するデバイスの両方が６桁の数字を表示できるものとする。（２）これらの両方のデバイスには、”Ｙｅｓ”又は”Ｎｏ”のユーザ入力が可能であるとする。このシナリオには、例えば、セルラーフォンやパーソナルコンピュータが適用される。

（ペアリングの確立手順について）
まず、ユーザは、両方のデバイスが備えるディスプレイ上に表示された６桁の数字（”００００００”から”９９９９９９”まで）を視認する。それから、ユーザは、両方のデバイスに表示された数字が同じであるか否かを尋ねられる。そこで、ユーザは、両方のデバイスに”ＹＥＳ”又は”ＮＯ”を入力する。もし、”ＹＥＳ”が両方のデバイスに入力されたならば、ペアリングが成立する。

（数字比較モデルの目的）
この数字比較モデルには２つの目的がある。１つ目の目的は、個々のデバイスに固有の名前を持っていない場合に、正しいデバイスがそれぞれ接続されたという承認をユーザに対して与えるということである。２つ目の目的は、中間者攻撃（ｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ ａｔｔａｃｋ）に対する防衛手段を提供することである。

尚、Ｃｏｒｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎｓ ２．０＋ＥＤＲ以前の規格で利用されるＰＩＮ入力モデルと、この数字比較モデルとの間には、暗号化技術に係る観点から重大な相違があるという点に注意が必要である。この数字比較モデルで利用される６桁の数字は、人工的なセキュリティアルゴリズムに基づくものであり、現行のセキュリティモデルのようなユーザの手で入力されるものではない。当然の事ながら、表示された数字が知らされることにより、両方のデバイス間で交換される暗号データが復号される危険性が高まるため、これを避けるように構成されているのである。

（１−２：ＪＷモデル）
ＪＷモデルでは、次のようなシナリオが想定されている。このシナリオでは、少なくとも１つのデバイスが、６桁の数字が表示できるディスプレイを備えていないか、或いは、６桁の数字を入力するためのキーボードを備えていないということが想定されている。このシナリオには、例えば、携帯電話や単体のハンドセットが適用される。現状、大部分のハンドセットはディスプレイを持っていないからである。

ＪＷモデルは、数字比較方式を利用する。しかし、ユーザには、数字が表示されることはない。また、アプリケーションは、ユーザに対して単に接続の承認を尋ねるだけである。ＪＷモデルは、受動的な盗聴に対して上記の数字比較モデルと同等の耐性を備えた防御手段を提供する。但し、中間者攻撃に対する防御手段を提供するものではない。

一般的なハンドセット等による４桁の数字（固定ＰＩＮ）を利用したセキュリティモデルと比較するとき、ＪＷモデルのセキュリティレベルは比較的高いと考えられる。その理由は、受動的な盗聴に対する高い耐性が実現されているためである。

（１−３：ＯＯＢモデル）
ＯＯＢ（Ｏｕｔ Ｏｆ Ｂａｎｄ）モデルは、次のようなシナリオを想定している。まず、ＯＯＢの技術は、ペアリングの工程で暗号数字を交換する際又は送信する際に、両方のデバイスを発見するために用いられる。但し、このＯＯＢチャネルは、セキュリティに関する効果を期待して、デバイスの発見とは異なる目的でも提供されるべきである。例えば、ＯＯＢチャネルは、ＢＴの通信チャネルにおけるセキュリティを高めるために提供されるべきである。ＯＯＢチャネルは、中間者攻撃、及びプライバシーの侵害に対する防御手段を提供する。

尚、ユーザの操作はＯＯＢの機構に依存して異なるかもしれない。例えば、ＯＯＢとして近接場通信（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ；ＮＦＣ）を適用する場合、ユーザは、はじめに２つのデバイスを互いにタッチさせる。それから、ユーザは、他のデバイスとペアリングを構成したいか否かを尋ねられる。そこで、ユーザは、”ＹＥＳ”又は”ＮＯ”を入力する。”Ｙｅｓ”が入力されると、ペアリングが形成される。

上記の操作は、デバイス間で情報を交換するためのシングルタッチの操作である。この交換される情報には、ＢＤの発見に利用されるＢＤアドレスのようなデバイス情報と、暗号化に利用されるセキュリティ情報とが含まれる。デバイスの一方は、受信したＢＤアドレスを他のデバイスとの間の接続を確立するために利用することができる。一方、交換されたセキュリティ情報は、認証処理において利用される。尚、ＯＯＢの機構が有する特徴に依存して、１方向、又は双方向の認証処理が実現される。

ＯＯＢ方式は、次のような場合にのみ選択される。例えば、ＯＯＢによる情報交換によりペアリングが既に有効化されていた場合や、一方又は両方のデバイスが入出力機能の有無（ＩＯ Ｃａｐａｂｉｌｉｔｙ；Ｉｎｐｕｔ／Ｏｕｔｐｕｔ Ｃａｐａｂｉｌｉｔｙ）を応答する際にＯＯＢ方式に対応可能であることを通知した場合である。

ＯＯＢ方式では、ユーザに対して単に接続の承認を尋ねるための情報が利用される。尚、ＯＯＢモデルには、暗号化に必要な情報、及びＢＤアドレスを交換可能な機構であれば、任意のＯＯＢ機構を適用することができる。また、このＯＯＢモデルでは、ユーザがＢＴ通信を利用して既に接続を有効にした手段をサポートせず、接続に際して認証処理のためにＯＯＢチャネルが利用される。

（１−４：パスキー入力モデル）
パスキー入力モデルは、次のようなシナリオを想定している。（１）一方のデバイスは、入力機能を備えており、かつ、６桁の数字を表示する機能を備えていない。（２）そして、他方のデバイスは、出力機能を備えている。このシナリオは、例えば、パーソナルコンピュータとキーボードの組み合わせに適用される。

まず、ユーザに対し、一方のデバイスが備えるディスプレイ上に６桁の数字（”００００００”から”９９９９９９”まで）が表示される。それから、ユーザは、他方のデバイスにより表示された数字を入力するように求められる。表示された数字が他方のデバイスに正しく入力された場合にペアリングが形成される。

［２：セキュリティ確立手段］
ＳＳＰ方式のセキュリティ確立手段は、次のような５つのフェーズにより構成される。
フェーズ１：公開鍵の交換
フェーズ２：認証ステージ１
フェーズ３：認証ステージ２
フェーズ４：リンクキーの算出
フェーズ５：ＬＭＰ認証、及び暗号化

フェーズ１、３、４、５は、上記の全てのモデルで同じである。但し、フェーズ２（認証ステージ１）に関しては、適用するモデルに依存して若干異なる。尚、以下の説明において、下表１で定義される表現（［Ｔｅｒｍ］）が用いられる。

（２−１：フェーズ１＜公開鍵の交換＞（図２５（Ａ）を参照））
まず、各デバイスがＥＣＤＨ（Ｅｌｌｉｐｔｉｃ Ｃｕｒｖｅ Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ）方式に基づいて自身の公開鍵／秘密鍵のペア（ＰＫ，ＳＫ）を生成する（ステップ１）。この鍵ペアは、デバイスの組毎に１度だけ生成される。この鍵ペアは、ペアリング処理の開始前に算出されていてもよい。また、任意の時点で、その鍵ペアはデバイスにより放棄され、新たな鍵ペアが生成されることがある。

ペアリングは、初期化デバイス（Ｉｎｉｔｉａｔｉｎｇ Ｄｅｖｉｃｅ Ａ）により、受信側のデバイス（以下、応答デバイス（Ｎｏｎ−ｉｎｉｔｉａｔｉｎｇ Ｄｅｖｉｃｅ Ｂ））に公開鍵が送信されることで開始される（ステップ１ａ）。応答デバイスは、初期化デバイスによる公開鍵の送信に応じて、自身の公開鍵を初期化デバイスに送信する（ステップ１ｂ）。双方の公開鍵（ＰＫａ，ＰＫｂ）は、たとえ、デバイスを認証するものであろうとも、秘密のものと見なされない。尚、ステップ１ａ、１ｂは、上記の全てのモデルで共通である。

（２−２：フェーズ２＜認証ステージ１＞（図２６〜図２８を参照））
認証ステージ１は、上記の３つのモデル（数字比較モデル、ＯＯＢモデル、パスキー入力モデル）の間で処理が異なる。いずれのモデルを選択するかは、両方のデバイスの入出力機能の有無に基づいて決定される。尚、図２５〜図２８の中で、文頭に記載された数字はステップを表す。

（２−２−１：認証ステージ１（数字比較モデル／図２６））
数字比較モデルは、効果的な中間者攻撃に対して一定の耐性を有する防御手段を提供する。１度の中間者攻撃に対し、０．０００００１程度の確率でしか攻撃が成功しないであろう。もし、ペアリングされている時点で中間者攻撃がないならば、共有されているリンクキーは、計算上、ペアリングされている間の受動的な盗聴に対しても安全である。

以下、暗号化の観点から、数字比較モデルにおける認証ステージ１（Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｓｔａｇｅ １）のシーケンスダイアグラムについて説明する。

公開鍵が交換された後で、各デバイスは、一時的な１２８ビットの疑似乱数（Ｎａ，Ｎｂ）を生成する（ステップ２ａ，２ｂ）。この疑似乱数値は、反復攻撃を避けるために利用される。また、この疑似乱数値は、ペアリングが形成される毎に新規に生成されなければならない。さらに、この疑似乱数値は、物理的な乱数発生源、又は物理的な発生源による乱数値をシードとする優れた疑似乱数発生器から直接生成されるべきである。

次いで、対向するデバイスは、双方の公開鍵に対応した証明書（Ｃａ，Ｃｂ）を算出する。この証明書は、一時的な疑似乱数を用いて生成されているため、それ自体が一時値である（ステップ３ｃ）。この証明書は、その証明書の算出に利用されるパラメータの入力に対して１方向性を有する関数（ｆ１）によって算出される。次いで、この証明書は、初期化デバイスに送信される（ステップ４）。尚、この証明書は、一時期間を経過した後で攻撃者によりパラメータが変更されるのを避けるために利用される。

次いで、初期化デバイス、及び応答デバイスは、上記の一時値（疑似乱数値（Ｎａ，Ｎｂ））を交換する（ステップ５、６）。次いで、初期化デバイスは、その証明書が正しいか否かを確認する（ステップ６ａ）。ステップ６ａにおける確認の失敗は、攻撃者の存在、又は他の送信エラーが存在することを示すものである。もし、確認が失敗したならば、このモデルにおけるペアリングの形成処理は破棄される。尚、これらのステップは、新たな鍵ペアが生成された際に、又は、新たな鍵ペアが生成されていなくても繰り返し実行されることがある。しかし、そうしたステップが繰り返されるならば、新たな一時値が生成されねばならない。

さて、証明書のチェックが成功した場合、双方のデバイスは、６桁の数字（認証値（Ｖａ，Ｖｂ））をそれぞれ算出する。この認証値は、ユーザに提示されるために、各デバイスが備えるディスプレイ上に表示される（ステップ７ａ、７ｂ、８）。ユーザには、これらの６桁の認証値が一致しているか否か、或いは、一致しているものがあるか否かの確認が期待される。もし、一致しているものがないならば、その認証ステップは破棄される。さらに、その認証ステップが繰り返されるならば、新たな一時値が生成されねばならない。

尚、狡猾な中間者によりサービス否認以外の任意の影響が及ばないように、認証プロセスにおいて自身のデバイスに関する鍵の情報が認証の際に利用される。単純な中間者攻撃であれば、０．９９９９９９の確率で異なる２組の６桁の表示値に帰着するであろう。より洗練された攻撃であれば、技術者に対し、表示値を一致させるように試みるかもしれないが、上記の認証処理シーケンスにより防ぐことができる。

（２−２−２：認証ステージ１＜ＯＯＢモデル＞（図２７））
ＯＯＢモデルは、ＬＭＰ入出力機能の可否に関する情報を交換するシーケンスの中で、認証に利用されるセキュリティ情報が少なくとも一方のデバイスによって受信され、その中にＯＯＢ認証データ存在パラメータ（ＯＯＢ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｄａｔａ Ｐｒｅｓｅｎｔ ｐａｒａｍｅｔｅｒ）が含まれる場合に選択される。

両方のデバイスがＯＯＢチャネルを介してデータを送信及び／又は受信できるならば、相互認証は、ＯＯＢ公開鍵（ＰＫａ，ＰＫｂ）に基づく証明書（Ｃａ，Ｃｂ）が認証ステージの中で交換されることにより実現されることになる。

１．ＯＯＢ通信が１方向でのみ可能である場合（例えば、受動的なＮＦＣタグ等で構成されるデバイスを適用する場合、又は一方のデバイスが読み込み専用のものである場合）、ＯＯＢ通信における受信デバイスの認証は、ＯＯＢ通信を介して送信された乱数ｒを知っているデバイスにより実現される。このケースにおいて、乱数ｒは、秘密でなければならない。また、乱数ｒが毎回新たに生成されるか、或いは、乱数ｒを送信するデバイスへのアクセスが制限されていなければならない。もし、乱数ｒがデバイスに送られなかったならば、ステップ４ａ、４ｂの中でＯＯＢ情報（Ａ，Ｂ，ｒａ，ｒｂ，Ｃａ，Ｃｂ）を受信したデバイスにより、ｒが０であると設定される。

もし、ＯＯＢ通信が堅牢なものであるならば（例えば、中間者攻撃を防御可能であるならば）、ＯＯＢモデルは、中間者攻撃による影響を受けにくいものであると言える。また、ＯＯＢモデルの中で、認証に利用されるパラメータ（Ｃａ、Ｃｂ、ｒａ、ｒｂ）のサイズは、ユーザが読み易いか、或いは、手入力し易いかということに配慮して制限されることがない。こうした理由により、ＯＯＢモデルは、数字比較モデル、又はパスキー入力モデルよりも、よりセキュアにすることができる。しかしながら、両方のデバイスが相互に対応するＯＯＢインターフェースを有することが必要となる。

デバイスＡ、Ｂの役割：ＯＯＢモデルにおいて、デバイスＡとデバイスＢには、その役割に関して対称性がある。まず、デバイスＡがいつもペアリングを開始することは要求されない。例えば、一方のデバイスがＮＦＣタグを備え、ＯＯＢ情報の送信のみができる場合、ＯＯＢ通信の中で自動的に非対称性が解決される。

しかしながら、ステップ１２（図２５（Ｂ））でリンクキー（ＬＫ）が計算される際、双方のデバイス群は、同じオーダー（秩序）のパラメータを入力しなければならない。但し、各デバイスにより異なる鍵が算出される。このオーダーとは、例えば、「デバイスＡ´のパラメータがピコネットマスターのパラメータであり、デバイスＢ´のパラメータがピコネットスレーブのパラメータである」といったものである。

ステップの順序：公開鍵の交換は、認証処理のステップ（ステップ５）よりも以前に実行されなければならない。ダイアグラムの中で、デバイス間におけるＢＴバンド内での公開鍵の交換（ステップ１）は、ＯＯＢ通信（ステップ４）の以前に実行される。しかし、ＯＯＢインターフェースによりペアリングを開始しようとすると、公開鍵の交換はＯＯＢ通信の後になってしまう（ステップ１がステップ４とステップ５との間になろう）。

ｒａ，ｒｂの値：ＯＯＢ通信が実行される以前には対向するデバイスのＯＯＢインターフェースの方向性が確認できないため、デバイスによりｒａ、ｒｂの値がいつも生成される。そして、可能ならば、ＯＯＢインターフェースを通じて対向するデバイスに乱数ｒが送信される。各デバイスは、自身のｒの値、及び対向するデバイスのｒの値をローカルで設定するために、次のようなルールを適用する。

１．最初、デバイスのｒが乱数に設定され、対向するデバイスのｒが０に設定される（ステップ２）。
２．デバイスがＯＯＢで情報を受信したならば、対向するデバイスにより送信されたｒ値を設定する（ステップ５）。
３．デバイスがＯＯＢ認証データを受信したと示さなければ、自身のｒ値を０に設定する（ステップ５）。

これらのルールにより、認証ステージ２でＯＯＢ通信が行われた際に、入力されたｒａ、ｒｂに関し、両方のデバイスＡ、Ｂが同じ値を持つことが確認される。

（２−２−２−１：ＯＯＢ機構の一例であるＮＦＣ）
ＮＦＣ（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ；近接場通信）デバイスは、異なるデータレート（１０６ｋｂｐｓ、２１２ｋｂｐｓ、４２４ｋｂｐｓ）にそれぞれ対応するモードや、異なるオペレーション（有効／無効）に対応するモードをサポートしている。

さらに、いくつかのＮＦＣデバイスは、初期化（初期化／リーダモード）の機能を有しており、接続（タグ／ターゲットモード）を許可する機能を有している。一方、他のデバイスは、接続を受け付ける能力のみを有している。例えば、ＯＯＢーＩＯ ＮＦＣデバイスは、他のＮＦＣデバイスに対し、データを送信したり、データを受信したりする機能を有すると共に、ＢＴ通信するための機能を有している。

ＯＯＢ機構に適用される場合、ＮＦＣデバイスに対して、デバイスＡ、Ｂが次の組み合わせとなるような３つのシナリオが想定されている。
（１）デバイスＡ：ＯＯＢ−ＩＯ ＮＦＣデバイス、かつ、デバイスＢ：ＯＯＢ−Ｏ ＮＦＣデバイスである場合、（２）デバイスＡ：ＯＯＢ−Ｏ ＮＦＣデバイス、かつ、デバイスＢ：ＯＯＢ−ＩＯ ＮＦＣデバイスである場合、（３）デバイスＡ：ＯＯＢ−ＩＯ ＮＦＣデバイス、かつ、デバイスＢ：ＯＯＢ−ＩＯ ＮＦＣデバイスである場合である（但し、ＯＯＢ−Ｏ：アウトプットのみ、ＯＯＢ−ＩＯ：インプット／アウトプット対応）。つまり、ＯＯＢ−Ｏ／ＯＯＢ−Ｏ（ｔａｇ／ｔａｇ）のケースが存在せず、一方のデバイスがリーダと成り得ることが求められる。

（２−２−３：認証ステージ１＜パスキー入力モデル＞（図２８））
パスキー入力モデルに関し、認証ステージ１におけるシーケンスダイアグラムについて説明する。

ユーザにより両方のデバイスに個々のパスキーが入力される代わりに、パスキー（ｒａ，ｒｂ）が生成され、一方のデバイスに表示される。そして、ユーザは、表示されたパスキーを他方のデバイスに入力する（ステップ２）。この短い共有値（ｒａ，ｒｂ）により、デバイス間の相互認証が実現される。ステップ３〜８は、ｋビットのパスキーに対し、ｋ回繰り返される。例えば、６桁の数字に対するパスキー（９９９９９９＝０ｘＦ４２３Ｆ）は、ｋ＝２０である。

ステップ３〜８において、各デバイスは、長い一時値（１２８ビット）を用いて、パスキーの各ビットを送る。さらに、一時値のハッシュ、パスキーのビット、及び他方のデバイスの公開鍵を送信する。

次いで、各デバイスは、互いの証明書を確認すべく、パスキーが相互に開示されるまで返信する。与えられたパスキーのビットについて証明書を折り返す最初のデバイスは、そのプロセスの中でパスキーのビットを効果的に返信する。しかし、他のデバイスは、与えられたパスキーのビットと同じ値を示すビットの証明書を返信するか、或いは、パスキーのビットが更に返信されなかった場合に、この認証ステップが破棄される。

この”漸次的な開示”は、中間者攻撃によりパスキーの情報が推測されないように１ビット以上の漏洩を避けるためのものである。パスキーの部分的な知識のみを有する中間者攻撃者は、この認証ステップが失敗する以前の不確かなパスキーの受信ビットしか推定できないことになる。ゆえに、０．０００００１の確率で成功する単純なＢｒｕｔｅ−ｆｏｒｃｅ攻撃者のような中間者攻撃者に対して、最大で２ビットの分の推測困難性を加えることができる。また、長い一時値は、認証ステップが失敗した後でさえも、ｂｒｕｔｅ−ｆｏｒｃｅ攻撃を困難にさせるための証明書のハッシュが含む。

標準的な中間者攻撃はＥＣＤＨを交換する両サイドで攻撃者の公開鍵を置き換える。このため、中間者攻撃を避けるために、オリジナルのＥＣＤＨ鍵の交換に際して、パスキー入力モデルのセキュリティを厳しくするために公開Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ値が含まれる。このステージの最後において、認証ステージ２で利用されるＮａにＮａ２０が設定され、ＮｂにＮｂ２０が設定される。

（２−３：フェーズ３＜認証ステージ２＞（図２９を参照））
認証ステージ２では両方のデバイスが認証情報の交換を成功裏に完了したことが確かめられる。このステージは、上記の３つのモデルにおいて共通である。

まず、各デバイスは、新たに認証値（Ｅａ，Ｅｂ）を算出する。この認証値は、既に交換されたパラメータに基づいて算出される。また、デバイス間でこの認証値は共有される（ステップ９）。次いで、初期化デバイスにより、対向する応答デバイスに認証値が送信される。次いで、送信された認証値は、応答デバイスにより確認される（ステップ１０）。もし、この確認が失敗であれば、初期化デバイスがペアリングを認証しなかったことが示される。その場合、この認証ステップが破棄される。

次いで、応答デバイスは、自身が算出した認証値を初期化デバイスに送信する。この認証値は、初期化デバイスにより確認される（ステップ１１）。この確認が失敗であれば、応答デバイスがペアリングを認証しなかったことが示される。その場合、この認証ステップが破棄される。

（２−４：フェーズ４：リンクキーの算出（図２５（Ｂ）を参照））
両方のサイドでペアリングが認証されると、共有鍵（ＤＨＫｅｙ）等によりリンクキー（ＬＫ）が算出され、このリンクキーを用いて公にデータが交換されるようになる（ステップ１２）。このとき利用される一時値は、リンクキーの新しさを示す。たとえ、長文のＥＣＤＨ値が両サイドで利用される場合であっても、このリンクキーは、ペアリングを管理するために利用される。

リンクキーを算出する際に、両方のデバイスはパラメータを入力する。これらのパラメータは、両方のデバイスが同じリンクキーを算出したことを確かめるために、同じオーダー（順序）で入力される。また、パラメータには、「デバイスＡ’のパラメータはピコネットマスターのものであり、デバイスＢ’のパラメータはピコネットスレーブのものである」といったことを示す情報も含まれる。

（２−５：フェーズ５：ＬＭＰ認証、及び暗号化）
シンプルペアリングの最終フェーズは、暗号鍵を生成することである。これは、従来のペアリングの最終ステップと同じように実行される。

［３：暗号化に用いる関数群］
（３−１：楕円曲線の定義）
ＳＳＰ方式は、「ＦＩＰＳ（Ｆｅｄｅｒａｌ Ｉｎｆｏｒｍａｔｉｏｎ Ｐｒｏｃｅｓｓｉｎｇ Ｓｔａｎｄａｒｄｓ Ｐｕｂｌｉｃａｔｉｏｎ） Ｐ−１９２ ｃｕｒｖｅ」の楕円曲線を暗号化に利用している。この楕円曲線Ｅは、下記の式（１）に示すようにパラメータｐ、ａ、ｂを引数として値が決定されるものである。

但し、パラメータｂの値に対して一意に曲線が決定される。「ＮＩＳＴ（Ｎａｔｉｏｎａｌ Ｉｎｓｔｉｔｕｔｅ ｏｆ Ｓｔａｎｄａｒｄｓ ａｎｄ Ｔｅｃｈｎｏｌｏｇｙ） Ｐ−１９２」において、パラメータａは下記の式（２）により定義されている。

一方、パラメータｂは定義されおり、その生成の方法はＳＨＡ−１（シード値ｓに対し、ｂ２ｓ＝−２７（ｍｏｄ ｐ）を利用する。）を用いて確かめられる。また、次のようなパラメータが与えられる。

主なパラメータは、第１の係数（絶対値）ｐ、オーダーｒ、基準となるｘ座標Ｇｘ、基準となるｙ座標Ｇｙである。また、整数ｐ、ｒは、１０進法の形式で与えられる。そして、ビット列、フィールド要素はｈｅｘ（１６進数）の形式で与えられる。これらのパラメータは、例えば、次のような数値（＃１〜＃５）で与えられる。

（＃１） ｐ＝６２７７１０１７３５３８６６８０７６３８３５７８９４２３２０７６６６４１６０８３９０８７００３９０３２４９６１２７９
（＃２） ｒ＝６２７７１０１７３５３８６６８０７６３８３５７８９４２３１７６０５９０１３７６７１９４７７３１８２８４２２８４０８１
（＃３） ｂ＝６４２１０５１９ ｅ５９ｃ８０ｅ７ ０ｆａ７ｅ９ａｂ ７２２４３０４９ ｆｅｂ８ｄｅｅｃ ｃ１４６ｂ９ｂ１
（＃４） Ｇｘ＝１８８ｄａ８０ｅ ｂ０３０９０ｆ６ ７ｃｂｆ２０ｅｂ ４３ａ１８８００ ｆ４ｆｆ０ａｆｄ ８２ｆｆ１０１２
（＃５） Ｇｙ＝０７１９２ｂ９５ ｆｆｃ８ｄａ７８ ６３１０１１ｅｄ ６ｂ２４ｃｄｄ５ ７３ｆ９７７ａ１ １ｅ７９４８１１

関数Ｐ１９２（）は次のように定義されている。整数ｕ（０＜ｕ＜ｒ）、曲線Ｅ上の点Ｖが与えられると、点Ｖのｕ倍であるｕＶをｘ座標値とする値Ｐ１９２（ｕ，Ｖ）が算出される。秘密鍵は、１〜ｒ／２の間になる。ここで、ｒは、楕円曲線上のアーベル群のオーダーである（例えば、１〜２１９２／２）。

（３−２：暗号化関数の定義）
楕円曲線Ｄｉｆｆｉｅ−Ｈｅｌｌｍａｎ鍵の算出に加え、数字比較モデル、ＯＯＢモデル、パスキー入力モデルの各プロトコルには、４つの暗号化関数が必要とされる。これらの関数は、後述する関数ｆ１，ｇ，ｆ２，ｆ３である。

ｆ１は、１２８ビットの証明書の値Ｃａ、Ｃｂを生成するために利用される。ｇは、認証値を算出するために利用される。ｆ２は、リンクキー、及び、ＤＨＫｅｙや一時乱数値を用いて導出される他の鍵を算出するために利用される。ｆ３は、認証ステージ２における認証値Ｅａ、Ｅｂを算出するために利用される。これらの関数の基本的な構成はＳＨＡー２５６に基づいている。

（３−２−１：ＳＳＰ方式における証明書生成関数ｆ１）
証明書は、関数ｆ１により算出される。ＳＳＰ方式の証明書用関数の定義は、ＳＨＡ−２５６に基づくＭＡＣ関数（ＨＭＡＣ）を用いている。このＨＭＡＣは１２８ビット鍵の場合に、ＨＭＡＣ−ＳＨＡ−２５６Ｘと表記されるものである。ＳＳＰ方式の関数ｆ１には、次のような形式のパラメータ（Ｕ，Ｖ，Ｘ，Ｚ）が入力される。

Ｕは１９２ビット値である。Ｖは１９２ビット値である。Ｘは１２８ビット値である。
Ｚは８ビット値である。

Ｚは、数字比較モデル、及びＯＯＢモデルの各プロトコルにおいて０である（即ち、８ビットの０）。パスキー入力モデルのプロトコルの中で、Ｚの最も重要なビットは１に設定され、そして、少なくとも重要なビットはパスキーの１ビット目に生成される。例えば、パスキーが”１”である場合、Ｚ＝０ｘ８１に設定され、パスキーが”０”である場合、Ｚ＝０ｘ８０に設定される。

ＳＳＰ方式の関数ｆ１の出力は、下記の式（３）のようになる。

関数ｆ１の入力は、下表２に示すようにプロトコルに依存して異なる。

ここで、ＰＫａｘは、デバイスＡの公開鍵ＰＫａに対するｘ座標値を示す。同様に、ＰＫｂｘは、デバイスＢの公開鍵ＰＫｂに対するｘ座標値を示す。Ｎａｉは、ｉ番目の繰り返し処理における一時値を示す。繰り返し処理の各工程において、Ｎａｉの値は、あらたな１２８ビット数となる。同様に、ｒａｉは、８ビットに拡張されたパスキーの１ビット値（例えば、０ｘ８０、又は０ｘ８１）である。

（３−２−２：ＳＳＰ方式における数値認証関数ｇ）
ＳＳＰ方式の関数ｇは、次のように定義される。ＳＳＰ方式の関数ｇの入力（Ｕ，Ｖ，Ｘ，Ｙ）の形式は次の通りである。

Ｕは１９２ビット値である。Ｖは１９２ビット値である。Ｘは１２８ビット値である。
Ｙは１２８ビット値である。

ＳＳＰ方式の関数ｇの出力は、下記の式（４）のようになる。

数値認証値は、３２ビット整数ｇ（ＰＫａｘ，ＰＫｂｘ，Ｎａ，Ｎｂ）の中で、６つの少なくとも重要なビットが取り出される。ここで、ＰＫａｘはデバイスＡの公開鍵ＰＫａに対するｘ座標値を示し、ＰＫｂｘはデバイスＢの公開鍵ＰＫｂに対するｘ座標値を示す。

ＳＨＡ−２５６の出力は、ＳＨＡ−２５６の出力に対応する少なくとも重要な３２ビットを取り出すことによって３２ビットに切りつめられる。この値は、１０進数形式の数値に変換される。数字比較モデルで利用されるチェックサムは、少なくとも重要な６桁である。比較結果（Ｃｏｍｐａｒｅ Ｖａｌｕｅ）は、下記の式（５）のようになる。

例えば、出力が０ｘ ０１ ２ｅ ｂ７ ２ａであった場合、１０進数形式の数値は１９８３８７６２になる。そして、数字比較のためのチェックサムとして、８３８７６２が取り出される。

（３−２−３：ＳＳＰ方式における鍵導出関数ｆ２）
ＳＳＰ方式の鍵導出関数には、ＳＨＡ−２５６に基づくＭＡＣ関数（ＨＭＡＣ）が用いられる。このＨＭＡＣは、１９２ビット鍵Ｗに対してＨＭＡＣ−ＳＨＡ−２５６Ｗと表現される。ＳＳＰ方式の関数ｆ２に対する入力（Ｗ，Ｎ１，Ｎ２，ＫｅｙＩＤ，Ａ１，Ａ２）の形式は次のようになる。

Ｗは１９２ビット値である。Ｎ１は１２８ビット値である。Ｎ２は１２８ビット値である。ＫｅｙＩＤは３２ビット値である。Ａ１は４８ビット値である。Ａ２は４８ビット値である。

文字列”ｂｔｌｋ”は拡張ＡＳＣＩＩコードにより、次のようにＫｅｙＩＤに対してマッピングされている。

ＫｅｙＩＤ［０］＝０１１０ １０１１ （ｌｓｂ）
ＫｅｙＩＤ［１］＝０１１０ １１００
ＫｅｙＩＤ［２］＝０１１１ ０１００
ＫｅｙＩＤ［３］＝０１１０ ００１０
ＫｅｙＩＤ＝０ｘ６２７４６ｃ６ｂ

ＳＳＰ方式の関数ｆ２の出力は、下記の式（６）のようになる。

関数ｆ２の出力としては、ＨＭＡＣ−ＳＨＡ−２５６の出力の中で、１２８の最も重要な（最左の）ビットが取り出される。また、リンクキーは、下記の式（７）により算出される。

（３−２−４：ＳＳＰ方式におけるチェックサム関数ｆ３）
ＳＳＰ方式のチェックサム関数ｆ３の定義には、ＳＨＡ−２５６に基づくＭＡＣ関数（ＨＭＡＣ）が用いられる。このＨＭＡＣは、１９２ビット鍵Ｗに対してＨＭＡＣ−ＳＨＡ−２５６Ｗと表現される。ＳＳＰ方式の関数ｆ３の入力（Ｗ，Ｎ１，Ｎ２，Ｒ，ＩＯｃａｐ，Ａ１，Ａ２）の形式は次の通りである。

Ｗは１９２ビット値である。Ｎ１は１２８ビット値である。Ｎ２は１２８ビット値である。Ｒは１２８ビット値である。ＩＯｃａｐは１６ビット値である。Ａ１は４８ビット値である。Ａ２は４８ビット値である。

ＩＯｃａｐは、ＬＭＰ ＯＯＢ認証データとして最も重要なオクテット（８桁）、及びＬＭＰ入出力機能の可否を示す最小の重要度のオクテットで構成されるオクテットの組である。ＳＳＰ方式の関数ｆ３の出力は、下記の式（８）の通りである。

関数ｆ３の出力には、ＨＭＡＣ−ＳＨＡ−２５６の出力の中で１２８の最も重要な（最左の）ビットが取り出される。認証値は、関数ｆ３により算出される。関数ｆ３の入力は、下表３のように、プロトコル毎に異なる。

ＤＨＫｅｙは、デバイスＡによりＰ１９２（ＳＫａ，ＰＫｂ）として、そして、デバイスＢによりＰ１９２（ＳＫｂ，ＰＫａ）として算出された、共有された秘密のＤｉｆｆｅ−Ｈｅｌｌｍａｎ鍵である。ＡデータはデバイスＡの機能を示すデータである。ＢデータはデバイスＢの機能を示すデータである。パスキー入力モデルにおいて、データｒａ、ｒｂは６桁のパスキーの値であり、１２８ビットの整数値により表現される。例えば、ｒａの６桁の値が１３１３１３であったならば、Ｒ＝０ｘ００ ００ ００ ００ ００ ００ ００ ００ ００ ００ ００ ００ ００ ０２ ００ ｆ１となる。入力ＡはデバイスＡのＢＤアドレスである。入力ＢはデバイスＢのＢＤアドレスである。

［補遺２：＜ＷＰＳ１．０ｈについて＞］
上記の第２実施形態に係る技術は、以下で説明するＷＰＳ１．０ｈ方式に対し、好適に適用することが可能である。そこで、ＷＰＳ１．０ｈ方式に係る認証方法について、以下で詳細に説明する。尚、ここで用いられる用語の意味、及び表現については、後段で示す表５〜表１０を参照されたい。

［ＷＰＳ（Ｗｉ−Ｆｉ Ｐｒｏｔｅｃｔｅｄ Ｓｅｔｕｐ）について］
ＷＰＳは、Ｗｉ−Ｆｉ Ａｌｌｉａｎｃｅにより独立に構築された１つの規格である。また、ＷＰＳは、Ｗｉ−Ｆｉ ＣＥＲＴＩＦＩＥＤ（ＷＦＣ）の８０２．１１デバイスをサポートするようにデザインされている。このデバイスの形態としては、コンシューマ向けの電化プロダクトや電話機等が含まれる。これらのＷＦＣデバイスは、コンピュータ（ＰＣ）やアクセスポイント（ＡＰ）と同等の通信機能を有している。この通信機能は、家庭や小規模オフィス等に設置された８０２．１１デバイスにて利用されているようなものである。

これらのデバイスには、８０２．１１ｂ、８０２．１１ａ、８０２．１１ｇを用いて通信するマルチバンドデバイスと同様の拡張機能を有しているものもある。こうした拡張機能は、ＷＦＣプログラムのオプションとして提供される。このオプションは、８０２．１１ｎ規格のプレ標準プロダクトに関するものである。このプレ標準プロダクトは、２００８年に予定している最終的な８０２．１１ｎの標準プロダクトに認定される予定にものである。尚、Ｗｉ−Ｆｉ Ａｌｌｉａｎｃｅは、ＷＰＳに準拠した最初のプロダクトを２００７年の１月に承認している。

ＷＰＳは、コンシューマに対し、Ｗｉ−Ｆｉネットワークを有効化する際に行うセキュリティ設定に関して、購入したＷＦＣデバイスがより簡単に設定できることを確信させるためのものである。また、既に構築されたネットワークに対して新たなＷＰＳデバイスを追加する際にも、ＷＰＳにより、従来より遥かに容易に追加設定ができるようになるのである。

尚、ＷＰＳは、オプション的な認証事項である。つまり、全てのプロダクトにその認証が与えられるわけではない。特に、ＷＰＳは、ＳＯＨＯ市場における利用を想定しており、エンタープライズ環境における使用を目的にしたものではない。こうしたエンタープライズ環境では、分散して設置されたネットワークサーバ群がネットワークアクセスの制御用に設けられていたり、暗号化技術により厳重に情報が管理されていたりする。そこで、コンシューマは、購入するデバイスにＷＰＳ認証が与えられているかを確認するためには、購入するデバイスにＷＰＳ−ＷＦＣプロダクトの認定マークが存在するか否かを確認すればよい。このＷＰＳ認定マークは、プロダクト、パッケージ、ユーザドキュメントに表示されている。

ＷＰＳは、典型的な家庭用ネットワークに適用される。その中で、デバイスは、アクセスポイント（ＡＰ）、又はルータを介して通信する。こうした通信環境では、”アドホック”ネットワークがサポートされていないことが多い。この”アドホック”ネットワークとは、各デバイスがＡＰから独立して直接的に他のデバイスと通信するネットワークである。

典型的な通信環境では、ネットワーク上で、ネットワークネーム（ＳＳＩＤ）、及びＷＰＡ２セキュリティキーがＡＰ、及びＷＰＳクライアントデバイスに設定される。ＷＰＳの標準化されたアプローチによると、典型的なＷｉ−Ｆｉユーザにより簡単にＷｉ−Ｆｉネットワークが設定可能になり、セキュリティが有効化されたネットワークが構築できるようになる。このとき、Ｗｉ−Ｆｉユーザは、セキュリティやネットワークに関する基盤の技術、及び、その設定に含まれるプロセスについて理解していなくともよい。即ち、ユーザは、ＳＳＩＤがネットワークの名前を参照することや、ＷＰＡ２がセキュリティ機構を参照することを知る必要すらないのである。

ＷＰＳはＷＰＡ２の個人向け技術を利用する。この技術は、レガシーデバイスとの互換性がある。ＷＰＡ／ＷＰＡ２ Ｐｅｒｓｏｎａｌに関してＷＦＣが認定を与えるのである。ＷＰＡとＷＰＡ２はＷｉ−Ｆｉ技術に関するセキュリティに関して最新のものである。ユーザは、レガシーデバイス（即ち、ＷＰＡ／ＷＰＡ２ Ｐｅｒｓｏｎａｌに関するＷＦＣでないデバイス）を利用することが、ＷＬＡＮが弱点を有する状態にあるということを認識しておかなければならない。２００３年９月以後に認定された全てのＷＦＣプロダクトは、ＷＰＡ又はＷＰＡ２のいずれかをサポートしている。つまり、２００６年３月以降に認定されるプロダクトには、ＷＰＡ２のサポートが要求されるのである。

ＷＰＳで認定されたプロダクトは、ユーザに２つの簡単な設定方法を提供している。それらは個人識別数字（ＰＩＮ）による設定方法、及びプッシュボタン認証設定（ＰＢＣ）方法である。もちろん、ＷＰＳは、他の方法に対する拡張性も考慮してデザインされている。近接場通信（ＮＦＣ）カードやＵＳＢフラッシュデバイスを利用した認証方法についても、２００７年の後半にテストプログラムに追加されることが予定されている。

尚、ユーザは、レガシーデバイスが含まれるＷｉーＦｉネットワークにＷＰＳーＷＦＣデバイスを加えるかもしれない。このネットワークは、デバイスの設計者により提供されるマニュアルの手順に従ってユーザが以前に構築したものである。

ＷＰＳーＷＦＣプロダクトは、ＡＰにおいてＰＩＮによる認証設定、又はＰＢＣ設定の両方が可能なようにテストされてから認定される。クライアントデバイスでは、少なくとも、ＰＩＮによる認証設定がテストされてから認定される。

レジスタラ（Ｒｅｇｉｓｔｒａｒ）は、新しいクライアントをネットワークに登録するのに必要な証明書を発行する。このレジスタラは、ＡＰ又はクライアント等の様々なデバイスに設定できる。ユーザが様々な環境や場所にデバイスを加えることができるように、仕様書では、１つのネットワーク内に多重のレジスタラが含まれることをサポートしている。但し、レジスタラの機能は、ＡＰの管轄内に限定される。

ＰＩＮ設定に関し、ＰＩＮは、ネットワークに接続しようとする個々のデバイスに対して与えられる。通常、ユーザがＰＩＮを認識できるように、デバイス上に固定ラベルやステッカーが設けられている。また、動的なＰＩＮが生成される場合、そのＰＩＮは、例えば、デバイスに設置されたＴＶスクリーンやモニターのようなディスプレイに表示される。ＰＩＮは、他者による事故や悪意の企てによりネットワークに意図しないデバイスが加えられないように、ユーザがネットワークに加えようと考えるデバイスであるか否かを確かめるために利用される。

まず、ユーザはＰＩＮをレジスタラに入力する。例えば、ＰＩＮは、ＡＰのＧＵＩを介して入力されるか、或いは、ネットワーク上の他のデバイスに設けられたオンスクリーンインターフェースを介して管理ページにアクセスすることにより入力される。

ＰＢＣ設定に関し、ユーザは、デバイスをネットワークに接続し、ＡＰとクライアントデバイスのボタンを押下することによりデータの暗号化を有効にする。このとき、ユーザは、ＡＰとクライアントのボタンを押下する間に、意図しないデバイスがとても簡単にネットワークに接続することが可能な期間があることを意識しておく必要がある。

（設定ステップの比較）
表４は、ＰＩＮによる認証設定とＰＢＣによる認証設定との間の操作ステップの比較を示した図表である。また、参考までに、ＷＰＳ以前の方法によるＷＬＡＮ上の設定、及びセキュリティの有効化に要求されるステップも併せて掲載している。これによると、ＷＰＳ以前の方法は多数のステップを有する。

ＷＰＳ以前の方法において、ユーザは、デバイスを電源に接続し、有線ネットワークに接続した上でＡＰを有効化する（ステップ１）。次いで、ユーザは、有線ネットワークに接続されたコンピュータからウェブブラウザを立ち上げ、管理ページにログインしてＡＰにアクセスする（ステップ２）。次いで、ユーザは、ネットワークネーム（ＳＳＩＤ）を選択し、それをＡＰに入力する（ステップ３）。

次いで、ユーザは、セキュリティ設定ページに導かれる。そこで、ユーザは、利用するセキュリティタイプを選択し、セキュリティ設定を有効にする（ステップ４）。セキュリティ設定が有効化された後で、ユーザは、ＡＰがセキュリティキーを生成するために利用されるパスフレーズの入力を促される。そこで、ユーザは、パスフレーズをＡＰに設定し、セキュリティキーを設定する。（ステップ５）。ユーザは、コントロールパネルを用いてネットワークに登録されるクライアントデバイスを設定する。このとき、ユーザは、デバイスの無線インターフェースを有効化し、ＷＬＡＮ接続を有効化する（ステップ６）。

次いで、クライアントデバイスは、ユーザに対し、周囲に発見される全てのＷＬＡＮのネットワークネーム（ＳＳＩＤ）を提示する。そこで、ユーザは、（ステップ３で選択した）適切なネットワークネームを選択し、ネットワークに接続する（ステップ７）。次いで、ユーザは、ステップ５で設定したパスフレーズを入力するように促される。そこで、ユーザは、クライアントデバイスにパスフレーズを入力する（ステップ８）。その後、クライアント、及びＡＰは、セキュリティ証明書を交換し、新たなデバイスがセキュアにＷＬＡＮに接続される。

多くの場合、ＷＰＳを適用することにより、上記のステップ２〜５の手順が省略される。加えて、ユーザに要求されるいくつかの作業（例えば、パスフレーズの設定等）が簡単化される。

ＷＰＳにおいて、ユーザは、単にＡＰとクライアントデバイスを有効化する。そして、ＡＰの生成手段により提供されたＰＩＮを入力するか（ＰＩＮによる認証設定の場合）、或いは、セキュリティの設定を開始するために、ＡＰとクライアントデバイスのボタンを押下する（ＰＢＣによる認証設定の場合）。このとき、ユーザには、パスフレーズの設定が要求されない。つまり、セキュリティコードが自動的に有効化されて通信されるのである。

ＳＳＩＤとＷＰＡ２セキュリティキーが適切に設定されるのを保証するのに加え、ＷＰＳは、空間に伝播する情報セキュリティを確保するための技術を提供する。つまり、ＷＰＳは、ネットワークにアクセスするために不正なＰＩＮを入力するユーザを排除する。また、ＷＰＳには、認証に用いる証明書を一時的な証明書にすることで、その時点で転送された証明書でない場合には設定プロセスをキャンセルするタイムアウト機能も提供する。

また、ＷＰＳでは、ユーザが生成したパスフレーズを消去することにより、セキュリティを向上させる。ＷＰＳ以前、ユーザは、ＡＰ上でパスフレーズを生成し、入力することを要求されていた。彼らは、任意の新たなデバイスをネットワークに追加する際に、ネットワークをセキュアにするためのパスフレーズを再利用していた。さらに、そのパスフレーズの多くは、短く、子供やペットの名前のような覚えやすく、外部の人に容易に推測されるような分かり易いパスフレーズであった。

（ＷＰＳのオプション）
ＷＰＳのオプションとして、ＮＦＣやＵＳＢを利用した認証方法がある。これらの方法は、ＰＢＣによる認証方法やＰＩＮによる方法のようにユーザの手入力を要求せずにデバイスをネットワークに参加させるものである。

ＷＰＳのＮＦＣによる設定方法を適用すると、新たなデバイスをＡＰ又はレジスタラ機
能を有する他のデバイスにタッチすることで、簡単に、セキュアなネットワークが有効化される。ＷＰＳのＵＳＢによる設定方法では、証明書はＵＳＢフラッシュドライブ（ＵＦＤ）を介して転送される。これらの方法は、意図しないデバイスがネットワークに加入することに対して強固な防御効果を与える。

しかしながら、ＵＳＢによる方法やＮＦＣによる方法は、２００７年の第１四半期後半でＷＦＳに対するＷＦＣプログラムに予定されている。他の方法についても、後日、認定プログラムに加えられるかもしれない。ＷＰＳは、こうした方法についても、他の技術に対する拡張性を考慮してデザインされている。

（ＷＰＳの機能について）
詳細な設定手段とＷＰＳデバイスのセキュリティとは、従来のホームセキュリティに関する馴染み深い比喩”ｌｏｃｋ ａｎｄ ｋｅｙ”に対比される。ＷＰＳの仕様は、新たなデバイスが探索プロトコルに基づいて構築されたＷｉ−Ｆｉネットワークに加入される際に、シンプルで矛盾しない手順を提供している。また、このプロトコルは、ベンダー間で整合している。

この手順では、ネットワークに登録されるデバイスの証明書を自動的に発行するためにレジスタラが利用される。ＷＰＳーＷＦＣデバイスのＡＰにはレジスタラ機能が搭載されている。さらに、レジスタラは、ＷＬＡＮ上の任意のデバイスに駐在することができる。ＡＰ上に駐在するレジスタラは、内部のレジスタラとして参照される。ネットワーク上の他のデバイスに駐在するレジスタラは、外部のレジスタラとして参照される。ＷＰＳネットワークでは、１つのＷＬＡＮ上における多重のレジスタラがサポートされている。

ユーザがＷＬＡＮ上に新たなデバイスを追加設定するプロセスは、鍵を錠に挿入する工程と対比される次のようなアクションによって開始される。このプロセスでは、設定ウィザードが起動され、ユーザによりＰＩＮが入力されるか、又はＰＢＣボタンが押下される。この時点で、新たなデバイスのアクセスが検出される。

ＷＰＳデバイスは、レジスタラとの間で情報の交換を開始する。次いで、レジスタラは、ネットワーク証明書を発行する。ネットワーク証明書は、クライアントがＷＬＡＮに加入するのを認証するためのネットワークネーム、及びセキュリティキーを含むものである。錠と鍵の比喩において、このネットワーク証明書の交換は、アクセスが受け入れられるように錠の中でキーを回す動作に似ている。その後、新たなデバイスは、ネットワークを介し、侵入者による認証されていないアクセスに対してセキュアにデータを通信することができる。

新たなＷＰＳ−ＷＦＣデバイスは、有効なＡＰの範囲内に入ったときに存在が検出される。その後、ＷＰＳ−ＷＦＣデバイスは、レジスタラに通信し、ユーザに証明書の発行を認証する行為を促す。

ＷＰＳネットワークでは、各デバイスを認証する際にデータが暗号化される。つまり、情報とネットワーク証明書は、拡張認証プロトコル（ＥＡＰ）を利用して空間内でセキュアに交換される。認証プロトコルにはＷＰＡ２が使われる。デバイスにより相互に認証が実行され、クライアントがネットワーク上で許容された場合に接続が行われる。レジスタラは、セキュリティを有効にするためにネットワークネーム（ＳＳＩＤ）、及びＷＰＡ２の”Ｐｒｅ−Ｓｈａｒｅｄ Ｋｅｙ（ＰＳＫ）”を通知する。ランダムなＰＳＫの使用は、予測可能なパスフレーズの使用を避けることでセキュリティが向上する。

ＷＰＳ以前の設定方法では、ユーザに対し、ＡＰがＰＳＫをサポートするように手動で設定すること、及び、ＳＳＩＤとＰＳＫを手動で入力することが要求されていた。ＳＳＩＤやＰＳＫの入力は、ＡＰとクライアントの両方で行われる。このアプローチは、ユーザエラーの原因の大部分を占めていた。ユーザエラーとしては、ミスタイピング、及びＰＳＫとＳＳＩＤの混同である。ところが、ＷＰＳを用いた場合、証明書の交換プロセスは、初期の設定処理が完了した後において、ユーザによる僅かな介在を要求するのみである。例えば、ＰＩＮの入力、又はＰＢＣボタンの押下だけである。このとき、ネットワークネームとＰＳＫは自動的に発行されているのである。

次に、証明書の交換、及びデバイスの追加に関するダイアグラムを示す。つまり、ＷＰＳデバイスにより、どのようにしてネットワークが設定されるかについて説明する。

（証明書の交換について）
ＷＰＳでは、レジスタラがネットワーク上の他のデバイスに対して識別情報を発行するように促し、さらに、証明書を発行する。このとき、各種の情報は、Ｗｉ−Ｆｉネットワークを介して交換される。１つのシナリオとして、レジスタラがＡＰに設定される。証明書の交換は、クライアント、及びＡＰに設けられたボタンを押下することで行われてもよい（ＰＢＣ方式）。また、証明書の交換はクライアントデバイスを用いたＰＩＮの入力により行われてもよい（ＰＩＮ方式）。例えば、ＰＩＮ入力は、ＰＩＮ方式用のＧＵＩにユーザがＰＩＮを入力する形式で行われる。

（デバイスの追加について）
新たなクライアントが既に存在するネットワークに加えられるものとする。このとき、ＰＩＮ又はプッシュボタンにより設定されてもよい。例えば、既に存在するネットワークに新たなＡＰデバイスが加えられる場合にも、ＰＩＮ又はプッシュボタンによる設定が可能である。ＰＩＮ方式、及びＰＣＢ方式のいずれの方法が利用されるかは、どちらの設定方法がクライアントデバイスによりサポートされるかに依存して選択される。

（ＷＰＳにおける設定オプション）
ＰＢＣ方式やＰＩＮ方式の設定オプションは、ＷＰＳーＷＦＣプロダクトに対して適用される。つまり、ＮＦＣやＵＳＢによる設定方法は、オプションであり、Ｗｉ−Ｆｉ Ａｌｌｉａｎｃｅによりテスト及び認定されているものではない。しかしながら、製造者は、オプション的にこれらを提供することができる。ＮＦＣやＵＳＢによる設定方法は、２００７年のＷＰＳに対するＷＦＡの認定テストプログラムに含まれることが予定されている。

（ＮＦＣ設定の場合）
ＮＦＣ設定は、タッチベースの相互作用を利用する。ＮＦＣ設定では、ＡＰ又は他のレジスタラとクライアントとの間でのＮＦＣを利用したネットワーク証明書の交換を有効にする。証明書の交換は、ＮＦＣが有効なクライアントをＡＰ（又は他のＮＦＣが有効なレジスタラ）上のＮＦＣターゲットマークにタッチした時点で開始されるか、或いは、クライアントをＮＦＣターゲットマークの近接領域内に持っていくことで開始される。その距離は、およそ１０ｃｍである。

レジスタラは、クライアント識別用の証明書をＮＦＣを介して読み出す。ＮＦＣデバイスは、レジスタラに埋め込まれている。そして、新たなデバイスをネットワークに接続するために、レジスタラはネットワークＳＳＩＤとＰＳＫセキュリティコードをクライアントに返信する。

（ＵＳＢ設定の場合）
ＵＳＢ設定において、ＵＳＢフラッシュドライブをレジスタラデバイス（この場合、ＡＰ）に接続することによって証明書が交換される。この証明書は、フラッシュドライブ上にコピーされる。一方、そのフラッシュドライブは、新たなデバイスに挿入されて証明書の交換が完了する。

（ＷＰＳのまとめ）
ＷＰＳにより、ユーザに設定アプローチの統一的な枠組みが提供される。この枠組みには、ＰＩＮ入力やプッシュボタンのシーケンスが含まれる。このシーケンスは、新たなＷＦＣデバイスの設定をより容易にし、家庭又は小規模オフィスの環境においてＷＦＣネットワークのセキュリティを簡単に有効にすることができる。

ＷＰＳは、ＷＦＣデバイスに対するユーザのアウトオブボックス操作を改善するようにデザインされている。このため、ベンダーの技術サポートに対する依存性を低減し小売店によるプロダクト回収の数を低減すると共に、ユーザの技術に対する満足度を増大させる。特に、ＷＰＳは、ユーザにＰＳＫやＳＳＩＤのようなコンセプトを理解させるような要求を排除し、誤入力が避けられないＰＳＫの手入力プロセスを排除する。これによりＷＰＳは、ネットワーク設定をより容易にする。

ＷＰＳは、８０２．１１ａ，ｂ，ｇのＷＦＣデバイスがサポートする２．４ＧＨｚや５ＧＨｚ周波数帯の両方をサポートできるように拡張可能にデザインされている。認定自体はオプション的な位置付けであるが、家庭又は小規模オフィスに存在するマルチバンド、マルチモードをサポートするデバイスに適用されるであろう。また、このオプションは、２００７年の８０２．１１ｎのプレスタンダードプロダクトに対するＷＦＣプログラムへの適用が予定されている。また、２００８年に予定されている最終的な８０２．１１ｎ標準で認定されるプロダクトに対しても同様である。

以上、添付図面を参照しながら本発明の好適な実施形態について説明したが、本発明は係る例に限定されないことは言うまでもない。当業者であれば、特許請求の範囲に記載された範疇内において、各種の変更例または修正例に想到し得ることは明らかであり、それらについても当然に本発明の技術的範囲に属するものと了解される。

上記の実施形態の説明においては、第１通信方式としてＮＦＣ通信を想定していたが、必ずしもこれに限定されるものではなく、例えば、赤外線通信、或いは、ＵＳＢメモリによる設定情報の交換等も含まれる。

上記の実施形態の説明においては、主に、ＰＣや携帯電話を例に挙げて説明したが、上記の実施形態を適用できる範囲は、これに限定されない。例えば、テレビジョン等の映像機器、カーナビゲーション装置、オーディオ装置、決済端末、プリンタ等の電子機器、或いは、各種の情報家電等にも適用可能である。また、ＩＣタグ等を備えることが可能なデバイス等に対しても適用される。このように、上記の実施形態に係る技術は、多種多様な電子機器に適用することが可能である。

本発明の一実施形態に係る通信システムの構成例を示す説明図である。 本発明の第１実施形態に係る通信装置の機能構成を示す説明図である。 同実施形態に係る認証処理方法の流れを示す説明図である。 本発明の一実施形態に係るレコードの構成例を示す説明図である。 本発明の一実施形態に係るレコードの構成例を示す説明図である。 本発明の第１実施形態に係るレコードの構成例を示す説明図である。 同実施形態に係る認証処理方法の流れを示す説明図である。 同実施形態に係る認証処理方法の流れを示す説明図である。 同実施形態に係る認証処理方法の一例を示す説明図である。 同実施形態に係る認証処理方法の一例を示す説明図である。 同実施形態に係る認証処理方法の一例を示す説明図である。 同実施形態に係るネットワーク形成方法の一例を示す説明図である。 同実施形態に係るネットワーク形成方法の一例を示す説明図である。 同実施形態に係るネットワーク形成方法の一例を示す説明図である。 同実施形態に係るネットワーク形成方法の一例を示す説明図である。 本発明の第２実施形態に係る通信装置の機能構成を示す説明図である。 同実施形態に係るレコードの構成例を示す説明図である。 同実施形態に係る認証処理方法の流れを示す説明図である。 同実施形態に係る認証処理方法の流れを示す説明図である。 同実施形態に係るネットワーク形成方法の一例を示す説明図である。 同実施形態に係るネットワーク形成方法の一例を示す説明図である。 同実施形態に係るネットワーク形成方法の一例を示す説明図である。 本発明の一実施形態に係る通信装置の装置構成例を示す説明図である。 本発明の一実施形態に係る通信装置の装置構成例を示す説明図である。 ＢＴデバイスにおける認証処理方法の流れを示す説明図である。 ＢＴデバイスにおける認証処理方法の流れを示す説明図である。 ＢＴデバイスにおける認証処理方法の流れを示す説明図である。 ＢＴデバイスにおける認証処理方法の流れを示す説明図である。 ＢＴデバイスにおける認証処理方法の流れを示す説明図である。

１０ 通信システム
１００、２００ 通信装置
１０２、１０６ アンテナ
１０４ 近接通信部
１０８、１５８ 近距離通信部
１１０、１６０ 制御部
１１２ ＲＡＭ
１１４ ＲＯＭ
１１６ フラッシュメモリ
１１８ 入力部
１２０ 表示部

Claims (8)

1. 第１及び第２の通信部により通信する通信装置であって、
   第１の通信部を介して、他の通信装置との接続毎に生成される乱数と、当該乱数により算出される証明書と、前記第２の通信部での認証方式を示す認証方式情報と、が含まれる通信データを受信する受信部と、
   前記通信データに含まれる認証方式情報に基づいて当該通信データの送信元が対応している認証方式を判別する方式判別部と、
   を備え、
   前記方式判別部による判別結果に応じて前記通信データに含まれる乱数を前記第２の通信部での認証処理に用いる識別情報として利用する、通信装置。
2. 前記認証方式情報は、前記第２の通信部での認証方式が公開鍵方式に対応するか否かを示す情報であり、
   前記方式判別部は、前記通信データに含まれる認証方式情報に基づいて当該通信データの送信元が公開鍵方式に対応するか否かを判別し、
   前記方式判別部により前記通信データの送信元が公開鍵方式に非対応であると判別された場合に、自装置の識別情報として前記通信データに含まれる情報を送信元に返信する、請求項１に記載の通信装置。
3. 前記通信データには、前記送信元を識別するための識別情報と、当該識別情報に有効期限が設定されているか否かを示す期限情報がさらに含まれており、
   前記期限情報が有効期限の設定有りを示す場合に、前記有効期限が経過した後で、前記通信データに含まれる設定情報に基づいて生成された情報を全て破棄する、請求項２に記載の通信装置。
4. 所定の確認情報を表示する表示部と、
   前記確認情報に対する承認を示す情報を入力するための入力部と、
   をさらに備え、
   前記通信データに含まれる識別情報を有効にすることの承認要求を前記表示部に表示し、前記入力部により承認を示す情報が入力された場合に、当該識別情報を有効化する、請求項３に記載の通信装置。
5. 所定の確認情報を表示する表示部と、
   前記確認情報に対する承認を示す情報を入力するための入力部と、
   をさらに備え、
   前記通信データに含まれる情報を返信することの承認要求を前記表示部に表示し、前記入力部により承認を示す情報が入力された場合に、当該識別情報に基づいて前記第２の通信部による通信を開始する、請求項１に記載の通信装置。
6. 前記通信データには、送信元を特定するためのアドレス情報がさらに含まれており、
   前記第２の通信部は、前記アドレス情報で特定される前記送信元との間のみで通信する、請求項１に記載の通信装置。
7. 前記通信データには、前記第２の通信部により形成可能なネットワーク構成を示す構成情報がさらに含まれており、
   所定の属性の中から、前記構成情報に基づいてネットワーク内における自装置の属性を決定する、請求項１に記載の通信装置。
8. 第１及び第２の通信部を有する通信装置による通信方法であって、
   第１の通信部を介して、他の通信装置との接続毎に生成される乱数と、当該乱数により算出される証明書と、前記第２の通信部での認証方式を示す認証方式情報と、が含まれる通信データが受信される受信ステップと、
   前記通信データに含まれる認証方式情報に基づいて当該通信データの送信元が対応している認証方式を判別する方式判別ステップと、
   前記方式判別ステップにおける判別結果に応じて前記通信データに含まれる乱数を識別情報として利用することで前記第２の通信部での認証処理がされる認証ステップと、
   を含む、通信方法。