JPWO2014156620A1 - 集積回路、通信方法、コンピュータプログラム及び通信装置 - Google Patents

Abstract

【課題】近距離非接触無線通信の際に、安全に暗号通信を行うことが可能な集積回路を提供する。【解決手段】非接触通信により他の装置と通信を行う通信処理部と、前記通信処理部が前記他の装置との間で情報を暗号化した通信を実行する前に、前記他の装置との非接触通信の履歴の有無に応じて、前記他の装置との間の非接触通信において該他の装置を相互に認証する際に用いられる認証情報の生成を判断する暗号化情報生成部と、を備える、集積回路が提供される。係る集積回路は、他の装置との間の安全な近距離非接触無線通信を行うことを可能にする。【選択図】図２

Description

本開示は、集積回路、通信方法、コンピュータプログラム及び通信装置に関する。

ＩＣ（Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）カードを用いて、近距離で非接触により無線通信を行う近距離無線通信システムが広く利用されている。このような近距離無線通信システムは、例えば電子乗車券や、電子マネーとしての利用がよく知られている。また、最近では、近距離非接触無線通信による電子乗車券や電子マネーの機能を備えた携帯電話機も普及してきている。

近距離無線通信システムは、世界規模で急激に普及し、国際規格にもなっている。近距離無線通信システムの国際規格には、例えば近接型のＩＣカードシステムの規格であるＩＳＯ／ＩＥＣ １４４４３、およびＮＦＣＩＰ（Ｎｅａｒ Ｆｉｅｌｄ Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｉｎｔｅｒｆａｃｅ ａｎｄ Ｐｒｏｔｏｃｏｌ）−１の規格であるＩＳＯ／ＩＥＣ １８０９２などがある。またＩＳＯ／ＩＥＣ １８０９２ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌの上位レイヤープロトコルであるＮＦＣ ＬＬＣＰ（ＮＦＣ Ｆｏｒｕｍ Ｌｏｇｉｃａｌ Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ、非特許文献１参照）において定義されるＬＬＣ ＰＤＵ（Ｐｒｏｔｏｃｏｌ Ｄａｔａ Ｕｎｉｔ）は、複数コネクションの同時通信が可能となっている。

ＮＦＣ Ｆｏｒｕｍ Ｌｏｇｉｃａｌ Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ ＴＳ １．１

ＮＦＣＩＰ−１のためのセキュリティオプションであるＮＦＣ−ＳＥＣ技術（ＩＳＯ／ＩＥＣ １３１５７−１及びＩＳＯ／ＩＥＣ １３１５７−２）では、２つの装置の間で相互認証を行う機能が存在しない。ＮＦＣ−ＳＥＣ技術では、２つの装置を近づけただけで共有秘密情報（Ｓｈａｒｅｄ ｓｅｃｒｅｔ）を生成する。従って、既存のＮＦＣ−ＳＥＣ技術では、装置が近づいてしまえば、信頼出来ない相手にも共有秘密情報を交換して暗号通信を行なってしまっていた。

そこで本開示は、近距離非接触無線通信による暗号通信の際に、より安全に暗号通信を行うことが可能な、新規かつ改良された集積回路、通信方法、コンピュータプログラム及び通信装置を提供する。

本開示によれば、非接触通信により他の装置と通信を行う通信処理部と、前記通信処理部が前記他の装置との間で情報を暗号化した通信を実行する前に、前記他の装置との非接触通信の履歴の有無に応じて、前記他の装置との間の非接触通信において該他の装置を相互に認証する際に用いられる認証情報の生成を判断する暗号化情報生成部と、を備える、集積回路が提供される。

また本開示によれば、非接触通信により他の装置と通信を行うステップと、前記他の装置との間で情報を暗号化した通信が実行される前に、前記他の装置との非接触通信の履歴の有無に応じて、前記他の装置との間の非接触通信において該他の装置を相互に認証する際に用いられる認証情報の生成を判断するステップと、を備える、通信方法が提供される。

また本開示によれば、コンピュータに、非接触通信により他の装置と通信を行うステップと、前記他の装置との間で情報を暗号化した通信が実行される前に、前記他の装置との非接触通信の履歴の有無に応じて、前記他の装置との非接触通信の履歴の有無に応じて、前記他の装置との間の非接触通信において該他の装置を相互に認証する際に用いられる認証情報の生成を判断するステップと、を実行させる、コンピュータプログラムが提供される。

また本開示によれば、非接触通信により他の装置と通信を行う通信処理部、および前記通信処理部が前記他の装置との間で情報を暗号化した通信を実行する前に、前記他の装置との非接触通信の履歴の有無に応じて、前記他の装置との間の非接触通信において該他の装置を相互に認証する際に用いられる認証情報の生成を判断する暗号化情報生成部、を有する集積回路と、前記集積回路へ電源を供給する電源部と、を備える、通信装置が提供される。

以上説明したように本開示によれば、近距離非接触無線通信による暗号通信の際に、より安全に暗号通信を行うことが可能な、新規かつ改良された集積回路、通信方法、コンピュータプログラム及び通信装置を提供することが出来る。

本開示の一実施形態に係る近距離無線通信システム１の構成例を示す説明図である。 本開示の一実施形態に係る通信装置１００の機能構成例を示す説明図である。 通信装置１００のハードウェア構成の形態例を示す説明図である。 本開示の一実施形態に係る通信装置１００、２００の動作例を示す流れ図である。 本開示の一実施形態に係る通信装置１００、２００の動作例を示す流れ図である。 本開示の一実施形態に係る通信装置１００、２００の動作例を示す流れ図である。 本開示の一実施形態に係る通信装置１００、２００の動作例を示す流れ図である。 プロトコル層及び暗号化されるプロトコルデータの例を示す説明図である。 プロトコル層及び暗号化されるプロトコルデータの例を示す説明図である。 コマンドＡＴＲ＿ＲＥＱの構造を示す説明図である。 コマンドＡＴＲ＿ＲＥＳの構造を示す説明図である。 機器ＩＤが格納されるデータの例を示す説明図である。 セキュリティプロトコル指示情報が格納されるデータの例を示す説明図である。 セキュリティプロトコル能力情報が格納されるデータの例を示す説明図である。 機器ＩＤの比較結果が格納されるデータの例を示す説明図である。 コマンドＤＥＰ＿ＲＥＱ及びコマンドＤＥＰ＿ＲＥＳの構造を示す説明図である。 ＬＬＣ ＰＤＵの構造を示す説明図である。 ＰＴＹＰＥフィールドに格納される情報を示す説明図である。 ＮＦＣ−ＳＥＣのプロトコルデータユニットの構造を示す説明図である。 ＮＦＣ−ＳＥＣのプロトコルデータユニットの各コマンドが使用するフィールドの関係を示す説明図である。 ＳＥＰフィールドのビット割り当てを示す説明図である。 ＳＥＰフィールドに格納されるコード及びそのコードが示す内容の対応関係を示す説明図である。 本開示の一実施形態に係る通信装置１００の動作例を示す流れ図である。 本開示の一実施形態に係る通信装置１００の動作例を示す流れ図である。 本開示の一実施形態に係る通信装置１００の動作例を示す流れ図である。 通信装置１００、２００の間の処理シーケンスを示す流れ図である。 通信装置１００、２００の間の処理シーケンスを示す流れ図である。 通信装置１００、２００の間の処理シーケンスを示す流れ図である。 通信装置１００、２００の間の処理シーケンスを示す流れ図である。 通信装置１００、２００の間の処理シーケンスを示す流れ図である。 通信装置１００、２００の間の処理シーケンスを示す流れ図である。

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

なお、説明は以下の順序で行うものとする。
＜１．本開示の一実施形態＞
［システム構成例］
［通信装置の機能構成例］
［通信装置の動作例（基本シーケンス）］
［プロトコル及びプロトコルメッセージ例］
［通信装置の動作例（具体的な処理フローの例）］
＜２．まとめ＞

＜１．本開示の一実施形態＞
［システム構成例］
まず、本開示の一実施形態に係る近距離無線通信システムの構成例を説明する。図１は本開示の一実施形態に係る近距離無線通信システム１の構成例を示す説明図である。以下、図１を用いて本開示の一実施形態に係る近距離無線通信システムの構成例について説明する。

図１に示したように、本開示の一実施形態に係る近距離無線通信システム１は、通信装置１００、２００を含んで構成される。通信装置１００、２００は、いずれも、ＩＳＯ／ＩＥＣ １８０９２及びＩＳＯ／ＩＥＣ １４４４３の両方または一方による近距離無線通信を行う通信装置である。また通信装置１００、２００は、いずれもＩＳＯ／ＩＥＣ １８０９２ ｔｒａｎｓｐｏｒｔ ｐｒｏｔｏｃｏｌの上位レイヤープロトコルであるＬＬＣＰによる近距離無線通信を行う通信装置である。

通信装置１００、２００は、いずれもポーリングデバイス（Ｐｏｌｌｉｎｇ ｄｅｖｉｃｅ）、リスニングデバイス（Ｌｉｓｔｅｎｉｎｇ ｄｅｖｉｃｅ）のいずれとしても動作することができる。ポーリングデバイスは、電磁波を発生することにより、いわゆるＲＦ（Ｒａｄｉｏ Ｆｒｅｑｕｅｎｃｙ）フィールド（磁界）を形成し、リモートターゲットとしてのリスニングデバイスを検出するためにポーリングコマンドを送信し、リスニングデバイスからのレスポンスを待つ。つまりポーリングデバイスは、ＩＳＯ／ＩＥＣ １４４４３のＰＣＤ（Ｐｒｏｘｉｍｉｔｙ Ｃｏｕｐｌｉｎｇ Ｄｅｖｉｃｅ）の動作、または、ＩＳＯ／ＩＥＣ １８０９２のパッシブモードのイニシエータの動作を行う。

リスニングデバイスは、ポーリングデバイスがＲＦフィールドを形成して送信するポーリングコマンドを受信すると、ポーリングレスポンスで応答する。つまりリスニングデバイスは、ＩＳＯ／ＩＥＣ １４４４３のＰＩＣＣの動作、または、ＩＳＯ／ＩＥＣ １８０９２のパッシブモードのターゲットの動作を行う。従って、通信装置１００、２００は、同一のハードウェア構成とすることができる。

以下の説明では、通信装置１００を取り上げて、その構成及び動作について説明する。また通信装置１００の動作について説明する際には必要に応じて通信装置２００の動作についても併せて説明する。

以上、図１を用いて本開示の一実施形態に係る近距離無線通信システムの構成例について説明した。次に、本開示の一実施形態に係る通信装置１００の機能構成例について説明する。

［通信装置の機能構成例］
図２は、本開示の一実施形態に係る通信装置１００の機能構成例を示す説明図である。以下、図２を用いて本開示の一実施形態に係る通信装置１００の機能構成例について説明する。

図２に示したように、本開示の一実施形態に係る通信装置１００は、制御部１１０と、記憶部１１１と、アプリケーション実行部１２０と、ＲＦ通信部１３０と、を含んで構成される。なお、図示しないが、通信装置１００はＲＦ通信部１３０（集積回路）に電源を供給する電源部をさらに備える。

制御部１１０は、通信装置１００の動作を制御する。制御部１１０は、例えば、記憶部１１１に格納されているコンピュータプログラムを読み出して順次実行することで、通信装置１００の動作を制御しても良い。また記憶部１１１は、制御部１１０で実行されるコンピュータプロフラムや、制御部１１０での制御時に用いられるデータを一時的に格納したりする記憶領域である。また記憶部１１１には、ＲＦ通信部１３０が使用するデータについても格納される。

記憶部１１１には、共有秘密情報及び通信相手を一意に識別できる識別情報（例えば機器ＩＤ）が記憶され得る。共有秘密情報は、通信装置１００と通信装置２００との間の暗号通信や相互認証を行うために用いられる情報である。従って、記憶部１１１は、通信装置１００の外部から中身が読み取られないように耐タンパ性を有しておくことが望ましい。

アプリケーション実行部１２０は、ＬＬＣＰを利用するアプリケーションを実行する。アプリケーション実行部１２０は、同時に複数のアプリケーションを実行しても良い。アプリケーション実行部１２０によって実行されるアプリケーションは、それぞれ個別のサービスアクセスポイント（Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ；ＳＡＰ）を有する。

ＲＦ通信部１３０は、所定の周波数による近距離無線通信を実行する。ＲＦ通信部１３０は、図２に示したように、ＬＬＣＰコネクション処理部１３１と、ＬＬＣＰリンクプロトコル処理部１３２と、暗号処理部１３３と、ＮＦＣ−ＳＥＣプロトコル処理部１３４と、ＮＦＣＩＰ−１プロトコル処理部１３５と、を含んで構成される。

ＬＬＣＰコネクション処理部１３１は、指定された送信元サービスアクセスポイント（Ｓｏｕｒｃｅ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ；ＳＳＡＰ）及び宛先サービスアクセスポイント（Ｄｅｓｔｉｎａｔｉｏｎ Ｓｅｒｖｉｃｅ Ａｃｃｅｓｓ Ｐｏｉｎｔ；ＤＳＡＰ）に従って、対応するアプリケーション（例えばアプリケーション実行部１２０で実行されるアプリケーション）との間でデータ授受を実行する。

ＬＬＣＰリンクプロトコル処理部１３２は、ＬＬＣＰリンクの活性化（すなわち、ＮＦＣＩＰ−１プロトコルの活性化）、維持、非活性化を実行する。

暗号処理部１３３は、通信装置１００と通信装置２００との間で暗号化された近距離非接触無線通信が実行される際に、ＮＦＣ−ＳＥＣその他の暗号方式で規定された暗号処理を実行する。暗号処理部１３３は、暗号処理として、例えば通信されるデータ列の暗号化、メッセージ認証符号（Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ；ＭＡＣ）の生成、乱数の生成等を実行する。

ＮＦＣ−ＳＥＣプロトコル処理部１３４は、ＮＦＣ−ＳＥＣで規定されたプロトコルを処理する。ＮＦＣ−ＳＥＣで規定されたプロトコルには、ＳＳＥ（Ｓｈａｒｅｄ ＳＥｃｒｅｔ ｓｅｒｖｉｃｅ）及びＳＣＨ（Ｓｅｃｕｒｅ ＣＨａｎｎｅｌ ｓｅｒｖｉｃｅ）がある。ＳＳＥは、ＮＦＣ−ＳＥＣを使用するデバイスの間で、共有秘密情報を生成し、デバイス間で共有するサービスである。またＳＣＨは、ＳＳＥで共有された共有秘密情報を用いて、ＮＦＣ−ＳＥＣを使用するデバイスの間で暗号化通信を実行するサービスであり、すべてのチャネルの通信が暗号化される。ＮＦＣ−ＳＥＣプロトコル処理部１３４は、本開示の暗号化情報生成部の一例に該当する。ＮＦＣＩＰ−１プロトコル処理部１３５は、ＮＦＣＩＰ−１で規定されたプロトコルを処理する。

本開示の一実施形態に係る通信装置１００は、図２に示したような構成を有することで、ＲＦ通信部１３０によって、通信装置２００との間の近距離無線通信を実行する。

図２に示したＲＦ通信部１３０は、例えば非接触無線チップ（ＣＬＦ；Ｃｏｎｔａｃｔｌｅｓｓ Ｆｒｏｎｔ Ｅｎｄ）として、１つのＩＣチップ上で実現されるようにしてもよい。なお、図２に示したＲＦ通信部１３０に加えて、制御部１１０もＣＬＦとして１つのＩＣチップ上で実現されるようにしてもよい。さらに、ＲＦ通信部１３０及び制御部１１０に加えて、記憶部１１１もＣＬＦとして１つのＩＣチップ上で実現されるようにしてもよい。

この他にも、本開示の一実施形態に係る通信装置１００のハードウェア構成は様々な形態を採り得る。例えば、図２に示した通信装置１００がＣＬＦ、ＤＨ（Ｄｅｖｉｃｅ Ｈｏｓｔ）、ＳＥ（Ｓｅｃｕｒｅ Ｅｌｅｍｅｎｔ）で構成される場合、通信装置１００のハードウェア構成は、図３に示すような形態のいずれかを採り得る。

図３のケース１は、全ての機能がＣＬＦで処理される。すなわち、ＣＬＦの内部でセキュアに情報が格納される。図３のケース２は、情報の格納のみをＳＥが行い、その他の処理はＣＬＦが行う。図３のケース３は、ＲＦ通信はＣＬＦが行い、通信装置１００の制御及び情報の格納はＳＥが行う。図３のケース４は、ＲＦ通信はＣＬＦが行い、通信装置１００の制御はＤＨが行い、情報の格納はＳＥが行う。図３のケース５は、ＲＦ通信はＣＬＦが行い、通信装置１００の制御及び情報の格納をＤＨが行うことで、ＤＨ内部でセキュアに情報が格納される。

なお図２には図示しないが本開示の一実施形態に係る通信装置１００は、所定の周波数で他の装置と近距離非接触無線通信を行うためのアンテナが設けられ得る。係るアンテナは例えばＲＦ通信部１３０に設けられ得る。

以上、図２を用いて本開示の一実施形態に係る通信装置１００の機能構成例について説明した。次に、本開示の一実施形態に係る通信装置１００の動作例について説明する。

［通信装置の動作例（基本シーケンス）］
まず、２台の通信装置１００、２００の間で安全に相互認証を行う場合の基本シーケンスの例を示す。図４は、本開示の一実施形態に係る通信装置１００、２００の動作例を示す流れ図である。この図４に示した動作は、例えばＲＦ通信部１３０がＬＬＣＰによって実行し得る。以下、図４を用いて本開示の一実施形態に係る通信装置１００、２００の動作例について説明する。

通信装置１００、２００を至近距離に近づけることでＲＦ通信が行われる場合、まず通信装置１００、２００は、記憶部１１１に記憶されているお互いの機器ＩＤをＲＦ通信により交換する（ステップＳ１０１）。図４に示した基本シーケンスのように、例えば通信装置２００から受け取った機器ＩＤが通信装置１００の中に保存されている機器ＩＤと一致しなかった場合、又は、通信装置１００から受け取った機器ＩＤが通信装置２００の中に保存されている機器ＩＤと一致しなかった場合は、通信装置１００と通信装置２００とによるＲＦ通信は初めてだと判断される。通信装置１００と通信装置２００とによるＲＦ通信が初めてだと判断すると、通信装置１００、２００は、ＮＦＣ−ＳＥＣによる共有秘密情報Ｋ１を生成する（ステップＳ１０２）。生成した共有秘密情報Ｋ１は、お互い、通信相手を識別する機器ＩＤと紐付けられて、通信装置１００、２００の内部に保存される。通信装置１００、２００は、ＮＦＣ−ＳＥＣによる共有秘密情報Ｋ１を生成すると、ＲＦ通信を一旦終了する。

通信装置１００、２００はそれぞれ、上記ステップＳ１０１の機器ＩＤを交換の際に相手を記憶しておくかどうか選択できるようにしてもよい。例えば、ユーザが自分の目で信頼する相手だと確認してから、通信装置１００で表示されるユーザインタフェースを操作するというユースケースが想定され得る。

以上、図４を用いて、お互いの機器ＩＤを交換した際に、取得した機器ＩＤが保存されている機器ＩＤと一致しなかった場合の、通信装置１００、２００の動作例について説明した。

図５は、本開示の一実施形態に係る通信装置１００、２００の動作例を示す流れ図である。この図５に示した動作は、例えばＲＦ通信部１３０がＬＬＣＰによって実行し得る。以下、図５を用いて本開示の一実施形態に係る通信装置１００、２００の動作例について説明する。

通信装置１００、２００を至近距離に近づけることでＲＦ通信が行われる場合、まず通信装置１００、２００は、記憶部１１１に記憶されているお互いの機器ＩＤをＲＦ通信により交換する（ステップＳ１１１）。図５に示したシーケンスのように、通信装置２００から受け取った機器ＩＤが通信装置１００の中に保存されている機器ＩＤと一致した場合、及び、通信装置１００から受け取った機器ＩＤが通信装置２００の中に保存されている機器ＩＤと一致した場合は、通信装置１００と通信装置２００とによるＲＦ通信が以前に行われ、ＮＦＣ−ＳＥＣによる共有秘密情報Ｋ１が生成済みであると判断される。通信装置１００と通信装置２００とによるＲＦ通信が以前に行われたと判断すると、通信装置１００、２００は、共有秘密情報Ｋ１を秘密鍵として相互認証を行い、相互認証の後にセッション鍵Ｋ２を生成する（ステップＳ１１２）。セッション鍵Ｋ２を生成すると、通信装置１００、２００はお互いに暗号化したＲＦ通信を行う（ステップＳ１１３）。

以上、図５を用いて、お互いの機器ＩＤを交換した際に、取得した機器ＩＤが保存されている機器ＩＤと一致した場合の、通信装置１００、２００の動作例について説明した。

なお、一方だけで機器ＩＤが一致したと判断された場合は、上記ステップＳ１１２の相互認証の時点で相互認証が失敗することになる。一方だけで機器ＩＤが一致したと判断された場合としては、例えば通信装置２００において、通信装置１００の機器ＩＤが破棄されたような場合が考えられ得る。このような場合を考慮したシーケンス例について説明する。

図６は、本開示の一実施形態に係る通信装置１００、２００の動作例を示す流れ図である。図６に示した流れ図は、お互いの機器ＩＤを交換した後に、通信装置１００、２００のそれぞれで、取得した機器ＩＤと保存されている機器ＩＤとを比較する場合のシーケンス例である。以下、図６を用いて本開示の一実施形態に係る通信装置１００、２００の動作例について説明する。

通信装置１００、２００を至近距離に近づけることでＲＦ通信が行われる場合、まず通信装置１００、２００は、記憶部１１１に記憶されているお互いの機器ＩＤをＲＦ通信により交換する（ステップＳ１２１）。お互いの機器ＩＤを交換すると、続いて通信装置１００、２００はそれぞれ、内部での機器ＩＤの比較結果を交換する（ステップＳ１２２）。

上記ステップＳ１２２で、お互いに内部での機器ＩＤの比較結果を交換した結果、機器ＩＤが一致しなかったことが分かった場合は、通信装置１００と通信装置２００とによるＲＦ通信は初めてだと判断される。通信装置１００と通信装置２００とによるＲＦ通信が初めてだと判断すると、通信装置１００、２００は、ＮＦＣ−ＳＥＣによる共有秘密情報Ｋ１を生成する（ステップＳ１２３）。通信装置１００、２００は、ＮＦＣ−ＳＥＣによる共有秘密情報Ｋ１を生成すると、ＲＦ通信を一旦終了する。

図７は、本開示の一実施形態に係る通信装置１００、２００の動作例を示す流れ図である。図７に示した流れ図は、お互いの機器ＩＤを交換した後に、通信装置１００、２００のそれぞれで、取得した機器ＩＤと保存されている機器ＩＤとを比較する場合のシーケンス例である。以下、図７を用いて本開示の一実施形態に係る通信装置１００、２００の動作例について説明する。

通信装置１００、２００を至近距離に近づけることでＲＦ通信が行われる場合、まず通信装置１００、２００は、記憶部１１１に記憶されているお互いの機器ＩＤをＲＦ通信により交換する（ステップＳ１３１）。お互いの機器ＩＤを交換すると、続いて通信装置１００、２００はそれぞれ、内部での機器ＩＤの比較結果を交換する（ステップＳ１３２）。

上記ステップＳ１３２で、お互いに内部での機器ＩＤの比較結果を交換した結果、機器ＩＤが一致したことが分かった場合は、通信装置１００と通信装置２００とによるＲＦ通信が以前に行われ、ＮＦＣ−ＳＥＣによる共有秘密情報Ｋ１が生成済みであると判断される。通信装置１００と通信装置２００とによるＲＦ通信が以前に行われたと判断すると、通信装置１００、２００は、共有秘密情報Ｋ１を秘密鍵として相互認証を行い、相互認証の後にセッション鍵Ｋ２を生成する（ステップＳ１３３）。セッション鍵Ｋ２を生成すると、通信装置１００、２００はお互いに暗号化したＲＦ通信を行う（ステップＳ１３４）。

このように、お互いの機器ＩＤを交換した後に、通信装置１００、２００のそれぞれで、取得した機器ＩＤと保存されている機器ＩＤとを比較し、その比較結果を交換することで、相互認証の時点での相互認証の失敗が回避される。

このように動作することで、本開示の一実施形態に係る通信装置１００は、他の通信装置（例えば通信装置２００）との間で近距離無線通信を実行する際に、ＮＦＣ−ＳＥＣを用いた相互認証を安全に実行することが出来る。すなわち、本開示の一実施形態に係る通信装置１００は、近距離無線通信を実行する相手が、以前に機器ＩＤを交換し、ＮＦＣ−ＳＥＣによる共有秘密情報Ｋ１が生成済みであることを判断してから、その相手との間の暗号通信を実行することが出来る。

以上、２台の通信装置１００、２００の間で安全に相互認証を行う場合の基本シーケンスの例について説明した。次に、本開示の一実施形態に係る通信装置１００のより具体的な動作例について説明する。

［プロトコル及びプロトコルメッセージ例］
ここで、本開示の一実施形態に係る通信装置１００のより具体的な動作例について説明する前に、本開示の一実施形態に係る通信装置１００が実行する近距離無線通信において用いられるプロトコル及びそのプロトコルで用いられるプロトコルメッセージの例を説明する。

図８は、本開示の一実施形態に係る通信装置１００が実行する近距離無線通信において用いられるプロトコルのプロトコル層、及び暗号化されるプロトコルデータの例を示す説明図である。

図８に示したように、ＮＦＣＩＰ−１層の上位にＮＦＣ−ＳＥＣ層が位置する。ＮＦＣ−ＳＥＣ層の上位に、例えばＬＬＣＰ層が位置する。ＬＬＣＰ層にはリンク層とトランスポート層とがある。ＬＬＣ ＰＤＵはリンク層で扱われ、ＬＬＣ Ｉ ＰＤＵはトランスポート層（コネクション指向トランスポート）で扱われる。

ＮＦＣ−ＳＥＣによって生成された鍵を秘密鍵として、鍵共有を行って生成した別のセッション鍵は、上位層のプロトコルデータの暗号化に適用することができる。例えばＮＦＣ−ＳＥＣによって生成された鍵を秘密鍵として、鍵共有を行って生成した別のセッション鍵は、ＬＬＣ ＰＤＵやＬＬＣ Ｉ ＰＤＵのＩｎｆｏｒｍａｔｉｏｎフィールドの暗号化に適用し得る。

なお鍵共有の際には、ＮＦＣ−ＳＥＣは必ずしも利用されなくても良い。鍵の共有にＮＦＣ−ＳＥＣを利用しない場合は、図８に示したＮＦＣ−ＳＥＣ ＰＤＵは使用されない。従って鍵共有にＮＦＣ−ＳＥＣを利用しない場合は、鍵共有は、複数のコネクションを確立して同時に通信を実行することが可能なＬＬＣ ＰＤＵを使って行われる。図９は、本開示の一実施形態に係る通信装置１００が実行する近距離無線通信において用いられるプロトコルのプロトコル層と、暗号化されるプロトコルデータの例を示す説明図であり、鍵共有にＮＦＣ−ＳＥＣを利用しない場合を示した図である。

通信装置１００は、機器ＩＤ及びセキュリティプロトコル指示情報の交換に、ＩＳＯ／ＩＥＣ １８０９２で定義されるＡＴＲ＿ＲＥＱ及びＡＴＲ＿ＲＥＳのＧｅｎｅｒａｌ Ｂｙｔｅｓ（汎用バイト）を利用する。

図１０は、ＩＳＯ／ＩＥＣ １８０９２で用意されているリクエストコマンドである、コマンドＡＴＲ＿ＲＥＱの構造を示す説明図である。コマンドＡＴＲ＿ＲＥＱは、イニシエータが、ターゲットに対して、自身の属性情報（仕様）を知らせるとともに、ターゲットの属性情報を要求するときに、ターゲットに送信される。ここで、イニシエータまたはターゲットの属性情報としては、そのイニシエータまたはターゲットが送受信することのできるデータの伝送レートなどがある。なお、コマンドＡＴＲ＿ＲＥＱには、イニシエータの属性情報の他、そのイニシエータを特定するＮＦＣＩＤなどが配置され、ターゲットは、コマンドＡＴＲ＿ＲＥＱを受信することにより、イニシエータの属性情報とＮＦＣＩＤを認識する。

図１０に示したように、コマンドＡＴＲ＿ＲＥＱは、先頭から（図１０中左から）、ＣＭＤ０フィールド、ＣＭＤ１フィールドおよび、Ｂｙｔｅ０〜Ｂｙｔｅ１４＋ｎフィールド（ｎは０以上の整数値）から構成されている。

ＣＭＤ０フィールドとＣＭＤ１フィールドには、それぞれ、このコマンドがコマンドＡＴＲ＿ＲＥＱであることを示す値“Ｄ４”と“００”が格納される。Ｂｙｔｅ０〜Ｂｙｔｅ９フィールドには、このコマンドＡＴＲ＿ＲＥＱを送信する通信装置（イニシエータ）を特定するＮＦＣＩＤ（ｎｆｃｉｄ３ｉ０〜ｎｆｃｉｄ３ｉ９）が格納される。Ｂｙｔｅ１０フィールドには、このコマンドＡＴＲ＿ＲＥＱを送信するイニシエータのデバイスＩＤであるＤＩＤｉが設定される。Ｂｙｔｅ１０フィールドは、ＤＩＤｉフィールドとも称される。

Ｂｙｔｅ１１フィールドには、このコマンドＡＴＲ＿ＲＥＱを送信するイニシエータがデータを送信することができるビットレート（伝送レート）ＢＳｉが設定される。Ｂｙｔｅ１２フィールドには、このコマンドＡＴＲ＿ＲＥＱを送信するイニシエータがデータを受信することができるビットレート（伝送レート）ＢＲｉが設定される。

Ｂｙｔｅ１３フィールドには、このコマンドＡＴＲ＿ＲＥＱを送信するイニシエータについてのオプションパラメータＰＰｉが設定される。このＢｙｔｅ１３フィールドには、例えば、自デバイスがＮＦＣ−ＳＥＣによる処理が可能であることを示すパラメータが設定される。

Ｂｙｔｅ１４〜Ｂｙｔｅ１４＋ｎフィールドのそれぞれは、設計者等により指定される各種情報が設定されるフィールドであって、オプションとして用意されているフィールドである。値ｎは、設計者等により可変可能とされており、０以上の整数値となる。この値ｎは、後述するように、ＰＰｉフィールドに設定される。以下、ｎ個のＧｉフィールドのそれぞれを、その配置順に（図１０中左から順に）、Ｇｉ［０］〜Ｇｉ［ｎ］フィールドと呼ぶ。

図１１は、ＩＳＯ／ＩＥＣ １８０９２で用意されているレスポンスコマンドである、コマンドＡＴＲ＿ＲＥＳの構造を示す説明図である。コマンドＡＴＲ＿ＲＥＳは、ターゲットが、コマンドＡＴＲ＿ＲＥＱを受信した場合に、そのコマンドＡＴＲ＿ＲＥＱに対するレスポンスとして、イニシエータに送信される。コマンドＡＴＲ＿ＲＥＳには、ターゲットの属性情報やＮＦＣＩＤなどが配置される。

図１１に示したように、コマンドＡＴＲ＿ＲＥＳは、先頭から（図１１中左から）、ＣＭＤ０フィールド、ＣＭＤ１フィールド、および、Ｂｙｔｅ０〜Ｂｙｔｅｎ＋１５フィールド（ｎは０以上の整数値）から構成されている。

ＣＭＤ０フィールドとＣＭＤ１フィールドには、それぞれ、このコマンドがコマンドＡＴＲ＿ＲＥＳであることを示す値“Ｄ５”と“０１”が格納される。Ｂｙｔｅ０〜Ｂｙｔｅ１２フィールドには、上述したコマンドＡＴＲ＿ＲＥＱのＢｙｔｅ０〜Ｂｙｔｅ１２フィールドと同様のデータが設定される。すなわち、Ｂｙｔｅ０〜Ｂｙｔｅ９フィールドには、このコマンドＡＴＲ＿ＲＥＳを送信するデバイス、即ち、ターゲットを特定するＮＦＣＩＤが格納される。Ｂｙｔｅ１０フィールドには、このコマンドＡＴＲ＿ＲＥＱを送信するイニシエータが指定したデバイスＩＤまたはゼロが設定される。Ｂｙｔｅ１０フィールドは、ＤＩＤｔフィールドとも称される。

Ｂｙｔｅ１１フィールドには、このコマンドＡＴＲ＿ＲＥＳを送信するターゲットがデータを送信することができるビットレート（伝送レート）ＢＳｔが設定される。Ｂｙｔｅ１２フィールドには、このコマンドＡＴＲ＿ＲＥＳを送信するターゲットがデータを受信することができるビットレート（伝送レート）ＢＲｔが設定される。Ｂｙｔｅ１３フィールドには、ターゲットのタイムアウトの値ＴＯが設定される。

Ｂｙｔｅ１４フィールドは、コマンドＡＴＲ＿ＲＥＱのＢｙｔｅ１３フィールドと同様である。すなわち、Ｂｙｔｅ１４フィールドには、このコマンドＡＴＲ＿ＲＥＳを送信するターゲットについてのオプションパラメータＰＰｔが設定される。なお、以下、コマンドＡＴＲ＿ＲＥＳのＢｙｔｅ１４フィールドを、ＰＰｔフィールドとも称する。

Ｂｙｔｅ１５〜Ｂｙｔｅ１５＋ｎフィールドは、コマンドＡＴＲ＿ＲＥＱのＢｙｔｅ１４〜Ｂｙｔｅ１４＋ｎフィールドとそれぞれ同様である。すなわち、Ｂｙｔｅ１５〜Ｂｙｔｅ１５＋ｎフィールドは、上位層のアプリケーションや設計者等により指定される各種情報が設定されるフィールドであって、オプションとして用意されているフィールドである。値ｎは、設計者等により可変可能とされており、０以上の整数値となる。以下、ｎ個のＧｔフィールドのそれぞれを、その配置順に（図１１中左から順に）、Ｇｔ［０］〜Ｇｔ［ｎ］フィールドと呼ぶ。

本実施形態では、ＡＴＲ＿ＲＥＱの場合はＧｉ［ｎ］に、ＡＴＲ＿ＲＥＳの場合はＧｔ［ｎ］に，それぞれ自身の機器ＩＤと、セキュリティプロトコル指示情報とを格納して相手へ通知する。これらの情報はＬＬＣ ＰＡＸ ＰＤＵを使って交換してもよい。

本実施形態で用いられる機器ＩＤは、例えばＩＣチップ固有のＩＤを用いてもよい。すなわち本実施形態で用いられる機器ＩＤは、ＩＳＯ／ＩＥＣ ＪＴＣ １／ＳＣ １７ Ｎ ４１４０で割り当てられる値によって製造者が識別できるようにしてもよい。例えば本実施形態で用いられる機器ＩＤは、図１２に示したように、ＴＬＶ（Ｔｙｐｅ−ｌｅｎｇｔｈ−ｖａｌｕｅ）形式によってＡＴＲ＿ＲＥＱ及びＡＴＲ＿ＲＥＳに格納されても良い。

上述のセキュリティプロトコル指示情報は、相手機器と暗号通信を行うかどうか、また暗号通信を行う場合はセッション鍵生成方法と暗号化範囲を示すための情報である。セキュリティプロトコル指示情報は、例えば図１３に示したようなＴＬＶ形式を用いて、ＡＴＲ＿ＲＥＱ及びＡＴＲ＿ＲＥＳに格納されても良い。セキュリティプロトコル指示情報で指定する値を、セキュリティプロトコル番号と称する。

セキュリティプロトコルには、鍵共有の方法（例えばＩＳＯ／ＩＥＣ １３１５７−２で定義される方法）、相互認証の方法（例えばＩＳＯ／ＩＥＣ ９７９８−２をベースとした方法）、及び通信暗号化の方法（例えばＩＳＯ／ＩＥＣ １８０３３やＩＳＯ／ＩＥＣ ２９１９２で定義される方法）が含まれ得る。

本実施形態では、ＰＡＸ ＰＤＵを利用した機器ＩＤ及びセキュリティプロトコル指示情報の交換の際に、図１４に示したような、自装置のセキュリティプロトコル能力情報、すなわち、どのセキュリティプロトコルが使用可能かについての情報を相手に提供し、相手に選択を促すようにしてもよい。

取得した機器ＩＤと保存されている機器ＩＤとの比較は，それぞれの通信装置で実行されるので、一方の通信装置では両者が一致し、もう一方の通信装置では両者が一致しない場合もありうる。そこで、上述し、また図６及び図７で示したように、取得した機器ＩＤと保存されている機器ＩＤとの比較結果を相手に通知することで，失敗することが明らかな相互認証を開始する必要が無くなる。例えば、図１５に示したようなＴＬＶ形式を用い、ＰＡＸ ＰＤＵを利用して機器ＩＤの比較結果の情報を相手に通知しても良い。

本実施形態に係る通信装置１００、２００は、ＡＴＲ＿ＲＥＱ／ＲＥＳ交換後のデータ交換に、ＩＳＯ／ＩＥＣ １８０９２で用意されているＤＥＰ＿ＲＥＱ及びＤＥＰ＿ＲＥＳを利用する。

図１６は、ＩＳＯ／ＩＥＣ １８０９２で用意されているリクエストコマンドであるコマンドＤＥＰ＿ＲＥＱ、及びレスポンスコマンドであるコマンドＤＥＰ＿ＲＥＳの構造を示す説明図である。コマンドＤＥＰ＿ＲＥＱは、イニシエータが、データ（いわゆる実データ）の送受信（ターゲットとの間のデータ交換）を行うときに送信され、そこには、ターゲットに送信すべきデータが配置される。コマンドＤＥＰ＿ＲＥＳは、ターゲットが、コマンドＤＥＰ＿ＲＥＱに対するレスポンスとして送信し、そこには、イニシエータに送信すべきデータが配置される。従って、コマンドＤＥＰ＿ＲＥＱによって、イニシエータからターゲットにデータが送信され、そのコマンドＤＥＰ＿ＲＥＱに対するレスポンスであるコマンドＤＥＰ＿ＲＥＳによって、ターゲットからイニシエータにデータが送信される。

ＮＦＣ−ＳＥＣの上位層の例として，ＬＬＣＰがある。図１７は、ＬＬＣ ＰＤＵの構造を示す説明図である。図１７に示したように、ＬＬＣ ＰＤＵは、ＤＳＡＰフィールドと、ＰＴＹＰＥ（Ｐａｙｌｏａｄ ｄａｔａ ｕｎｉｔ ｔｙｐｅ）フィールドと、ＳＳＡＰフィールドと、Ｓｅｑｕｅｎｃｅフィールドと、Ｉｎｆｏｒｍａｔｉｏｎフィールドと、で構成される。ＤＳＡＰフィールド、ＰＴＹＰＥフィールド、ＳＳＡＰフィールド及びＳｅｑｕｅｎｃｅフィールドはＬＬＣＰヘッダで、ＩｎｆｏｒｍａｔｉｏｎフィールドはＬＬＣＰペイロードである。

ＤＳＡＰフィールドには、ＤＳＡＰのアドレスが格納される。ＰＴＹＰＥフィールドにはＰＤＵのタイプが格納される。ＰＤＵのタイプはＮＦＣ Ｆｏｒｕｍ Ｌｏｇｉｃａｌ Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌにおいて定義されており、そのＰＤＵのタイプに応じた値が格納される。ＳＳＡＰフィールドには、ＳＳＡＰのアドレスが格納される。Ｓｅｑｕｅｎｃｅフィールドには、ＬＬＣ ＰＤＵのシーケンス番号が格納される。Ｉｎｆｏｒｍａｔｉｏｎフィールドには、ＬＬＣ ＰＤＵによってやり取りされる情報が格納される。

図１８は、図１７に示したＬＬＣ ＰＤＵの構造におけるＰＴＹＰＥフィールドに格納される情報を示す説明図である。図１８の“ＰＴＹＰＥ”が図１７のＰＴＹＰＥフィールドに格納される値である。図１８に示した値はＮＦＣ Ｆｏｒｕｍ Ｌｏｇｉｃａｌ Ｌｉｎｋ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ ＴＳにおいて決められている値である。

本実施形態に係る通信装置１００、２００は、共有秘密情報の生成に、ＩＳＯ／ＩＥＣ １３１５７−１で用意されているＡＣＴ＿ＲＥＱ、ＡＣＴ＿ＲＥＳ及びＶＦＹ＿ＲＥＱ、ＶＦＹ＿ＲＥＳを利用する。図１９は、ＮＦＣ−ＳＥＣのプロトコルデータユニットの構造を示す説明図である。図１９に示したように、ＮＦＣ−ＳＥＣのプロトコルデータユニットは、ＳＥＰ（Ｓｅｃｕｒｅ Ｅｘｃｈａｇｅ Ｐｒｏｔｏｃｏｌ）、ＰＩＤ（Ｐｒｏｔｏｃｏｌ Ｉｄｅｎｔｉｆｉｅｒ）及びＮＦＣ−ＳＥＣ Ｐａｙｌｏａｄの各フィールドで構成される。

ＳＥＰフィールドには、ＮＦＣ−ＳＥＣのプロトコルデータユニットのタイプや、ＳＳＥとＳＣＨのどちらを使用しているか等のデータが格納される。図２０は、ＮＦＣ−ＳＥＣのプロトコルデータユニットの各コマンドが使用するフィールドの関係を示す説明図である。ｍは値の格納が義務付けられ、ｐは値の格納が禁止され、ｃは条件付きで値の格納が認められることを示す。

また、図２１は、ＳＥＰフィールドのビット割り当てを示す説明図であり、図２２は、ＳＥＰフィールドに格納されるコード及びそのコードが示す内容の対応関係を示す説明図である。ＰＩＤフィールドには、ＮＦＣ−ＳＥＣによる暗号処理で用いられるＰＩＤが格納される。ＮＦＣ−ＳＥＣ ＰａｙｌｏａｄフィールドにはＮＦＣ−ＳＥＣによる暗号処理で使用されるデータが格納される。

ＮＦＣ−ＳＥＣにより生成される共有秘密情報Ｋ１を用いた、通信装置１００、２００の間の相互認証は、ＬＬＣ ＳＡＣ ＰＤＵ（Ｓｅｃｕｒｉｔｙ Ａｃｔｉｖａｔｉｏｎ ＰＤＵ）を利用する。本実施形態においては、このＰＤＵはＰＴＹＰＥフィールドに“１０１０ｂ”が指定される。表１は、ＬＬＣ ＳＡＣ ＰＤＵを利用して通信装置１００、２００の間の相互認証を実行する場合のパラメータの例を示す表である。

表１で示されている、ＳＫ１＿ＲＥＱ ＴＬＶ、ＳＫ１＿ＲＥＳ ＴＬＶ、ＳＫ２＿ＲＥＱ ＴＬＶ、およびＳＫ２＿ＲＥＳ ＴＬＶは、ＬＬＣ ＳＡＣ ＰＤＵにより鍵を共有するためのパラメータである。表２は、ＳＫ１＿ＲＥＱ ＴＬＶ、ＳＫ１＿ＲＥＳ ＴＬＶ、ＳＫ２＿ＲＥＱ ＴＬＶ、およびＳＫ２＿ＲＥＳ ＴＬＶとして授受される鍵共有用のパラメータ例を示す表である。

表２に示したパラメータにおいて、Ｌｅｎ及びＶａｌｕｅは，セキュリティプロトコル番号に対応するセキュリティプロトコルで定義された値が用いられる。Ｄｅｓｃｒｉｐｔｉｏｎで記載されるパラメータは、例えばＩＳＯ／ＩＥＣ１３１５７−２で定義されるＫｅｙ ａｇｒｅｅｍｅｎｔ及びＫｅｙ ｃｏｎｆｉｒｍａｔｉｏｎを利用する場合のパラメータである。

また表１で示されている、ＳＡ１＿ＲＥＱ ＴＬＶ、ＳＡ１＿ＲＥＳ ＴＬＶ、ＳＡ２＿ＲＥＱ ＴＬＶ、およびＳＡ２＿ＲＥＳ ＴＬＶは、ＬＬＣ ＳＡＣ ＰＤＵにより相互認証を実行するためのパラメータである。表３は、ＳＡ１＿ＲＥＱ ＴＬＶ、ＳＡ１＿ＲＥＳ ＴＬＶ、ＳＡ２＿ＲＥＱ ＴＬＶ、およびＳＡ２＿ＲＥＳ ＴＬＶとして授受される相互認証用のパラメータを示す説明図である。

表２に示したパラメータにおいて、Ｌｅｎ及びＶａｌｕｅは，セキュリティプロトコル番号に対応するセキュリティプロトコルで定義された値が用いられる。また表２に示したパラメータにおいて、Ｄｅｓｃｒｉｐｔｉｏｎで記載されるパラメータは、例えばＩＳＯ／ＩＥＣ ９７９８−２で定義されるＴｈｒｅｅ−ｐａｓｓ ａｕｔｈｅｎｔｉｃａｔｉｏｎを利用する場合のパラメータである。Ｆｏｕｒ−ｐａｓｓ ａｕｔｈｅｎｔｉｃａｔｉｏｎを利用する場合は、別のパラメータが指定される。

ＮＦＣ−ＳＥＣにより生成される共有秘密情報Ｋ１によって相互認証された通信装置１００、２００の間の、ＬＬＣリンク層での暗号通信は、ＬＬＣ ＰＵＩ ＰＤＵ（Ｐｒｏｔｅｃｔｅｄ Ｕｎｎｕｍｂｅｒｅｄ Ｉｎｆｏｒｍａｔｉｏｎ）が用いられる。本実施形態においては、このＰＤＵはＰＴＹＰＥフィールドに“１０１１ｂ”が指定される。表４は、ＬＬＣ ＰＵＩ ＰＤＵを利用して、通信装置１００、２００の間のＬＬＣリンク層での暗号通信を実行する場合のパラメータの例を示す表である。

表４に示したＩｎｆｏｒｍａｔｉｏｎフィールドは、予め交換されるセキュリティプロトコル番号に対応するセキュリティプロトコルで定義されるので、暗号通信時のセキュリティプロトコルに依存する。

以上、本開示の一実施形態に係る通信装置１００が実行する近距離無線通信において用いられるプロトコル及びそのプロトコルで用いられるプロトコルメッセージの例を説明した。続いて、本開示の一実施形態に係る通信装置１００のより具体的な動作例について説明する。

［通信装置の動作例（具体的な処理フローの例）］
本開示の一実施形態に係る通信装置１００の動作例として２つのケースを示す。１つ目のケースは、通信装置１００が最初に暗号通信の実行を指示するケースであり、通信装置１００は機器ＩＤ及びセキュリティ指示情報をＡＴＲ＿ＲＥＱ及びＡＴＲ＿ＲＥＳで交換する。２つ目のケースは、通信装置１００が後から暗号通信の実行を指示するケースであり、通信装置１００は機器ＩＤ及びセキュリティ指示情報をＬＬＣ ＰＡＸ ＰＤＵで交換する。以下の説明では、前者をケース１、後者をケース２として説明する。

図２３は、本開示の一実施形態に係る通信装置１００の動作例を示す流れ図である。図２３に示したのは、上述のケース１でイニシエータとして動作する場合の通信装置１００の動作例である。以下、図２３を用いて本開示の一実施形態に係る通信装置１００の動作例について説明する。

通信装置１００は、他の通信装置（以下では通信装置２００として説明する）との間で近距離無線通信により自装置の機器ＩＤ及びセキュリティプロトコル指示情報を交換する際に、ＡＴＲ＿ＲＥＱのＧｉ［ｎ］に、自装置の機器ＩＤ及びセキュリティプロトコル指示情報をセットする（ステップＳ２０１）。ステップＳ２０１の処理は例えば制御部１１０が実行し得る。

ＡＴＲ＿ＲＥＱのＧｉ［ｎ］に、自装置の機器ＩＤ及びセキュリティプロトコル指示情報をセットすると、続いて通信装置１００は、情報をセットしたＡＴＲ＿ＲＥＱを通信装置２００へ近距離無線通信により送信する（ステップＳ２０２）。ステップＳ２０２の送信処理はＲＦ通信部１３０が実行し得る。

情報をセットしたＡＴＲ＿ＲＥＱを通信装置２００へ近距離無線通信により送信すると、続いて通信装置１００は、ＡＴＲ＿ＲＥＱに対するレスポンスであるＡＴＲ＿ＲＥＳを通信装置２００から近距離無線通信により受信する（ステップＳ２０３）。ステップＳ２０３の受信処理はＲＦ通信部１３０が実行し得る。ＡＴＲ＿ＲＥＳのＧｔ［ｎ］には、通信装置２００の機器ＩＤ及びセキュリティプロトコル指示情報がセットされている。

ＡＴＲ＿ＲＥＱに対するレスポンスであるＡＴＲ＿ＲＥＳを通信装置２００から近距離無線通信により受信すると、続いて通信装置１００は、記憶部１１１に記憶されている機器ＩＤの中に、ＡＴＲ＿ＲＥＳにセットされている通信装置２００の機器ＩＤと同じものがあるかどうか判断する（ステップＳ２０４）。ステップＳ２０４の判断処理は制御部１１０が実行し得る。

ステップＳ２０４の判断の結果、記憶部１１１に記憶されている機器ＩＤの中に、ＡＴＲ＿ＲＥＳにセットされている通信装置２００の機器ＩＤと同じものがあると判断した場合、続いて通信装置１００は、通信装置２００との相互認証を実行する（ステップＳ２０５）。通信装置１００は、通信装置２００との相互認証の実行に際し、相手の機器ＩＤに対応する共有秘密情報Ｋ１を秘密鍵として用い、相手の機器ＩＤに対応するセキュリティプロトコルＳ１で指定された方式に従うことで通信装置２００との相互認証を実行する。通信装置２００との相互認証処理は、例えば制御部１１０や、ＬＬＣＰリンクプロトコル処理部１３２や、ＮＦＣ−ＳＥＣプロトコル処理部１３４が実行し得る。

通信装置２００との相互認証を実行すると、続いて通信装置１００は、通信装置２００との相互認証が成功したかどうか判断する（ステップＳ２０６）。ステップＳ２０６の判断処理は制御部１１０が実行し得る。なお、通信装置１００で共有秘密情報Ｋ１を保持していても、通信装置２００で共有秘密情報Ｋ１が保持されていない場合は、通信装置１００と通信装置２００との間の相互認証は失敗する。

上記ステップＳ２０６の判断の結果、通信装置２００との相互認証が成功した場合は、通信装置１００は、相互認証された通信装置２００との間での暗号通信を実行する。

ステップＳ２０４の判断の結果、記憶部１１１に記憶されている機器ＩＤの中に、ＡＴＲ＿ＲＥＳにセットされている通信装置２００の機器ＩＤと同じものがないと判断した場合、または、上記ステップＳ２０６の判断の結果、通信装置２００との相互認証が失敗した場合は、通信装置１００は、通信装置２００との間の相互認証のための共有秘密情報Ｋ１を生成するかどうか判断する（ステップＳ２０７）。ステップＳ２０７の判断処理は制御部１１０が実行し得る。また、共有秘密情報Ｋ１を生成するかどうかは、通信装置１００が実行するアプリケーションや、そのアプリケーションを使用するユーザによっても判断され得る。

ステップＳ２０７の判断の結果、共有秘密情報Ｋ１を生成しないと判断した場合は、通信装置１００は、通信装置２００との間の通信を非暗号で行うかどうか判断する（ステップＳ２０８）。ステップＳ２０８の判断処理は制御部１１０が実行し得る。また通信装置２００との間の通信を非暗号で行うかどうか、通信装置１００が実行するアプリケーションや、そのアプリケーションを使用するユーザによっても判断され得る。

上記ステップＳ２０８の判断の結果、通信装置２００との間の通信を非暗号で行うと判断した場合は、通信装置１００は、（相互認証されていない）通信装置２００との間での非暗号通信を実行する。

一方、ステップＳ２０７の判断の結果、共有秘密情報Ｋ１を生成すると判断した場合は、通信装置１００は、ＮＦＣ−ＳＥＣのＳＳＥサービスを用いて共有秘密情報Ｋ１を生成する（ステップＳ２０９）。ステップＳ２０９の共有秘密情報Ｋ１の生成は、例えばＲＦ通信部１３０、より具体的にはＮＦＣ−ＳＥＣプロトコル処理部１３４が実行し得る。

ＮＦＣ−ＳＥＣのＳＳＥサービスを用いて共有秘密情報Ｋ１を生成すると、通信装置１００は、上記ステップＳ２０３で受信したＡＴＲ＿ＲＥＳのＧｔ［ｎ］にセットされている通信装置２００の機器ＩＤに、上記ステップＳ２０９で生成した共有秘密情報Ｋ１を対応付けて登録する（ステップＳ２１０）。ステップＳ２１０の登録処理は、例えば制御部１１０が、通信装置２００の機器ＩＤに共有秘密情報Ｋ１を対応付けて記憶部１１１に記憶させることで実行し得る。

上記ステップＳ２０８での判断の結果、通信装置２００との間の通信を非暗号では行わないと判断した場合、または上記ステップＳ２１０での登録処理が完了した場合は、通信装置１００は、ＲＦ通信を終了する。

このように、通信装置１００が最初に暗号通信の実行を指示する場合には、近距離無線通信の相手と過去に通信した履歴が双方にあり、その過去の通信で共有秘密情報Ｋ１が双方に保存されていれば、相互認証が成功する。通信装置１００は、相互認証を経てからでないと通信相手との暗号化された近距離無線通信を実行することが出来ないので、より安全な暗号化された近距離無線通信を実行出来る。

なお通信装置１００は、図２３に示した例において、ステップＳ２０５における相互認証処理の開始に先立って、相手側の機器である通信装置２００に対し、自装置、すなわち通信装置１００の機器ＩＤを持っているかどうかを問い合わせても良い。通信装置１００は、当該問い合わせを、ＰＡＸ ＰＤＵを使用して行い得る。

図２４Ａ及び図２４Ｂは、本開示の一実施形態に係る通信装置１００の動作例を示す流れ図である。図２４Ａ及び図２４Ｂに示したのは、上述のケース２で動作する場合の通信装置１００の動作例である。以下、図２４Ａ及び図２４Ｂを用いて本開示の一実施形態に係る通信装置１００の動作例について説明する。

通信装置１００は、他の通信装置（以下では通信装置２００として説明する）との間で近距離無線通信を実行する際に、まずＡＴＲ＿ＲＥＱを通信装置２００へ近距離無線通信により送信する（ステップＳ２１１）。ステップＳ２０２の送信処理はＲＦ通信部１３０が実行し得る。

ＡＴＲ＿ＲＥＱを通信装置２００へ近距離無線通信により送信すると、続いて通信装置１００は、ＡＴＲ＿ＲＥＱに対するレスポンスであるＡＴＲ＿ＲＥＳを通信装置２００から近距離無線通信により受信する（ステップＳ２１２）。ステップＳ２１２の受信処理はＲＦ通信部１３０が実行し得る。

続いて通信装置１００は、通信装置２００との間で非暗号の近距離無線通信を開始する（ステップＳ２１３）。通信装置１００は、通信装置２００との間で非暗号の近距離無線通信を実行している間、装置内のアプリケーションや、ユーザインタフェース等から、相手機器である通信装置２００と暗号通信を行う指示を受領したかどうか判断する（ステップＳ２１４）。ステップＳ２１４の判断処理は、例えば制御部１１０が実行し得る。

上記ステップＳ２１４の判断の結果、通信装置２００と暗号通信を行う指示を受領していなければ、通信装置１００は、通信装置２００との間での非暗号の近距離無線通信を継続する。一方、上記ステップＳ２１４の判断の結果、通信装置２００と暗号通信を行う指示を受領していれば、続いて通信装置１００は、相手機器である通信装置２００から機器ＩＤを受領済みかどうか判断する（ステップＳ２１５）。ステップＳ２１４の判断処理は、例えば制御部１１０が実行し得る。

ステップＳ２１５の判断の結果、通信装置２００から機器ＩＤを受領済みで無ければ、通信装置１００は、ＬＬＣ ＰＡＸ ＰＤＵにより通信装置２００との間で機器ＩＤ及びセキュリティプロトコル指示情報を交換する（ステップＳ２１６）。このステップＳ２１６の交換処理は、ＲＦ通信部１３０、具体的にはＬＬＣＰコネクション処理部１３１が実行し得る。

通信装置２００から機器ＩＤを受領すると、続いて通信装置１００は、記憶部１１１に記憶されている機器ＩＤの中に、ＡＴＲ＿ＲＥＳにセットされている通信装置２００の機器ＩＤと同じものがあるかどうか判断する（ステップＳ２１７）。ステップＳ２１７の判断処理は制御部１１０が実行し得る。

ステップＳ２１７の判断の結果、記憶部１１１に記憶されている機器ＩＤの中に、ＡＴＲ＿ＲＥＳにセットされている通信装置２００の機器ＩＤと同じものがないと判断した場合は、通信装置１００は、ＮＦＣ−ＳＥＣのＳＳＥサービスを用いて共有秘密情報Ｋ１を生成する（ステップＳ２１８）。ステップＳ２１８の共有秘密情報Ｋ１の生成は、例えばＲＦ通信部１３０、より具体的にはＮＦＣ−ＳＥＣプロトコル処理部１３４が実行し得る。

ＮＦＣ−ＳＥＣのＳＳＥサービスを用いて共有秘密情報Ｋ１を生成すると、通信装置１００は、上記ステップＳ２１２で受信したＡＴＲ＿ＲＥＳのＧｔ［ｎ］にセットされている通信装置２００の機器ＩＤに、上記ステップＳ２１８で生成した共有秘密情報Ｋ１を対応付けて登録する（ステップＳ２１９）。ステップＳ２１９の登録処理は、例えば制御部１１０が、通信装置２００の機器ＩＤに共有秘密情報Ｋ１を対応付けて記憶部１１１に記憶させることで実行し得る。

ステップＳ２１７の判断の結果、記憶部１１１に記憶されている機器ＩＤの中に、ＡＴＲ＿ＲＥＳにセットされている通信装置２００の機器ＩＤと同じものがあると判断した場合、または、上記ステップＳ２１９の登録処理が完了した場合は、続いて通信装置１００は、通信装置２００との相互認証を実行する（ステップＳ２２０）。通信装置１００は、通信装置２００との相互認証の実行に際し、相手の機器ＩＤに対応する共有秘密情報Ｋ１を秘密鍵として用い、相手の機器ＩＤに対応するセキュリティプロトコルＳ１で指定された方式に従うことで通信装置２００との相互認証を実行する。通信装置２００との相互認証処理は、例えば制御部１１０や、ＬＬＣＰリンクプロトコル処理部１３２や、ＮＦＣ−ＳＥＣプロトコル処理部１３４が実行し得る。

通信装置２００との相互認証を実行すると、続いて通信装置１００は、通信装置２００との相互認証が成功したかどうか判断する（ステップＳ２２１）。ステップＳ２２１の判断処理は制御部１１０が実行し得る。なお、通信装置１００で共有秘密情報Ｋ１を保持していても、通信装置２００で共有秘密情報Ｋ１が保持されていない場合は、通信装置１００と通信装置２００との間の相互認証は失敗する。

上記ステップＳ２２１の判断の結果、通信装置２００との相互認証が成功した場合は、通信装置１００は、相互認証された通信装置２００との間での暗号通信を実行する。

一方、上記ステップＳ２２１の判断の結果、通信装置２００との相互認証が失敗した場合は、通信装置１００は、通信装置２００との間の相互認証のための共有秘密情報Ｋ１を生成するかどうか判断する（ステップＳ２２２）。ステップＳ２２２の判断処理は制御部１１０が実行し得る。また、共有秘密情報Ｋ１を生成するかどうかは、通信装置１００が実行するアプリケーションや、そのアプリケーションを使用するユーザによっても判断され得る。

ステップＳ２２２の判断の結果、共有秘密情報Ｋ１を生成しないと判断した場合は、通信装置１００は、通信装置２００との間の通信を非暗号で行うかどうか判断する（ステップＳ２２３）。ステップＳ２２３の判断処理は制御部１１０が実行し得る。また通信装置２００との間の通信を非暗号で行うかどうか、通信装置１００が実行するアプリケーションや、そのアプリケーションを使用するユーザによっても判断され得る。

上記ステップＳ２２３の判断の結果、通信装置２００との間の通信を非暗号で行うと判断した場合は、通信装置１００は、（相互認証されていない）通信装置２００との間での非暗号通信を実行する。一方上記ステップＳ２２３での判断の結果、通信装置２００との間の通信を非暗号では行わないと判断した場合は、通信装置１００は、ＲＦ通信を終了する。

ステップＳ２２２の判断の結果、共有秘密情報Ｋ１を生成すると判断した場合は、通信装置１００は、上記ステップＳ２１８の共有秘密情報Ｋ１の生成処理を実行する。

このように、通信装置１００が後から暗号通信の実行を指示する場合にも、近距離無線通信の相手と過去に通信した履歴が双方にあり、その過去の通信で共有秘密情報Ｋ１が双方に保存されていれば、相互認証が成功する。通信装置１００は、後から暗号通信の実行を指示する場合であっても、相互認証を経てからでないと通信相手との暗号化された近距離無線通信を実行することが出来ないので、より安全な暗号化された近距離無線通信を実行出来る。

通信装置２００は、図２４Ａ、図２４Ｂに示した例において、ステップＳ２２０における相互認証処理の開始に先立って、相手側の機器である通信装置２００に対し、自装置、すなわち通信装置１００の機器ＩＤを持っているかどうかを問い合わせても良い。通信装置１００は、当該問い合わせを、ＰＡＸ ＰＤＵを使用して行い得る。

図２３及び図２４Ａ、図２４Ｂに示した流れ図では、ステップＳ２０６またはステップＳ２２０で相互認証の成否を判断しているが、自装置で共有秘密情報Ｋ１を保持していても、相手の装置が共有秘密情報Ｋ１を保持していなければ相互認証は失敗する。従って、本開示では、通信装置１００は、ステップＳ２０６またはステップＳ２２０での相互認証の成否の判断に先立って、相手の装置が自装置（通信装置１００）に対応する共有秘密情報Ｋ１を保持しているか否かを問い合わせても良い。通信装置１００は、当該問い合わせを、ＰＡＸ ＰＤＵを使用して行い得る。

ここで、記憶部１１１に記憶される、機器ＩＤ、共有秘密情報（秘密鍵）Ｋ１、及びセキュリティプロトコル番号Ｓ１の組について説明する。以下、機器ＩＤ、共有秘密情報（秘密鍵）Ｋ１、及びセキュリティプロトコル番号Ｓ１の組が格納されるテーブルを機器ＩＤ−秘密鍵対応表（ＩＤ−ＳＫ Ｔａｂｌｅ）と称する。

表５は、記憶部１１１に記憶される、機器ＩＤ−秘密鍵対応表の例を示す説明図である。通信装置１００は、相手機器との暗号通信の実行を試みる場合に，その相手機器の機器ＩＤが機器ＩＤ−秘密鍵対応表に含まれていれば、その機器ＩＤに対応する共有秘密情報（秘密鍵）を使用し、またその機器ＩＤに対応するセキュリティプロトコルに従って相互認証を実行する。通信装置１００は、相手機器との相互認証に成功すれば、その相手機器との間で暗号通信を実行するよう動作する。

以上、本開示の一実施形態に係る通信装置１００のより具体的な動作例について説明した。次に、本開示の一実施形態に係る通信装置１００の動作について、さらに詳細な処理シーケンスで説明する。以下の説明では、図１３に示したセキュリティプロトコル指示情報のセキュリティプロトコル番号（Ｖａｌｕｅフィールドで設定された番号）毎の処理シーケンスの例を示す。

まず、セキュリティプロトコル番号が００ｈ、すなわち暗号化せずに近距離無線通信を実行する場合の処理シーケンスを説明する。図２５は、通信装置１００、２００の間の処理シーケンスを示す流れ図である。図２５に示した流れ図は、セキュリティプロトコル番号が００ｈ、すなわち暗号化せずに近距離無線通信を実行する場合の処理シーケンスを示したものである。図２５の処理シーケンスでは、通信装置１００がイニシエータであり、通信装置２００がターゲットである場合が示されている。

イニシエータの通信装置１００は、まずセキュリティプロトコル番号が００ｈ、すなわち暗号化せずに近距離無線通信を実行することを決定する（ステップＳ３０１）。ステップＳ３０１の決定処理は、例えば制御部１１０が実行し得る。暗号化せずに近距離無線通信を実行することは、通信装置１００が実行するアプリケーションや、そのアプリケーションを使用するユーザによっても判断され得る。

暗号化せずに近距離無線通信を実行することを決定すると、続いて通信装置１００は、自装置の機器ＩＤと、セキュリティプロトコル番号に００ｈが指定されたセキュリティプロトコル指示情報とをＡＴＲ＿ＲＥＱにセットして、ターゲットである通信装置２００に近距離無線通信で送信する（ステップＳ３０２）。図２５以降では、自装置の機器ＩＤがセットされるＴＬＶをＤｅｖＩＤ ＴＬＶ、セキュリティプロトコル指示情報がセットされるＴＬＶをＮＳＰ ＴＬＶと表記する。

通信装置２００は、通信装置１００からＡＴＲ＿ＲＥＱを受信すると、セキュリティプロトコル指示情報において指定されたセキュリティプロトコル番号を見て、暗号化せずに近距離無線通信を実行することに同意する（ステップＳ３０３）。暗号化せずに近距離無線通信を実行することに同意した通信装置２００は、自装置の機器ＩＤと、セキュリティプロトコル番号に００ｈが指定されたセキュリティプロトコル指示情報とをＡＴＲ＿ＲＥＳにセットして、イニシエータである通信装置１００に近距離無線通信で送信する（ステップＳ３０４）。

通信装置１００、２００の双方で暗号化せずに近距離無線通信を実行することに合意すると、通信装置１００は、送信するデータをＤＥＰ＿ＲＥＱにセットして通信装置２００に送信し（ステップＳ３０５）、通信装置２００は、ＤＥＰ＿ＲＥＱを受けて、送信するデータをＤＥＰ＿ＲＥＳにセットして通信装置１００に送信する（ステップＳ３０６）。

次に、セキュリティプロトコル番号が０１ｈ、すなわちＮＦＣ−ＳＥＣ ＳＣＨを利用して、ＮＦＣ−ＳＥＣ ＳＤＵを暗号化する場合の処理シーケンスを説明する。図２６は、通信装置１００、２００の間の処理シーケンスを示す流れ図である。図２６に示した流れ図は、セキュリティプロトコル番号が０１ｈ、すなわちＮＦＣ−ＳＥＣ ＳＣＨを利用して、ＮＦＣ−ＳＥＣ ＳＤＵを暗号化する場合の処理シーケンスを示したものである。図２６の処理シーケンスでは、通信装置１００がイニシエータであり、通信装置２００がターゲットである場合が示されている。なお、セキュリティプロトコル番号が０１ｈの場合は、上述のケース１の適用のみ可能であり、ケース２の適用は出来ない。

イニシエータの通信装置１００は、まずセキュリティプロトコル番号が０１ｈ、すなわちＮＦＣ−ＳＥＣ ＳＣＨを利用して、ＮＦＣ−ＳＥＣ ＳＤＵを暗号化することを決定する（ステップＳ３１１）。ステップＳ３１１の決定処理は、例えば制御部１１０が実行し得る。暗号化せずに近距離無線通信を実行することは、通信装置１００が実行するアプリケーションや、そのアプリケーションを使用するユーザによっても判断され得る。

ＮＦＣ−ＳＥＣ ＳＣＨを利用して、ＮＦＣ−ＳＥＣ ＳＤＵを暗号化することを決定すると、続いて通信装置１００は、自装置の機器ＩＤと、セキュリティプロトコル番号に０１ｈが指定されたセキュリティプロトコル指示情報とをＡＴＲ＿ＲＥＱにセットして、ターゲットである通信装置２００に近距離無線通信で送信する（ステップＳ３１２）。

通信装置２００は、通信装置１００からＡＴＲ＿ＲＥＱを受信すると、セキュリティプロトコル指示情報において指定されたセキュリティプロトコル番号を見て、ＮＦＣ−ＳＥＣ ＳＣＨを利用して、ＮＦＣ−ＳＥＣ ＳＤＵを暗号化することに同意する（ステップＳ３１３）。ＮＦＣ−ＳＥＣ ＳＣＨを利用して、ＮＦＣ−ＳＥＣ ＳＤＵを暗号化することに同意した通信装置２００は、自装置の機器ＩＤと、セキュリティプロトコル番号に０１ｈが指定されたセキュリティプロトコル指示情報とをＡＴＲ＿ＲＥＳにセットして、イニシエータである通信装置１００に近距離無線通信で送信する（ステップＳ３１４）。

通信装置１００、２００の双方でＮＦＣ−ＳＥＣ ＳＣＨを利用して、ＮＦＣ−ＳＥＣ ＳＤＵを暗号化することに合意すると、通信装置１００、２００は、ＩＳＯ／ＩＥＣ １３１５７−１のＡＣＴ＿ＲＥＱ、ＡＣＴ＿ＲＥＳ及びＶＦＹ＿ＲＥＱ、ＶＦＹ＿ＲＥＳを利用して、共有秘密情報の生成処理を実行する（ステップＳ３１５〜Ｓ３１８）。通信装置１００、２００での共有秘密情報の生成処理の実行に際しては、ＤＥＰ＿ＲＥＱ及びＤＥＰ＿ＲＥＳが使用され得る。共有秘密情報の生成処理は、鍵の合意（Ｋｅｙ ａｇｒｅｅｍｅｎｔ）フェーズと鍵の検証（Ｋｅｙ ｖｅｒｉｆｉｃａｔｉｏｎ）フェーズとにより行われる。

通信装置１００、２００の双方で共有秘密情報の生成処理を実行することで、通信装置１００、２００は、それぞれ共有秘密情報を生成して、内部に保持する（ステップＳ３１９、３２０）。共有秘密情報を生成した通信装置１００、２００は、ＮＦＣ−ＳＥＣのＥＮＣコマンドを実行することでＮＦＣ−ＳＥＣ ＳＤＵを暗号化した近距離無線通信を実行する（ステップＳ３２１、３２２）。ＮＦＣ−ＳＥＣ ＳＤＵを暗号化した近距離無線通信の際には、ＤＥＰ＿ＲＥＱ及びＤＥＰ＿ＲＥＳが使用され得る。

次に、セキュリティプロトコル番号が１０ｈ、すなわちＬＬＣ ＳＤＵを暗号化する場合の処理シーケンスを説明する。図２７は、通信装置１００、２００の間の処理シーケンスを示す流れ図である。図２７に示した流れ図は、セキュリティプロトコル番号が１０ｈ、すなわちＬＬＣ ＳＤＵを暗号化する場合の処理シーケンスを示したものである。図２７の処理シーケンスでは、通信装置１００がイニシエータであり、通信装置２００がターゲットである場合が示されている。なお、セキュリティプロトコル番号が１０ｈの場合は、上述のケース１、ケース２のいずれの適用も可能である。図２７に示したのは、この内、ケース１が適用された場合の処理シーケンスである。

イニシエータの通信装置１００は、まずセキュリティプロトコル番号が１０ｈ、すなわちＬＬＣ ＳＤＵを暗号化することを決定する（ステップＳ３３１）。ステップＳ３３１の決定処理は、例えば制御部１１０が実行し得る。暗号化せずに近距離無線通信を実行することは、通信装置１００が実行するアプリケーションや、そのアプリケーションを使用するユーザによっても判断され得る。

ＬＬＣ ＳＤＵを暗号化することを決定すると、続いて通信装置１００は、自装置の機器ＩＤと、セキュリティプロトコル番号に１０ｈが指定されたセキュリティプロトコル指示情報とをＡＴＲ＿ＲＥＱにセットして、ターゲットである通信装置２００に近距離無線通信で送信する（ステップＳ３３２）。

通信装置２００は、通信装置１００からＡＴＲ＿ＲＥＱを受信すると、セキュリティプロトコル指示情報において指定されたセキュリティプロトコル番号を見て、ＬＬＣ ＳＤＵを暗号化することに同意する（ステップＳ３３３）。ＬＬＣ ＳＤＵを暗号化することに同意した通信装置２００は、自装置の機器ＩＤと、セキュリティプロトコル番号に１０ｈが指定されたセキュリティプロトコル指示情報とをＡＴＲ＿ＲＥＳにセットして、イニシエータである通信装置１００に近距離無線通信で送信する（ステップＳ３３４）。

通信装置１００、２００の双方でＬＬＣ ＳＤＵを暗号化することに合意すると、続いて通信装置１００は、自装置で記憶されている機器ＩＤの中に、受信したＡＴＲ＿ＲＥＳに含まれていた通信装置２００の機器ＩＤと同じ物があるかどうかチェックする（ステップＳ３３５）。

上記ステップＳ３３５の判断の結果、同じ機器ＩＤが無かった場合は、通信装置１００は共有秘密情報の生成処理を開始する。通信装置１００、２００は、ＩＳＯ／ＩＥＣ １３１５７−１のＡＣＴ＿ＲＥＱ、ＡＣＴ＿ＲＥＳ及びＶＦＹ＿ＲＥＱ、ＶＦＹ＿ＲＥＳを利用して、共有秘密情報の生成処理を実行する（ステップＳ３３６〜Ｓ３３９）。通信装置１００、２００での共有秘密情報の生成処理の実行に際しては、ＤＥＰ＿ＲＥＱ及びＤＥＰ＿ＲＥＳが使用され得る。共有秘密情報の生成処理は、鍵の合意（Ｋｅｙ ａｇｒｅｅｍｅｎｔ）フェーズと鍵の検証（Ｋｅｙ ｖｅｒｉｆｉｃａｔｉｏｎ）フェーズとにより行われる。

通信装置１００、２００の双方で共有秘密情報の生成処理を実行することで、通信装置１００、２００は、それぞれ共有秘密情報を生成して、内部に保持する（ステップＳ３４０、Ｓ３４１）。共有秘密情報を生成した通信装置１００、２００は、ＬＬＣ ＳＡＣ ＰＤＵを利用した相互認証処理を実行する（ステップＳ３４２〜Ｓ３４５）。ＬＬＣ ＳＡＣ ＰＤＵを利用した相互認証処理には、上述のＳＡ１＿ＲＥＱ ＴＬＶ、ＳＡ１＿ＲＥＳ ＴＬＶ、ＳＡ２＿ＲＥＱ ＴＬＶ、およびＳＡ２＿ＲＥＳ ＴＬＶが使用される。

ＬＬＣ ＳＡＣ ＰＤＵを利用した相互認証処理によりお互いの認証が完了すると、通信装置１００、２００は、それぞれセッション鍵を生成して、内部に保持する（ステップＳ３４６、３４７）。セッション鍵を生成すると、通信装置１００、２００は、そのセッション鍵を使用した、ＬＬＣ ＰＵＩ ＰＤＵによる暗号通信を実行する（ステップＳ３４８、３４９）。

なお、図２７に示した処理シーケンスにおいて、上記ステップＳ３３５の判断の結果、同じ機器ＩＤが存在していた場合は、通信装置１００は、ステップＳ３３６〜Ｓ３３９の共有秘密情報の生成処理を省略し、相互認証処理へ直接移行し得る。

図２８は、通信装置１００、２００の間の処理シーケンスを示す流れ図である。図２７に示した流れ図は、図２７と同様に、セキュリティプロトコル番号が１０ｈ、すなわちＬＬＣ ＳＤＵを暗号化する場合の処理シーケンスを示したものである。図２８の処理シーケンスでは、通信装置１００がイニシエータであり、通信装置２００がターゲットである場合が示されている。図２８に示したのは、ケース２が適用された場合の処理シーケンスである。

イニシエータの通信装置１００は、ＡＴＲ＿ＲＥＱをターゲットの通信装置２００に送信することで近距離無線通信を開始する（ステップＳ３５１）。通信装置２００は、ＡＴＲ＿ＲＥＱを受信すると、ＡＴＲ＿ＲＥＳの返信により通信装置１００に応答する（ステップＳ３５２）。通信装置１００は、ＡＴＲ＿ＲＥＳを受信すると、通信装置２００への情報の送信のためにＤＥＰ＿ＲＥＱを送信し（ステップＳ３５３）、ＤＥＰ＿ＲＥＱを受信した通信装置２００は、ＤＥＰ＿ＲＥＳの返信により通信装置１００に応答する（ステップＳ３５４）。ステップＳ３５３、Ｓ３５４のＤＥＰ＿ＲＥＱ、ＤＥＰ＿ＲＥＳは、暗号化されずにそれぞれ送信される。

このように非暗号での通信が行われている際に、その後の通信において暗号通信を希望すると、通信装置１００は、セキュリティプロトコル番号が１０ｈ、すなわちＬＬＣ ＳＤＵを暗号化することを決定する（ステップＳ３５５）。ステップＳ３３５の決定処理は、例えば制御部１１０が実行し得る。暗号化せずに近距離無線通信を実行することは、通信装置１００が実行するアプリケーションや、そのアプリケーションを使用するユーザによっても判断され得る。

ＬＬＣ ＳＤＵを暗号化することを決定すると、続いて通信装置１００は、自装置の機器ＩＤと、セキュリティプロトコル番号に１０ｈが指定されたセキュリティプロトコル指示情報とをＤＥＰ＿ＲＥＱにセットして、ＰＡＸ ＰＤＵを用いて、ターゲットである通信装置２００に近距離無線通信で送信する（ステップＳ３５６）。

通信装置２００は、通信装置１００からＤＥＰ＿ＲＥＱを受信すると、セキュリティプロトコル指示情報において指定されたセキュリティプロトコル番号を見て、ＬＬＣ ＳＤＵを暗号化することに同意する（ステップＳ３５７）。ＬＬＣ ＳＤＵを暗号化することに同意した通信装置２００は、自装置の機器ＩＤと、セキュリティプロトコル番号に１０ｈが指定されたセキュリティプロトコル指示情報とをＤＥＰ＿ＲＥＳにセットして、イニシエータである通信装置１００に近距離無線通信で送信する（ステップＳ３５８）。

通信装置１００、２００の双方でＬＬＣ ＳＤＵを暗号化することに合意すると、その後は図２７に示した処理シーケンスと同じ処理シーケンスとなる。続いて通信装置１００は、自装置で記憶されている機器ＩＤの中に、受信したＤＥＰ＿ＲＥＳに含まれていた通信装置２００の機器ＩＤと同じ物があるかどうかチェックする（ステップＳ３５９）。

上記ステップＳ３５８の判断の結果、同じ機器ＩＤが無かった場合は、通信装置１００は共有秘密情報の生成処理を開始する。通信装置１００、２００は、ＮＦＣ−ＳＥＣ（ＩＳＯ／ＩＥＣ １３１５７−１）のＡＣＴ＿ＲＥＱ、ＡＣＴ＿ＲＥＳ及びＶＦＹ＿ＲＥＱ、ＶＦＹ＿ＲＥＳを利用して、共有秘密情報の生成処理を実行する（ステップＳ３６０〜Ｓ３６３）。通信装置１００、２００での共有秘密情報の生成処理の実行に際しては、ＤＥＰ＿ＲＥＱ及びＤＥＰ＿ＲＥＳが使用され得る。共有秘密情報の生成処理は、鍵の合意（Ｋｅｙ ａｇｒｅｅｍｅｎｔ）フェーズと鍵の検証（Ｋｅｙ ｖｅｒｉｆｉｃａｔｉｏｎ）フェーズとにより行われる。

通信装置１００、２００の双方で共有秘密情報の生成処理を実行することで、通信装置１００、２００は、それぞれ共有秘密情報を生成して、内部に保持する（ステップＳ３６４、３６５）。共有秘密情報を生成した通信装置１００、２００は、ＬＬＣ ＳＡＣ ＰＤＵを利用した相互認証処理を実行する（ステップＳ３６６〜Ｓ３６９）。ＬＬＣ ＳＡＣ ＰＤＵを利用した相互認証処理には、上述のＳＡ１＿ＲＥＱ ＴＬＶ、ＳＡ１＿ＲＥＳ ＴＬＶ、ＳＡ２＿ＲＥＱ ＴＬＶ、およびＳＡ２＿ＲＥＳ ＴＬＶが使用される。

ＬＬＣ ＳＡＣ ＰＤＵを利用した相互認証処理によりお互いの認証が完了すると、通信装置１００、２００は、それぞれセッション鍵を生成して、内部に保持する（ステップＳ３７０、３７１）。セッション鍵を生成すると、通信装置１００、２００は、そのセッション鍵を使用した、ＬＬＣ ＰＵＩ ＰＤＵによる暗号通信を実行する（ステップＳ３７２、３７３）。

なお、図２８に示した処理シーケンスにおいて、上記ステップＳ３５８の判断の結果、同じ機器ＩＤが存在していた場合は、通信装置１００は、ステップステップＳ３５９〜Ｓ３６２の共有秘密情報の生成処理を省略し、相互認証処理へ直接移行し得る。

このように、ケース２においては、通信装置１００、２００は、ＰＡＸ ＰＤＵを利用してお互いの機器ＩＤとセキュリティプロトコル指示情報を交換するが、例えば自身のセキュリティプロトコル能力情報を相手に提供して、その中から使用するプロトコルを相手に選択させるよう促してもよい。使用するプロトコルを相手に選択させる場合、例えば図１４に記載されるような形式で、セキュリティプロトコル能力情報がＰＡＸ ＰＤＵのパラメータに含められ得る。セキュリティプロトコル能力情報を受け取った場合は、受け取った側がセキュリティプロトコル指示情報によって利用するセキュリティプロトコルを指示することができる。また、通信装置２００が、通信装置１００の提示した指示情報に合意する場合は、同じ指示情報で、通信装置１００に返答する。

図２８に示した処理シーケンスでは、通信装置１００、２００は、ＮＦＣ−ＳＥＣ（ＩＳＯ／ＩＥＣ １３１５７−１）のＡＣＴ＿ＲＥＱ、ＡＣＴ＿ＲＥＳ及びＶＦＹ＿ＲＥＱ、ＶＦＹ＿ＲＥＳを利用して、共有秘密情報の生成処理を実行していたが、ＮＦＣ−ＳＥＣの替わりにＬＬＣ ＰＤＵを使用し得る。

図２９は、通信装置１００、２００の間の処理シーケンスを示す流れ図である。図２７に示した流れ図は、図２８と同様に、セキュリティプロトコル番号が１０ｈ、すなわちＬＬＣ ＳＤＵを暗号化する場合の処理シーケンスを示したものである。図２９の処理シーケンスでは、通信装置１００がイニシエータであり、通信装置２００がターゲットである場合が示されている。図２９に示したのは、ＮＦＣ−ＳＥＣの替わりにＬＬＣ ＰＤＵを使用して共有秘密情報の生成処理が実行される場合の処理シーケンスである。

図２９に示した処理シーケンスにおいては、ステップＳ３５８の判断の結果、同じ機器ＩＤが無かった場合は、通信装置１００、２００は、ＬＬＣ ＳＡＣ ＰＤＵのＳＫ１＿ＲＥＱ ＴＬＶ、ＳＫ１＿ＲＥＳ ＴＬＶ、ＳＫ２＿ＲＥＱ ＴＬＶ、およびＳＫ２＿ＲＥＳ ＴＬＶを利用して、共有秘密情報の生成処理を実行する（ステップＳ３６０’〜Ｓ３６３’）。このように通信装置１００、２００は、ＮＦＣ−ＳＥＣの替わりにＬＬＣ ＰＤＵを使用することでも、共有秘密情報の生成処理の実行が可能である。

次に、セキュリティプロトコル番号が１１ｈ、すなわちＬＬＣ Ｉ ＳＤＵを暗号化する場合の処理シーケンスを説明する。図３０は、通信装置１００、２００の間の処理シーケンスを示す流れ図である。図３０に示した流れ図は、セキュリティプロトコル番号が１１ｈ、すなわちＬＬＣ Ｉ ＳＤＵを暗号化する場合の処理シーケンスを示したものである。図３０の処理シーケンスでは、通信装置１００がイニシエータであり、通信装置２００がターゲットである場合が示されている。なお、セキュリティプロトコル番号が１１ｈの場合は、上述のケース１の適用のみが可能である。

イニシエータの通信装置１００は、まずセキュリティプロトコル番号が１１ｈ、すなわちＬＬＣ Ｉ ＳＤＵを暗号化することを決定する（ステップＳ３８１）。ステップＳ３８１の決定処理は、例えば制御部１１０が実行し得る。暗号化せずに近距離無線通信を実行することは、通信装置１００が実行するアプリケーションや、そのアプリケーションを使用するユーザによっても判断され得る。

ＬＬＣ Ｉ ＳＤＵを暗号化することを決定すると、続いて通信装置１００は、自装置の機器ＩＤと、セキュリティプロトコル番号に１１ｈが指定されたセキュリティプロトコル指示情報とをＡＴＲ＿ＲＥＱにセットして、ターゲットである通信装置２００に近距離無線通信で送信する（ステップＳ３８２）。

通信装置２００は、通信装置１００からＡＴＲ＿ＲＥＱを受信すると、セキュリティプロトコル指示情報において指定されたセキュリティプロトコル番号を見て、ＬＬＣ Ｉ ＳＤＵを暗号化することに同意する（ステップＳ３８３）。ＬＬＣ Ｉ ＳＤＵを暗号化することに同意した通信装置２００は、自装置の機器ＩＤと、セキュリティプロトコル番号に１１ｈが指定されたセキュリティプロトコル指示情報とをＡＴＲ＿ＲＥＳにセットして、イニシエータである通信装置１００に近距離無線通信で送信する（ステップＳ３８４）。

通信装置１００、２００の双方でＬＬＣ Ｉ ＳＤＵを暗号化することに合意すると、続いて通信装置１００は、自装置で記憶されている機器ＩＤの中に、受信したＡＴＲ＿ＲＥＳに含まれていた通信装置２００の機器ＩＤと同じ物があるかどうかチェックする（ステップＳ３８５）。

上記ステップＳ３８５の判断の結果、同じ機器ＩＤが無かった場合は、通信装置１００は共有秘密情報の生成処理を開始する。通信装置１００、２００は、ＩＳＯ／ＩＥＣ １３１５７−１のＡＣＴ＿ＲＥＱ、ＡＣＴ＿ＲＥＳ及びＶＦＹ＿ＲＥＱ、ＶＦＹ＿ＲＥＳを利用して、共有秘密情報の生成処理を実行する（ステップＳ３８６〜Ｓ３８９）。通信装置１００、２００での共有秘密情報の生成処理の実行に際しては、ＤＥＰ＿ＲＥＱ及びＤＥＰ＿ＲＥＳが使用され得る。共有秘密情報の生成処理は、鍵の合意（Ｋｅｙ ａｇｒｅｅｍｅｎｔ）フェーズと鍵の検証（Ｋｅｙ ｖｅｒｉｆｉｃａｔｉｏｎ）フェーズとにより行われる。

通信装置１００、２００の双方で共有秘密情報の生成処理を実行することで、通信装置１００、２００は、それぞれ共有秘密情報を生成して、内部に保持する（ステップＳ３８９、３９０）。共有秘密情報を生成した通信装置１００、２００は、共有秘密情報を用いた相互認証処理を実行する。なお、トランスポート層における特定のコネクションのＰＤＵのみ暗号化する場合は、通信装置１００、２００は、セキュリティプロトコル番号に１１ｈを指定したセキュリティプロトコル指示情報を含むＣＯＮＮＥＣＴ ＰＤＵ及びＣＣ ＰＤＵを交換する（ステップＳ３９１〜Ｓ３９４）。

共有秘密情報を生成し、ＣＯＮＮＥＣＴ ＰＤＵ及びＣＣ ＰＤＵを交換した通信装置１００、２００は、ＬＬＣ ＳＡＣ ＰＤＵを利用した相互認証処理を実行する（ステップＳ３９５〜Ｓ３９８）。ＬＬＣ ＳＡＣ ＰＤＵを利用した相互認証処理には、上述のＳＡ１＿ＲＥＱ ＴＬＶ、ＳＡ１＿ＲＥＳ ＴＬＶ、ＳＡ２＿ＲＥＱ ＴＬＶ、およびＳＡ２＿ＲＥＳ ＴＬＶが使用される。

ＬＬＣ ＳＡＣ ＰＤＵを利用した相互認証処理によりお互いの認証が完了すると、通信装置１００、２００は、それぞれセッション鍵を生成して、内部に保持する（ステップＳ３９９、４００）。セッション鍵を生成すると、通信装置１００、２００は、そのセッション鍵を使用した、ＬＬＣ ＰＵＩ ＰＤＵによる暗号通信を実行する（ステップＳ４０１、４０２）。

なお、図３０に示した処理シーケンスにおいて、上記ステップＳ３８５の判断の結果、同じ機器ＩＤが存在していた場合は、通信装置１００は、ステップＳ３８６〜Ｓ３８９の共有秘密情報の生成処理を省略し得る。

以上、通信装置１００、２００の詳細な処理シーケンスについて説明した。本開示の一実施形態に係る通信装置１００、２００は、上述した処理シーケンスに基づいて動作することで、相互認証を経てからでないと通信相手との暗号化された近距離無線通信を実行することが出来ないので、より安全な暗号化された近距離無線通信を実行出来る。

＜２．まとめ＞
以上説明したように本開示の一実施形態によれば、相互認証を経てから通信相手との暗号化された近距離無線通信を実行することが可能な通信装置及び通信方法が提供される。本開示の一実施形態に係る通信装置１００は、通信装置２００との間で暗号化された近距離無線通信を実行する際に、ＮＦＣ−ＳＥＣ技術を用いて共有秘密情報を生成し、生成した共有秘密情報と通信装置２００の機器ＩＤとを内部に保持しておく。

通信装置１００は、次に通信装置２００と近距離無線通信を実行しようとする場合に、以前の近距離無線通信によって共有秘密情報を生成した相手と同じ機器ＩＤを持つ相手であることを、相互認証処理によって確認することができる。そして通信装置１００は、相互認証処理によって以前の近距離無線通信によって共有秘密情報を生成した相手と同じ機器ＩＤを持つ相手であることが確認できた場合に、通信装置２００との間で暗号通信を実行する。

このように、以前の近距離無線通信によって共有秘密情報を生成した相手と同じ機器ＩＤを持つ相手であることが確認できた場合に、通信装置２００との間で暗号通信を実行することで、本開示の一実施形態に係る通信装置１００は、意図しない相手との秘密情報を交換するための暗号通信を回避することができる。従って、本開示の一実施形態に係る通信装置１００は、近距離無線通信時により安全な暗号通信を実行することが可能となる。

本明細書の各装置が実行する処理における各ステップは、必ずしもシーケンス図またはフローチャートとして記載された順序に沿って時系列に処理する必要はない。例えば、各装置が実行する処理における各ステップは、フローチャートとして記載した順序と異なる順序で処理されても、並列的に処理されてもよい。

また、各装置に内蔵されるＣＰＵ、ＲＯＭおよびＲＡＭなどのハードウェアを、上述した各装置の構成と同等の機能を発揮させるためのコンピュータプログラムも作成可能である。また、該コンピュータプログラムを記憶させた記憶媒体も提供されることが可能である。また、機能ブロック図で示したそれぞれの機能ブロックをハードウェアで構成することで、一連の処理をハードウェアで実現することもできる。

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

なお、本技術は以下のような構成も取ることができる。
（１）
非接触通信により他の装置と通信を行う通信処理部と、
前記通信処理部が前記他の装置との間で情報を暗号化した通信を実行する前に、前記他の装置との非接触通信の履歴の有無に応じて、前記他の装置との間の非接触通信において該他の装置を相互に認証する際に用いられる認証情報の生成を判断する暗号化情報生成部と、
を備える、集積回路。
（２）
前記暗号化情報生成部は、前記他の装置との非接触通信の履歴が無ければ、前記他の装置との間の非接触通信において該他の装置を相互に認証する際に用いられる認証情報を生成する、前記（１）に記載の集積回路。
（３）
前記通信処理部は、前記他の装置を識別する識別情報を該他の装置から受信し、前記識別情報を前記暗号化情報生成部が生成した前記認証情報と紐付けて記憶させる、前記（２）に記載の集積回路。
（４）
前記通信処理部は、他の装置との非接触通信の履歴の存在に基づき生成された前記認証情報を用いて該他の装置の認証を実行する、前記（１）〜（３）のいずれかに記載の集積回路。
（５）
前記通信処理部は、前記他の装置の認証の実行前に該他の装置と交換した使用可能なプロトコルの中から選択したプロトコルを用いて前記他の装置の認証を実行する、前記（４）に記載の集積回路。
（６）
前記暗号化情報生成部は、前記通信処理部が認証した前記他の装置との間の暗号化された非接触通信に用いられる暗号鍵を生成する、前記（４）または（５）に記載の集積回路。
（７）
前記通信処理部は、前記暗号化情報生成部が生成した暗号鍵を用いて前記他の装置との間で非接触通信により送信される情報を暗号化する暗号化部を更に備える、前記（６）に記載の集積回路。
（８）
前記暗号化部は、前記他の装置との間で非接触通信により送信される情報を暗号化する前に該他の装置と交換したパラメータに基づき暗号化する情報の範囲を決定する、前記（７）に記載の集積回路。
（９）
前記他の装置との非接触通信の開始前に該他の装置と暗号化された通信を行うことを予め指定されていない場合は、前記暗号化情報生成部は、前記他の装置と暗号化された通信を行うことが指定されてから、該他の装置との非接触通信の履歴の有無に応じて、前記他の装置との間の非接触通信において該他の装置を相互に認証する際に用いられる認証情報の生成を判断する、前記（１）〜（８）のいずれかに記載の集積回路。
（１０）
前記通信処理部が行う非接触通信は複数のコネクションを確立して同時に通信を実行することが可能な通信である、前記（１）〜（９）のいずれかに記載の集積回路。
（１１）
非接触通信により他の装置と通信を行うステップと、
前記他の装置との間で情報を暗号化した通信が実行される前に、前記他の装置との非接触通信の履歴の有無に応じて、前記他の装置との間の非接触通信において該他の装置を相互に認証する際に用いられる認証情報の生成を判断するステップと、
を備える、通信方法。
（１２）
コンピュータに、
非接触通信により他の装置と通信を行うステップと、
前記他の装置との間で情報を暗号化した通信が実行される前に、前記他の装置との非接触通信の履歴の有無に応じて、前記他の装置との間の非接触通信において該他の装置を相互に認証する際に用いられる認証情報の生成を判断するステップと、
を実行させる、コンピュータプログラム。
（１３）
非接触通信により他の装置と通信を行う通信処理部、および前記通信処理部が前記他の装置との間で情報を暗号化した通信を実行する前に、前記他の装置との非接触通信の履歴の有無に応じて、前記他の装置との間の非接触通信において該他の装置を相互に認証する際に用いられる認証情報の生成を判断する暗号化情報生成部、を有する集積回路と、前記集積回路へ電源を供給する電源部と、を備える、通信装置。

１００、２００ 通信装置
１１０ 制御部
１１１ 記憶部
１２０ アプリケーション実行部
１３０ ＲＦ通信部
１３１ ＬＬＣＰコネクション処理部
１３２ ＬＬＣＰリンクプロトコル処理部
１３３ 暗号処理部
１３４ ＮＦＣ−ＳＥＣプロトコル処理部
１３５ ＮＦＣＩＰ−１プロトコル処理部

Claims (13)

1. 非接触通信により他の装置と通信を行う通信処理部と、
   前記通信処理部が前記他の装置との間で情報を暗号化した通信を実行する前に、前記他の装置との非接触通信の履歴の有無に応じて、前記他の装置との間の非接触通信において該他の装置を相互に認証する際に用いられる認証情報の生成を判断する暗号化情報生成部と、
   を備える、集積回路。
2. 前記暗号化情報生成部は、前記他の装置との非接触通信の履歴が無ければ、前記他の装置との間の非接触通信において該他の装置を相互に認証する際に用いられる認証情報を生成する、請求項１に記載の集積回路。
3. 前記通信処理部は、前記他の装置を識別する識別情報を該他の装置から受信し、前記識別情報を前記暗号化情報生成部が生成した前記認証情報と紐付けて記憶させる、請求項２に記載の集積回路。
4. 前記通信処理部は、前記他の装置との非接触通信の履歴の存在に基づき生成された前記認証情報を用いて該他の装置の認証を実行する、請求項１に記載の集積回路。
5. 前記通信処理部は、前記他の装置の認証の実行前に該他の装置と交換した使用可能なプロトコルの中から選択したプロトコルを用いて前記他の装置の認証を実行する、請求項４に記載の集積回路。
6. 前記暗号化情報生成部は、前記通信処理部が認証した前記他の装置との間の暗号化された非接触通信に用いられる暗号鍵を生成する、請求項４に記載の集積回路。
7. 前記通信処理部は、前記暗号化情報生成部が生成した暗号鍵を用いて前記他の装置との間で非接触通信により送信される情報を暗号化する暗号化部を更に備える、請求項６に記載の集積回路。
8. 前記暗号化部は、前記他の装置との間で非接触通信により送信される情報を暗号化する前に該他の装置と交換したパラメータに基づき暗号化する情報の範囲を決定する、請求項７に記載の集積回路。
9. 前記他の装置との非接触通信の開始前に該他の装置と暗号化された通信を行うことを予め指定されていない場合は、前記暗号化情報生成部は、前記他の装置と暗号化された通信を行うことが指定されてから、該他の装置との非接触通信の履歴の有無に応じて、前記他の装置との間の非接触通信において該他の装置を相互に認証する際に用いられる認証情報の生成を判断する、請求項１に記載の集積回路。
10. 前記通信処理部が行う非接触通信は複数のコネクションを確立して同時に通信を実行することが可能な通信である、請求項１に記載の集積回路。
11. 非接触通信により他の装置と通信を行うことと、
    前記他の装置との間で情報を暗号化した通信が実行される前に、前記他の装置との非接触通信の履歴の有無に応じて、前記他の装置との間の非接触通信において該他の装置を相互に認証する際に用いられる認証情報の生成を判断することと、
    を備える、通信方法。
12. コンピュータに、
    非接触通信により他の装置と通信を行うことと、
    前記他の装置との間で情報を暗号化した通信が実行される前に、前記他の装置との非接触通信の履歴の有無に応じて、前記他の装置との間の非接触通信において該他の装置を相互に認証する際に用いられる認証情報の生成を判断することと、
    を実行させる、コンピュータプログラム。
13. 非接触通信により他の装置と通信を行う通信処理部、および
    前記通信処理部が前記他の装置との間で情報を暗号化した通信を実行する前に、前記他の装置との非接触通信の履歴の有無に応じて、前記他の装置との間の非接触通信において該他の装置を相互に認証する際に用いられる認証情報の生成を判断する暗号化情報生成部、を有する集積回路と、
    前記集積回路へ電源を供給する電源部と、
    を備える、通信装置。
    

Images