以下、図面を参照して本発明の実施形態について詳細に説明する。以下に説明する実施形態は、通信システムにおけるDE(Device)に対して本発明を適用した場合の実施の形態である。なお、通信システムは、例えばIoTシステムとして利用される。
[1.通信システムSの構成及び通信プロトコル]
先ず、図1及び図2を参照して、本実施形態に係る通信システムSの概要構成及び通信プロトコルについて説明する。図1は、本実施形態に係る通信システムSの概要構成例を示す図であり、図2は、本実施形態に係る通信システムSにおける通信プロトコルを階層別に示す概念図である。
図1に示すように、通信システムSは、サーバ1、DE(Device)2、及びSE(セキュアエレメント)3等を含んで構成される。サーバ1とDE2は、それぞれ、インターネットや移動通信網等により構成されるネットワークNTに接続され、ネットワークNTを介して互いに通信可能になっている。具体的には、サーバ1とDE2は、図2に示すように、ネットワーク・インターフェース(ネットワークNT)をベースとして、TCP(Transmission Control Protocol)/IP(Internet protocol)及びTLSプロトコルにしたがって通信する。ここで、TLSプロトコルは、TLSレコード層(TLS Record)とTLSハンドシェイク層という2つの層から構成される。TLSハンドシェイク層は、ハンドシェイクプロトコル(TLS HS(Handshake))、アラートプロトコル(TLS AL(Alert))、暗号仕様変更プロトコル(TLS CC(Change Cipher Spec))、及びアプリケーションデータプロトコル(App(Application) Data)から構成される。本実施形態では、ハンドシェイクプロトコルは、サーバ1とSE3との間で暗号通信を行うためのセッションを確立することに用いられる。ハンドシェイクプロトコルにしたがってサーバ1とSE3との間でセッションを確立するためのやり取りをハンドシェイクという。このようなハンドシェイクにおいてサーバ1とSE3との間で共通のセッション鍵(以下、「共通鍵」という)が生成される。アプリケーションデータプロトコルは、サーバ1とSE3との間で共通鍵により暗号化されたアプリケーションデータを送受信することに用いられる。なお、アプリケーションデータプロトコルには、例えば、HTTPS (Hypertext Transfer Protocol Secure)及びFTPS (File Transfer Protocol Secure)などが該当する。
一方、DE2とSE3は、所定のインターフェースを介して互いに通信可能になっている。具体的には、DE2とSE3は、図2に示すように、所定のインターフェースをベースとして、SE用プロトコル及びAPDU(Application Protocol Data Unit)プロトコルにしたがって通信する。ここで、SE用プロトコルは、所定のインターフェースに依存するプロトコルである。このインターフェースの例として、SPI(Serial Peripheral Interface)、I2C(Inter-Integrated Circuit)、及びISO7816インターフェースなどが挙げられる。SPI及びI2Cは、シリアル通信インターフェース(シリアル通信バスともいう)であり、特に、SPIは、同時に双方向の通信を行う全二重シリアル通信プロトコルを用いる。一方、ISO7816インターフェースは、ISO7816-2で定義される通信インターフェース(C1〜C8の8個の端子を利用した通信インターフェース)であり、TPDU(Transmission Protocol Data Unit)プロトコル(例えば、T=0またはT=1)を用いる。なお、APDUプロトコルは、ISO7816-3で定義されるAPDUを送受信するためのプロトコルである。さらに、DE2は、サーバ1とSE3との間の通信を仲介する機能を担っており、この仲介の際にプロトコル変換を行う。つまり、DE2は、図2に示すように、TLSプロトコルにおけるTLSハンドシェイク層を維持しつつ、TCP/IP及びTLSプロトコルにおけるTLSレコード層と、SE用プロトコル及びAPDUプロトコルとを変換する。
ここで、図3〜図5を参照して、プロトコル変換について説明する。図3は、TLSハンドシェイク層でハンドシェイクプロトコルが用いられる場合のプロトコル変換の一例を示す概念図であり、図4及び図5は、TLSハンドシェイク層でアプリケーションデータプロトコルが用いられる場合のプロトコル変換の一例を示す概念図である。
先ず、図3に示すように、TLSハンドシェイク層でハンドシェイクプロトコルが用いられる場合のプロトコル変換によって、サーバ1とDE2との間で送受信されるデータD(Message)1は、DE2とSE3との間で送受信されるデータD2(APDU)に変換され、また、データD2は、データD1に変換される。データD1は、IPヘッダ、TCPヘッダ、タイプ、プロトコルバージョン、データ長(TLSデータのデータ長)、及びTLSデータから構成される。ここで、IPヘッダには、送信元IPアドレス、宛先IPアドレス、及びIPヘッダのエラーチェックを行うためのチェックサム等が含まれる。TCPヘッダには、送信元ポート番号、宛先ポート番号、及びTCPヘッダ及びデータ部分のエラーチェックを行うためのチェックサム等が含まれる。タイプ、プロトコルバージョン、及びデータ長は、TLSレコードヘッダを構成する。タイプは、ハンドシェイクプロトコル、アラートプロトコル、暗号仕様変更プロトコル、及びアプリケーションデータプロトコルのうち何れかのプロトコル種別を示す値であるが、図3の例では、ハンドシェイクプロトコルを示している。この場合のTLSデータは、msgタイプ、データ長(ハンドシェイクデータのデータ長)、及びハンドシェイクに用いられるハンドシェイクデータから構成される。msgタイプは、ハンドシェイクデータの種別を示す値(図3の例では、16進数(0x)で示している)である。
一方、データD2は、CLA、INS、P1、P2、Lc、及びハンドシェイクデータから構成される。ここで、CLA、INS、P1及びP2はAPDUヘッダを構成し、Lc及びハンドシェイクデータはAPDUボディを構成する。つまり、データD2のデータフォーマットとして、ISO7816-3で定義されたコマンドAPDU(Case3)のデータフォーマットが利用されている。CLAはコマンドクラス(命令クラス)を示す値であり、INSはコマンドコード(命令コード)を示す値であり、P1及びP2はコマンドパラメータ(命令パラメータ)を示す値である。ISO7816-4では、“SELECT FILE”,“READ BINARY”,“UPDATE BINARY”,“WRITE BINARY”,及び“VERIFY”等のコマンド種別毎に異なるINSが割り当てられているが、本実施形態では、図3に示すように、ISO7816-4において使用されていないINSがハンドシェイクデータに対して割り当てられる。例えば、ハンドシェイクデータ“Client Hello”には、INS“Ox00”が割り当てられ、ハンドシェイクデータ“Server Hello”には、INS“Ox02”が割り当てられている。このように、ハンドシェイクデータの種別毎に異なるINSが割り当てられている。一方、CLAはハンドシェイクデータの種別によらず固定値となっており、P1及びP2は後続データの有無などにより変化する。なお、上記msgタイプで示されるハンドシェイクデータは10種類であるが、これらのうち、本実施形態では、ハンドシェイクデータ“Hello Request”及び“Server Key Exchange”を使用しなくてもよいため、これらのハンドシェイクデータには、INSが割り当てられていない。ただし、ハンドシェイクデータ“Server Key Exchange”については利用されてもよく、この場合、“Server Key Exchange”には固有のINSが割り当てられる。
次に、図4に示すように、TLSハンドシェイク層でアプリケーションデータプロトコルが用いられる場合のプロトコル変換によって、サーバ1とDE2との間で送受信されるデータD3は、DE2とSE3との間で送受信されるデータD4に変換される。データD3は、IPヘッダ、TCPヘッダ、アプリケーションデータプロトコルを示すタイプ、プロトコルバージョン、データ長、及び暗号化コマンド(TLSデータ)から構成される。ここで、暗号化コマンドは、サーバ1とSE3との間で実施されたハンドシェイクにおいて生成された共通鍵で暗号化されたコマンドAPDUである。一方、データD4は、CLA、INS、P1、P2、Lc、及び暗号化コマンドから構成される。この場合のCLA及びINSは固定値となっており、特に、INSは暗号化されたデータであることを示す。一方、P1及びP2は後続データの有無などにより変化する。そして、SE3において、図4に示すように、データD4に含まれる暗号化コマンドが上記共通鍵で復号されることでデータD5(コマンドAPDU)が抽出される。データD5は、“SELECT FILE”,“READ BINARY”,“UPDATE BINARY”,“WRITE BINARY”,または“VERIFY”等のコマンドである。なお、図4の例では、データD5は、CLA、INS、P1、P2、Lc、及びDataから構成されている(Case3)が、CLA、INS、P1及びP2から構成(Case1)される場合、或いは、CLA、INS、P1、P2、及びLe(レスポンスAPDUの最大長(最大サイズ))から構成(Case2)される場合、或いは、CLA、INS、P1、P2、Lc、Data、Leから構成(Case4)される場合もある。
このように抽出されたデータD5(コマンドAPDU)に応じた処理がSE3により実行されると、図5に示すように、その実行結果を示すデータD6(SW(ステータスワード)1及びSW2からなるレスポンスAPDU)が生成される。続いて、SE3において、データD6が上記共通鍵で暗号化されることで暗号化レスポンスが生成され、この暗号化レスポンスにSW1及びSW2が付加されることでデータD7(レスポンスAPDU)が生成される。なお、図5の例では、データD7は、SW1及びSW2から構成されている(Case1,Case3)が、DATA(例えばNVM34から読み出されたデータ)、SW1及びSW2から構成される(Case2,Case4)される場合もある。このように生成されたデータD7は、SE3からDE2へ送信され、プロトコル変換されることで、データD8に変換される。データD8は、IPヘッダ、TCPヘッダ、アプリケーションデータプロトコルを示すタイプ、プロトコルバージョン、データ長(暗号化レスポンスのデータ長)、及び暗号化レスポンス(TLSデータ)から構成される。
[2.DE2及びSE3の構成及び機能]
次に、図6を参照して、本実施形態に係るDE2及びSE3の構成及び機能について説明する。なお、本実施形態では、DE2及びSE3は、同じ端末T内に搭載されることを例にとって説明するが、別々の端末に搭載されてもよい。また、DE2は、本発明の通信デバイスの一例である。また、SE3は、例えば、eUICC(Embedded Universal Integrated Circuit Card)として、端末Tから容易に取り外しや取り換えができないように組み込み基盤上に実装(つまり、端末Tと一体的に形成)される。或いは、SE3はICカードに搭載されてもよく、この場合、当該ICカードは端末Tに着脱可能に装着される。
図6は、端末Tのハードウェア構成例を示す図である。図6に示すように、端末Tは、DE2、SE3、及びセンサー4を備えて構成される。DE2は、I/F部21,22、通信部23、記憶部24、及びデバイス制御部25等を備えて構成される。I/F部21は、SE3との間のインターフェースを担う。このインターフェースは、上述したように、SPI、I2C、またはISO7816インターフェースなどである。I/F部22は、センサー4との間のインターフェースを担う。センサー4は、端末Tから所定の近傍範囲(例えば、数mの範囲)内の状態(例えば、温度、湿度、気圧、照度、水位、騒音など)を例えば定期的に検知する。センサー4により検知、取得された状態を示す情報は、デバイス制御部25によりI/F部21を介してSE3に送信され、SE3によりNVM34に記憶(蓄積)される。
通信部23は、ネットワークNTに接続するための通信機器である。なお、通信部23は、移動通信網の基地局を検出するモデムを備えている場合もある。この場合、通信部23は、デバイス制御部25により指定されたデータを変調し、その電波(搬送波)をアンテナを介して基地局へ送信し、また、基地局からの電波をアンテナを介して受信して復調することでデータを取り出してデバイス制御部25へ送信する。記憶部24(記憶手段の一例)は、例えば不揮発性メモリから構成され、所定のプログラム(本発明のプログラムを含む)、及びデータが記憶される。本発明のプログラムは、DE2に含まれるコンピュータ(CPU(Central Processing Unit))を、第1送信手段、第2送信手段、第3送信手段、第4送信手段、第5送信手段、及び判定手段として機能させる。また、記憶部24には、データとして、サーバ1のIPアドレス及びポート番号、或いはサーバ1のURL(Uniform Resource Locator)が記憶される。さらに、記憶部24には、ハンドシェイクデータの種別を示すmsgタイプと、ハンドシェイクデータの種別毎に割り当てられたINSとの対応関係を示すデータ種別対応情報が含まれており、これはプロトコル変換のために用いられる。例えば、図3の場合、データ種別対応情報には、“Client Hello”のmsgタイプ“Ox01”と、“Client Hello”に割り当てられたINS“Ox00”とが対応付けられ、“Server Hello”のmsgタイプ“Ox02”と、“Server Hello”に割り当てられたINS“Ox02”とが対応付けられている。なお、ハンドシェイクデータの全種別について、msgタイプとINSとが完全に一致する場合、データ種別対応情報が記憶部24に記憶されなくてもよい。
デバイス制御部25は、例えばCPU、RAM(Random Access Memory)、及びROM(Read Only Memory)等により構成され、サーバ1とSE3との間の通信を仲介する機能を担っており、上述したように、この仲介の際にプロトコル変換を行う。デバイス制御部25は、サーバ1とSE3との間で暗号通信を行うためのセッションを確立するハンドシェイクを開始させる開始要求をSE3へ送信する。そして、当該開始要求により開始されたハンドシェイクにおいて、デバイス制御部25は、APDUヘッダが付加されたハンドシェイクデータをSE3から受信すると、APDUヘッダに代えてTLSレコードヘッダ、TCPヘッダ、及びIPヘッダを、ハンドシェイクデータを含むTLSデータに付加してサーバ1へ送信する。一方、上記開始要求により開始されたハンドシェイクにおいて、デバイス制御部25は、TLSレコードヘッダ、TCPヘッダ、及びIPヘッダが付加されたTLSデータをサーバ1から受信すると、TLSレコードヘッダ、TCPヘッダ、及びIPヘッダに代えてAPDUヘッダを、TLSデータに含まれるハンドシェイクデータに付加してSE3へ送信する。ここで、デバイス制御部25は、TCPヘッダ及びIPヘッダに含まれるデータに基づいて解析処理(例えば、Messageの解析処理)を実行しその結果が良好である場合に限り、TLSレコードヘッダ、TCPヘッダ、及びIPヘッダに代えてAPDUヘッダを、TLSデータに含まれるハンドシェイクデータに付加してSE3へ送信するとよい。
SE3は、I/F部31、RAM32、ROM33、NVM(Nonvolatile Memory)34、及びCPU35(コンピュータの一例)等を備えて構成される。I/F部31は、DE2との間のインターフェースを担う。このインターフェースは、上述したように、SPI、I2C、またはISO7816インターフェースなどである。NVM34は、例えばフラッシュメモリ等の不揮発性メモリである。なお、NVM34は、「Electrically Erasable Programmable Read-Only Memory」であってもよい。ROM33またはNVM34には、オペレーティングシステム(以下、「OS(Operating System)」という)を構成するソフトウェア、及びアプリケーションプログラムが記憶される。ここで、アプリケーションプログラムは、SE3においてアプリケーションインスタンス(これを、「アプリケーション」という)の機能を実現するためのプログラムである。アプリケーションは、アプリケーションプログラム等をメモリに展開して実行可能な状態にインストール(搭載)されたモジュールであり、CPU35によってOS上で動作する。なお、アプリケーションは複数搭載されてもよい。
SE3のCPU35は、アプリケーションにしたがって、サーバ1との間で上記ハンドシェイクを実施し、サーバ1との間で暗号通信を行うためのセッションを確立する。SE3のCPU35は、セッションが確立されたサーバ1からの暗号化コマンドを受信(つまり、DE2を介して受信)した場合、アプリケーションにしたがって、当該セッションの確立において(つまり、ハンドシェイクにおいて)生成された共通鍵を用いて、暗号化コマンドを復号する。そして、SE3のCPU35は、アプリケーションにしたがって、当該復号されたコマンドに応じた処理を実行し、その実行結果を示すレスポンスを生成する。そして、SE3のCPU35は、アプリケーションにしたがって、生成されたレスポンスを上記共通鍵で暗号化することで暗号化レスポンスを生成し、この暗号化レスポンスを、セッションが確立されたサーバ1へ返信(つまり、DE2を介して返信)する。なお、上記ハンドシェイク、暗号化コマンドの復号、及びレスポンスの暗号化は、専用のアプリケーションにより行われるとよく、この場合、専用のアプリケーション以外のアプリケーションが復号されたコマンドに応じた処理を実行し、その実行結果を示すレスポンスを生成することになる。
[3.通信システムSの動作]
次に、図7を参照して、通信システムSの動作について説明する。図7は、通信システムSの動作例を示すシーケンスである。なお、通信システムSの動作の前提として、サーバ1には、サーバ1の公開鍵と秘密鍵の鍵ペア、サーバ1の証明書(サーバ証明書)、及び認証局の証明書等が予め記憶され、SE3のNVM34には、SE3の秘密鍵と公開鍵の鍵ペア、SE3の証明書(クライアント証明書)、及び認証局の証明書等が予め記憶される。ここで、サーバ1の証明書は、サーバ1の公開鍵及び認証局の電子署名(デジタル署名)が付与された証明書であり、認証局により発行される。SE3の証明書は、SE3の公開鍵及び認証局の電子署名が付与された証明書であり、認証局により発行される。認証局の証明書は、認証局の公開鍵が付与された証明書であり、認証局により発行される。
図7において、先ず、DE2のデバイス制御部25は、セッション開始要求を示すコマンドAPDUをI/F部21を介してSE3へ送信する(ステップS1)。セッション開始要求は、サーバ1とSE3との間で暗号通信を行うためのセッションを確立するハンドシェイクを開始させる要求である。次いで、SE3のCPU35は、セッション開始要求を示すコマンドAPDUをI/F部31を介して受信すると、サーバ1との間のハンドシェイクを開始し、初期乱数CHを生成して記憶する(ステップS2)。次いで、SE3のCPU35は、Client Hello APDU(図3に示すデータD2)を生成し、I/F部31を介してDE2へ送信する(ステップS3)。ここで、Client Hello APDUに含まれるハンドシェイクデータ“Client Hello”には、ステップS2で生成された初期乱数CHが含まれる。なお、ハンドシェイクデータ“Client Hello”には、プロトコルバージョン、セッションID、暗号方式、及び圧縮方式等が含まれる場合もある。
次いで、DE2のデバイス制御部25は、Client Hello APDUをI/F部21を介して受信すると、TCPプロトコルにしたがってサーバ1との間のコネクションを確立(3ウェイハンドシェイク)し、Client Hello APDU(図3に示すデータD2)についてプロトコル変換を行うことでClient Hello Message(図3に示すデータD1)を生成する。より具体的には、デバイス制御部25がClient Hello APDUからハンドシェイクデータ“Client Hello”を抽出し、抽出したハンドシェイクデータ“Client Hello”、そのデータ長、及びそのmsgタイプから構成されるTLSデータを生成し、生成したTLSデータにTLSレコードヘッダ、TCPヘッダ、及びIPヘッダを付加することでClient Hello Messageを生成する。ここで、msgタイプは、Client Hello APDUのAPDUヘッダに含まれるINSと、記憶部24に記憶されたデータ種別対応情報とに基づいてデバイス制御部25により特定される。そして、DE2のデバイス制御部25は、生成したClient Hello Messageを通信部23を介してサーバ1へ送信する(ステップS4)。
次いで、サーバ1は、Client Hello Messageを受信すると、Client Hello Messageの解析処理(IPヘッダ及びTCPヘッダに含まれるチェックサムによるエラーチェック等を含む)を実行しその結果が良好であれば、Client Hello Messageから初期乱数CHを抽出して記憶すると共に、初期乱数SHを生成して記憶する(ステップS5)。次いで、サーバ1は、Server Hello Messageを生成し、生成したServer Hello MessageをDE2へ送信する(ステップS6)。ここで、Server Hello Messageに含まれるハンドシェイクデータ“Server Hello”には、ステップS5で生成された初期乱数SHが含まれる。なお、ハンドシェイクデータ“Server Hello”には、“Client Hello”と同様、プロトコルバージョン、セッションID、暗号方式、及び圧縮方式等が含まれる場合もある。さらに、サーバ1は、Server Certificate Messageを生成し、生成したServer Certificate MessageをDE2へ送信する(ステップS7)。ここで、Server Certificate Messageに含まれるハンドシェイクデータ“Server Certificate”には、サーバ1の証明書が含まれる。さらに、サーバ1は、Certificate Request Messageを生成し、生成したCertificate Request MessageをDE2へ送信する(ステップS8)。さらに、サーバ1は、Server Hello Done Messageを生成し、生成したServer Hello Done MessageをDE2へ送信する(ステップS9)。なお、サーバ1は、Server Hello Message、Server Certificate Message、Certificate Request Message、及びServer Hello Done Messageを一つに纏めたMultiple Handshake MessageをDE2へ送信してもよい。
次いで、DE2のデバイス制御部25は、Server Hello Messageを通信部23を介して受信すると、Server Hello Messageの解析処理(IPヘッダ及びTCPヘッダに含まれるチェックサムによるエラーチェック等を含む)を実行しその結果が良好であれば、Server Hello Messageについてプロトコル変換を行うことでServer Hello APDUを生成する。より具体的には、デバイス制御部25がServer Hello Messageからハンドシェイクデータ“Server Hello”を抽出し、抽出したハンドシェイクデータ“Server Hello”、及びそのデータ長(Lc)にAPDUヘッダを付加することでServer HelloAPDUを生成する。言い換えれば、デバイス制御部25は、Server Hello MessageからIPヘッダ、TCPヘッダ、及びTLSレコードヘッダを削除して、代わりにAPDUヘッダをハンドシェイクデータ“Server Hello”に付加する。ここで、APDUヘッダに含まれるINSは、Server Hello Messageに含まれるmsgタイプと、記憶部24に記憶されたデータ種別対応情報とに基づいてデバイス制御部25により特定される。そして、DE2のデバイス制御部25は、生成したServer Hello APDUをI/F部21を介してSE3へ送信する(ステップS10)。
また、DE2のデバイス制御部25は、Server Certificate Messageを通信部23を介して受信すると、Server Certificate Messageの解析処理を実行しその結果が良好であれば、Server Certificate Messageについてプロトコル変換を行うことでServer Certificate APDUを生成し、生成したServer Certificate APDUをI/F部21を介してSE3へ送信する(ステップS11)。また、DE2のデバイス制御部25は、Certificate Request Messageを通信部23を介して受信すると、Certificate Request Messageの解析処理を実行しその結果が良好であれば、Certificate Request Messageについてプロトコル変換を行うことでCertificate Request APDUを生成し、生成したCertificate Request APDUをI/F部21を介してSE3へ送信する(ステップS12)。また、DE2のデバイス制御部25は、Server Hello Done Messageを通信部23を介して受信すると、Server Hello Done Messageの解析処理を実行しその結果が良好であれば、Server Hello Done Messageについてプロトコル変換を行うことでServer Hello Done APDUを生成し、生成したServer Hello Done APDUをI/F部21を介してSE3へ送信する(ステップS13)。
なお、DE2のデバイス制御部25は、サーバ3からMultiple Handshake Messageを受信した場合、Server Hello APDU、Server Certificate APDU、Certificate Request APDU、及びServer Hello Done APDUをそれぞれ生成し、それぞれのAPDUをSE3へ送信することになる。以上のように、各Messageの解析処理(例えば、IPヘッダ及びTCPヘッダの解析処理)をDE2側で実施し、SE3側で不要なデータを削除することで、SE3の処理負荷を低減させることができる。また、TCP/IP及びTLSプロトコルにしたがった通信では多くのデータを送受信する必要があるが、これらの多くのデータの処理はDE2で止まるので、SE3でのデータの処理を最小限にしつつ、SE3はサーバ1との間でTLSプロトコルによる暗号化通信を行うことができる。
次いで、SE3のCPU35は、Server Hello APDU、Server Certificate APDU、Certificate Request APDU、及びServer Hello Done APDUをI/F部31を介してそれぞれ受信する。そして、SE3のCPU35は、受信されたServer Hello APDUから初期乱数SHを抽出して記憶する。次いで、SE3のCPU35は、受信されたServer Certificate APDUからサーバ1の証明書を抽出し、当該証明書の検証を行う(ステップS14)。この証明書の検証において、SE3のCPU35は、例えば、認証局の証明書に付与された公開鍵を用いてサーバ1の証明書における認証局の電子署名の署名検証を行い、当該証明書の有効期限等の検査を行う。そして、SE3のCPU35は、サーバ1の証明書の検証結果が良好(検証成功)であれば、Certificate Request APDUに応じて、Client Certificate APDUを生成し、生成したClient Certificate APDUをI/F部31を介してDE2へ送信する(ステップS15)。ここで、Client Certificate APDUに含まれるハンドシェイクデータ“Client Certificate”には、SE3の証明書が含まれる。
次いで、SE3のCPU35は、共通鍵の基になる元となる秘密情報(例えば、46バイトの乱数であるプリマスターシークレット)を生成し、生成した秘密情報をサーバ1の証明書に付与された公開鍵を用いて暗号化する(ステップS16)。次いで、SE3のCPU35は、Client Key Exchange APDUを生成し、生成したClient Key Exchange APDUをI/F部31を介してDE2へ送信する(ステップS17)。ここで、Client Key Exchange APDUに含まれるハンドシェイクデータ“Client Key Exchange”には、ステップS16で暗号化された秘密情報が含まれる。次いで、SE3のCPU35は、Certificate Verify APDUを生成し、生成したCertificate Verify APDUをI/F部31を介してDE2へ送信する(ステップS18)。ここで、Certificate Verify APDUに含まれるハンドシェイクデータ“Certificate Verify”には、SE3の電子署名(SE3の秘密鍵で署名)が付与された署名データが含まれる。次いで、SE3のCPU35は、上記生成された秘密情報と、上記生成された初期乱数CHと、Server Hello APDUから抽出された初期乱数SHとに基づいて共通鍵を生成して記憶する(ステップS19)。なお、この例では、共通鍵の交換方式としてRSA方式を用いているが、DHE方式やECDHE方式が用いられてもよく、この場合、“Client Key Exchange”と“Server Key Exchange”が用いられてサーバ1とSE3間で鍵交換が実施される。
次いで、DE2のデバイス制御部25は、Client Certificate APDU、Client Key Exchange APDU、及びCertificate Verify APDUをI/F部21を介してそれぞれ受信すると、それぞれのAPDUについてプロトコル変換(Client Hello APDUと同じようにプロトコル変換)を行うことで、Client Certificate Message、Client Key Exchange Message、及びCertificate Verify Messageを生成する。そして、DE2のデバイス制御部25は、生成したClient Certificate Message、Client Key Exchange Message、及びCertificate Verify Messageを通信部23を介してサーバ1へ送信する(ステップS20〜S22)。
次いで、サーバ1は、Client Certificate Message、Client Key Exchange Message、及びCertificate Verify Messageをそれぞれ受信する。そして、サーバ1は、受信されたそれぞれのMessageの解析処理を実行しその結果が良好であれば、Client Certificate MessageからSE3の証明書を抽出し、当該証明書の検証を行う(ステップS23)。この証明書の検証方法は、ステップS14における検証方法と同様である。そして、サーバ1は、SE3の証明書の検証結果が良好であれば、Certificate Verify Messageから署名データを抽出し、SE3の証明書に付与された公開鍵を用いて当該署名データにおけるSE3の電子署名の署名検証を行う(ステップS24)。そして、サーバ1は、SE3の証明書の検証結果が良好であれば、Client Key Exchange Messageから秘密情報を抽出し、抽出した秘密情報と、上記生成された初期乱数SHと、Client Hello Messageから抽出された初期乱数CHとに基づいて共通鍵を生成(ステップS19と同様の方法で生成)して記憶する(ステップS25)。こうして、サーバ1とSE3は、同じ共通鍵と共有することになる。
次いで、サーバ1は、Server Finished Messageを生成し、生成したServer Finished MessageをDE2へ送信する(ステップS26)。ここで、Server Finished Messageに含まれるハンドシェイクデータ“Server Finished”には、終了検証データが含まれる。次いで、DE2のデバイス制御部25は、Server Finished Messageを通信部23を介して受信すると、Server Finished Messageについてプロトコル変換を行うことでServer Finished APDUを生成し、生成したServer Finished APDUをI/F部21を介してSE3へ送信する(ステップS27)。なお、Server Finished Messageの送信前に、サーバ1から、無暗号通信の終了を示すChange Cipher Spec Messageが送信されてもよい。次いで、SE3のCPU35は、Server Finished APDUをI/F部31を介して受信すると、Client Finished APDUを生成し、生成したClient Finished APDUをI/F部31を介してDE2へ送信する(ステップS28)。ここで、Client Finished APDUに含まれるハンドシェイクデータ“Client Finished”には、終了検証データが含まれる。なお、Client Finished APDUの送信前に、SE3から、無暗号通信の終了を示すChange Cipher Spec APDUが送信されてもよい。DE2のデバイス制御部25は、Client Finished APDUをI/F部21を介して受信すると、Client Finished APDUについてプロトコル変換を行うことでClient Finished Messageを生成し、生成したClient Finished Messageを通信部23を介してサーバ1へ送信する(ステップS29)。
以上のように、サーバ1とSE3との間でDE2を介してハンドシェイクが実施され、サーバ1とSE3との間で暗号通信を行うためのセッションが確立すると、暗号化通信が行われることになる。まず、サーバ1は、暗号化コマンド Message(図4に示すデータD3)を生成し、生成した暗号化コマンドMessageをDE2へ送信する(ステップS30)。ここで、暗号化コマンド Messageに含まれるアプリケーションデータには、ステップS25で生成された共通鍵により暗号化された暗号化コマンドが含まれる。次いで、DE2のデバイス制御部25は、暗号化コマンド Messageを通信部23を介して受信すると、暗号化コマンド Messageの解析処理を実行しその結果が良好であれば、暗号化コマンドMessageについてプロトコル変換を行うことで暗号化コマンドAPDU(図4に示すデータD4)を生成する。より具体的には、デバイス制御部25が暗号化コマンド Messageから暗号化コマンドを抽出し、抽出した暗号化コマンド、及びそのデータ長(Lc)にAPDUヘッダを付加することで暗号化コマンドAPDUを生成する。言い換えれば、デバイス制御部25は、暗号化コマンド MessageからIPヘッダ、TCPヘッダ、及びTLSレコードヘッダを削除して、代わりにAPDUヘッダを暗号化コマンドに付加する。そして、DE2のデバイス制御部25は、生成した暗号化コマンドAPDUをI/F部21を介してSE3へ送信する(ステップS31)。このように、DE2は、暗号化コマンドをハンドリングするだけであり、暗号通信を解読することはできない。そのため、通信情報は、セキュアに保たれると同時に、DE2にTLS機能を搭載する必要がないという利点がある。
次いで、SE3のCPU35は、暗号化コマンドAPDUをI/F部31を介して受信すると、当該暗号化コマンドAPDUに含まれる暗号化コマンドをステップS19で生成された共通鍵により復号する(ステップS32)。次いで、SE3のCPU35は、当該コマンドAPDUに応じた処理を実行し(ステップS33)、その実行結果を示すレスポンスAPDU(図5に示すデータD6)を生成する。次いで、SE3のCPU35は、レスポンスAPDUを受信すると、当該レスポンスAPDUをステップS19で生成された共通鍵により暗号化する(ステップS34)ことで暗号化レスポンスを生成する。次いで、SE3のCPU35は、生成した暗号化レスポンスを含む暗号化レスポンスAPDU(図5に示すデータD7)を生成し、生成した暗号化レスポンスAPDUをI/F部31を介してDE2へ送信する(ステップS35)。
次いで、DE2のデバイス制御部25は、暗号化レスポンスAPDUをI/F部21を介して受信すると、暗号化レスポンスAPDUについてプロトコル変換を行うことで暗号化レスポンスMessage(図5に示すデータD8)を生成する。より具体的には、デバイス制御部25が暗号化レスポンスAPDUから暗号化レスポンスを抽出し、抽出した暗号化レスポンスにTLSレコードヘッダ、TCPヘッダ、及びIPヘッダを付加することで暗号化レスポンスMessageを生成する。そして、DE2のデバイス制御部25は、生成した暗号化レスポンスMessageを通信部23を介してサーバ1へ送信する(ステップS36)。サーバ1は、暗号化レスポンスMessageを受信すると、ステップS25で生成された共通鍵により暗号化レスポンスMessageに含まれる暗号化レスポンスを復号する。そして、サーバ1は、復号されたレスポンスに応じて、次の暗号化コマンドMessageを生成してDE2へ送信する(ステップS30)。こうして上記と同じ流れでステップS31以降の処理が行われる。これにより、例えばコマンドが“READ BINARY”である場合、センサー4により取得されNVM34に記憶(蓄積)されたデータを安全にサーバ1へ送信することができる。
以上説明したように、上記実施形態によれば、DE2は、セッション開始要求によりサーバ1とSE3との間で暗号通信を行うためのセッションを確立するハンドシェイクを開始させ、開始されたハンドシェイクにおいて、DE2は、APDUヘッダが付加されたハンドシェイクデータをSE3から受信すると、APDUヘッダに代えてTLSレコードヘッダ等をTLSデータに付加してサーバ1へ送信する一方、TLSレコードヘッダ等が付加されたTLSデータをサーバ1から受信すると、TLSレコードヘッダ等に代えてAPDUヘッダをハンドシェイクデータに付加してSE3へ送信するように構成したので、SE3とサーバ1との間のハンドシェイクの迅速化を図ることができる。また、SE3がサーバ1との間でハンドシェイクに係る端末T側の全ての処理(乱数CH生成、証明書検証、秘密情報生成及び暗号化、及び共通鍵生成)を実施するように構成したので、DE2がハンドシェイクの一部を実施することがない。つまり、DE2は、SE3とサーバ1との間でプロトコル変換及びデータ転送だけを実施するので、中間者攻撃を防ぎ、セキュリティを向上することができる。よって、高速かつ安全な暗号化通信を実現させることができる。
[3.通信システムSの応用例]
次に、図8〜図10を参照して、通信システムSの応用例について説明する。
(応用例1)
応用例1では、DE2がアクセス可能なサーバが複数存在するケースを想定する。図8は、応用例に係る通信システムSの概要構成例を示す図であり、図9は、DE2がサーバからデータを受信したときの処理の一例を示すフローチャートである。図8に示すように、応用例に係る通信システムSは、サーバ1a〜サーバ1c、DE2、及びSE3等を含んで構成される。例えば、サーバ1aは、機密性の高いデータ(重要な情報を含む)を配信するサーバであり、サーバ1b及びサーバ1cは、機密性の高くないデータを配信するサーバであるとする。サーバ1aの例として、発行データ配信サーバが挙げられ、サーバ1bの例として、利用データ配信サーバが挙げられ、サーバ1cの例として、時刻データ配信サーバが挙げられる。
DE2のデバイス制御部25は、上記ステップS1を実行する前に、アクセス先のサーバが機密性の高いデータを配信するサーバであるか否かを判定する。例えば機密性の高いデータを配信するサーバの情報(例えばURLやIPアドレス)を登録するリストを予め取得しておき、このリストに基づいて、アクセス先のサーバが機密性の高いデータを配信するサーバであるか否かが判定されるとよい。例えば、アクセス先のサーバがサーバ1aである場合、DE2のデバイス制御部25は、当該アクセス先のサーバ1aが機密性の高いデータを配信するサーバであると判定し、上記セッション開始要求をSE3へ送信することでサーバ1aとSE3との間で暗号通信を行うためのセッションを確立するハンドシェイクを開始させる。一方、例えば、アクセス先のサーバがサーバ1bまたは1cである場合、DE2のデバイス制御部25は、当該アクセス先のサーバ1bまたは1cが機密性の高くないデータを配信するサーバであると判定し、上記セッション開始要求を送信することなく、DE2とサーバ1bまたは1cとの間で通信を行うことになる。
そして、図9に示す処理は、例えば、サーバ1a〜サーバ1cの何れか1のサーバからデータが受信され、当該データに基づいて実行された解析処理の結果が良好である場合に開始される。図9に示す処理が開始されると、DE2のデバイス制御部25は、受信されたデータがサーバ1aからのデータ(図4に示すデータD3)であるか否かを判定する(ステップS51)。サーバ1aからのデータであるか否かは、例えば、受信されたデータ中(IPヘッダ中)の送信元IPアドレスから判定される。DE2のデバイス制御部25は、受信されたデータがサーバ1aからのデータでないと判定した場合(ステップS51:NO)、ステップS52へ進む。一方、DE2のデバイス制御部25は、受信されたデータがサーバ1aからのデータであると判定した場合(ステップS51:YES)、ステップS55へ進む。
ステップS52では、DE2のデバイス制御部25は、受信されたデータがサーバ1bまたは1cからのデータであるか否かを判定する。DE2のデバイス制御部25は、受信されたデータがサーバ1bまたは1cからのデータでないと判定した場合(ステップS52:NO)、受信されたデータを破棄する(ステップS53)。一方、DE2のデバイス制御部25は、受信されたデータがサーバ1bまたは1cからのデータであると判定した場合(ステップS52:YES)、当該データに含まれるコマンドに応じた処理(例えば、DE2に搭載されるアプリケーションにデータを渡す)を実行する(ステップS54)。ステップS55では、DE2のデバイス制御部25は、受信されたデータについて上述したプロトコル変換を行うことで生成したデータ(図4に示すデータD4)をI/F部21を介してSE3へ送信する。
以上説明したように、応用例1によれば、DE2がアクセス可能なサーバが複数存在する場合、DE2が通信するサーバに応じて上記ハンドシェイクを実施させるかどうかを判断するように構成したので、セキュリティを維持しつつ、SE3の処理負荷を低減させることができる。
(応用例2)
応用例2では、TCP/IPプロトコルとSE用プロトコルとで1度に(つまり、1回で)送受信可能なデータ長が異なるケースを想定する。図10(A)は、DE2がSE3へデータを送信するとき処理の一例を示すフローチャートであり、図10(B)は、DE2がサーバ1(またはサーバ1a)へデータを送信するときの処理の一例を示すフローチャートである。例えば、TCP/IPプロトコルで1度に送受信可能なデータ長が4096バイトであるとし、SE用プロトコルで1度に送受信可能なデータ長が256バイトであるとする。
図10(A)に示す処理は、SE3との間で暗号通信を行うためのセッションが確立されたサーバ1(またはサーバ1a)からデータが受信され、上述したプロトコル変換が行われたときに開始される。図10(A)に示す処理が開始されると、DE2のデバイス制御部25は、SE3へ送信すべきデータの残りデータ長が所定長(例えば、256バイト)より大きいか否かを判定する(ステップS61)。DE2のデバイス制御部25は、SE3へ送信すべきデータの残りデータ長が所定長より大きくないと判定した場合(ステップS61:NO)、当該データ(図4に示すデータD4)をI/F部21を介してSE3へ送信する(ステップS62)。一方、DE2のデバイス制御部25は、SE3へ送信すべきデータの残りデータ長が所定長より大きいと判定した場合(ステップS61:YES)、当該データを分割し(ステップS63)、分割されたデータをI/F部21を介してSE3へ送信する(ステップS64)。次いで、DE2のデバイス制御部25は、残りデータ長を減算し(ステップS65)、ステップS61に戻る。
図4に示すデータD4を例にとると、分割対象は暗号化コマンドであり、APDUヘッダ及びLcを付加したデータのデータ長が256バイト以下になるように暗号化コマンドが分割される(このときLcが参照される)。例えば、APDUヘッダとLcとの合計のデータ長が5バイトであるとすると、暗号化コマンドから251バイト分のデータが分割により抽出され、当該抽出されたデータにAPDUヘッダとLcが付加されたデータ(つまり、256バイトのデータ)がSE3へ送信される。これにより、残りデータ長から251バイトが減算され、次に送信すべきデータの残りデータ長は、分割された暗号化コマンドのうち未送信のデータにAPDUヘッダ及びLcが付加されたデータとなる。そして、次に続くステップS61において、次に送信すべきデータの残りデータ長が256バイトより大きい場合、上記と同様、ステップS63〜S65の処理が行われる一方、次に送信すべきデータの残りデータ長が256バイトより大きくない場合、ステップS62の処理が行われる。例えば、SE3へ送信すべきデータが500バイトであるとすると、当該データは2回に分けてSE3へ送信されることになる。なお、ステップS62で送信されるデータに含まれるAPDUヘッダ中のP2は後続データの無を示す値(例えば、0x00)に設定される一方、ステップS64で送信されるデータに含まれるAPDUヘッダ中のP2は後続データの有を示す値(例えば、0x01)に設定される。
一方、図10(B)に示す処理は、サーバ1(またはサーバ1a)との間で暗号通信を行うためのセッションが確立されたSE3からデータが受信されたときに開始される。なお、図10(B)に示す処理は、SE3においてデータが分割され、分割されたデータが複数回に分けてDE2へ送信されることに対応可能な処理である。図10(B)に示す処理が開始されると、DE2のデバイス制御部25は、サーバ1(またはサーバ1a)へ送信すべきデータの残りがあるか(言い換えれば、後から次のデータが送信されてくるか)否かを判定する(ステップS71)。DE2のデバイス制御部25は、サーバ1(またはサーバ1a)へ送信すべきデータの残りがないと判定した場合(ステップS71:NO)、SE3から受信された全データ(連結されたデータを含む)について上述したプロトコル変換を行うことで生成したデータ(図5に示すデータD8)を通信部23を介してサーバ1へ送信する(ステップS72)。一方、DE2のデバイス制御部25は、サーバ1(またはサーバ1a)へ送信すべきデータの残りがあると判定した場合(ステップS71:YES)、後から送信されてきた次のデータを受信する(ステップS73)。次いで、DE2のデバイス制御部25は、当該受信された次のデータを、先に受信されたデータに連結し(ステップS74)、ステップS71に戻る。こうして、ステップS71でデータの残りがないと判定されるまで、データの連結が行われる。
以上説明したように、応用例2によれば、DE2はサーバ1(またはサーバ1a)から受信されたデータのデータ長に応じて、当該データを分割して複数回に分けてSE3へ送信するように構成したので、TCP/IPプロトコルとSE用プロトコルとで1度に送受信可能なデータ長が異なるケースに柔軟に対応することができる。また、DE2は、SE3から複数回に亘って受信されたデータを連結してサーバ1(またはサーバ1a)へ送信するように構成したので、サーバ1(またはサーバ1a)へのデータ送信の効率化を図ることができる。