JP7052616B2

JP7052616B2 - 通信デバイス、データ送信方法、及びプログラム

Info

Publication number: JP7052616B2
Application number: JP2018139569A
Authority: JP
Inventors: 正剛福永
Original assignee: Dai Nippon Printing Co Ltd
Current assignee: Dai Nippon Printing Co Ltd
Priority date: 2018-07-25
Filing date: 2018-07-25
Publication date: 2022-04-12
Anticipated expiration: 2038-07-25
Also published as: JP2020017857A

Description

サーバとＳＥ（Secure Element）との間の通信を仲介する通信デバイスの技術分野に関する。

物をインターネットに繋げるＩｏＴ（Internet of Things）製品は、センサーからの情報取得や、装置の遠隔管理などを目的としている。ＩｏＴ製品にセキュリティが要求される場合、ＩｏＴ製品に組み込まれるＳＥにて鍵などの秘密情報を管理する必要がある。このとき、ＳＥとサーバとの間で安全な通信経路を確立し、秘密情報の送受信を行う必要がある。特許文献１には、鍵情報を保持するセキュリティチップとサーバとの間でセッションを確立して秘密情報を送受信するシステムが開示されている。このシステムでは、セキュリティチップとサーバとの間にＰＣが介在している。そして、このＰＣは、セキュリティチップとサーバとの間のハンドシェイクにおいて、サーバからのサーバ証明書を受信すると当該サーバ証明書を検証し、当該サーバ証明書のサーバ公開鍵を用いて受信した署名を検証するようになっている。つまり、特許文献１のシステムでは、上記ハンドシェイクの一部をＰＣが実施している。

特開２００６－１２９１４３号公報

ところで、インターネット上における暗号化通信として、例えばＳＳＬ（Secure Sockets Layer）／ＴＬＳ（Transport Layer Security）プロトコル（以下、ＴＬＳプロトコルという）による暗号化通信が知られているが、これは、ブラウザなど、機能や性能が豊富なアプリケーションが搭載されるＰＣとサーバとの通信で利用されることが主であり、機能や性能に制限のあるＳＥとサーバとの通信に利用されていなかった。これは、インターネットを介する通信では多くのデータを送受信する必要があるため、ＳＥがサーバからの全てのデータを処理すると処理時間がかかるからである。なお、特許文献１のシステムでは、セキュリティチップとサーバとの間のハンドシェイクの一部をＰＣが実施するため、中間者攻撃を受ける可能性があり、セキュリティ的に万全ではないという問題がある。

そこで、本発明は、このような点等に鑑みてなされたものであり、ＳＥとサーバとの間のハンドシェイクの迅速化を図ることが可能な通信デバイス、データ送信方法、及びプログラムを提供することを目的とする。

上記課題を解決するために、請求項１に記載の発明は、サーバとセキュアエレメントとの間の通信を仲介する通信デバイスであって、前記サーバと前記セキュアエレメントとの間で暗号通信を行うためのセッションを確立するハンドシェイクを開始させる開始要求を前記セキュアエレメントへ送信する第１送信手段と、前記開始要求により開始された前記ハンドシェイクにおいて、ＡＰＤＵ（Application Protocol Data Unit）ヘッダが付加されたハンドシェイクデータを前記セキュアエレメントから受信すると、前記ＡＰＤＵヘッダに代えてＴＬＳ（Transport Layer Security）レコードヘッダ、ＴＣＰ（Transimission Control Protocol）ヘッダ、及びＩＰ（Internet protocol）ヘッダを、前記ハンドシェイクデータを含むＴＬＳデータに付加して前記サーバへ送信する第２送信手段と、前記開始要求により開始された前記ハンドシェイクにおいて、ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダが付加されたＴＬＳデータを前記サーバから受信すると、前記ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダに代えてＡＰＤＵヘッダを、前記ＴＬＳデータに含まれるハンドシェイクデータに付加して前記セキュアエレメントへ送信する第３送信手段と、を備えることを特徴とする。

請求項２に記載の発明は、請求項１に記載の通信デバイスにおいて、前記第３送信手段は、前記ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダが付加されたＴＬＳデータを前記サーバから受信すると、前記ＴＣＰヘッダ及び前記ＩＰヘッダに含まれるデータに基づいて解析処理を実行しその結果が良好である場合に限り、前記ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダに代えてＡＰＤＵヘッダを、前記ＴＬＳデータに含まれるハンドシェイクデータに付加して前記セキュアエレメントへ送信することを特徴とする。

請求項３に記載の発明は、請求項１または２に記載の通信デバイスにおいて、前記ハンドシェイクデータの種別を示すmsgタイプと、当該ハンドシェイクデータの種別毎に割り当てられたＩＮＳとの対応関係を示すデータ種別対応情報を記憶する記憶手段を更に備え、前記第２送信手段は、前記ＡＰＤＵヘッダが付加されたハンドシェイクデータを前記セキュアエレメントから受信すると、当該ＡＰＤＵヘッダに含まれるＩＮＳと、前記記憶手段に記憶されたデータ種別対応情報とに基づいて前記msgタイプを特定し、特定したmsgタイプ及び前記ハンドシェイクデータを含むＴＬＳデータに、前記ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダを付加して前記サーバへ送信することを特徴とする。

請求項４に記載の発明は、請求項１または２に記載の通信デバイスにおいて、前記ハンドシェイクデータの種別を示すmsgタイプと、当該ハンドシェイクデータの種別毎に割り当てられたＩＮＳとの対応関係を示すデータ種別対応情報を記憶する記憶手段を備え、前記第３送信手段は、前記ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダが付加されたＴＬＳデータを前記サーバから受信すると、当該ＴＬＳデータに含まれるmsgタイプと、前記記憶手段に記憶されたデータ種別対応情報とに基づいて前記ＩＮＳを特定し、当該特定したＩＮＳを含むＡＰＤＵヘッダを前記ハンドシェイクデータに付加して前記セキュアエレメントへ送信することを特徴とする。

請求項５に記載の発明は、請求項１乃至４の何れか１項に記載の通信デバイスにおいて、前記サーバが機密性の高いデータを配信するサーバであるか否かを判定する判定手段を更に備え、前記判定手段により前記サーバが機密性の高いデータを配信するサーバであると判定された場合、前記第１送信手段は、前記開始要求を前記セキュアエレメントへ送信することを特徴とする。

請求項６に記載の発明は、請求項１乃至５の何れか１項に記載の通信デバイスにおいて、前記セキュアエレメントとの間で暗号通信を行うためのセッションが確立された前記サーバから受信されたデータのデータ長に応じて、当該データを分割して複数回に分けて前記セキュアエレメントへ送信する第４送信手段を更に備えることを特徴とする。

請求項７に記載の発明は、請求項１乃至６の何れか１項に記載の通信デバイスにおいて、前記セキュアエレメントから複数回に亘って受信されたデータを連結して当該セキュアエレメントとの間で暗号通信を行うためのセッションが確立された前記サーバへ送信する第５送信手段を更に備えることを特徴とする。

請求項８に記載の発明は、サーバとセキュアエレメントとの間の通信を仲介する通信デバイスに含まれるコンピュータにより実行されるデータ送信方法であって、前記サーバと前記セキュアエレメントとの間で暗号通信を行うためのセッションを確立するハンドシェイクを開始させる開始要求を前記セキュアエレメントへ送信するステップと、前記開始要求により開始された前記ハンドシェイクにおいて、ＡＰＤＵヘッダが付加されたハンドシェイクデータを前記セキュアエレメントから受信すると、前記ＡＰＤＵヘッダに代えてＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダを、前記ハンドシェイクデータを含むＴＬＳデータに付加して前記サーバへ送信するステップと、前記開始要求により開始された前記ハンドシェイクにおいて、ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダが付加されたＴＬＳデータを前記サーバから受信すると、前記ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダに代えてＡＰＤＵヘッダを、前記ＴＬＳデータに含まれるハンドシェイクデータに付加して前記セキュアエレメントへ送信するステップと、を含むことを特徴とする。

請求項９に記載の発明は、サーバとセキュアエレメントとの間の通信を仲介する通信デバイスに含まれるコンピュータを、前記サーバと前記セキュアエレメントとの間で暗号通信を行うためのセッションを確立するハンドシェイクを開始させる開始要求を前記セキュアエレメントへ送信する第１送信手段と、前記開始要求により開始された前記ハンドシェイクにおいて、ＡＰＤＵヘッダが付加されたハンドシェイクデータを前記セキュアエレメントから受信すると、前記ＡＰＤＵヘッダに代えてＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダを、前記ハンドシェイクデータを含むＴＬＳデータに付加して前記サーバへ送信する第２送信手段と、前記開始要求により開始された前記ハンドシェイクにおいて、ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダが付加されたＴＬＳデータを前記サーバから受信すると、前記ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダに代えてＡＰＤＵヘッダを、前記ＴＬＳデータに含まれるハンドシェイクデータに付加して前記セキュアエレメントへ送信する第３送信手段として機能させることを特徴とする。

本発明によれば、ＳＥとサーバとの間のハンドシェイクの迅速化を図ることができる。

本実施形態に係る通信システムＳの概要構成例を示す図である。本実施形態に係る通信システムＳにおける通信プロトコルを階層別に示す概念図である。ＴＬＳハンドシェイク層でハンドシェイクプロトコルが用いられる場合のプロトコル変換の一例を示す概念図である。ＴＬＳハンドシェイク層でアプリケーションデータプロトコルが用いられる場合のプロトコル変換の一例を示す概念図である。ＴＬＳハンドシェイク層でアプリケーションデータプロトコルが用いられる場合のプロトコル変換の一例を示す概念図である。端末Ｔのハードウェア構成例を示す図である。通信システムＳの動作例を示すシーケンスである。応用例に係る通信システムＳの概要構成例を示す図である。ＤＥ２がサーバからデータを受信したときの処理の一例を示すフローチャートである。（Ａ）は、ＤＥ２がＳＥ３へデータを送信するとき処理の一例を示すフローチャートであり、（Ｂ）は、ＤＥ２がサーバ１（またはサーバ１ａ）へデータを送信するときの処理の一例を示すフローチャートである。

以下、図面を参照して本発明の実施形態について詳細に説明する。以下に説明する実施形態は、通信システムにおけるＤＥ（Device）に対して本発明を適用した場合の実施の形態である。なお、通信システムは、例えばＩｏＴシステムとして利用される。

［１．通信システムＳの構成及び通信プロトコル］
先ず、図１及び図２を参照して、本実施形態に係る通信システムＳの概要構成及び通信プロトコルについて説明する。図１は、本実施形態に係る通信システムＳの概要構成例を示す図であり、図２は、本実施形態に係る通信システムＳにおける通信プロトコルを階層別に示す概念図である。

図１に示すように、通信システムＳは、サーバ１、ＤＥ（Device）２、及びＳＥ（セキュアエレメント）３等を含んで構成される。サーバ１とＤＥ２は、それぞれ、インターネットや移動通信網等により構成されるネットワークＮＴに接続され、ネットワークＮＴを介して互いに通信可能になっている。具体的には、サーバ１とＤＥ２は、図２に示すように、ネットワーク・インターフェース（ネットワークＮＴ）をベースとして、ＴＣＰ（Transmission Control Protocol）／ＩＰ（Internet protocol）及びＴＬＳプロトコルにしたがって通信する。ここで、ＴＬＳプロトコルは、ＴＬＳレコード層（TLS Record）とＴＬＳハンドシェイク層という２つの層から構成される。ＴＬＳハンドシェイク層は、ハンドシェイクプロトコル（TLS HS(Handshake)）、アラートプロトコル（TLS AL(Alert)）、暗号仕様変更プロトコル（TLS CC(Change Cipher Spec)）、及びアプリケーションデータプロトコル（App(Application) Data)から構成される。本実施形態では、ハンドシェイクプロトコルは、サーバ１とＳＥ３との間で暗号通信を行うためのセッションを確立することに用いられる。ハンドシェイクプロトコルにしたがってサーバ１とＳＥ３との間でセッションを確立するためのやり取りをハンドシェイクという。このようなハンドシェイクにおいてサーバ１とＳＥ３との間で共通のセッション鍵（以下、「共通鍵」という）が生成される。アプリケーションデータプロトコルは、サーバ１とＳＥ３との間で共通鍵により暗号化されたアプリケーションデータを送受信することに用いられる。なお、アプリケーションデータプロトコルには、例えば、HTTPS (Hypertext Transfer Protocol Secure）及びFTPS (File Transfer Protocol Secure)などが該当する。

一方、ＤＥ２とＳＥ３は、所定のインターフェースを介して互いに通信可能になっている。具体的には、ＤＥ２とＳＥ３は、図２に示すように、所定のインターフェースをベースとして、ＳＥ用プロトコル及びＡＰＤＵ（Application Protocol Data Unit）プロトコルにしたがって通信する。ここで、ＳＥ用プロトコルは、所定のインターフェースに依存するプロトコルである。このインターフェースの例として、ＳＰＩ（Serial Peripheral Interface）、Ｉ²Ｃ（Inter-Integrated Circuit）、及びISO7816インターフェースなどが挙げられる。ＳＰＩ及びＩ²Ｃは、シリアル通信インターフェース（シリアル通信バスともいう）であり、特に、ＳＰＩは、同時に双方向の通信を行う全二重シリアル通信プロトコルを用いる。一方、ISO7816インターフェースは、ISO7816-2で定義される通信インターフェース（Ｃ１～Ｃ８の８個の端子を利用した通信インターフェース）であり、ＴＰＤＵ（Transmission Protocol Data Unit）プロトコル（例えば、Ｔ＝０またはＴ＝１）を用いる。なお、ＡＰＤＵプロトコルは、ISO7816-3で定義されるＡＰＤＵを送受信するためのプロトコルである。さらに、ＤＥ２は、サーバ１とＳＥ３との間の通信を仲介する機能を担っており、この仲介の際にプロトコル変換を行う。つまり、ＤＥ２は、図２に示すように、ＴＬＳプロトコルにおけるＴＬＳハンドシェイク層を維持しつつ、ＴＣＰ／ＩＰ及びＴＬＳプロトコルにおけるＴＬＳレコード層と、ＳＥ用プロトコル及びＡＰＤＵプロトコルとを変換する。

ここで、図３～図５を参照して、プロトコル変換について説明する。図３は、ＴＬＳハンドシェイク層でハンドシェイクプロトコルが用いられる場合のプロトコル変換の一例を示す概念図であり、図４及び図５は、ＴＬＳハンドシェイク層でアプリケーションデータプロトコルが用いられる場合のプロトコル変換の一例を示す概念図である。

先ず、図３に示すように、ＴＬＳハンドシェイク層でハンドシェイクプロトコルが用いられる場合のプロトコル変換によって、サーバ１とＤＥ２との間で送受信されるデータＤ（Message）１は、ＤＥ２とＳＥ３との間で送受信されるデータＤ２（ＡＰＤＵ）に変換され、また、データＤ２は、データＤ１に変換される。データＤ１は、ＩＰヘッダ、ＴＣＰヘッダ、タイプ、プロトコルバージョン、データ長（ＴＬＳデータのデータ長）、及びＴＬＳデータから構成される。ここで、ＩＰヘッダには、送信元ＩＰアドレス、宛先ＩＰアドレス、及びＩＰヘッダのエラーチェックを行うためのチェックサム等が含まれる。ＴＣＰヘッダには、送信元ポート番号、宛先ポート番号、及びＴＣＰヘッダ及びデータ部分のエラーチェックを行うためのチェックサム等が含まれる。タイプ、プロトコルバージョン、及びデータ長は、ＴＬＳレコードヘッダを構成する。タイプは、ハンドシェイクプロトコル、アラートプロトコル、暗号仕様変更プロトコル、及びアプリケーションデータプロトコルのうち何れかのプロトコル種別を示す値であるが、図３の例では、ハンドシェイクプロトコルを示している。この場合のＴＬＳデータは、msgタイプ、データ長（ハンドシェイクデータのデータ長）、及びハンドシェイクに用いられるハンドシェイクデータから構成される。msgタイプは、ハンドシェイクデータの種別を示す値（図３の例では、１６進数（0x）で示している）である。

一方、データＤ２は、ＣＬＡ、ＩＮＳ、Ｐ１、Ｐ２、Ｌｃ、及びハンドシェイクデータから構成される。ここで、ＣＬＡ、ＩＮＳ、Ｐ１及びＰ２はＡＰＤＵヘッダを構成し、Ｌｃ及びハンドシェイクデータはＡＰＤＵボディを構成する。つまり、データＤ２のデータフォーマットとして、ISO7816-3で定義されたコマンドＡＰＤＵ（Case3）のデータフォーマットが利用されている。ＣＬＡはコマンドクラス（命令クラス）を示す値であり、ＩＮＳはコマンドコード（命令コード）を示す値であり、Ｐ１及びＰ２はコマンドパラメータ（命令パラメータ）を示す値である。ISO7816-4では、“SELECT FILE”，“READ BINARY”，“UPDATE BINARY”，“WRITE BINARY”，及び“VERIFY”等のコマンド種別毎に異なるＩＮＳが割り当てられているが、本実施形態では、図３に示すように、ISO7816-4において使用されていないＩＮＳがハンドシェイクデータに対して割り当てられる。例えば、ハンドシェイクデータ“Client Hello”には、ＩＮＳ“Ox00”が割り当てられ、ハンドシェイクデータ“Server Hello”には、ＩＮＳ“Ox02”が割り当てられている。このように、ハンドシェイクデータの種別毎に異なるＩＮＳが割り当てられている。一方、ＣＬＡはハンドシェイクデータの種別によらず固定値となっており、Ｐ１及びＰ２は後続データの有無などにより変化する。なお、上記msgタイプで示されるハンドシェイクデータは１０種類であるが、これらのうち、本実施形態では、ハンドシェイクデータ“Hello Request”及び“Server Key Exchange”を使用しなくてもよいため、これらのハンドシェイクデータには、ＩＮＳが割り当てられていない。ただし、ハンドシェイクデータ“Server Key Exchange”については利用されてもよく、この場合、“Server Key Exchange”には固有のＩＮＳが割り当てられる。

次に、図４に示すように、ＴＬＳハンドシェイク層でアプリケーションデータプロトコルが用いられる場合のプロトコル変換によって、サーバ１とＤＥ２との間で送受信されるデータＤ３は、ＤＥ２とＳＥ３との間で送受信されるデータＤ４に変換される。データＤ３は、ＩＰヘッダ、ＴＣＰヘッダ、アプリケーションデータプロトコルを示すタイプ、プロトコルバージョン、データ長、及び暗号化コマンド（ＴＬＳデータ）から構成される。ここで、暗号化コマンドは、サーバ１とＳＥ３との間で実施されたハンドシェイクにおいて生成された共通鍵で暗号化されたコマンドＡＰＤＵである。一方、データＤ４は、ＣＬＡ、ＩＮＳ、Ｐ１、Ｐ２、Ｌｃ、及び暗号化コマンドから構成される。この場合のＣＬＡ及びＩＮＳは固定値となっており、特に、ＩＮＳは暗号化されたデータであることを示す。一方、Ｐ１及びＰ２は後続データの有無などにより変化する。そして、ＳＥ３において、図４に示すように、データＤ４に含まれる暗号化コマンドが上記共通鍵で復号されることでデータＤ５（コマンドＡＰＤＵ）が抽出される。データＤ５は、“SELECT FILE”，“READ BINARY”，“UPDATE BINARY”，“WRITE BINARY”，または“VERIFY”等のコマンドである。なお、図４の例では、データＤ５は、ＣＬＡ、ＩＮＳ、Ｐ１、Ｐ２、Ｌｃ、及びＤａｔａから構成されている（Case3）が、ＣＬＡ、ＩＮＳ、Ｐ１及びＰ２から構成（Case1）される場合、或いは、ＣＬＡ、ＩＮＳ、Ｐ１、Ｐ２、及びＬｅ（レスポンスＡＰＤＵの最大長（最大サイズ））から構成（Case2）される場合、或いは、ＣＬＡ、ＩＮＳ、Ｐ１、Ｐ２、Ｌｃ、Ｄａｔａ、Ｌｅから構成（Case4）される場合もある。

このように抽出されたデータＤ５（コマンドＡＰＤＵ）に応じた処理がＳＥ３により実行されると、図５に示すように、その実行結果を示すデータＤ６（ＳＷ（ステータスワード）１及びＳＷ２からなるレスポンスＡＰＤＵ）が生成される。続いて、ＳＥ３において、データＤ６が上記共通鍵で暗号化されることで暗号化レスポンスが生成され、この暗号化レスポンスにＳＷ１及びＳＷ２が付加されることでデータＤ７（レスポンスＡＰＤＵ）が生成される。なお、図５の例では、データＤ７は、ＳＷ１及びＳＷ２から構成されている（Case1,Case3）が、ＤＡＴＡ（例えばＮＶＭ３４から読み出されたデータ）、ＳＷ１及びＳＷ２から構成される（Case2,Case4）される場合もある。このように生成されたデータＤ７は、ＳＥ３からＤＥ２へ送信され、プロトコル変換されることで、データＤ８に変換される。データＤ８は、ＩＰヘッダ、ＴＣＰヘッダ、アプリケーションデータプロトコルを示すタイプ、プロトコルバージョン、データ長（暗号化レスポンスのデータ長）、及び暗号化レスポンス（ＴＬＳデータ）から構成される。

［２．ＤＥ２及びＳＥ３の構成及び機能］
次に、図６を参照して、本実施形態に係るＤＥ２及びＳＥ３の構成及び機能について説明する。なお、本実施形態では、ＤＥ２及びＳＥ３は、同じ端末Ｔ内に搭載されることを例にとって説明するが、別々の端末に搭載されてもよい。また、ＤＥ２は、本発明の通信デバイスの一例である。また、ＳＥ３は、例えば、eUICC（Embedded Universal Integrated Circuit Card）として、端末Ｔから容易に取り外しや取り換えができないように組み込み基盤上に実装（つまり、端末Ｔと一体的に形成）される。或いは、ＳＥ３はＩＣカードに搭載されてもよく、この場合、当該ＩＣカードは端末Ｔに着脱可能に装着される。

図６は、端末Ｔのハードウェア構成例を示す図である。図６に示すように、端末Ｔは、ＤＥ２、ＳＥ３、及びセンサー４を備えて構成される。ＤＥ２は、Ｉ／Ｆ部２１，２２、通信部２３、記憶部２４、及びデバイス制御部２５等を備えて構成される。Ｉ／Ｆ部２１は、ＳＥ３との間のインターフェースを担う。このインターフェースは、上述したように、ＳＰＩ、Ｉ²Ｃ、またはISO7816インターフェースなどである。Ｉ／Ｆ部２２は、センサー４との間のインターフェースを担う。センサー４は、端末Ｔから所定の近傍範囲（例えば、数ｍの範囲）内の状態（例えば、温度、湿度、気圧、照度、水位、騒音など）を例えば定期的に検知する。センサー４により検知、取得された状態を示す情報は、デバイス制御部２５によりＩ／Ｆ部２１を介してＳＥ３に送信され、ＳＥ３によりＮＶＭ３４に記憶（蓄積）される。

通信部２３は、ネットワークＮＴに接続するための通信機器である。なお、通信部２３は、移動通信網の基地局を検出するモデムを備えている場合もある。この場合、通信部２３は、デバイス制御部２５により指定されたデータを変調し、その電波（搬送波）をアンテナを介して基地局へ送信し、また、基地局からの電波をアンテナを介して受信して復調することでデータを取り出してデバイス制御部２５へ送信する。記憶部２４（記憶手段の一例）は、例えば不揮発性メモリから構成され、所定のプログラム（本発明のプログラムを含む）、及びデータが記憶される。本発明のプログラムは、ＤＥ２に含まれるコンピュータ（ＣＰＵ（Central Processing Unit））を、第１送信手段、第２送信手段、第３送信手段、第４送信手段、第５送信手段、及び判定手段として機能させる。また、記憶部２４には、データとして、サーバ１のＩＰアドレス及びポート番号、或いはサーバ１のＵＲＬ（Uniform Resource Locator）が記憶される。さらに、記憶部２４には、ハンドシェイクデータの種別を示すmsgタイプと、ハンドシェイクデータの種別毎に割り当てられたＩＮＳとの対応関係を示すデータ種別対応情報が含まれており、これはプロトコル変換のために用いられる。例えば、図３の場合、データ種別対応情報には、“Client Hello”のmsgタイプ“Ox01”と、“Client Hello”に割り当てられたＩＮＳ“Ox00”とが対応付けられ、“Server Hello”のmsgタイプ“Ox02”と、“Server Hello”に割り当てられたＩＮＳ“Ox02”とが対応付けられている。なお、ハンドシェイクデータの全種別について、msgタイプとＩＮＳとが完全に一致する場合、データ種別対応情報が記憶部２４に記憶されなくてもよい。

デバイス制御部２５は、例えばＣＰＵ、ＲＡＭ（Random Access Memory）、及びＲＯＭ（Read Only Memory）等により構成され、サーバ１とＳＥ３との間の通信を仲介する機能を担っており、上述したように、この仲介の際にプロトコル変換を行う。デバイス制御部２５は、サーバ１とＳＥ３との間で暗号通信を行うためのセッションを確立するハンドシェイクを開始させる開始要求をＳＥ３へ送信する。そして、当該開始要求により開始されたハンドシェイクにおいて、デバイス制御部２５は、ＡＰＤＵヘッダが付加されたハンドシェイクデータをＳＥ３から受信すると、ＡＰＤＵヘッダに代えてＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダを、ハンドシェイクデータを含むＴＬＳデータに付加してサーバ１へ送信する。一方、上記開始要求により開始されたハンドシェイクにおいて、デバイス制御部２５は、ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダが付加されたＴＬＳデータをサーバ１から受信すると、ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダに代えてＡＰＤＵヘッダを、ＴＬＳデータに含まれるハンドシェイクデータに付加してＳＥ３へ送信する。ここで、デバイス制御部２５は、ＴＣＰヘッダ及びＩＰヘッダに含まれるデータに基づいて解析処理（例えば、Messageの解析処理）を実行しその結果が良好である場合に限り、ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダに代えてＡＰＤＵヘッダを、ＴＬＳデータに含まれるハンドシェイクデータに付加してＳＥ３へ送信するとよい。

ＳＥ３は、Ｉ／Ｆ部３１、ＲＡＭ３２、ＲＯＭ３３、ＮＶＭ（Nonvolatile Memory）３４、及びＣＰＵ３５（コンピュータの一例）等を備えて構成される。Ｉ／Ｆ部３１は、ＤＥ２との間のインターフェースを担う。このインターフェースは、上述したように、ＳＰＩ、Ｉ²Ｃ、またはISO7816インターフェースなどである。ＮＶＭ３４は、例えばフラッシュメモリ等の不揮発性メモリである。なお、ＮＶＭ３４は、「Electrically Erasable Programmable Read-Only Memory」であってもよい。ＲＯＭ３３またはＮＶＭ３４には、オペレーティングシステム（以下、「ＯＳ（Operating System）」という）を構成するソフトウェア、及びアプリケーションプログラムが記憶される。ここで、アプリケーションプログラムは、ＳＥ３においてアプリケーションインスタンス（これを、「アプリケーション」という）の機能を実現するためのプログラムである。アプリケーションは、アプリケーションプログラム等をメモリに展開して実行可能な状態にインストール（搭載）されたモジュールであり、ＣＰＵ３５によってＯＳ上で動作する。なお、アプリケーションは複数搭載されてもよい。

ＳＥ３のＣＰＵ３５は、アプリケーションにしたがって、サーバ１との間で上記ハンドシェイクを実施し、サーバ１との間で暗号通信を行うためのセッションを確立する。ＳＥ３のＣＰＵ３５は、セッションが確立されたサーバ１からの暗号化コマンドを受信（つまり、ＤＥ２を介して受信）した場合、アプリケーションにしたがって、当該セッションの確立において（つまり、ハンドシェイクにおいて）生成された共通鍵を用いて、暗号化コマンドを復号する。そして、ＳＥ３のＣＰＵ３５は、アプリケーションにしたがって、当該復号されたコマンドに応じた処理を実行し、その実行結果を示すレスポンスを生成する。そして、ＳＥ３のＣＰＵ３５は、アプリケーションにしたがって、生成されたレスポンスを上記共通鍵で暗号化することで暗号化レスポンスを生成し、この暗号化レスポンスを、セッションが確立されたサーバ１へ返信（つまり、ＤＥ２を介して返信）する。なお、上記ハンドシェイク、暗号化コマンドの復号、及びレスポンスの暗号化は、専用のアプリケーションにより行われるとよく、この場合、専用のアプリケーション以外のアプリケーションが復号されたコマンドに応じた処理を実行し、その実行結果を示すレスポンスを生成することになる。

［３．通信システムＳの動作］
次に、図７を参照して、通信システムＳの動作について説明する。図７は、通信システムＳの動作例を示すシーケンスである。なお、通信システムＳの動作の前提として、サーバ１には、サーバ１の公開鍵と秘密鍵の鍵ペア、サーバ１の証明書（サーバ証明書）、及び認証局の証明書等が予め記憶され、ＳＥ３のＮＶＭ３４には、ＳＥ３の秘密鍵と公開鍵の鍵ペア、ＳＥ３の証明書（クライアント証明書）、及び認証局の証明書等が予め記憶される。ここで、サーバ１の証明書は、サーバ１の公開鍵及び認証局の電子署名（デジタル署名）が付与された証明書であり、認証局により発行される。ＳＥ３の証明書は、ＳＥ３の公開鍵及び認証局の電子署名が付与された証明書であり、認証局により発行される。認証局の証明書は、認証局の公開鍵が付与された証明書であり、認証局により発行される。

図７において、先ず、ＤＥ２のデバイス制御部２５は、セッション開始要求を示すコマンドＡＰＤＵをＩ／Ｆ部２１を介してＳＥ３へ送信する（ステップＳ１）。セッション開始要求は、サーバ１とＳＥ３との間で暗号通信を行うためのセッションを確立するハンドシェイクを開始させる要求である。次いで、ＳＥ３のＣＰＵ３５は、セッション開始要求を示すコマンドＡＰＤＵをＩ／Ｆ部３１を介して受信すると、サーバ１との間のハンドシェイクを開始し、初期乱数CHを生成して記憶する（ステップＳ２）。次いで、ＳＥ３のＣＰＵ３５は、Client Hello ＡＰＤＵ（図３に示すデータＤ２）を生成し、Ｉ／Ｆ部３１を介してＤＥ２へ送信する（ステップＳ３）。ここで、Client Hello ＡＰＤＵに含まれるハンドシェイクデータ“Client Hello”には、ステップＳ２で生成された初期乱数CHが含まれる。なお、ハンドシェイクデータ“Client Hello”には、プロトコルバージョン、セッションＩＤ、暗号方式、及び圧縮方式等が含まれる場合もある。

次いで、ＤＥ２のデバイス制御部２５は、Client Hello ＡＰＤＵをＩ／Ｆ部２１を介して受信すると、ＴＣＰプロトコルにしたがってサーバ１との間のコネクションを確立（３ウェイハンドシェイク）し、Client Hello ＡＰＤＵ（図３に示すデータＤ２）についてプロトコル変換を行うことでClient Hello Message（図３に示すデータＤ１）を生成する。より具体的には、デバイス制御部２５がClient Hello ＡＰＤＵからハンドシェイクデータ“Client Hello”を抽出し、抽出したハンドシェイクデータ“Client Hello”、そのデータ長、及びそのmsgタイプから構成されるＴＬＳデータを生成し、生成したＴＬＳデータにＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダを付加することでClient Hello Messageを生成する。ここで、msgタイプは、Client Hello ＡＰＤＵのＡＰＤＵヘッダに含まれるＩＮＳと、記憶部２４に記憶されたデータ種別対応情報とに基づいてデバイス制御部２５により特定される。そして、ＤＥ２のデバイス制御部２５は、生成したClient Hello Messageを通信部２３を介してサーバ１へ送信する（ステップＳ４）。

次いで、サーバ１は、Client Hello Messageを受信すると、Client Hello Messageの解析処理（ＩＰヘッダ及びＴＣＰヘッダに含まれるチェックサムによるエラーチェック等を含む）を実行しその結果が良好であれば、Client Hello Messageから初期乱数CHを抽出して記憶すると共に、初期乱数SHを生成して記憶する（ステップＳ５）。次いで、サーバ１は、Server Hello Messageを生成し、生成したServer Hello MessageをＤＥ２へ送信する（ステップＳ６）。ここで、Server Hello Messageに含まれるハンドシェイクデータ“Server Hello”には、ステップＳ５で生成された初期乱数SHが含まれる。なお、ハンドシェイクデータ“Server Hello”には、“Client Hello”と同様、プロトコルバージョン、セッションＩＤ、暗号方式、及び圧縮方式等が含まれる場合もある。さらに、サーバ１は、Server Certificate Messageを生成し、生成したServer Certificate MessageをＤＥ２へ送信する（ステップＳ７）。ここで、Server Certificate Messageに含まれるハンドシェイクデータ“Server Certificate”には、サーバ１の証明書が含まれる。さらに、サーバ１は、Certificate Request Messageを生成し、生成したCertificate Request MessageをＤＥ２へ送信する（ステップＳ８）。さらに、サーバ１は、Server Hello Done Messageを生成し、生成したServer Hello Done MessageをＤＥ２へ送信する（ステップＳ９）。なお、サーバ１は、Server Hello Message、Server Certificate Message、Certificate Request Message、及びServer Hello Done Messageを一つに纏めたMultiple Handshake MessageをＤＥ２へ送信してもよい。

次いで、ＤＥ２のデバイス制御部２５は、Server Hello Messageを通信部２３を介して受信すると、Server Hello Messageの解析処理（ＩＰヘッダ及びＴＣＰヘッダに含まれるチェックサムによるエラーチェック等を含む）を実行しその結果が良好であれば、Server Hello Messageについてプロトコル変換を行うことでServer Hello ＡＰＤＵを生成する。より具体的には、デバイス制御部２５がServer Hello Messageからハンドシェイクデータ“Server Hello”を抽出し、抽出したハンドシェイクデータ“Server Hello”、及びそのデータ長（Ｌｃ）にＡＰＤＵヘッダを付加することでServer HelloＡＰＤＵを生成する。言い換えれば、デバイス制御部２５は、Server Hello MessageからＩＰヘッダ、ＴＣＰヘッダ、及びＴＬＳレコードヘッダを削除して、代わりにＡＰＤＵヘッダをハンドシェイクデータ“Server Hello”に付加する。ここで、ＡＰＤＵヘッダに含まれるＩＮＳは、Server Hello Messageに含まれるmsgタイプと、記憶部２４に記憶されたデータ種別対応情報とに基づいてデバイス制御部２５により特定される。そして、ＤＥ２のデバイス制御部２５は、生成したServer Hello ＡＰＤＵをＩ／Ｆ部２１を介してＳＥ３へ送信する（ステップＳ１０）。

また、ＤＥ２のデバイス制御部２５は、Server Certificate Messageを通信部２３を介して受信すると、Server Certificate Messageの解析処理を実行しその結果が良好であれば、Server Certificate Messageについてプロトコル変換を行うことでServer Certificate ＡＰＤＵを生成し、生成したServer Certificate ＡＰＤＵをＩ／Ｆ部２１を介してＳＥ３へ送信する（ステップＳ１１）。また、ＤＥ２のデバイス制御部２５は、Certificate Request Messageを通信部２３を介して受信すると、Certificate Request Messageの解析処理を実行しその結果が良好であれば、Certificate Request Messageについてプロトコル変換を行うことでCertificate Request ＡＰＤＵを生成し、生成したCertificate Request ＡＰＤＵをＩ／Ｆ部２１を介してＳＥ３へ送信する（ステップＳ１２）。また、ＤＥ２のデバイス制御部２５は、Server Hello Done Messageを通信部２３を介して受信すると、Server Hello Done Messageの解析処理を実行しその結果が良好であれば、Server Hello Done Messageについてプロトコル変換を行うことでServer Hello Done ＡＰＤＵを生成し、生成したServer Hello Done ＡＰＤＵをＩ／Ｆ部２１を介してＳＥ３へ送信する（ステップＳ１３）。

なお、ＤＥ２のデバイス制御部２５は、サーバ３からMultiple Handshake Messageを受信した場合、Server Hello ＡＰＤＵ、Server Certificate ＡＰＤＵ、Certificate Request ＡＰＤＵ、及びServer Hello Done ＡＰＤＵをそれぞれ生成し、それぞれのＡＰＤＵをＳＥ３へ送信することになる。以上のように、各Messageの解析処理（例えば、ＩＰヘッダ及びＴＣＰヘッダの解析処理）をＤＥ２側で実施し、ＳＥ３側で不要なデータを削除することで、ＳＥ３の処理負荷を低減させることができる。また、ＴＣＰ／ＩＰ及びＴＬＳプロトコルにしたがった通信では多くのデータを送受信する必要があるが、これらの多くのデータの処理はＤＥ２で止まるので、ＳＥ３でのデータの処理を最小限にしつつ、ＳＥ３はサーバ１との間でＴＬＳプロトコルによる暗号化通信を行うことができる。

次いで、ＳＥ３のＣＰＵ３５は、Server Hello ＡＰＤＵ、Server Certificate ＡＰＤＵ、Certificate Request ＡＰＤＵ、及びServer Hello Done ＡＰＤＵをＩ／Ｆ部３１を介してそれぞれ受信する。そして、ＳＥ３のＣＰＵ３５は、受信されたServer Hello ＡＰＤＵから初期乱数SHを抽出して記憶する。次いで、ＳＥ３のＣＰＵ３５は、受信されたServer Certificate ＡＰＤＵからサーバ１の証明書を抽出し、当該証明書の検証を行う（ステップＳ１４）。この証明書の検証において、ＳＥ３のＣＰＵ３５は、例えば、認証局の証明書に付与された公開鍵を用いてサーバ１の証明書における認証局の電子署名の署名検証を行い、当該証明書の有効期限等の検査を行う。そして、ＳＥ３のＣＰＵ３５は、サーバ１の証明書の検証結果が良好（検証成功）であれば、Certificate Request ＡＰＤＵに応じて、Client Certificate ＡＰＤＵを生成し、生成したClient Certificate ＡＰＤＵをＩ／Ｆ部３１を介してＤＥ２へ送信する（ステップＳ１５）。ここで、Client Certificate ＡＰＤＵに含まれるハンドシェイクデータ“Client Certificate”には、ＳＥ３の証明書が含まれる。

次いで、ＳＥ３のＣＰＵ３５は、共通鍵の基になる元となる秘密情報（例えば、４６バイトの乱数であるプリマスターシークレット）を生成し、生成した秘密情報をサーバ１の証明書に付与された公開鍵を用いて暗号化する（ステップＳ１６）。次いで、ＳＥ３のＣＰＵ３５は、Client Key Exchange ＡＰＤＵを生成し、生成したClient Key Exchange ＡＰＤＵをＩ／Ｆ部３１を介してＤＥ２へ送信する（ステップＳ１７）。ここで、Client Key Exchange ＡＰＤＵに含まれるハンドシェイクデータ“Client Key Exchange”には、ステップＳ１６で暗号化された秘密情報が含まれる。次いで、ＳＥ３のＣＰＵ３５は、Certificate Verify ＡＰＤＵを生成し、生成したCertificate Verify ＡＰＤＵをＩ／Ｆ部３１を介してＤＥ２へ送信する（ステップＳ１８）。ここで、Certificate Verify ＡＰＤＵに含まれるハンドシェイクデータ“Certificate Verify”には、ＳＥ３の電子署名（ＳＥ３の秘密鍵で署名）が付与された署名データが含まれる。次いで、ＳＥ３のＣＰＵ３５は、上記生成された秘密情報と、上記生成された初期乱数CHと、Server Hello ＡＰＤＵから抽出された初期乱数SHとに基づいて共通鍵を生成して記憶する（ステップＳ１９）。なお、この例では、共通鍵の交換方式としてRSA方式を用いているが、DHE方式やECDHE方式が用いられてもよく、この場合、“Client Key Exchange”と“Server Key Exchange”が用いられてサーバ１とＳＥ３間で鍵交換が実施される。

次いで、ＤＥ２のデバイス制御部２５は、Client Certificate ＡＰＤＵ、Client Key Exchange ＡＰＤＵ、及びCertificate Verify ＡＰＤＵをＩ／Ｆ部２１を介してそれぞれ受信すると、それぞれのＡＰＤＵについてプロトコル変換（Client Hello ＡＰＤＵと同じようにプロトコル変換）を行うことで、Client Certificate Message、Client Key Exchange Message、及びCertificate Verify Messageを生成する。そして、ＤＥ２のデバイス制御部２５は、生成したClient Certificate Message、Client Key Exchange Message、及びCertificate Verify Messageを通信部２３を介してサーバ１へ送信する（ステップＳ２０～Ｓ２２）。

次いで、サーバ１は、Client Certificate Message、Client Key Exchange Message、及びCertificate Verify Messageをそれぞれ受信する。そして、サーバ１は、受信されたそれぞれのMessageの解析処理を実行しその結果が良好であれば、Client Certificate MessageからＳＥ３の証明書を抽出し、当該証明書の検証を行う（ステップＳ２３）。この証明書の検証方法は、ステップＳ１４における検証方法と同様である。そして、サーバ１は、ＳＥ３の証明書の検証結果が良好であれば、Certificate Verify Messageから署名データを抽出し、ＳＥ３の証明書に付与された公開鍵を用いて当該署名データにおけるＳＥ３の電子署名の署名検証を行う（ステップＳ２４）。そして、サーバ１は、ＳＥ３の証明書の検証結果が良好であれば、Client Key Exchange Messageから秘密情報を抽出し、抽出した秘密情報と、上記生成された初期乱数SHと、Client Hello Messageから抽出された初期乱数CHとに基づいて共通鍵を生成（ステップＳ１９と同様の方法で生成）して記憶する（ステップＳ２５）。こうして、サーバ１とＳＥ３は、同じ共通鍵と共有することになる。

次いで、サーバ１は、Server Finished Messageを生成し、生成したServer Finished MessageをＤＥ２へ送信する（ステップＳ２６）。ここで、Server Finished Messageに含まれるハンドシェイクデータ“Server Finished”には、終了検証データが含まれる。次いで、ＤＥ２のデバイス制御部２５は、Server Finished Messageを通信部２３を介して受信すると、Server Finished Messageについてプロトコル変換を行うことでServer Finished ＡＰＤＵを生成し、生成したServer Finished ＡＰＤＵをＩ／Ｆ部２１を介してＳＥ３へ送信する（ステップＳ２７）。なお、Server Finished Messageの送信前に、サーバ１から、無暗号通信の終了を示すChange Cipher Spec Messageが送信されてもよい。次いで、ＳＥ３のＣＰＵ３５は、Server Finished ＡＰＤＵをＩ／Ｆ部３１を介して受信すると、Client Finished ＡＰＤＵを生成し、生成したClient Finished ＡＰＤＵをＩ／Ｆ部３１を介してＤＥ２へ送信する（ステップＳ２８）。ここで、Client Finished ＡＰＤＵに含まれるハンドシェイクデータ“Client Finished”には、終了検証データが含まれる。なお、Client Finished ＡＰＤＵの送信前に、ＳＥ３から、無暗号通信の終了を示すChange Cipher Spec ＡＰＤＵが送信されてもよい。ＤＥ２のデバイス制御部２５は、Client Finished ＡＰＤＵをＩ／Ｆ部２１を介して受信すると、Client Finished ＡＰＤＵについてプロトコル変換を行うことでClient Finished Messageを生成し、生成したClient Finished Messageを通信部２３を介してサーバ１へ送信する（ステップＳ２９）。

以上のように、サーバ１とＳＥ３との間でＤＥ２を介してハンドシェイクが実施され、サーバ１とＳＥ３との間で暗号通信を行うためのセッションが確立すると、暗号化通信が行われることになる。まず、サーバ１は、暗号化コマンド Message（図４に示すデータＤ３）を生成し、生成した暗号化コマンドMessageをＤＥ２へ送信する（ステップＳ３０）。ここで、暗号化コマンド Messageに含まれるアプリケーションデータには、ステップＳ２５で生成された共通鍵により暗号化された暗号化コマンドが含まれる。次いで、ＤＥ２のデバイス制御部２５は、暗号化コマンド Messageを通信部２３を介して受信すると、暗号化コマンド Messageの解析処理を実行しその結果が良好であれば、暗号化コマンドMessageについてプロトコル変換を行うことで暗号化コマンドＡＰＤＵ（図４に示すデータＤ４）を生成する。より具体的には、デバイス制御部２５が暗号化コマンド Messageから暗号化コマンドを抽出し、抽出した暗号化コマンド、及びそのデータ長（Ｌｃ）にＡＰＤＵヘッダを付加することで暗号化コマンドＡＰＤＵを生成する。言い換えれば、デバイス制御部２５は、暗号化コマンド MessageからＩＰヘッダ、ＴＣＰヘッダ、及びＴＬＳレコードヘッダを削除して、代わりにＡＰＤＵヘッダを暗号化コマンドに付加する。そして、ＤＥ２のデバイス制御部２５は、生成した暗号化コマンドＡＰＤＵをＩ／Ｆ部２１を介してＳＥ３へ送信する（ステップＳ３１）。このように、ＤＥ２は、暗号化コマンドをハンドリングするだけであり、暗号通信を解読することはできない。そのため、通信情報は、セキュアに保たれると同時に、ＤＥ２にＴＬＳ機能を搭載する必要がないという利点がある。

次いで、ＳＥ３のＣＰＵ３５は、暗号化コマンドＡＰＤＵをＩ／Ｆ部３１を介して受信すると、当該暗号化コマンドＡＰＤＵに含まれる暗号化コマンドをステップＳ１９で生成された共通鍵により復号する（ステップＳ３２）。次いで、ＳＥ３のＣＰＵ３５は、当該コマンドＡＰＤＵに応じた処理を実行し（ステップＳ３３）、その実行結果を示すレスポンスＡＰＤＵ（図５に示すデータＤ６）を生成する。次いで、ＳＥ３のＣＰＵ３５は、レスポンスＡＰＤＵを受信すると、当該レスポンスＡＰＤＵをステップＳ１９で生成された共通鍵により暗号化する（ステップＳ３４）ことで暗号化レスポンスを生成する。次いで、ＳＥ３のＣＰＵ３５は、生成した暗号化レスポンスを含む暗号化レスポンスＡＰＤＵ（図５に示すデータＤ７）を生成し、生成した暗号化レスポンスＡＰＤＵをＩ／Ｆ部３１を介してＤＥ２へ送信する（ステップＳ３５）。

次いで、ＤＥ２のデバイス制御部２５は、暗号化レスポンスＡＰＤＵをＩ／Ｆ部２１を介して受信すると、暗号化レスポンスＡＰＤＵについてプロトコル変換を行うことで暗号化レスポンスMessage（図５に示すデータＤ８）を生成する。より具体的には、デバイス制御部２５が暗号化レスポンスＡＰＤＵから暗号化レスポンスを抽出し、抽出した暗号化レスポンスにＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダを付加することで暗号化レスポンスMessageを生成する。そして、ＤＥ２のデバイス制御部２５は、生成した暗号化レスポンスMessageを通信部２３を介してサーバ１へ送信する（ステップＳ３６）。サーバ１は、暗号化レスポンスMessageを受信すると、ステップＳ２５で生成された共通鍵により暗号化レスポンスMessageに含まれる暗号化レスポンスを復号する。そして、サーバ１は、復号されたレスポンスに応じて、次の暗号化コマンドMessageを生成してＤＥ２へ送信する（ステップＳ３０）。こうして上記と同じ流れでステップＳ３１以降の処理が行われる。これにより、例えばコマンドが“READ BINARY”である場合、センサー４により取得されＮＶＭ３４に記憶（蓄積）されたデータを安全にサーバ１へ送信することができる。

以上説明したように、上記実施形態によれば、ＤＥ２は、セッション開始要求によりサーバ１とＳＥ３との間で暗号通信を行うためのセッションを確立するハンドシェイクを開始させ、開始されたハンドシェイクにおいて、ＤＥ２は、ＡＰＤＵヘッダが付加されたハンドシェイクデータをＳＥ３から受信すると、ＡＰＤＵヘッダに代えてＴＬＳレコードヘッダ等をＴＬＳデータに付加してサーバ１へ送信する一方、ＴＬＳレコードヘッダ等が付加されたＴＬＳデータをサーバ１から受信すると、ＴＬＳレコードヘッダ等に代えてＡＰＤＵヘッダをハンドシェイクデータに付加してＳＥ３へ送信するように構成したので、ＳＥ３とサーバ１との間のハンドシェイクの迅速化を図ることができる。また、ＳＥ３がサーバ１との間でハンドシェイクに係る端末Ｔ側の全ての処理（乱数CH生成、証明書検証、秘密情報生成及び暗号化、及び共通鍵生成）を実施するように構成したので、ＤＥ２がハンドシェイクの一部を実施することがない。つまり、ＤＥ２は、ＳＥ３とサーバ１との間でプロトコル変換及びデータ転送だけを実施するので、中間者攻撃を防ぎ、セキュリティを向上することができる。よって、高速かつ安全な暗号化通信を実現させることができる。

［３．通信システムＳの応用例］
次に、図８～図１０を参照して、通信システムＳの応用例について説明する。

（応用例１）
応用例１では、ＤＥ２がアクセス可能なサーバが複数存在するケースを想定する。図８は、応用例に係る通信システムＳの概要構成例を示す図であり、図９は、ＤＥ２がサーバからデータを受信したときの処理の一例を示すフローチャートである。図８に示すように、応用例に係る通信システムＳは、サーバ１ａ～サーバ１ｃ、ＤＥ２、及びＳＥ３等を含んで構成される。例えば、サーバ１ａは、機密性の高いデータ（重要な情報を含む）を配信するサーバであり、サーバ１ｂ及びサーバ１ｃは、機密性の高くないデータを配信するサーバであるとする。サーバ１ａの例として、発行データ配信サーバが挙げられ、サーバ１ｂの例として、利用データ配信サーバが挙げられ、サーバ１ｃの例として、時刻データ配信サーバが挙げられる。

ＤＥ２のデバイス制御部２５は、上記ステップＳ１を実行する前に、アクセス先のサーバが機密性の高いデータを配信するサーバであるか否かを判定する。例えば機密性の高いデータを配信するサーバの情報（例えばＵＲＬやＩＰアドレス）を登録するリストを予め取得しておき、このリストに基づいて、アクセス先のサーバが機密性の高いデータを配信するサーバであるか否かが判定されるとよい。例えば、アクセス先のサーバがサーバ１ａである場合、ＤＥ２のデバイス制御部２５は、当該アクセス先のサーバ１ａが機密性の高いデータを配信するサーバであると判定し、上記セッション開始要求をＳＥ３へ送信することでサーバ１ａとＳＥ３との間で暗号通信を行うためのセッションを確立するハンドシェイクを開始させる。一方、例えば、アクセス先のサーバがサーバ１ｂまたは１ｃである場合、ＤＥ２のデバイス制御部２５は、当該アクセス先のサーバ１ｂまたは１ｃが機密性の高くないデータを配信するサーバであると判定し、上記セッション開始要求を送信することなく、ＤＥ２とサーバ１ｂまたは１ｃとの間で通信を行うことになる。

そして、図９に示す処理は、例えば、サーバ１ａ～サーバ１ｃの何れか１のサーバからデータが受信され、当該データに基づいて実行された解析処理の結果が良好である場合に開始される。図９に示す処理が開始されると、ＤＥ２のデバイス制御部２５は、受信されたデータがサーバ１ａからのデータ（図４に示すデータＤ３）であるか否かを判定する（ステップＳ５１）。サーバ１ａからのデータであるか否かは、例えば、受信されたデータ中（ＩＰヘッダ中）の送信元ＩＰアドレスから判定される。ＤＥ２のデバイス制御部２５は、受信されたデータがサーバ１ａからのデータでないと判定した場合（ステップＳ５１：ＮＯ）、ステップＳ５２へ進む。一方、ＤＥ２のデバイス制御部２５は、受信されたデータがサーバ１ａからのデータであると判定した場合（ステップＳ５１：ＹＥＳ）、ステップＳ５５へ進む。

ステップＳ５２では、ＤＥ２のデバイス制御部２５は、受信されたデータがサーバ１ｂまたは１ｃからのデータであるか否かを判定する。ＤＥ２のデバイス制御部２５は、受信されたデータがサーバ１ｂまたは１ｃからのデータでないと判定した場合（ステップＳ５２：ＮＯ）、受信されたデータを破棄する（ステップＳ５３）。一方、ＤＥ２のデバイス制御部２５は、受信されたデータがサーバ１ｂまたは１ｃからのデータであると判定した場合（ステップＳ５２：ＹＥＳ）、当該データに含まれるコマンドに応じた処理（例えば、ＤＥ２に搭載されるアプリケーションにデータを渡す）を実行する（ステップＳ５４）。ステップＳ５５では、ＤＥ２のデバイス制御部２５は、受信されたデータについて上述したプロトコル変換を行うことで生成したデータ（図４に示すデータＤ４）をＩ／Ｆ部２１を介してＳＥ３へ送信する。

以上説明したように、応用例１によれば、ＤＥ２がアクセス可能なサーバが複数存在する場合、ＤＥ２が通信するサーバに応じて上記ハンドシェイクを実施させるかどうかを判断するように構成したので、セキュリティを維持しつつ、ＳＥ３の処理負荷を低減させることができる。

（応用例２）
応用例２では、ＴＣＰ／ＩＰプロトコルとＳＥ用プロトコルとで１度に（つまり、１回で）送受信可能なデータ長が異なるケースを想定する。図１０（Ａ）は、ＤＥ２がＳＥ３へデータを送信するとき処理の一例を示すフローチャートであり、図１０（Ｂ）は、ＤＥ２がサーバ１（またはサーバ１ａ）へデータを送信するときの処理の一例を示すフローチャートである。例えば、ＴＣＰ／ＩＰプロトコルで１度に送受信可能なデータ長が４０９６バイトであるとし、ＳＥ用プロトコルで１度に送受信可能なデータ長が２５６バイトであるとする。

図１０（Ａ）に示す処理は、ＳＥ３との間で暗号通信を行うためのセッションが確立されたサーバ１（またはサーバ１ａ）からデータが受信され、上述したプロトコル変換が行われたときに開始される。図１０（Ａ）に示す処理が開始されると、ＤＥ２のデバイス制御部２５は、ＳＥ３へ送信すべきデータの残りデータ長が所定長（例えば、２５６バイト）より大きいか否かを判定する（ステップＳ６１）。ＤＥ２のデバイス制御部２５は、ＳＥ３へ送信すべきデータの残りデータ長が所定長より大きくないと判定した場合（ステップＳ６１：ＮＯ）、当該データ（図４に示すデータＤ４）をＩ／Ｆ部２１を介してＳＥ３へ送信する（ステップＳ６２）。一方、ＤＥ２のデバイス制御部２５は、ＳＥ３へ送信すべきデータの残りデータ長が所定長より大きいと判定した場合（ステップＳ６１：ＹＥＳ）、当該データを分割し（ステップＳ６３）、分割されたデータをＩ／Ｆ部２１を介してＳＥ３へ送信する（ステップＳ６４）。次いで、ＤＥ２のデバイス制御部２５は、残りデータ長を減算し（ステップＳ６５）、ステップＳ６１に戻る。

図４に示すデータＤ４を例にとると、分割対象は暗号化コマンドであり、ＡＰＤＵヘッダ及びＬｃを付加したデータのデータ長が２５６バイト以下になるように暗号化コマンドが分割される（このときＬｃが参照される）。例えば、ＡＰＤＵヘッダとＬｃとの合計のデータ長が５バイトであるとすると、暗号化コマンドから２５１バイト分のデータが分割により抽出され、当該抽出されたデータにＡＰＤＵヘッダとＬｃが付加されたデータ（つまり、２５６バイトのデータ）がＳＥ３へ送信される。これにより、残りデータ長から２５１バイトが減算され、次に送信すべきデータの残りデータ長は、分割された暗号化コマンドのうち未送信のデータにＡＰＤＵヘッダ及びＬｃが付加されたデータとなる。そして、次に続くステップＳ６１において、次に送信すべきデータの残りデータ長が２５６バイトより大きい場合、上記と同様、ステップＳ６３～Ｓ６５の処理が行われる一方、次に送信すべきデータの残りデータ長が２５６バイトより大きくない場合、ステップＳ６２の処理が行われる。例えば、ＳＥ３へ送信すべきデータが５００バイトであるとすると、当該データは２回に分けてＳＥ３へ送信されることになる。なお、ステップＳ６２で送信されるデータに含まれるＡＰＤＵヘッダ中のＰ２は後続データの無を示す値（例えば、0x00）に設定される一方、ステップＳ６４で送信されるデータに含まれるＡＰＤＵヘッダ中のＰ２は後続データの有を示す値（例えば、0x01）に設定される。

一方、図１０（Ｂ）に示す処理は、サーバ１（またはサーバ１ａ）との間で暗号通信を行うためのセッションが確立されたＳＥ３からデータが受信されたときに開始される。なお、図１０（Ｂ）に示す処理は、ＳＥ３においてデータが分割され、分割されたデータが複数回に分けてＤＥ２へ送信されることに対応可能な処理である。図１０（Ｂ）に示す処理が開始されると、ＤＥ２のデバイス制御部２５は、サーバ１（またはサーバ１ａ）へ送信すべきデータの残りがあるか（言い換えれば、後から次のデータが送信されてくるか）否かを判定する（ステップＳ７１）。ＤＥ２のデバイス制御部２５は、サーバ１（またはサーバ１ａ）へ送信すべきデータの残りがないと判定した場合（ステップＳ７１：ＮＯ）、ＳＥ３から受信された全データ（連結されたデータを含む）について上述したプロトコル変換を行うことで生成したデータ（図５に示すデータＤ８）を通信部２３を介してサーバ１へ送信する（ステップＳ７２）。一方、ＤＥ２のデバイス制御部２５は、サーバ１（またはサーバ１ａ）へ送信すべきデータの残りがあると判定した場合（ステップＳ７１：ＹＥＳ）、後から送信されてきた次のデータを受信する（ステップＳ７３）。次いで、ＤＥ２のデバイス制御部２５は、当該受信された次のデータを、先に受信されたデータに連結し（ステップＳ７４）、ステップＳ７１に戻る。こうして、ステップＳ７１でデータの残りがないと判定されるまで、データの連結が行われる。

以上説明したように、応用例２によれば、ＤＥ２はサーバ１（またはサーバ１ａ）から受信されたデータのデータ長に応じて、当該データを分割して複数回に分けてＳＥ３へ送信するように構成したので、ＴＣＰ／ＩＰプロトコルとＳＥ用プロトコルとで１度に送受信可能なデータ長が異なるケースに柔軟に対応することができる。また、ＤＥ２は、ＳＥ３から複数回に亘って受信されたデータを連結してサーバ１（またはサーバ１ａ）へ送信するように構成したので、サーバ１（またはサーバ１ａ）へのデータ送信の効率化を図ることができる。

１，１ａ～１ｃサーバ
２ＤＥ
３ＳＥ
４センサー
２１，２２Ｉ／Ｆ部
２３通信部
２４記憶部
２５デバイス制御部
３１Ｉ／Ｆ部
３２ＲＡＭ
３３ＲＯＭ
３４ＮＶＭ
３５ＣＰＵ
Ｔ端末
ＮＴネットワーク

Claims

サーバとセキュアエレメントとの間の通信を仲介する通信デバイスであって、
前記サーバと前記セキュアエレメントとの間で暗号通信を行うためのセッションを確立するハンドシェイクを開始させる開始要求を前記セキュアエレメントへ送信する第１送信手段と、
前記開始要求により開始された前記ハンドシェイクにおいて、ＡＰＤＵ（Application Protocol Data Unit）ヘッダが付加されたハンドシェイクデータを前記セキュアエレメントから受信すると、前記ＡＰＤＵヘッダに代えてＴＬＳ（Transport Layer Security）レコードヘッダ、ＴＣＰ（Transimission Control Protocol）ヘッダ、及びＩＰ（Internet protocol）ヘッダを、前記ハンドシェイクデータを含むＴＬＳデータに付加して前記サーバへ送信する第２送信手段と、
前記開始要求により開始された前記ハンドシェイクにおいて、ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダが付加されたＴＬＳデータを前記サーバから受信すると、前記ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダに代えてＡＰＤＵヘッダを、前記ＴＬＳデータに含まれるハンドシェイクデータに付加して前記セキュアエレメントへ送信する第３送信手段と、
を備えることを特徴とする通信デバイス。
前記第３送信手段は、前記ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダが付加されたＴＬＳデータを前記サーバから受信すると、前記ＴＣＰヘッダ及び前記ＩＰヘッダに含まれるデータに基づいて解析処理を実行しその結果が良好である場合に限り、前記ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダに代えてＡＰＤＵヘッダを、前記ＴＬＳデータに含まれるハンドシェイクデータに付加して前記セキュアエレメントへ送信することを特徴とする請求項１に記載の通信デバイス。
前記ハンドシェイクデータの種別を示すmsgタイプと、当該ハンドシェイクデータの種別毎に割り当てられたＩＮＳとの対応関係を示すデータ種別対応情報を記憶する記憶手段を更に備え、
前記第２送信手段は、前記ＡＰＤＵヘッダが付加されたハンドシェイクデータを前記セキュアエレメントから受信すると、当該ＡＰＤＵヘッダに含まれるＩＮＳと、前記記憶手段に記憶されたデータ種別対応情報とに基づいて前記msgタイプを特定し、特定したmsgタイプ及び前記ハンドシェイクデータを含むＴＬＳデータに、前記ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダを付加して前記サーバへ送信することを特徴とする請求項１または２に記載の通信デバイス。
前記ハンドシェイクデータの種別を示すmsgタイプと、当該ハンドシェイクデータの種別毎に割り当てられたＩＮＳとの対応関係を示すデータ種別対応情報を記憶する記憶手段を備え、
前記第３送信手段は、前記ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダが付加されたＴＬＳデータを前記サーバから受信すると、当該ＴＬＳデータに含まれるmsgタイプと、前記記憶手段に記憶されたデータ種別対応情報とに基づいて前記ＩＮＳを特定し、当該特定したＩＮＳを含むＡＰＤＵヘッダを前記ハンドシェイクデータに付加して前記セキュアエレメントへ送信することを特徴とする請求項１または２に記載の通信デバイス。
前記サーバが機密性の高いデータを配信するサーバであるか否かを判定する判定手段を更に備え、
前記判定手段により前記サーバが機密性の高いデータを配信するサーバであると判定された場合、前記第１送信手段は、前記開始要求を前記セキュアエレメントへ送信することを特徴とする請求項１乃至４の何れか１項に記載の通信デバイス。
前記セキュアエレメントとの間で暗号通信を行うためのセッションが確立された前記サーバから受信されたデータのデータ長に応じて、当該データを分割して複数回に分けて前記セキュアエレメントへ送信する第４送信手段を更に備えることを特徴とする請求項１乃至５の何れか１項に記載の通信デバイス。
前記セキュアエレメントから複数回に亘って受信されたデータを連結して当該セキュアエレメントとの間で暗号通信を行うためのセッションが確立された前記サーバへ送信する第５送信手段を更に備えることを特徴とする請求項１乃至６の何れか１項に記載の通信デバイス。
サーバとセキュアエレメントとの間の通信を仲介する通信デバイスに含まれるコンピュータにより実行されるデータ送信方法であって、
前記サーバと前記セキュアエレメントとの間で暗号通信を行うためのセッションを確立するハンドシェイクを開始させる開始要求を前記セキュアエレメントへ送信するステップと、
前記開始要求により開始された前記ハンドシェイクにおいて、ＡＰＤＵヘッダが付加されたハンドシェイクデータを前記セキュアエレメントから受信すると、前記ＡＰＤＵヘッダに代えてＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダを、前記ハンドシェイクデータを含むＴＬＳデータに付加して前記サーバへ送信するステップと、
前記開始要求により開始された前記ハンドシェイクにおいて、ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダが付加されたＴＬＳデータを前記サーバから受信すると、前記ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダに代えてＡＰＤＵヘッダを、前記ＴＬＳデータに含まれるハンドシェイクデータに付加して前記セキュアエレメントへ送信するステップと、
を含むことを特徴とするデータ送信方法。
サーバとセキュアエレメントとの間の通信を仲介する通信デバイスに含まれるコンピュータを、
前記サーバと前記セキュアエレメントとの間で暗号通信を行うためのセッションを確立するハンドシェイクを開始させる開始要求を前記セキュアエレメントへ送信する第１送信手段と、
前記開始要求により開始された前記ハンドシェイクにおいて、ＡＰＤＵヘッダが付加されたハンドシェイクデータを前記セキュアエレメントから受信すると、前記ＡＰＤＵヘッダに代えてＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダを、前記ハンドシェイクデータを含むＴＬＳデータに付加して前記サーバへ送信する第２送信手段と、
前記開始要求により開始された前記ハンドシェイクにおいて、ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダが付加されたＴＬＳデータを前記サーバから受信すると、前記ＴＬＳレコードヘッダ、ＴＣＰヘッダ、及びＩＰヘッダに代えてＡＰＤＵヘッダを、前記ＴＬＳデータに含まれるハンドシェイクデータに付加して前記セキュアエレメントへ送信する第３送信手段として機能させることを特徴とするプログラム。