JP6965790B2 - 電子情報記憶媒体、コマンド処理方法、及びプログラム - Google Patents

Description

サーバと通信を行うＳＥ（Secure Element）の技術分野に関する。

物をインターネットに繋げるＩｏＴ（Internet of Things）製品は、センサーからの情報取得や、装置の遠隔管理などを目的としている。ＩｏＴ製品にセキュリティが要求される場合、ＩｏＴ製品に組み込まれるＳＥにて鍵などの秘密情報を管理する必要がある。このとき、ＳＥとサーバとの間で安全な通信経路を確立し、秘密情報の送受信を行う必要がある。特許文献１には、鍵情報を保持するセキュリティチップとサーバとの間で安全な通信経路を確立して秘密情報を送受信するシステムが開示されている。

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

ところで、インターネット上における暗号化通信として、例えばＳＳＬ（Secure Sockets Layer）／ＴＬＳ（Transport Layer Security）プロトコル（以下、ＴＬＳプロトコルという）による暗号化通信が知られているが、これは、ブラウザなど、機能や性能が豊富なアプリケーションが搭載されるＰＣとサーバとの通信で利用されることが主であり、機能や性能に制限のあるＳＥとサーバとの通信に利用されていなかった。ＳＥにＴＬＳプロトコルによる暗号化通信をサポートさせることを想定した場合、ＳＥに搭載される一部のアプリケーションにのみＴＬＳ機能（ＴＬＳプロトコルによる暗号化通信機能）を持たせることが考えられる。しかしながら、この場合、ＴＬＳ機能を持たないアプリケーションではＴＬＳプロトコルによる暗号化通信ができないという問題がある。一方、ＳＥに搭載される全てのアプリケーションにＴＬＳ機能を持たせる場合、メモリが不足するという問題が生じる。

そこで、本発明は、このような点等に鑑みてなされたものであり、メモリ不足の問題を解消しつつ、ＴＬＳプロトコル等による暗号化通信を実現することが可能な電子情報記憶媒体、コマンド処理方法、及びプログラムを提供することを目的とする。

上記課題を解決するために、請求項１に記載の発明は、オペレーティングシステム、及び複数のアプリケーションを搭載し、サーバと通信を行う電子情報記憶媒体であって、前記複数のアプリケーションのうち何れか第１のアプリケーションは、前記サーバとの間で暗号通信を行うためのセッションを確立するセッション確立部と、前記セッションが確立された前記サーバからの暗号化されたコマンドを受信した場合、前記セッションの確立において生成されたセッション鍵を用いて、前記暗号化されたコマンドを復号するコマンド復号部と、前記コマンド復号部により復号されたコマンドを、前記第１のアプリケーション以外の第２のアプリケーションへ送信するコマンド送信部と、を備えることを特徴とする。

請求項２に記載の発明は、請求項１に記載の電子情報記憶媒体において、前記サーバからの前記暗号化されたコマンドは、前記オペレーティングシステムを経由して前記第１のアプリケーションへ送信され、前記第１のアプリケーションの前記コマンド復号部により復号されたコマンドは、前記オペレーティングシステムを経由して前記第２のアプリケーションへ送信されることを特徴とする。

請求項３に記載の発明は、請求項２に記載の電子情報記憶媒体において、前記オペレーティングシステムは、外部からのコマンドが暗号化されているか否かを判定し、暗号化されている場合には前記第１のアプリケーションへ送信し、暗号化されていない場合には前記第２のアプリケーションへ送信することを特徴とする。

請求項４に記載の発明は、請求項１乃至３の何れか一項に記載の電子情報記憶媒体において、前記第２のアプリケーションからの前記復号されたコマンドに対するレスポンスを受信した場合、当該レスポンスを暗号化するレスポンス暗号化部と、前記レスポンス暗号化部により暗号化されたレスポンスを、前記セッションが確立された前記サーバへ返信するレスポンス返信部と、を更に備えることを特徴とする。

請求項５に記載の発明は、請求項４に記載の電子情報記憶媒体において、前記第２のアプリケーションからの前記レスポンスは、前記オペレーティングシステムを経由して前記第１のアプリケーションへ送信され、前記第１のアプリケーションの前記レスポンス暗号化部により暗号化されたレスポンスは、前記オペレーティングシステムを経由して前記サーバへ返信されることを特徴とする。

請求項６に記載の発明は、請求項１乃至５の何れか一項に記載の電子情報記憶媒体において、前記暗号通信は、ＴＬＳ(Transport Layer Security)プロトコルにしたがった通信であることを特徴とする。

請求項７に記載の発明は、オペレーティングシステム、及び複数のアプリケーションを搭載し、サーバと通信を行う電子情報記憶媒体により実行されるコマンド処理方法であって、前記複数のアプリケーションのうち何れか第１のアプリケーションが、前記サーバとの間で暗号通信を行うためのセッションを確立するステップと、前記第１のアプリケーションが、前記セッションが確立された前記サーバからの暗号化されたコマンドを受信した場合、前記セッションの確立において生成されたセッション鍵を用いて、前記暗号化されたコマンドを復号するステップと、前記第１のアプリケーションが、前記復号されたコマンドを、前記第１のアプリケーション以外の第２のアプリケーションへ送信するステップと、を含むことを特徴とする。

請求項８に記載の発明は、オペレーティングシステム、及び複数のアプリケーションを搭載し、サーバと通信を行う電子情報記憶媒体に含まれるコンピュータに処理を実行させるアプリケーションの機能を実現するためのプログラムであって、前記コンピュータに、前記サーバとの間で暗号通信を行うためのセッションを確立させ、前記セッションが確立された前記サーバからの暗号化されたコマンドを受信した場合、前記セッションの確立において生成されたセッション鍵を用いて、前記暗号化されたコマンドを復号させ、前記復号されたコマンドを、他のアプリケーションへ送信させることを特徴とする。

本発明によれば、メモリ不足の問題を解消しつつ、ＴＬＳプロトコル等による暗号化通信を実現することができる。

本実施形態に係る通信システムＳの概要構成例を示す図である。 本実施形態に係る通信システムＳにおける通信プロトコルを階層別に示す概念図である。 ＴＬＳハンドシェイク層でハンドシェイクプロトコルが用いられる場合のプロトコル変換の一例を示す概念図である。 ＴＬＳハンドシェイク層でアプリケーションデータプロトコルが用いられる場合のプロトコル変換の一例を示す概念図である。 ＴＬＳハンドシェイク層でアプリケーションデータプロトコルが用いられる場合のプロトコル変換の一例を示す概念図である。 端末Ｔのハードウェア構成例を示す図である。 ＳＥ３のソフトウェア構成例を示す図である。 （Ａ）は、Dispatcherを使用しない場合における、暗号化されていないコマンドの流れを示す図であり、（Ｂ）は、Dispatcherを使用しない場合における、暗号化コマンドの流れを示す図である。 （Ａ）は、Dispatcherを使用する場合における、暗号化されていないコマンドの流れを示す図であり、（Ｂ）は、Dispatcherを使用する場合における、暗号化コマンドの流れを示す図である。 （Ａ）は、Dispatcherを使用しない場合における、暗号化されないレスポンスの流れを示す図であり、（Ｂ）は、Dispatcherを使用しない場合における、暗号化されるレスポンスの流れを示す図である。 （Ａ）は、Dispatcherを使用する場合における、暗号化されないレスポンスの流れを示す図であり、（Ｂ）は、Dispatcherを使用する場合における、暗号化されるレスポンスの流れを示す図である。 通信システムＳにおいてサーバ１とＳＥ３との間でセッションが確立されるまでのやりとりを示すシーケンスである。 サーバ１とＳＥ３との間でセッションが確立された後のやりとりを示すシーケンスである。

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

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

図１に示すように、通信システムＳは、サーバ１、ＤＥ（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インターフェースなどである。Ｉ／Ｆ部２２は、センサー４との間のインターフェースを担う。センサー４は、端末Ｔから所定の近傍範囲（例えば、数ｍの範囲）内の状態（例えば、温度、湿度、気圧、照度、水位、騒音など）を例えば定期的に検知する。センサー４により検知、取得された状態を示す情報は、デバイス制御部２５によりＩ／Ｆ部２１を介してＳＥ３に送信され、ＳＥ３によりＮＶＭ３４に記憶（蓄積）される。

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

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

図７は、ＳＥ３のソフトウェア構成例を示す図である。図７に示すように、ＳＥ３では、ＯＳ上で複数のアプリケーションが動作するように構成されている。図７の例では、ＯＳは、効率の良い処理を実現するためのDispatcher（ディスパッチャー）を備えているが、Dispatcherを備えない場合もある。図７の例では、App(1)、App(2)、App(3)、TLS Manager、及びＩＳＤ（Issuer Security Domain）はいずれもアプリケーションである。ここで、TLS Managerは、本発明における第１のアプリケーションの一例であり、ＴＬＳ機能（本発明におけるセッション確立部、コマンド復号部、コマンド送信部、レスポンス暗号化部、及びレスポンス返信部）を有する。App(1)、App(2)、App(3)、及びＩＳＤは、本発明における第２のアプリケーションの一例であり、ＴＬＳ機能を有さない。なお、App(3)は、TLS Managerの利用を必須とし、外部からの暗号化されてないコマンドを受信しないように構成される。ＩＳＤは、例えば事業者がＳＥ３に搭載されたアプリケーションによるサービスを提供する上で必要となるＳＥ３内のコンテンツを管理するための機能を提供する管理アプリケーションである。例えば、ＩＳＤの配下にApp(1)が属する場合、App(1)はＩＳＤのセキュリティポリシーが適応される。

TLS Managerは、サーバ１との間で上記ハンドシェイクを実施し、サーバ１との間で暗号通信を行うためのセッションを確立する。そして、TLS Managerは、セッションが確立されたサーバ１からの暗号化コマンドを受信（つまり、ＤＥ２を介して受信）した場合、当該セッションの確立において（つまり、ハンドシェイクにおいて）生成された共通鍵を用いて、暗号化コマンドを復号し、当該復号されたコマンドを、TLS Manager以外のApp(1)、App(2)、App(3)、及びＩＳＤへ送信する。このように暗号通信専用のTLS Managerを設けることで、メモリ不足の問題を解消しつつ、アプリケーションに依存しない暗号化通信を実現することができる。

図８（Ａ）は、Dispatcherを使用しない場合における、暗号化されていないコマンドの流れを示す図であり、図８（Ｂ）は、Dispatcherを使用しない場合における、暗号化コマンドの流れを示す図である。図８（Ａ）に示すように、外部からの暗号化されてないコマンド（平文）は、ＯＳを経由してApp(1)、App(2)、及びＩＳＤへ送信されるが、App(3)には送信されない。一方、図８（Ｂ）に示すように、外部からの暗号化コマンド（暗号文）は、ＯＳを経由してTLS Managerへ送信され復号された後に、App(1)、App(2)、App(3)、及びＩＳＤへ送信される。

図９（Ａ）は、Dispatcherを使用する場合における、暗号化されていないコマンドの流れを示す図であり、図９（Ｂ）は、Dispatcherを使用する場合における、暗号化コマンドの流れを示す図である。図９（Ａ）に示すように、外部からの暗号化されてないコマンド（平文）は、Dispatcherを経由してApp(1)、App(2)、及びＩＳＤへ送信されるが、App(3)には送信されない。一方、図９（Ｂ）に示すように、外部からの暗号化コマンド（暗号文）は、Dispatcherを経由してTLS Managerへ送信され復号される。その後、復号されたコマンド（平文）は、Dispatcherを経由してApp(1)、App(2)、App(3)、及びＩＳＤへ送信される。

このように、ＯＳ（Dispatcher）は、外部からのコマンドが暗号化されているか否かを判定（コマンドのＡＰＤＵヘッダを解析することで判定）し、暗号化されている場合にはTLS Managerへ送信し、暗号化されていない場合にはApp(1)、App(2)、及びＩＳＤへ送信するので、外部からの暗号化されていないコマンドがApp(3)により受信されるのを防止することができる。さらに、TLS Managerにより復号されたコマンドがDispatcherを経由してApp(1)、App(2)、App(3)、及びＩＳＤへ送信されるように構成することで、アプリケーション間（つまり、第１のアプリケーションと第２のアプリケーションとの間）のやり取りを防止し、セキュリティレベルを向上することができる。

そして、TLS Managerは、App(1)、App(2)、App(3)、及びＩＳＤからのレスポンス（復号されたコマンドに対するレスポンス）を受信した場合、当該レスポンスを暗号化し、暗号化された暗号化レスポンスを、ＯＳを経由してセッションが確立されたサーバ１へ返信（つまり、ＤＥ２を介して返信）する。

図１０（Ａ）は、Dispatcherを使用しない場合における、暗号化されないレスポンスの流れを示す図であり、図１０（Ｂ）は、Dispatcherを使用しない場合における、暗号化されるレスポンスの流れを示す図である。図１０（Ａ）に示すように、App(1)、App(2)、及びＩＳＤからのレスポンス（平文）は、ＯＳを経由して外部へ送信される。一方、図１０（Ｂ）に示すように、App(1)、App(2)、App(3)、及びＩＳＤからのレスポンス（平文）は、TLS Managerへ送信され暗号化された後に、ＯＳを経由して外部へ送信される。

図１１（Ａ）は、Dispatcherを使用する場合における、暗号化されないレスポンスの流れを示す図であり、図１１（Ｂ）は、Dispatcherを使用する場合における、暗号化されるレスポンスの流れを示す図である。図１１（Ａ）に示すように、App(1)、App(2)、及びＩＳＤからのレスポンス（平文）は、Dispatcherを経由して外部へ送信される。一方、図１１（Ｂ）に示すように、App(1)、App(2)、App(3)、及びＩＳＤからのレスポンス（平文）は、Dispatcherを経由してTLS Managerへ送信され暗号化された後に、Dispatcherを経由して外部へ送信される。

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

図１２において、先ず、ＤＥ２のデバイス制御部２５は、TLS Managerの選択を示すコマンド（SELECT TLS Manager）ＡＰＤＵをＩ／Ｆ部２１を介してＳＥ３へ送信する（ステップＳ１）。次いで、ＳＥ３のDispatcherは、コマンド（SELECT TLS Manager）ＡＰＤＵをＩ／Ｆ部３１を介して受信すると、このコマンド（SELECT TLS Manager）ＡＰＤＵをTLS Managerへ送信する（ステップＳ２）。次いで、ＳＥ３のTLS Managerは、コマンド（SELECT TLS Manager）ＡＰＤＵを受信すると、このコマンド（SELECT TLS Manager）ＡＰＤＵに対するレスポンス（正常終了）ＡＰＤＵをDispatcherへ送信する（ステップＳ３）。こうして、TLS Managerはカレント選択アプリケーションとなる。次いで、ＳＥ３のDispatcherは、レスポンス（正常終了）ＡＰＤＵを受信すると、このレスポンス（正常終了）ＡＰＤＵをＩ／Ｆ部３１を介してＤＥ２へ送信する（ステップＳ４）。

次いで、ＤＥ２のデバイス制御部２５は、レスポンス（正常終了）ＡＰＤＵをＩ／Ｆ部２１を介して受信すると、セッション開始要求を示すコマンドＡＰＤＵをＩ／Ｆ部２１を介してＳＥ３へ送信する（ステップＳ５）。次いで、ＳＥ３のDispatcherは、セッション開始要求を示すコマンドＡＰＤＵをＩ／Ｆ部３１を介して受信すると、このコマンドＡＰＤＵをTLS Managerへ送信する（ステップＳ６）。次いで、ＳＥ３のTLS Managerは、セッション開始要求を示すコマンドＡＰＤＵを受信すると、サーバ１との間のハンドシェイクを開始し、初期乱数CHを生成して記憶する（ステップＳ７）。次いで、ＳＥ３のTLS Managerは、Client Hello ＡＰＤＵ（図３に示すデータＤ２）を生成し、生成したClient Hello ＡＰＤＵをDispatcherへ送信する（ステップＳ８）。ここで、Client Hello ＡＰＤＵに含まれるハンドシェイクデータ“Client Hello”には、ステップＳ７で生成された初期乱数CHが含まれる。なお、ハンドシェイクデータ“Client Hello”には、プロトコルバージョン、セッションＩＤ、暗号方式、及び圧縮方式等が含まれる場合もある。次いで、ＳＥ３のDispatcherは、Client Hello ＡＰＤＵを受信すると、この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の解析処理（例えば、ＩＰヘッダ及びＴＣＰヘッダの解析処理）をＤＥ２側で実施し、ＳＥ３側で不要なデータを削除することで、ＳＥ３の処理負荷を低減させることができる。また、ＴＣＰ／ＩＰ及びＴＬＳプロトコルにしたがった通信では多くのデータを送受信する必要があるが、これらの多くのデータの処理はＤＥ２で止まるので、ＳＥ３でのデータの処理を最小限にしつつ、ＳＥ３はサーバ１との間でＴＬＳプロトコルによる暗号化通信を行うことができる。

次いで、ＳＥ３のDispatcherは、Server Hello ＡＰＤＵをＩ／Ｆ部３１を介して受信すると、このServer Hello ＡＰＤＵをTLS Managerへ送信する（ステップＳ２０）。また、ＳＥ３のDispatcherは、Server Certificate ＡＰＤＵをＩ／Ｆ部３１を介して受信すると、このServer Certificate ＡＰＤＵをTLS Managerへ送信する（ステップＳ２１）。また、ＳＥ３のDispatcherは、Certificate Request ＡＰＤＵをＩ／Ｆ部３１を介して受信すると、このCertificate Request ＡＰＤＵをTLS Managerへ送信する（ステップＳ２２）。また、ＳＥ３のDispatcherは、Server Hello Done ＡＰＤＵをＩ／Ｆ部３１を介して受信すると、このServer Hello Done ＡＰＤＵをTLS Managerへ送信する（ステップＳ２３）。

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

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

次いで、ＳＥ３のDispatcherは、Client Certificate ＡＰＤＵ、Client Key Exchange ＡＰＤＵ、及びCertificate Verify ＡＰＤＵをそれぞれ受信すると、それぞれのＡＰＤＵをＩ／Ｆ部３１を介してＤＥ２へ送信する（ステップＳ３０〜Ｓ３２）。次いで、ＤＥ２のデバイス制御部２５は、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 ＡＰＤＵをＩ／Ｆ部２１を介してＳＥ３へ送信する（ステップＳ４０）。次いで、ＳＥ３のDispatcherは、Server Finished ＡＰＤＵをＩ／Ｆ部３１を介して受信すると、このServer Finished ＡＰＤＵをTLS Managerへ送信する（ステップＳ４１）。なお、Server Finished Messageの送信前に、サーバ１から、無暗号通信の終了を示すChange Cipher Spec Messageが送信されてもよい。

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

以上のように、サーバ１とＳＥ３との間でＤＥ２を介してハンドシェイクが実施され、サーバ１とＳＥ３との間で暗号通信を行うためのセッションが確立すると、図１３に示すように暗号化通信が行われることになる。なお、図１３は、Dispatcherを使用する場合の例を示す。

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

次いで、ＳＥ３のDispatcherは、暗号化コマンドＡＰＤＵをＩ／Ｆ部３１を介して受信すると、この暗号化コマンドＡＰＤＵをTLS Managerへ送信する（ステップＳ５３）。つまり、受信されたコマンドＡＰＤＵのＡＰＤＵヘッダ内のＩＮＳが暗号化されたデータ（図４の例では、“0x20”）であることを示す場合に、Dispatcherが暗号化コマンドＡＰＤＵを受信したと判定してTLS Managerへ送信する。次いで、ＳＥ３のTLS Managerは、暗号化コマンドＡＰＤＵを受信すると、当該暗号化コマンドＡＰＤＵに含まれる暗号化コマンドをステップＳ２９で生成された共通鍵により復号する（ステップＳ５４）。こうして復号されたコマンドＡＰＤＵは、例えば、App(1)、App(2)、App(3)、及びＩＳＤの選択を示す。次いで、ＳＥ３のTLS Managerは、復号されたコマンドＡＰＤＵ（図４に示すデータＤ５）をDispatcherへ送信する（ステップＳ５５）。次いで、ＳＥ３のDispatcherは、復号されたコマンドＡＰＤＵを受信すると、当該コマンドＡＰＤＵをApp（例えば、選択対象となったApp(1)、App(2)、App(3)、及びＩＳＤ）へ送信する（ステップＳ５６）。

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

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

以上説明したように、上記実施形態によれば、ＳＥ３内に、ＴＬＳプロトコルによる暗号化通信機能を持つTLS Manager（つまり、暗号通信専用のTLS Manager）を設け、TLS Manager以外のアプリケーションにはＴＬＳプロトコルによる暗号化通信機能を持たせないように構成した。そして、TLS Managerがサーバ１との間でハンドシェイクを実施してサーバ１との間で暗号通信を行うためのセッションを確立し、当該サーバ１からの暗号化コマンドを受信した場合、ハンドシェイクにおいて生成された共通鍵を用いて、暗号化コマンドを復号し、当該復号されたコマンドを、TLS Manager以外のアプリケーションへ送信するように構成したので、メモリ不足の問題を解消しつつ、アプリケーションに依存しない暗号化通信を実現することができる。また、TLS Managerがサーバ１との間でハンドシェイクに係る全ての処理を実行するように構成したので、中間者攻撃を防ぎ、セキュリティを向上することができる。さらに、TLS Managerにより復号されたコマンドがDispatcherを経由してTLS Manager以外のアプリケーションへ送信されるように構成することで、アプリケーション間のやり取りを防止し、セキュリティレベルを向上することができる。

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

Claims (8)

1. オペレーティングシステム、及び複数のアプリケーションを搭載し、サーバと通信を行う電子情報記憶媒体であって、
   前記複数のアプリケーションのうち何れか第１のアプリケーションは、
   前記サーバとの間で暗号通信を行うためのセッションを確立するセッション確立部と、
   前記セッションが確立された前記サーバからの暗号化されたコマンドを受信した場合、前記セッションの確立において生成されたセッション鍵を用いて、前記暗号化されたコマンドを復号するコマンド復号部と、
   前記コマンド復号部により復号されたコマンドを、前記第１のアプリケーション以外の第２のアプリケーションへ送信するコマンド送信部と、
   を備えることを特徴とする電子情報記憶媒体。
2. 前記サーバからの前記暗号化されたコマンドは、前記オペレーティングシステムを経由して前記第１のアプリケーションへ送信され、
   前記第１のアプリケーションの前記コマンド復号部により復号されたコマンドは、前記オペレーティングシステムを経由して前記第２のアプリケーションへ送信されることを特徴とする請求項１に記載の電子情報記憶媒体。
3. 前記オペレーティングシステムは、外部からのコマンドが暗号化されているか否かを判定し、暗号化されている場合には前記第１のアプリケーションへ送信し、暗号化されていない場合には前記第２のアプリケーションへ送信することを特徴とする請求項２に記載の電子情報記憶媒体。
4. 前記第２のアプリケーションからの前記復号されたコマンドに対するレスポンスを受信した場合、当該レスポンスを暗号化するレスポンス暗号化部と、
   前記レスポンス暗号化部により暗号化されたレスポンスを、前記セッションが確立された前記サーバへ返信するレスポンス返信部と、
   を更に備えることを特徴とする請求項１乃至３の何れか一項に記載の電子情報記憶媒体。
5. 前記第２のアプリケーションからの前記レスポンスは、前記オペレーティングシステムを経由して前記第１のアプリケーションへ送信され、
   前記第１のアプリケーションの前記レスポンス暗号化部により暗号化されたレスポンスは、前記オペレーティングシステムを経由して前記サーバへ返信されることを特徴とする請求項４に記載の電子情報記憶媒体。
6. 前記暗号通信は、ＴＬＳ(Transport Layer Security)プロトコルにしたがった通信であることを特徴とする請求項１乃至５の何れか一項に記載の電子情報記憶媒体。
7. オペレーティングシステム、及び複数のアプリケーションを搭載し、サーバと通信を行う電子情報記憶媒体により実行されるコマンド処理方法であって、
   前記複数のアプリケーションのうち何れか第１のアプリケーションが、前記サーバとの間で暗号通信を行うためのセッションを確立するステップと、
   前記第１のアプリケーションが、前記セッションが確立された前記サーバからの暗号化されたコマンドを受信した場合、前記セッションの確立において生成されたセッション鍵を用いて、前記暗号化されたコマンドを復号するステップと、
   前記第１のアプリケーションが、前記復号されたコマンドを、前記第１のアプリケーション以外の第２のアプリケーションへ送信するステップと、
   を含むことを特徴とするコマンド処理方法。
8. オペレーティングシステム、及び複数のアプリケーションを搭載し、サーバと通信を行う電子情報記憶媒体に含まれるコンピュータに処理を実行させるアプリケーションの機能を実現するプログラムであって、
   前記コンピュータに、
   前記サーバとの間で暗号通信を行うためのセッションを確立させ、
   前記セッションが確立された前記サーバからの暗号化されたコマンドを受信した場合、前記セッションの確立において生成されたセッション鍵を用いて、前記暗号化されたコマンドを復号させ、
   前記復号されたコマンドを、他のアプリケーションへ送信させることを特徴とするプログラム。

Images