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

Abstract

【課題】複数コネクションの同時通信機能を有する近距離非接触無線通信の際に、暗号化するコネクションやレイヤーの選択が可能な集積回路を提供する。
【解決手段】複数のコネクションを確立して同時に通信を実行することが可能な非接触通信により他の装置と通信を行う通信処理部と、前記他の装置との非接触通信の際に暗号化するコネクションを含む暗号化情報に基づいて前記非接触通信で送信されるデータの暗号処理を実行する暗号処理部と、を含む、集積回路が提供される。
【選択図】図１

Description

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

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

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

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

ＬＬＣ ＰＤＵの上位レイヤーのデータであるＬＬＣ ＳＤＵ（Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）を、ＮＦＣＩＰ−１のためのセキュリティオプションであるＮＦＣ−ＳＥＣで定義されるセキュアチャネルサービス（ＮＦＣ−ＳＥＣ ＳＣＨ）を用いて暗号化しようとすると、全てのＬＬＣ ＰＤＵが暗号化される。従って、ＮＦＣ−ＳＥＣ ＳＣＨを用いて暗号化すると、ＬＬＣ上のあるコネクションだけが暗号化を必要としない通信を行なうという処理が実現できず、ＬＬＣＰの複数コネクションの同時通信機能を十分に活用出来ない。

そこで本開示は、複数コネクションの同時通信機能を有する近距離非接触無線通信の際に、暗号化するコネクションやレイヤーの選択が可能な、新規かつ改良された集積回路、無線通信装置及びコンピュータプログラムを提供する。

本開示によれば、複数のコネクションを確立して同時に通信を実行することが可能な非接触通信により他の装置と通信を行う通信処理部と、前記他の装置との非接触通信の際に暗号化するコネクションを含む暗号化情報に基づいて前記非接触通信で送信されるデータの暗号処理を実行する暗号処理部と、を含む、集積回路が提供される。

また本開示によれば、複数のコネクションを確立して同時に通信を実行することが可能な非接触通信により他の装置と通信を行う通信処理部と、前記他の装置との前記非接触通信の際に暗号化するコネクションを決定する暗号化方式決定部と、前記暗号化方式決定部の決定に基づいて前記非接触通信で送信されるデータの暗号処理を実行する暗号処理部と、を含む、通信装置が提供される。

また本開示によれば、複数のコネクションを確立して同時に通信を実行することが可能な非接触通信により他の装置と通信を行う通信処理ステップを備え、前記通信処理ステップは、前記他の装置との前記非接触通信の際に暗号化するコネクションを決定する暗号化方式決定ステップと、前記暗号化方式決定ステップでの決定に基づいて前記非接触通信で送信されるデータの暗号処理を実行する暗号処理ステップと、を含む、通信方法が提供される。

また本開示によれば、コンピュータに、複数のコネクションを確立して同時に通信を実行することが可能な非接触通信により他の装置と通信を行う通信処理ステップを実行させ、前記通信処理ステップは、前記他の装置との前記非接触通信の際に暗号化するコネクションを決定する暗号化方式決定ステップと、前記暗号化方式決定ステップでの決定に基づいて前記非接触通信で送信されるデータの暗号処理を実行する暗号処理ステップと、を含む、コンピュータプログラムが提供される。

以上説明したように本開示によれば、複数コネクションの同時通信機能を有する近距離非接触無線通信の際に、暗号化するコネクションやレイヤーの選択が可能な、新規かつ改良された集積回路、無線通信装置及びコンピュータプログラムを提供することができる。

本開示の一実施形態に係る近距離無線通信システム１の構成例を示す説明図である。 本開示の一実施形態に係る通信装置１００の機能構成例を示す説明図である。 コマンドＡＴＲ＿ＲＥＱの構造を示す説明図である。 コマンドＡＴＲ＿ＲＥＳの構造を示す説明図である。 コマンドＤＥＰ＿ＲＥＱ、及びコマンドＤＥＰ＿ＲＥＳの構造を示す説明図である。 ＮＦＣ−ＳＥＣのプロトコルデータユニットの構造を示す説明図である。 ＳＥＰフィールドに格納されるコード及びそのコードが示す内容の対応関係を示す説明図である。 ＮＦＣ−ＳＥＣによる暗号鍵生成処理を示す流れ図である。 ＮＦＣ−ＳＥＣによる暗号化通信処理を示す流れ図である。 コマンドＡＴＲ＿ＲＥＱ、及びＬＬＣパラメータの構造を示す説明図である。 コマンドＡＴＲ＿ＲＥＳ、及びＬＬＣパラメータの構造を示す説明図である。 ＬＬＣ ＰＤＵの構造を示す説明図である。 ＮＦＣ−ＳＥＣ ＳＣＨで保護される範囲を示す説明図である。 ＮＦＣ−ＳＥＣ ＳＳＥで保護される範囲を示す説明図である。 本開示の一実施形態に係る通信装置１００の動作例を示す流れ図である。 本開示の一実施形態に係る通信装置２００の動作例を示す流れ図である。 本開示の一実施形態に係る通信装置１００の動作例を示す流れ図である。 本開示の一実施形態に係る通信装置１００の動作例を示す流れ図である。 本開示の一実施形態に係る通信装置２００の動作例を示す流れ図である。 本開示の一実施形態に係る通信装置１００の動作例を示す流れ図である。 本開示の一実施形態に係る通信装置２００の動作例を示す流れ図である。 本開示の一実施形態に係る通信装置１００の動作例を示す流れ図である。 本開示の一実施形態に係る通信装置２００の動作例を示す流れ図である。

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

なお、説明は以下の順序で行うものとする。
＜１．本開示の一実施形態＞
［システム構成例］
［通信装置の機能構成例］
［プロトコルデータユニットの例］
［動作シーケンス例］
［通信装置の動作例］
［通信装置が管理するデータの例］
＜２．まとめ＞

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

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

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

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

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

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

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

図２に示したように、本開示の一実施形態に係る通信装置１００は、ＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１１０と、メモリ１１１と、アプリケーション実行部１２０と、ＬＬＣＰ処理部１３０と、を含んで構成される。

また、図２に示したように、ＬＬＣＰ処理部１３０は、ＬＬＣＰコネクション処理部１３１と、ＬＬＣＰリンクプロトコル処理部１３２と、暗号処理部１３３と、ＮＦＣ−ＳＥＣプロトコル処理部１３４と、ＮＦＣＩＰ−１プロトコル処理部１３５と、を含んで構成される。

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

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

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

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

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

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

図２に示したＬＬＣＰ処理部１３０は、例えば非接触無線チップ（ＣＬＦ；Ｃｏｎｔａｃｔｌｅｓｓ Ｆｒｏｎｔ Ｅｎｄ）として、１つのＩＣチップ上で実現されるようにしてもよい。

以上、図２を用いて本開示の一実施形態に係る通信装置１００の機能構成例について説明した。上述したように、通信装置２００は、図２に示した通信装置１００と同様の機能構成を有する。そして本開示の一実施形態に係る通信装置１００及び通信装置２００は、図２に示したような構成を有することで、複数コネクションの同時通信機能を有する近距離非接触無線通信の際に、暗号化するコネクションやレイヤーの選択が可能となる。

次に、本開示の一実施形態に係る通信装置１００の動作例について説明するが、通信装置１００の動作例について詳細に説明する前に、本開示の一実施形態に係る通信装置１００及び通信装置２００で用いられる各種コマンドの構造等について説明する。

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

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

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

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

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

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

本実施形態では、イニシエータとなる通信装置１００が、コマンドＡＴＲ＿ＲＥＱに、イニシエータが使用しようとする暗号化方式や、暗号化するチャネル等の情報を含めてターゲットに送信する。具体的には後述するが、通信装置１００は、図３に示したコマンドＡＴＲ＿ＲＥＱのＢｙｔｅ１３フィールド以降に、使用しようとする暗号化方式や、暗号化するチャネル等の情報を含めてターゲットに送信する。

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

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

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

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

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

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

本実施形態では、ターゲットとなる通信装置２００が、コマンドＡＴＲ＿ＲＥＱに応答する形で、コマンドＡＴＲ＿ＲＥＳに、イニシエータとの間で使用する暗号化方式や、暗号化するチャネル等の情報を含めてイニシエータに送信する。具体的には後述するが、通信装置２００は、図４に示したコマンドＡＴＲ＿ＲＥＳのＢｙｔｅ１４フィールド以降に、使用する暗号化方式や、暗号化するチャネル等の情報を含めてイニシエータに送信する。

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

本実施形態では、コマンドＤＥＰ＿ＲＥＱ、及びコマンドＤＥＰ＿ＲＥＳによって、共有秘密情報の生成や、暗号化されたデータの送受信、及びコネクションの解除等が行われる。具体的なシーケンスについては後に詳述する。

図６は、ＮＦＣ−ＳＥＣのプロトコルデータユニットの構造を示す説明図である。図６に示したように、ＮＦＣ−ＳＥＣのプロトコルデータユニットは、ＳＥＰ（Ｓｅｃｕｒｅ Ｅｘｃｈａｇｅ Ｐｒｏｔｏｃｏｌ）、ＰＩＤ（Ｐｒｏｔｏｃｏｌ Ｉｄｅｎｔｉｆｉｅｒ）及びＮＦＣ−ＳＥＣ Ｐａｙｌｏａｄの各フィールドで構成される。

ＳＥＰフィールドには、ＮＦＣ−ＳＥＣのプロトコルデータユニットのタイプや、ＳＳＥとＳＣＨのどちらを使用しているか等のデータが格納される。図７は、ＳＥＰフィールドに格納されるコード及びそのコードが示す内容の対応関係を示す説明図である。ＰＩＤフィールドには、ＮＦＣ−ＳＥＣによる暗号処理で用いられるＰＩＤが格納される。ＮＦＣ−ＳＥＣ ＰａｙｌｏａｄフィールドにはＮＦＣ−ＳＥＣによる暗号処理で使用されるデータが格納される。

図８は、ＮＦＣ−ＳＥＣによる暗号鍵生成処理を示す流れ図である。図８では、Ｓｅｎｄｅｒ（送信者）Ａ及びＲｅｃｉｐｉｅｎｔ（受信者）Ｂとの間の処理が示されている。Ｓｅｎｄｅｒ Ａは、一時的な値ＮＡを生成し（ステップＳ１１）、Ｓｅｎｄｅｒ Ａの内部で確保した値ＱＡ及びステップＳ１１で生成した一時的な値ＮＡをＲｅｃｉｐｉｅｎｔ Ｂへ送信する（ステップＳ１２）。Ｒｅｃｉｐｉｅｎｔ Ｂは、一時的な値ＮＢを生成し（ステップＳ１３）、Ｒｅｃｉｐｉｅｎｔ Ｂの内部で確保した値ＱＢ及びステップＳ１３で生成した一時的な値ＮＢをＳｅｎｄｅｒ Ａへ送信する（ステップＳ１４）。

そして、Ｓｅｎｄｅｒ Ａは、Ｒｅｃｉｐｉｅｎｔ Ｂから送信された情報から、キーコンファメーションタグ（Ｋｅｙ Ｃｏｎｆｉｒｍａｔｉｏｎ Ｔａｇ）ＭａｃＴａｇＡを生成し（ステップＳ１５）、ＭａｃＴａｇＡをＲｅｃｉｐｉｅｎｔ Ｂへ送信する（ステップＳ１６）。Ｒｅｃｉｐｉｅｎｔ Ｂは、ＭａｃＴａｇＡを検証した後に、キーコンファメーションタグＭａｃＴａｇＢを生成し（ステップＳ１７、Ｓ１８）、ＭａｃＴａｇＢをＳｅｎｄｅｒ Ａへ送信する（ステップＳ１９）。

Ｓｅｎｄｅｒ Ａは、ＭａｃＴａｇＢを検証し、ＭａｃＴａｇＢを共有秘密情報としてセットする（ステップＳ２０）。同様にＲｅｃｉｐｉｅｎｔ Ｂは、ＭａｃＴａｇＡを共有秘密情報としてセットする（ステップＳ２１）。

なお、ＮＦＣ−ＳＥＣによる暗号鍵生成処理の詳細については、「ＮＦＣ−ＳＥＣ−０１： ＮＦＣ−ＳＥＣ Ｃｒｙｐｔｏｇｒａｐｈｙ Ｓｔａｎｄａｒｄ ｕｓｉｎｇ ＥＣＤＨ ａｎｄ ＡＥＳ」に開示されている。

図９は、ＮＦＣ−ＳＥＣによる暗号化通信処理を示す流れ図である。図９では、ＮＦＣ−ＳＥＣによる暗号化通信処理を実行するエンティティ ＡＡ及びＢＢとの間の処理が示されている。

エンティティ ＡＡは、送信しようとするデータを、共有秘密情報を用いて暗号化し（ステップＳ３１）、暗号化したデータを、データ長やその他復号に必要な情報と共にエンティティ ＢＢに送信する（ステップＳ３２）。エンティティ ＢＢは、エンティティ ＡＡから受信したデータを、共有秘密情報を用いて復号する（ステップＳ３３）。この一連の流れにより、エンティティ ＡＡとＢＢとの間で、ＮＦＣ−ＳＥＣによる暗号化通信処理が行われる。

なお、ＮＦＣ−ＳＥＣによる暗号化通信処理の詳細については、「ＮＦＣ−ＳＥＣ−０１： ＮＦＣ−ＳＥＣ Ｃｒｙｐｔｏｇｒａｐｈｙ Ｓｔａｎｄａｒｄ ｕｓｉｎｇ ＥＣＤＨ ａｎｄ ＡＥＳ」に開示されている。

図１０は、ＩＳＯ／ＩＥＣ １８０９２で用意されているリクエストコマンドであるコマンドＡＴＲ＿ＲＥＱ、及びＬＬＣパラメータの構造を示す説明図である。

コマンドＡＴＲ＿ＲＥＱは、イニシエータが、ターゲットに対して、自身の属性（仕様）を知らせるとともに、ターゲットの属性を要求するときに、ターゲットに送信される。ここで、イニシエータまたはターゲットの属性としては、そのイニシエータまたはターゲットが送受信することのできるデータの伝送レートなどがある。なお、コマンドＡＴＲ＿ＲＥＱには、イニシエータの属性の他、そのイニシエータを特定するＮＦＣＩＤなどが配置され、ターゲットは、コマンドＡＴＲ＿ＲＥＱを受信することにより、イニシエータの属性とＮＦＣＩＤを認識する。

図１１は、ＩＳＯ／ＩＥＣ １８０９２で用意されているレスポンスコマンドであるコマンドＡＴＲ＿ＲＥＳ、及びＬＬＣパラメータの構造を示す説明図である。

コマンドＡＴＲ＿ＲＥＳは、ターゲットが、コマンドＡＴＲ＿ＲＥＱを受信した場合に、そのコマンドＡＴＲ＿ＲＥＱに対する応答として、イニシエータに送信される。コマンドＡＴＲ＿ＲＥＳには、ターゲットの属性やＮＦＣＩＤなどが配置される。

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

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

このようなコマンドや処理が、本開示の一実施形態に係る通信装置１００及び通信装置２００において用意されている。しかし、上述したように、ＬＬＣ ＰＤＵの上位レイヤーのデータであるＬＬＣ ＳＤＵ（Ｓｅｒｖｉｃｅ Ｄａｔａ Ｕｎｉｔ）を、ＮＦＣＩＰ−１のためのセキュリティオプションであるＮＦＣ−ＳＥＣ ＳＣＨを用いて暗号化しようとすると、全てのＬＬＣ ＰＤＵが暗号化される。従って、ＮＦＣ−ＳＥＣ ＳＣＨを用いて暗号化すると、ＬＬＣ上のあるコネクションだけが暗号化を必要としない通信を行なうという処理が実現できていなかった。

そこで本開示の一実施形態は、暗号化するコネクションやレイヤーの選択が可能となるように、既存のデータ構造においてパラメータを追加定義する。具体的には、本開示の一実施形態は、暗号化するコネクションやレイヤーが選択できるようなパラメータを、既存のデータ構造に追加する。これにより本開示の一実施形態は、すべてのコネクションを暗号化したり、一部のコネクションのみを暗号化したりする等の柔軟な運用が実現できる。

表１は、本開示の一実施形態で追加定義されるパラメータを示す表である。表１に示したように、本開示の一実施形態では、以下の３つのパラメータが追加定義される。表１において、「Ｉｎｃｌｕｄｅｄ」の「ＭＡＹ」は指定が任意であるパラメータであることを意味する。また「Ｉｎ ＰＤＵ Ｔｙｐｅ」はＰＤＵの型を示している。

なおＬＬＣＰは、ＮＦＣＩＰ−１がＬＬＣの下位レイヤーの場合、ＰＡＸ ＰＤＵの代わりにＡＴＲ＿ＲＥＱ及びＡＴＲ＿ＲＥＳを利用することを規定している。従って、表１に示したパラメータの内、「ＮＦＣ−ＳＥＣ ＰＩＤ ＴＬＶ」及び「Ｓｅｃｕｒｅ ＬＬＣ ＴＬＶ」は、ＡＴＲ＿ＲＥＱ及びＡＴＲ＿ＲＥＳで交換される。なお、イニシエータとターゲットとの間でデータを暗号化しない場合は、「Ｓｅｃｕｒｅ ＬＬＣ ＴＬＶ」及び「Ｓｅｃｕｒｅ Ｃｏｎｎｅｃｔｉｏｎ ＴＬＶ」は使用されない。

表２は、表１で示した追加定義パラメータの内の「ＮＦＣ−ＳＥＣ ＰＩＤ ＴＬＶ」を説明する表である。「ＮＦＣ−ＳＥＣ ＰＩＤ ＴＬＶ」は、イニシエータとターゲットとの間で、利用できる暗号方式を交換するために用いられる。

表３は、表１で示した追加定義パラメータの内の「Ｓｅｃｕｒｅ ＬＬＣ ＴＬＶ」を説明する表である。「Ｓｅｃｕｒｅ ＬＬＣ ＴＬＶ」は、イニシエータとターゲットとの間で、使用する暗号方式や、暗号化するチャネルの数を規定するために用いられる。

表３には、暗号化処理のパターンを３つ挙げているが、暗号化処理のパターンは４つ以上あってもよい。また表３では、ＮＦＣ−ＳＥＣ ＳＣＨ及びＮＦＣ−ＳＥＣ ＳＳＥ以外の暗号化処理として相互認証が挙げられている。相互認証による暗号化処理は、例えばアプリケーション実行部１１０が実行するアプリケーションによって実行されてもよい。なお、ＮＦＣ−ＳＥＣ ＳＳＥ以外の暗号方式を用いることの利点としては、例えばアプリケーション側で処理をすることになるので、ホストでの暗号方式の変更や追加が容易になるという点がある。

図１３及び図１４は、それぞれ、ＮＦＣ−ＳＥＣ ＳＣＨで保護される範囲及びＮＦＣ−ＳＥＣ ＳＳＥまたは相互認証で保護される範囲を示す説明図である。図１３に示すように、ＮＦＣ−ＳＥＣ ＳＣＨでは、ＰＴＹＰＥ・ＤＳＡＰ・ＳＳＡＰ、ＳＮ（Ｓｅｒｉａｌ Ｎｕｍｂｅｒ）及びＬＬＣ ＳＤＵが保護される。また図１４に示すように、ＮＦＣ−ＳＥＣ ＳＳＥでは、ＳＮ及びＬＬＣ ＳＤＵが保護される。

表４は、表１で示した追加定義パラメータの内の「Ｓｅｃｕｒｅ Ｃｏｎｎｅｃｔｉｏｎ ＴＬＶ」を説明する表である。「Ｓｅｃｕｒｅ Ｃｏｎｎｅｃｔｉｏｎ ＴＬＶ」は、イニシエータとターゲットとの間で、どの共有秘密情報を使用するかについて交換するために用いられる。

このように追加定義されるパラメータを用いることで、本開示の一実施形態は、すべてのコネクションを暗号化したり、一部のコネクションのみを暗号化したりする等の柔軟な運用が実現できる。以下、本開示の一実施形態に係る通信装置１００、２００の動作例について詳細に説明する。

イニシエータである通信装置１００と、ターゲットである通信装置２００との間で暗号化されたＬＬＣ通信が実行される場合は、以下のシーケンスに従って実行される。

まず、イニシエータである通信装置１００と、ターゲットである通信装置２００との間で、ＮＦＣＩＰ−１プロトコルの活性化が行われる。ＮＦＣＩＰ−１プロトコルの活性化は、ＡＴＲ＿ＲＥＱとＡＴＲ＿ＲＥＳの交換によって行われる。

ＮＦＣＩＰ−１プロトコルの活性化が行われると、続いて、ＮＦＣ−ＳＥＣを使用する場合であっても使用しない場合であっても、イニシエータ及びターゲットは、鍵生成及び鍵共有を行なう。ＮＦＣ−ＳＥＣを使用する場合には、イニシエータ及びターゲットは、上述したようなＮＦＣ−ＳＥＣで規定された方法に従って鍵生成及び鍵共有を行なう。またＮＦＣ−ＳＥＣを使用する場合には、イニシエータ及びターゲットは、例えば相互認証やチャレンジ・レスポンス認証等によって鍵生成及び鍵共有を行なう。

鍵生成及び鍵共有を行なうと、続いてイニシエータ及びターゲットは、ＬＬＣコネクションを確立し、ＬＬＣコネクションを確立すると、暗号化されたＬＬＣデータ交換を行なう。データの交換が完了すると、イニシエータ及びターゲットは、ＬＬＣコネクションを切断する。

［動作シーケンス例］
続いて、本開示の一実施形態に係る通信装置１００、２００の動作シーケンスの例を説明する。まず、本開示の一実施形態に係る通信装置１００、２００の間でデータを保護しない（データを暗号化しない）場合の動作シーケンスについて説明する。

表５は、本開示の一実施形態に係る通信装置１００、２００の間でデータを保護しない場合の動作シーケンスを示す表である。

この表５に示した動作シーケンスでは、最初にイニシエータからターゲットにコマンドＡＴＲ＿ＲＥＱが送信される際に、イニシエータとターゲットとの間で、表１で示した「Ｓｅｃｕｒｅ ＬＬＣ ＴＬＶ」が交換されていない。従って、通信装置１００、２００の間でデータを保護しない場合は、通信装置１００、２００は、表５に示したような動作シーケンスに従って動作する。

表６は、本開示の一実施形態に係る通信装置１００、２００の間で、ＮＦＣ−ＳＥＣ ＳＣＨを使用してデータを保護する場合の動作シーケンスを示す表である。表６に示したＡＣＴ＿ＲＥＱ、ＡＣＴ＿ＲＥＳ、ＶＦＹ＿ＲＥＱ、ＶＦＹ＿ＲＥＳ、ＥＮＣについては、図７を参照されたい。

この表６に示した動作シーケンスでは、最初にイニシエータからターゲットにコマンドＡＴＲ＿ＲＥＱが送信される際に、イニシエータとターゲットとの間で、表１で示した「Ｓｅｃｕｒｅ ＬＬＣ ＴＬＶ」が交換されている。また、ＡＴＲ＿ＲＥＱ及びＡＴＲ＿ＲＥＳにおいて「Ｓｅｃｕｒｅ ＬＬＣ ＴＬＶ」の値が「０１ｈ」である。すなわちイニシエータとターゲットとの間でＮＦＣ−ＳＥＣ ＳＣＨを使用することが宣言されている。従って、通信装置１００、２００の間でＮＦＣ−ＳＥＣ ＳＣＨを使用してデータを保護する場合は、通信装置１００、２００は、表６に示したような動作シーケンスに従って動作する。

表７及び表８は、本開示の一実施形態に係る通信装置１００、２００の間で、ＮＦＣ−ＳＥＣ ＳＳＥを使用してデータを保護する場合の動作シーケンスを示す表である。なお、表８に示した動作シーケンスは表７に続いて実行されるものであり、便宜上２つの表に分割したものである。表７及び表８に示したＡＣＴ＿ＲＥＱ、ＡＣＴ＿ＲＥＳ、ＶＦＹ＿ＲＥＱ、ＶＦＹ＿ＲＥＳ、ＥＮＣについては、図７を参照されたい。

この表７及び表８に示した動作シーケンスでは、最初にイニシエータからターゲットにコマンドＡＴＲ＿ＲＥＱが送信される際に、イニシエータとターゲットとの間で、表１で示した「Ｓｅｃｕｒｅ ＬＬＣ ＴＬＶ」が交換されている。また、ＡＴＲ＿ＲＥＱ及びＡＴＲ＿ＲＥＳにおいて「Ｓｅｃｕｒｅ ＬＬＣ ＴＬＶ」の値が「０２ｈ ０３ｈ」である。すなわちイニシエータとターゲットとの間でＮＦＣ−ＳＥＣ ＳＳＥを使用すること及び共有秘密情報の数が３つであることが宣言されている。従って、通信装置１００、２００の間でＮＦＣ−ＳＥＣ ＳＣＨを使用してデータを保護する場合は、通信装置１００、２００は、表７及び表８に示したような動作シーケンスに従って動作する。

表９は、本開示の一実施形態に係る通信装置１００、２００の間で、相互認証を使用してデータを保護する場合の動作シーケンスを示す表である。本実施形態では、相互認証としてチャレンジ・レスポンス認証によって暗号化通信を行なう場合の動作シーケンスを示す。

この表９に示した動作シーケンスでは、最初にイニシエータからターゲットにコマンドＡＴＲ＿ＲＥＱが送信される際に、イニシエータとターゲットとの間で、表１で示した「Ｓｅｃｕｒｅ ＬＬＣ ＴＬＶ」が交換されている。また、ＡＴＲ＿ＲＥＱ及びＡＴＲ＿ＲＥＳにおいて「Ｓｅｃｕｒｅ ＬＬＣ ＴＬＶ」の値が「０３ｈ ０１ｈ」である。すなわちイニシエータとターゲットとの間で相互認証を使用すること及び共有秘密情報の数が１つであることが宣言されている。従って、通信装置１００、２００の間で相互認証を使用してデータを保護する場合は、通信装置１００、２００は、表９に示したような動作シーケンスに従って動作する。

次に、上述してきた本開示の一実施形態に係る通信装置１００、２００の動作シーケンスをより詳細に説明する。

［通信装置の動作例］
図１５は、本開示の一実施形態に係る通信装置１００の動作例を示す流れ図である。図１５に示した流れ図は、イニシエータである通信装置１００によるＮＦＣＩＰ−１及びＬＬＣＰの活性化を示す流れ図である。なお、図１５に示した流れ図は、例えばＬＬＣＰ処理部１３０が実行しても良い。以下、図１５を用いて本開示の一実施形態に係る通信装置１００の動作例について説明する。

通信装置１００は、活性化の際に、まずＬＬＣ ＰＤＵを暗号化して通信するかどうかを判断する（ステップＳ１０１）。ステップＳ１０１の判断の結果、ＬＬＣ ＰＤＵを暗号化して通信する場合には、通信装置１００は、ＡＴＲ＿ＲＥＱのＧＢｉのＳｅｃｕｒｅ ＬＬＣ ＴＬＶにて、ＮＦＣ−ＳＥＣ ＳＣＨを使用してデータを保護するためのパラメータを設定する（ステップＳ１０２）。

一方、ステップＳ１０１の判断の結果、ＬＬＣ ＰＤＵを暗号化しない場合は、続いて通信装置１００は、ＬＬＣ ＳＤＵをＳＳＥで暗号化して通信するかどうかを判断する（ステップＳ１０３）。ステップＳ１０３の判断の結果、ＬＬＣ ＳＤＵを暗号化して通信する場合には、通信装置１００は、ＡＴＲ＿ＲＥＱのＧＢｉのＳｅｃｕｒｅ ＬＬＣ ＴＬＶにて、ＮＦＣ−ＳＥＣ ＳＳＥを使用してデータを保護するためのパラメータを設定する（ステップＳ１０４）。

一方、ステップＳ１０３の判断の結果、ＬＬＣ ＳＤＵをＳＳＥで暗号化しない場合は、続いて通信装置１００は、ＬＬＣ ＳＤＵを相互認証（Ａｕｔｈ）で暗号化して通信するかどうかを判断する（ステップＳ１０５）。ステップＳ１０５の判断の結果、ＬＬＣ ＳＤＵを相互認証で暗号化して通信する場合には、通信装置１００は、ＡＴＲ＿ＲＥＱのＧＢｉのＳｅｃｕｒｅ ＬＬＣ ＴＬＶにて、相互認証を使用してデータを保護するためのパラメータを設定する（ステップＳ１０６）。

一方、ステップＳ１０５の判断の結果、ＬＬＣ ＳＤＵを相互認証（Ａｕｔｈ）で暗号化しない場合は、通信装置１００は、ＡＴＲ＿ＲＥＱのＧＢｉのＳｅｃｕｒｅ ＬＬＣ ＴＬＶにて、暗号化をせずに通信するようなパラメータを設定する（ステップＳ１０７）。

最後に通信装置１００は、上記ステップＳ１０２、Ｓ１０４、Ｓ１０６またはＳ１０７において設定されたパラメータが含まれるＡＴＲ＿ＲＥＱを、ターゲットである通信装置２００へ送信する（ステップＳ１０８）。

以上、図１５を用いて本開示の一実施形態に係る通信装置１００の動作例について説明した。図１５に示したＮＦＣＩＰ−１及びＬＬＣＰの活性化処理は、ＮＦＣＩＰ−１プロトコル処理部１３５や、ＬＬＣＰリンクプロトコル処理部１３２が実行しても良い。次に、図１５に示した流れ図によってＡＴＲ＿ＲＥＱを生成した通信装置１００から、そのＡＴＲ＿ＲＥＱを受信した通信装置２００の動作例について説明する。

図１６は、本開示の一実施形態に係る通信装置２００の動作例を示す流れ図である。図１６に示した流れ図は、イニシエータである通信装置１００から送信されたＡＴＲ＿ＲＥＱに対してＡＴＲ＿ＲＥＳを送信する場合の動作を示したものである。なお、図１６に示した流れ図は、例えばＬＬＣＰ処理部１３０が実行しても良い。以下、図１６を用いて本開示の一実施形態に係る通信装置２００の動作例について説明する。

通信装置２００は、通信装置１００からＡＴＲ＿ＲＥＱを受信すると、ＡＴＲ＿ＲＥＱのＧＢｉのＳｅｃｕｒｅ ＬＬＣ ＴＬＶで設定されている機能を自装置で有しているかどうかを判断する（ステップＳ１１１）。

上記ステップＳ１１１の判断の結果、ＡＴＲ＿ＲＥＱのＧＢｉのＳｅｃｕｒｅ ＬＬＣ ＴＬＶで設定されている機能を有していると判断すると、通信装置２００は、その機能を使用するように、ＡＴＲ＿ＲＥＳのＧＢｔのＳｅｃｕｒｅ ＬＬＣ ＴＬＶを設定する（ステップＳ１１２）。一方、上記ステップＳ１１１の判断の結果、ＡＴＲ＿ＲＥＱのＧＢｉのＳｅｃｕｒｅ ＬＬＣ ＴＬＶで設定されている機能を有していないと判断すると、通信装置２００は、ＡＴＲ＿ＲＥＳのＧＢｔのＳｅｃｕｒｅ ＬＬＣ ＴＬＶを設定しない（ステップＳ１１３）。

最後に通信装置２００は、設定されたパラメータが含まれるＡＴＲ＿ＲＥＳを、イニシエータである通信装置１００へ送信する（ステップＳ１１４）。

以上、図１６を用いて本開示の一実施形態に係る通信装置２００の動作例について説明した。次に、図１６に示した流れ図によってＡＴＲ＿ＲＥＳを生成した通信装置２００から、そのＡＴＲ＿ＲＥＳを受信した通信装置１００の動作例について説明する。

図１７は、本開示の一実施形態に係る通信装置１００の動作例を示す流れ図である。図１７に示した流れ図は、イニシエータである通信装置１００によるＮＦＣＩＰ−１及びＬＬＣＰの活性化を示す流れ図であり、通信装置２００からＡＴＲ＿ＲＥＳを受信した通信装置１００の動作例を示したものである。以下、図１７を用いて本開示の一実施形態に係る通信装置１００の動作例について説明する。

まず通信装置１００は、ＡＴＲ＿ＲＥＱのＧＢｉ及びＡＴＲ＿ＲＥＳのＧＢｔのＳｅｃｕｒｅ ＬＬＣ ＴＬＶがＳＣＨであるかどうかを判断する（ステップＳ１２１）。ステップＳ１２１の判断の結果、ＡＴＲ＿ＲＥＱのＧＢｉ及びＡＴＲ＿ＲＥＳのＧＢｔのＳｅｃｕｒｅ ＬＬＣ ＴＬＶがＳＣＨであれば、通信装置１００は、ＮＦＣ−ＳＥＣによる鍵生成処理を実行し（ステップＳ１２２）、ＮＦＣ−ＳＥＣ ＳＣＨの利用を記憶する（ステップＳ１２３）。

ステップＳ１２１の判断の結果、ＡＴＲ＿ＲＥＱのＧＢｉとＡＴＲ＿ＲＥＳのＧＢｔのＳｅｃｕｒｅ ＬＬＣ ＴＬＶがいずれもＳＣＨで無ければ、続いて通信装置１００は、ＡＴＲ＿ＲＥＱのＧＢｉ及びＡＴＲ＿ＲＥＳのＧＢｔのＳｅｃｕｒｅ ＬＬＣ ＴＬＶがＳＳＥであるかどうかを判断する（ステップＳ１２４）。

ステップＳ１２４の判断の結果、ＡＴＲ＿ＲＥＱのＧＢｉ及びＡＴＲ＿ＲＥＳのＧＢｔのＳｅｃｕｒｅ ＬＬＣ ＴＬＶがＳＳＥであれば、通信装置１００は、ＮＦＣ−ＳＥＣによる鍵生成処理を実行し（ステップＳ１２５）、ＮＦＣ−ＳＥＣ ＳＳＥで生成された共有秘密情報を保持する（ステップＳ１２６）。続いて通信装置１００は、共有秘密情報を、ＡＴＲ＿ＲＥＱ及びＡＴＲ＿ＲＥＳで設定された数だけ生成したかどうかを判断し（ステップＳ１２７）、生成された共有秘密情報の数が設定された数に達していなければ、ステップＳ１２５及びＳ１２６の処理を設定された数に達するまで繰り返す。そして共有秘密情報を、ＡＴＲ＿ＲＥＱ及びＡＴＲ＿ＲＥＳで設定された数だけ生成すると、通信装置１００は、ＮＦＣ−ＳＥＣ ＳＳＥの利用を記憶する（ステップＳ１２８）。

ステップＳ１２４の判断の結果、ＡＴＲ＿ＲＥＱのＧＢｉとＡＴＲ＿ＲＥＳのＧＢｔとのＳｅｃｕｒｅ ＬＬＣ ＴＬＶがいずれもＳＳＥで無ければ、続いて通信装置１００は、ＡＴＲ＿ＲＥＱのＧＢｉ及びＡＴＲ＿ＲＥＳのＧＢｔのＳｅｃｕｒｅ ＬＬＣ ＴＬＶがＳＣＨ及びＳＳＥ以外の暗号方式（本実施形態では、相互認証方式）であるかどうかを判断する（ステップＳ１２９）。

ステップＳ１２９の判断の結果、ＡＴＲ＿ＲＥＱのＧＢｉ及びＡＴＲ＿ＲＥＳのＧＢｔのＳｅｃｕｒｅ ＬＬＣ ＴＬＶがＳＣＨ及びＳＳＥ以外の暗号方式であれば、通信装置１００は、当該暗号方式による共有秘密情報を生成する（ステップＳ１３０）。続いて通信装置１００は、共有秘密情報を、ＡＴＲ＿ＲＥＱ及びＡＴＲ＿ＲＥＳで設定された数だけ生成したかどうかを判断し（ステップＳ１３１）、生成された共有秘密情報の数が設定された数に達していなければ、ステップＳ１３０の処理を設定された数に達するまで繰り返す。そして共有秘密情報を、ＡＴＲ＿ＲＥＱ及びＡＴＲ＿ＲＥＳで設定された数だけ生成すると、通信装置１００は、上記暗号方式の利用を記憶する（ステップＳ１３２）。

ステップＳ１２９の判断の結果、ＡＴＲ＿ＲＥＱのＧＢｉとＡＴＲ＿ＲＥＳのＧＢｔとのＳｅｃｕｒｅ ＬＬＣ ＴＬＶが、いずれもＳＣＨ及びＳＳＥ以外の暗号方式でなければ、通信装置１００は、ＮＦＣＩＰ−１ ＳＤＵにＬＬＣ ＰＤＵを含めて、暗号化しないでデータ交換することを決定する（ステップＳ１３３）。

以上、図１７を用いて本開示の一実施形態に係る通信装置１００の動作例について説明した。次に、ＬＬＣコネクションを確立する際の通信装置１００、２００の動作例について説明する。

図１８は、本開示の一実施形態に係る通信装置１００の動作例を示す流れ図である。図１８に示した流れ図は、ＬＬＣコネクションの確立を要求する通信装置１００の動作例について示したものである。以下、図１８を用いて本開示の一実施形態に係る通信装置１００の動作例について説明する。

本開示の一実施形態に係る通信装置１００は、ＬＬＣコネクションの確立を要求にあたり、まずＮＦＣ−ＳＥＣ ＳＳＥまたは相互認証方式を利用するかどうかを判断する（ステップＳ１４１）。ＮＦＣ−ＳＥＣ ＳＳＥまたは相互認証方式を利用するかどうかの判断は、例えば図１７に示したＮＦＣＩＰ−１及びＬＬＣＰの活性化のフローの際に記憶された情報が用いられても良い。

ステップＳ１４１の判断の結果、ＮＦＣ−ＳＥＣ ＳＳＥまたは相互認証方式を利用する場合は、続いて通信装置１００は、コネクションを確立しようとする当該ＳＡＰのコネクションのＰＤＵを保護するかどうかを判断する（ステップＳ１４２）。

ステップＳ１４２の判断の結果、コネクションを確立しようとする当該ＳＡＰのコネクションのＰＤＵを保護する場合は、続いて通信装置１００は、Ｓｅｃｕｒｅ Ｃｏｎｎｅｃｔｉｏｎ ＴＬＶに、使用する共有秘密情報の番号を指定する（ステップＳ１４３）。

ステップＳ１４１の判断の結果、ＮＦＣ−ＳＥＣ ＳＳＥ及び相互認証方式のいずれも利用しない場合、ステップＳ１４２の判断の結果、コネクションを確立しようとする当該ＳＡＰのコネクションのＰＤＵを保護しない場合、またはステップＳ１４３でＳｅｃｕｒｅ Ｃｏｎｎｅｃｔｉｏｎ ＴＬＶに、使用する共有秘密情報の番号を指定すると、続いて通信装置１００は、ＬＬＣ ＣＯＮＮＥＣＴ ＰＤＵを通信装置２００へ送信する（ステップＳ１４４）。

続いて通信装置１００は、通信装置２００からＬＬＣ ＣＯＮＮＥＣＴ ＰＤＵに対するＣＣ（Ｃｏｎｎｅｃｔｉｏｎ Ｃｏｍｐｌｅｔｅ）を受信したかどうかを判断する（ステップＳ１４５）。

上記ステップＳ１４５の判断の結果、通信装置２００からＬＬＣ ＣＯＮＮＥＣＴ ＰＤＵに対するＣＣを受信したと判断すると、続いて通信装置１００は、指定された共有秘密情報を使用して、このコネクションにおける以降の通信を暗号化することを記憶する（ステップＳ１４６）。そして通信装置１００は、ＳＡＰと共有秘密情報番号との対応表を更新する（ステップＳ１４７）。

一方、上記ステップＳ１４５の判断の結果、通信装置２００からＬＬＣ ＣＯＮＮＥＣＴ ＰＤＵに対するＣＣを受信しなかったと判断すると、通信装置１００は、通信装置２００との間のコネクション確立に失敗したものとする。

以上、図１８を用いて本開示の一実施形態に係る通信装置１００の動作例について説明した。続いて、ＬＬＣコネクションの確立要求を受信した通信装置２００の動作例について説明する。

図１９は、本開示の一実施形態に係る通信装置２００の動作例を示す流れ図である。図１９に示したのは、通信装置１００からＬＬＣ ＣＯＮＮＥＣＴ ＰＤＵを受信した際の通信装置２００の動作例を示したものである。以下、図１９を用いて本開示の一実施形態に係る通信装置２００の動作例について説明する。

通信装置１００からＬＬＣ ＣＯＮＮＥＣＴ ＰＤＵを受信すると、通信装置２００は、Ｓｅｃｕｒｅ Ｃｏｎｎｅｃｔｉｏｎ ＴＬＶで指定された共有秘密情報の番号は有効かどうかを判断する（ステップＳ１５１）。

上記ステップＳ１５１の判断の結果、Ｓｅｃｕｒｅ Ｃｏｎｎｅｃｔｉｏｎ ＴＬＶで指定された共有秘密情報の番号が有効である場合は、通信装置２００は、指定された共有秘密情報を使用して、このコネクションにおける以降の通信を暗号化することを記憶する（ステップＳ１５２）。そして通信装置２００は、ＳＡＰと共有秘密情報番号との対応表を更新し（ステップＳ１５３）、通信装置１００へＬＬＣ ＣＯＮＮＥＣＴ ＰＤＵに対するＣＣ（Ｃｏｎｎｅｃｔｉｏｎ Ｃｏｍｐｌｅｔｅ）を送信する（ステップＳ１５４）。

一方、上記ステップＳ１５１の判断の結果、Ｓｅｃｕｒｅ Ｃｏｎｎｅｃｔｉｏｎ ＴＬＶで指定された共有秘密情報の番号が有効でない場合は、通信装置２００は、通信装置１００へＤＭ（Ｄｉｓｃｏｎｎｅｃｔｅｄ Ｍｏｄｅ）を送信する（ステップＳ１５５）。

以上、図１９を用いて本開示の一実施形態に係る通信装置２００の動作例について説明した。続いて、ＬＬＣデータ交換を行なう際の通信装置１００、２００の動作例について説明する。

図２０は、本開示の一実施形態に係る通信装置１００の動作例を示す流れ図である。図２０に示したのは、コネクションを確立した通信装置２００との間でＬＬＣデータ交換を行なう際の、通信装置１００の動作例を示したものである。以下、図２０を用いて本開示の一実施形態に係る通信装置１００の動作例について説明する。

通信装置１００は、コネクションを確立した通信装置２００との間でＬＬＣデータ交換を行なう際には、まずＬＬＣでデータ交換するアプリケーションからデータ送信を要求する（ステップＳ１６１）。続いて通信装置１００は、指定コネクションの通信が暗号化されるかどうかを判断する（ステップＳ１６２）。

上記ステップＳ１６２の判断の結果、指定コネクションの通信が暗号化される場合は、通信装置１００は当該コネクションに対応する共有秘密情報でＬＬＣ ＳＤＵを暗号化する（ステップＳ１６３）。暗号化処理は、暗号処理部１３３や、ＮＦＣ−ＳＥＣのプロトコルに従う場合はＮＦＣ−ＳＥＣプロトコル処理部１３４が、ＮＦＣ−ＳＥＣのプロトコルに従わない場合はアプリケーション実行部１２０が実行するアプリケーションが実行する。

最後に通信装置１００は、コネクションを確立した通信装置２００へ、ＬＬＣ Ｉ（Ｉｎｆｏｒｍａｔｉｏｎ） ＰＤＵを送信する（ステップＳ１６４）。指定コネクションの通信が暗号化される場合は暗号化された情報が、暗号化されない場合は平文が、通信装置１００から通信装置２００へ送信される。

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

図２１は、本開示の一実施形態に係る通信装置２００の動作例を示す流れ図である。図２１に示した流れ図は、コネクションを確立した通信装置１００との間でＬＬＣデータ交換を行なう際の、通信装置２００の動作例を示したものである。以下、図２１を用いて本開示の一実施形態に係る通信装置２００の動作例について説明する。

通信装置２００は、コネクションを確立した通信装置１００との間でＬＬＣデータを受信すると、データを受信した当該コネクションの通信が暗号化されているかどうかを判断する（ステップＳ１７１）。

上記ステップＳ１７１の判断の結果、データを受信した当該コネクションの通信が暗号化されていれば、通信装置２００は、当該コネクションに対応する共有秘密情報を用いて、ＬＬＣ ＳＤＵを復号する（ステップＳ１７２）。

最後に通信装置２００は、ＬＬＣでデータ交換するアプリケーションへ、受信した、または受信して復号したデータを転送する（ステップＳ１７３）。

以上、図２１を用いて本開示の一実施形態に係る通信装置２００の動作例について説明した。なお、図２１に示したのはＳＳＥによる暗号化が行われている場合であり、ＳＣＨによる暗号化が適用されている場合は、ＬＬＣでの処理が行われない。

続いて、確立したＬＬＣコネクションを切断する際の通信装置１００、２００の動作例について説明する。

図２２は、本開示の一実施形態に係る通信装置１００の動作例を示す流れ図である。図２２に示したのは、通信装置２００との間で確立したＬＬＣコネクションを切断する際の通信装置１００の動作例である。以下、図２２を用いて本開示の一実施形態に係る通信装置１００の動作例について説明する。

図２２に示したように、通信装置２００との間で確立したＬＬＣコネクションを切断する際には、まず通信装置１００は通信装置２００へ向けてＬＬＣ ＤＩＳＣＯＮＮＥＣＴ ＰＤＵを送信する（ステップＳ１８１）。

続いて通信装置１００は、ＬＬＣ ＤＩＳＣＯＮＮＥＣＴ ＰＤＵに対して通信装置２００から送信されるＤＭを受信する（ステップＳ１８２）と、切断する当該コネクションが、共有秘密情報による暗号化をしていたかどうかを判断する（ステップＳ１８３）。ステップＳ１８３の判断の結果、切断する当該コネクションが、共有秘密情報による暗号化をしていた場合は、通信装置１００は、ＳＡＰ・共有秘密情報番号の対応表を更新する（ステップＳ１８４）。

この一連の流れにより、通信装置１００は、通信装置２００との間で確立したＬＬＣコネクションを切断することができる。また、ＳＡＰ・共有秘密情報番号の対応表を更新することで、通信装置１００と通信装置２００との間で使用されていた共有秘密情報は使用されなくなる。

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

図２３は、本開示の一実施形態に係る通信装置２００の動作例を示す流れ図である。図２３に示したのは、通信装置１００との間で確立したＬＬＣコネクションを切断する際の通信装置２００の動作例である。以下、図２３を用いて本開示の一実施形態に係る通信装置２００の動作例について説明する。

図２２のステップＳ１８１で通信装置１００が送信したＬＬＣ ＤＩＳＣＯＮＮＥＣＴ ＰＤＵを受信すると、通信装置２００は、通信装置１００へ向けてＤＭ ＰＤＵを送信する（ステップＳ１９１）。

続いて通信装置２００は、切断する当該コネクションが、共有秘密情報による暗号化をしていたかどうかを判断する（ステップＳ１９２）。ステップＳ１９２の判断の結果、切断する当該コネクションが、共有秘密情報による暗号化をしていた場合は、通信装置２００は、ＳＡＰ・共有秘密情報番号の対応表を更新する（ステップＳ１９３）。

この一連の流れにより、通信装置２００は、通信装置１００との間で確立したＬＬＣコネクションを切断することができる。また、ＳＡＰ・共有秘密情報番号の対応表を更新することで、通信装置１００と通信装置２００との間で使用されていた共有秘密情報は使用されなくなる。この際に、通信装置１００及び通信装置２００は、セキュリティ上の観点から、暗号化通信の際に使用していた共有秘密情報を完全に削除しても良い。

以上、図２３を用いて本開示の一実施形態に係る通信装置２００の動作例について説明した。次に、本開示の一実施形態に係る通信装置１００が管理するデータの例を説明する。

［通信装置が管理するデータの例］
上述したように、通信装置１００は、共有秘密情報の番号（ＳＳＮ）と、共有秘密情報の値（ＳＳＶ）との対応表（ＳＳ Ｎ−Ｖテーブル）、及びＳＡＰと共有秘密情報の番号との対応表（ＳＳＰ−ＳＳＮテーブル）を管理する。

表９は、ＳＳ Ｎ−Ｖテーブルの初期状態を示す表である。表９に示したように、ＳＳ Ｎ−Ｖテーブルの初期状態は、エントリの数は０個である。

表１０は、ＳＳＰ−ＳＳＮテーブルの初期状態を示す表である。表１０に示したように、ＳＳＰ−ＳＳＮテーブルは、初期状態ではエントリの数は０個である。

通信装置１００は、共有秘密情報を生成すると、ＳＳ Ｎ−Ｖテーブルを更新する。例えば、通信装置１００は、共有秘密情報を３つ生成すると、表１１に示すようにＳＳ Ｎ−Ｖテーブルを更新する。もちろん、以下の表に示したＳＳＮ及びＳＳＶは一例であり、ＳＳＮ及びＳＳＶは係るものに限定されるものではない。

通信装置１００は、このように共有秘密情報を生成した後に、通信装置２００との間でコネクションを確立すると、ＳＳＰ−ＳＳＮテーブルを更新する。例えば、通信先のサービスアクセスポイントであるＤＳＡＰがＤＳＡＰ＝１０、通信元のサービスアクセスポイントであるＳＳＡＰがＳＳＡＰ＝２０，Ｃｏｎｎｅｃｔｉｏｎ ＴＬＶ＝０の場合は、通信装置１００は、表１２に示すようにＳＳＰ−ＳＳＮテーブルを更新する。

通信装置１００は、この表１２の状態からさらに通信装置２００との間でコネクションを確立すると、ＳＳＰ−ＳＳＮテーブルを更新する。例えば、新たなコネクションでは、ＤＳＡＰ＝１１，ＳＳＡＰ＝２１，Ｃｏｎｎｅｃｔｉｏｎ ＴＬＶ＝１である場合は、通信装置１００は、表１３に示すようにＳＳＰ−ＳＳＮテーブルを更新する。

通信装置１００は、この表１３の状態から、通信装置２００との間でコネクションを切断すると、ＳＳＰ−ＳＳＮテーブルを更新する。例えば、ＤＳＡＰ＝１０，ＳＳＡＰ＝２０，Ｃｏｎｎｅｃｔｉｏｎ ＴＬＶ＝０のコネクションを切断すると、通信装置１００は、表１４に示すようにＳＳＰ−ＳＳＮテーブルを更新する。

通信装置１００は、この表１４の状態から、新たに通信装置２００との間でコネクションを確立すると、ＳＳＰ−ＳＳＮテーブルを更新する。例えば、ＤＳＡＰ＝１０，ＳＳＡＰ＝２０，Ｃｏｎｎｅｃｔｉｏｎ ＴＬＶ＝０の場合は、通信装置１００は、表１５に示すようにＳＳＰ−ＳＳＮテーブルを更新する。

通信装置１００は、このように情報を管理することで、どのコネクションにどの共有秘密情報が使用されているかを把握でき、コネクションに適した共有秘密情報を使用してデータを暗号化することができる。

＜２．まとめ＞
以上説明したように本開示の一実施形態によれば、ＮＦＣ ＬＬＣＰによる通信に際し、リンク活性化において暗号化するレイヤーと、共有秘密情報の生成方法とが指定される。そして、本開示の一実施形態によれば、このように指定された暗号化レイヤーと共有秘密情報の生成方法とに基づき、コネクション確立において、使用される共有秘密情報が指定され、通信データが暗号化される。

本開示の一実施形態は、ＮＦＣ ＬＬＣＰを用いる上位レイヤー（アプリケーション実行部１２０が実行するアプリケーション）が、全ての通信に対するＮＦＣ−ＳＥＣによる暗号通信を行なうのか、ＮＦＣ ＬＬＣＰのコネクションごとの暗号通信を行なうのかが選択可能になるという効果を奏する。従って、本開示の一実施形態に係る通信装置１００、２００は、例えば、暗号通信の必要がないデータについては暗号化せずにデータの授受を実行し、暗号通信の必要があるデータについては暗号化してデータの授受を実行するという運用が可能になり、ＬＬＣＰの複数コネクションの同時通信機能を十分に活用することが出来るようになる。

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

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

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

例えば、上記実施形態では、ＬＬＣＰ処理部１３０において暗号方式の決定を行なっていたが、本開示は係る例に限定されるものではない。例えば、暗号方式の決定はＬＬＣＰ処理部１３０の外部、例えばアプリケーション実行部１２０が実行するアプリケーションが行ない、ＬＬＣＰ処理部１３０は、ＬＬＣＰ処理部１３０の外部で決定された暗号方式をＬＬＣＰコネクション処理部１３１で取得し、取得した暗号方式に基づいて暗号化通信を実行するようにしても良い。

例えば、上述の処理が実行される装置や、装置の内部で実行されるアプリケーションに応じて、使用する暗号化方式の優先度を変化させても良い。例えば、無線通信の接続情報等の、情報が傍受されると不都合が生じる情報の送受信を実行するアプリケーションの通信の際には暗号化通信が優先して実行されるように優先度を設定しても良い。

また例えば、一度生成された共有秘密情報が再利用されるようにしても良い。例えば、どのＳＳＡＰとＤＳＡＰの組でどの共有秘密情報が利用されたかの情報を保持しておき、同じＳＳＡＰとＤＳＡＰの組で再び暗号化通信が実行されようとする場合は、以前に利用されていた共有秘密情報が再利用されるようにしても良い。利用されていた共有秘密情報が再利用されるようにすることで、共有秘密情報の生成処理を省略でき、暗号化通信をより迅速に行えることができる。

なお、本技術は以下のような構成も取ることができる。
（１）
複数のコネクションを確立して同時に通信を実行することが可能な非接触通信により他の装置と通信を行う通信処理部と、
前記他の装置との非接触通信の際に暗号化するコネクションを含む暗号化情報に基づいて前記非接触通信で送信されるデータの暗号処理を実行する暗号処理部と、
を含む、集積回路。
（２）
前記他の装置との前記非接触通信の際に暗号化するコネクション及び暗号化方式を決定する暗号化方式決定部を有する、前記（１）に記載の集積回路。
（３）
前記暗号化方式決定部は、前記他の装置との前記非接触通信の際に使用する暗号化方式の決定の前に、前記他の装置との間で利用できる暗号化方式の情報を前記他の装置と交換する、前記（２）に記載の集積回路。
（４）
前記暗号化方式決定部は、全てのコネクションを暗号化するか、コネクションの一部を暗号化するかを決定する、前記（２）または（３）に記載の集積回路。
（５）
前記暗号化方式決定部は、前記他の装置との間の暗号化された通信に用いる暗号鍵の値及び前記暗号鍵を識別する情報を対応付けて管理する、前記（２）〜（４）のいずれかに記載の集積回路。
（６）
前記アプリケーションは、それぞれ固有のサービスアクセスポイントを有し、
前記暗号化方式決定部は、前記サービスアクセスポイント及び前記他の装置との間の暗号化された通信に用いる暗号鍵を識別する情報を対応付けて管理する、前記（２）〜（５）のいずれかに記載の集積回路。
（７）
前記暗号化方式決定部は、前記他の装置との間の前記非接触通信が終了すると、前記サービスアクセスポイント及び前記暗号鍵を識別する情報の対応付けを削除する、前記（６）に記載の集積回路。
（８）
前記暗号化方式決定部は、前記サービスアクセスポイント及び前記他の装置との間の暗号化された通信が終了した後に、前記サービスアクセスポイントが再度同じ相手との間で暗号化された通信を実行しようとする場合、同じ暗号鍵を再利用する、前記（６）または（７）に記載の集積回路。
（９）
前記暗号化情報を取得するためのインターフェースを有する、前記（１）〜（８）のいずれかに記載の集積回路。
（１０）
複数のコネクションを確立して同時に通信を実行することが可能な非接触通信により他の装置と通信を行う通信処理部と、
前記他の装置との前記非接触通信の際に暗号化するコネクションを決定する暗号化方式決定部と、
前記暗号化方式決定部の決定に基づいて前記非接触通信で送信されるデータの暗号処理を実行する暗号処理部と、
を含む、通信装置。
（１１）
複数のコネクションを確立して同時に通信を実行することが可能な非接触通信により他の装置と通信を行う通信処理ステップを備え、
前記通信処理ステップは、
前記他の装置との前記非接触通信の際に暗号化するコネクションを決定する暗号化方式決定ステップと、
前記暗号化方式決定ステップでの決定に基づいて前記非接触通信で送信されるデータの暗号処理を実行する暗号処理ステップと、
を含む、通信方法。
（１２）
コンピュータに、複数のコネクションを確立して同時に通信を実行することが可能な非接触通信により他の装置と通信を行う通信処理ステップを実行させ、
前記通信処理ステップは、
前記他の装置との前記非接触通信の際に暗号化するコネクションを決定する暗号化方式決定ステップと、
前記暗号化方式決定ステップでの決定に基づいて前記非接触通信で送信されるデータの暗号処理を実行する暗号処理ステップと、
を含む、コンピュータプログラム。

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

Claims (12)

1. 複数のコネクションを確立して同時に通信を実行することが可能な非接触通信により他の装置と通信を行う通信処理部と、
   前記他の装置との非接触通信の際に暗号化するコネクションを含む暗号化情報に基づいて前記非接触通信で送信されるデータの暗号処理を実行する暗号処理部と、
   を含む、集積回路。
2. 前記他の装置との前記非接触通信の際に暗号化するコネクション及び暗号化方式を決定する暗号化方式決定部を有する、請求項１に記載の集積回路。
3. 前記暗号化方式決定部は、前記他の装置との前記非接触通信の際に使用する暗号化方式の決定の前に、前記他の装置との間で利用できる暗号化方式の情報を前記他の装置と交換する、請求項２に記載の集積回路。
4. 前記暗号化方式決定部は、全てのコネクションを暗号化するか、コネクションの一部を暗号化するかを決定する、請求項２に記載の集積回路。
5. 前記暗号化方式決定部は、前記他の装置との間の暗号化された通信に用いる暗号鍵の値及び前記暗号鍵を識別する情報を対応付けて管理する、請求項２に記載の集積回路。
6. 前記アプリケーションは、それぞれ固有のサービスアクセスポイントを有し、
   前記暗号化方式決定部は、前記サービスアクセスポイント及び前記他の装置との間の暗号化された通信に用いる暗号鍵を識別する情報を対応付けて管理する、請求項２に記載の集積回路。
7. 前記暗号化方式決定部は、前記他の装置との間の前記非接触通信が終了すると、前記サービスアクセスポイント及び前記暗号鍵を識別する情報の対応付けを削除する、請求項６に記載の集積回路。
8. 前記暗号化方式決定部は、前記サービスアクセスポイント及び前記他の装置との間の暗号化された通信が終了した後に、前記サービスアクセスポイントが再度同じ相手との間で暗号化された通信を実行しようとする場合、同じ暗号鍵を再利用する、請求項６に記載の集積回路。
9. 前記暗号化情報を取得するためのインターフェースを有する、請求項１に記載の集積回路。
10. 複数のコネクションを確立して同時に通信を実行することが可能な非接触通信により他の装置と通信を行う通信処理部と、
    前記他の装置との前記非接触通信の際に暗号化するコネクションを決定する暗号化方式決定部と、
    前記暗号化方式決定部の決定に基づいて前記非接触通信で送信されるデータの暗号処理を実行する暗号処理部と、
    を含む、通信装置。
11. 複数のコネクションを確立して同時に通信を実行することが可能な非接触通信により他の装置と通信を行う通信処理ステップを備え、
    前記通信処理ステップは、
    前記他の装置との前記非接触通信の際に暗号化するコネクションを決定する暗号化方式決定ステップと、
    前記暗号化方式決定ステップでの決定に基づいて前記非接触通信で送信されるデータの暗号処理を実行する暗号処理ステップと、
    を含む、通信方法。
12. コンピュータに、複数のコネクションを確立して同時に通信を実行することが可能な非接触通信により他の装置と通信を行う通信処理ステップを実行させ、
    前記通信処理ステップは、
    前記他の装置との前記非接触通信の際に暗号化するコネクションを決定する暗号化方式決定ステップと、
    前記暗号化方式決定ステップでの決定に基づいて前記非接触通信で送信されるデータの暗号処理を実行する暗号処理ステップと、
    を含む、コンピュータプログラム。
    

Images