(57)【要約】【課題】メインシステムの暗号処理対象データのサイズがサブシステムのメモリ容量よりも大きい場合であっても、暗号処理対象データサイズ、サブシステムの搭載メモリ量、メインシステムとサブシステム間のデータ転送能力によらず暗号処理を実現することができる。【解決手段】メインプログラムで動作するメインシステム１１と、サブプログラムで動作するとともに該メインシステム１１の制御下で動作する複数のサブシステム１２が所定のバスによって離接可能に接続されている複合システムにおいて、メインシステム１１は、暗号処理の対象となるデータを分割したデータ断片ごとにサブシステム１２に転送し、サブシステム１２は、メインシステム１１から受信したデータ断片を一時的に書き込み／読み出し可能な受信バッファ１２ｆを有する。【選択図】図１
2013141137.tif 000002
【特許請求の範囲】
【請求項１】
メインプログラムで動作するメインシステムと、サブプログラムで動作するとともに該メインシステムの制御下で動作する複数のサブシステムが所定のバスによって離接可能に接続されている複合システムにおいて、
前記メインシステムは、
暗号処理の対象となるデータを分割したデータ断片ごとにサブシステムに転送する転送手段を有し、
前記サブシステムは、
前記メインシステムから受信したデータ断片を一時的に書き込み／読み出し可能な受信バッファを有し、
前記メインシステムの暗号処理の対象となるデータのサイズが、前記サブシステムの受信バッファの容量よりも大きい場合であっても、前記メインシステムと前記サブシステムとの間で暗号処理を行う、ことを特徴とする複合システム。
【請求項２】
前記サブシステムは、公開鍵を保存するためのセキュアデータベースを有することを特徴とする請求項１記載の複合システム。
【請求項３】
前記サブシステムは、セキュアデータベースにアクセス可能な暗号アプリサーバを有することを特徴とする請求項２記載の複合システム。
【請求項４】
前記暗号アプリサーバが、データ整列ルールを示す情報を保存することを特徴とする請求項３記載の複合システム。
【請求項５】
前記サブシステムは、データ整列ルールを示す情報を保存し、セキュアデータベースにアクセス可能な暗号アプリサーバを実行することを特徴とする請求項２記載の複合システム。
【請求項６】
前記メインシステムは、暗号アプリサーバからデータ整列ルールを取得する前記暗号利用アプリを実行することを特徴とする請求項５記載の複合システム。
【請求項７】
前記メインシステムは、前記メインシステムと前記サブシステムとを接続するバスの種類を判定する分割判定部を有することを特徴とする請求項１乃至６の何れか１項に記載の複合システム。
【請求項８】
前記メインシステムは、前記分割処理を前記暗号利用アプリから隠蔽することが可能な暗号処理プロキシを有することを特徴とする請求項１乃至７の何れか１項に記載の複合システム。
【請求項９】
前記メインシステムは、前記対象データを変換した結果に対するデジタル署名を複数保持することを特徴とする請求項１乃至８の何れか１項に記載の複合システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、メインシステムから暗号処理の対象となるデータをサブシステムに転送する複合システムに関する。
【背景技術】
【０００２】
従来、複数のシステムを複合した複合システムが構築されるようになってきており、サブシステムそれぞれがＣＰＵ（Central Processing Unit ）を搭載して当該サブシステムを制御するとともに、メインシステムのＣＰＵの制御下で全体の動作制御を行うようになってきている。
【０００３】
そして、このような複合システムにおいては、サブシステムの接続と切り離しが容易であることから、複合システム内に蓄積されているユーザの個人的な情報を保護することが重要な問題となってきている。このような複合システムにおいては、サブシステムになりすましたソフトウエアの不正改ざんや情報の漏洩が問題となっている。
【０００４】
また、従来、省エネ高速暗号通信を実現するため、暗号処理ハードウエアを搭載したサブボードが提案されている。
この技術は、メインシステムには暗号処理機能を搭載せず、サブシステムの暗号機能を利用する構成にした。
【０００５】
このため、ファームウエアデータ（例えば、30MB程度）の正当性を確認する暗号処理をサブシステムで行う必要があった。
しかし、サブシステムのコストダウンのためメモリ量を極小(数百KB程度)にしたため、サブシステムのメモリ上にデータを全て載せられなかった。
【０００６】
特許文献１では、サブシステムになりすました攻撃からセキュリティを確実に確保するメインシステムとサブシステムからなる複合システム、セキュリティ方法、セキュリティプログラム及び記録媒体を提供するという技術が開示されている。
特許文献２では、ファームウエアデータを制御装置を介して記憶装置に書き込む際の通信時間をできるだけ短縮させることができるファームウエアデータの書込み方法を提供するという技術が開示されている。
【発明の概要】
【発明が解決しようとする課題】
【０００７】
しかしながら、特許文献１では、暗号処理の対象となる大きなデータに対して、暗号処理を他のシステムに委譲する構成ではなかった。また、特許文献２では、ファームウエアの書き込み時の分割高速化を行うため、書き込み前の正当性検証時点での分割とは異なっていた。
このため、特許文献１、２では、暗号機能を備えたサブシステム（機種共通）を利用した暗号処理（ファームウエア正当性検証など）において、メインシステムの暗号処理対象データ（ファームウエア）のサイズがサブシステムのメモリ量より大きいため処理ができないといった問題があった。
【０００８】
以上のように、暗号処理対象のデータサイズ、サブシステムの搭載メモリ量、メインシステムとサブシステム間のデータ転送能力に暗号処理が依存しているため、メインシステムの暗号処理対象データ（ファームウエア）のサイズがサブシステムのメモリ容量よりも大きい場合には、暗号処理ができないといった問題があった。
【０００９】
本発明は上記事情に鑑みなされたものであって、メインシステムの暗号処理対象データのサイズがサブシステムのメモリ容量よりも大きい場合であっても、暗号処理対象データサイズ、サブシステムの搭載メモリ量、メインシステムとサブシステム間のデータ転送能力によらず暗号処理を実現することができる複合システムを提供することを目的とする。
【課題を解決するための手段】
【００１０】
上記課題を解決するたに、請求項１記載の発明は、メインプログラムで動作するメインシステムと、サブプログラムで動作するとともに該メインシステムの制御下で動作する複数のサブシステムが所定のバスによって離接可能に接続されている複合システムにおいて、前記メインシステムは、暗号処理の対象となるデータを分割したデータ断片ごとにサブシステムに転送する転送手段を有し、前記サブシステムは、前記メインシステムから受信したデータ断片を一時的に書き込み／読み出し可能な受信バッファを有し、前記メインシステムの暗号処理の対象となるデータのサイズが、前記サブシステムの受信バッファの容量よりも大きい場合であっても、前記メインシステムと前記サブシステムとの間で暗号処理を行う、ことを特徴とする複合システムである。
【発明の効果】
【００１１】
本発明によれば、メインシステムは、暗号処理の対象となるデータを分割したデータ断片ごとにサブシステムに転送し、サブシステムは、メインシステムから受信したデータ断片を一時的に書き込み／読み出し可能な受信バッファを有し、前記メインシステムの暗号処理の対象となるデータのサイズが、前記サブシステムの受信バッファの容量よりも大きい場合であっても、前記メインシステムと前記サブシステムとの間で暗号処理を行うことで、暗号処理対象データサイズ、サブシステムの搭載メモリ量、メインシステムとサブシステム間のデータ転送能力によらず暗号処理を実現することができる。
【図面の簡単な説明】
【００１２】
【図１】本発明の第１実施形態に係る複合システムについて説明するためのブロック図、フローチャートである。
【図２】図１に示すメインシステム１１とサブシステム１２との間における転送シーケンス図である。
【図３】本発明の第１実施形態に係る複合システムに用いるデジタル著名および公開鍵に関するデータ構造について説明するための図である。
【図４】本発明の第２実施形態に係る複合システムについて説明するためのブロック図である。
【図５】図４に示すメインシステム１１とサブシステム１２との間における転送シーケンス図である。
【図６】本発明の第３実施形態に係る複合システムに用いる転送シーケンス図である。
【図７】本発明の第４実施形態に係る複合システムに用いる転送シーケンス図である。
【図８】本発明の第５実施形態に係る複合システムに用いる転送シーケンス図である。
【図９】本発明の第６実施形態に係る複合システムに用いる転送シーケンス図である。
【図１０】本発明の第７実施形態に係る複合システムについて説明するためのブロック図、フローチャートである。
【図１１】本発明の第７実施形態に係る複合システムに用いる転送シーケンス図である。
【図１２】本発明の第８実施形態に係る複合システムについて説明するためのブロック図である。
【図１３】本発明の第８実施形態に係る複合システムに用いる転送シーケンス図である。
【図１４】本発明の第９実施形態に係る複合システムについて説明するためのフローチャートである。
【図１５】本発明の第９実施形態に係る複合システムに用いるファームウエア正当性検証の対象となるファームウエアデータのデータ構造を示す図である。
【図１６】本発明の第９実施形態に係る複合システムに用いる転送シーケンス図である。
【発明を実施するための形態】
【００１３】
以下、本発明を実施するための最良の形態について、図に示す実施形態を参照して説明する。
＜第１実施形態＞
まず、本発明の第１実施形態に係る複合システムについて説明する。
図１は、本発明の第１実施形態に係る複合システムについて説明するためのブロック図である。
図１（ａ）において、複合システム１は、メインシステム１１、サブシステム１２を備えている。ネットワークに接続するネットワーク通信部（図示しない）を備えており、メインシステム１１とサブシステム１２とは、ＵＳＢ（Universal Serial Bus）でそれぞれ接続されており、ＵＳＢは通信手段として機能している。
【００１４】
メインシステム１１は、ＣＰＵ１１ａ、メモリ１１ｂ、ストレージ１１ｃ、外部接続端子１１ｄを備えており、それぞれ内部バスにより接続されている。
ストレージ１１ｃには、ファームウエア（Ｆ／Ｗ）を更新可能なアプリケーションソフトウエアとして暗号利用アプリケーションソフトウエアが記憶されている。メインシステム１１の起動時には、ＣＰＵ１１ａがストレージ１１ｃから暗号利用アプリを順次に読み出して各ステップを実行する。
【００１５】
サブシステム１２は、ＣＰＵ１２ａ、メモリ１２ｂ、暗号処理器１２ｃ、接続端子１２ｄ、受信バッファ１２ｆを備えており、それぞれ内部バスにより接続されている。
メモリ１２ｂには、ＣＰＵ１２ａにより暗号アプリサーバ１４ａとして実行されるアプリケーションソフトウエアが記憶されている。
【００１６】
サブシステム１２の起動時には、ＣＰＵ１２ａがメモリ１２ｂからアプリケーションソフトウエアを順次に読み出して各ステップを実行することで、暗号アプリサーバ１４ａが実行される。
暗号処理器１２ｃは、暗号処理エンジン１４ｂとして動作する。
受信バッファ１２ｆは、メインシステム１１から受信したデータ断片を一時的に書き込み／読み出しを可能とする。
【００１７】
本実施形態では、サブシステム１２に関する製造コストを削減するため、メモリ１２ｂの容量を極小(数百KB程度)にしたため、サブシステム１２のメモリ１２ｂ上にメインシステムから受信する暗号処理の対象となるデータを全て載せられなかった。
また、本実施形態では、従来技術のように、メモリ１２ｂを用いて暗号処理の対象となるデータ全体を１回だけhashし、後にverify処理を行うという通常の方法では正当性検証ができなくなった。
【００１８】
そこで、本実施形態では、メインシステム１１からサブシステム１２の受信バッファ１２ｆにデータを分割して転送し、データ断片単位でN回hashし、後にverify処理を行うという、データ断片単位で暗号処理する方法をとった。
【００１９】
次に、図１（ｂ）に示すフローチャートを参照して、メインシステム１１における暗号利用アプリ１３ａによる処理動作を説明する。
まず、ステップＳ１０では、ＣＰＵ１１ａは、暗号利用の初期処理を行う。
次いで、ステップＳ２０では、ＣＰＵ１１ａは、データ分割が必要であるか否かを判断する。
【００２０】
すなわち、ＣＰＵ１１ａは、サブシステム１２側の受信バッファ１２ｆのサイズ(16KB)とファームウエア（F/W）のデータのサイズ(30MB)が既知であるので、ファームウエアのデータ容量をデータ断片に分割し、分割後のデータ断片のサイズも固定とする。
【００２１】
ここで、データ分割が必要な場合にはステップＳ３０に進む。一方、データ分割が必要ではない場合にはステップＳ５０に進む。
次いで、ステップＳ３０では、ＣＰＵ１１ａは、分割データの転送と、暗号処理を行う。
次いで、ステップＳ４０では、ＣＰＵ１１ａは、残分割データがあるか否かを判断する。
【００２２】
ここで、残分割データがある場合にはステップＳ３０に戻り、上記処理を繰り返す。一方、残分割データがない場合にはステップＳ５０に進む。
次いで、ステップＳ５０では、ＣＰＵ１１ａは、暗号利用の最終処理を行う。
【００２３】
次に、図２を参照して、メインシステム１１とサブシステム１２との間における転送シーケンスについて説明する。
まず、手順Ｓｅ１では、ＣＰＵ１１ａにより実行される暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデジタル署名と公開鍵を、外部接続端子１１ｄ、接続端子１２ｄを介してサブシステム１２に設けられたＣＰＵ１２ａにより実行される暗号アプリサーバ１４ａに送信する。
【００２４】
次いで、ＣＰＵ１２ａにより実行される暗号アプリサーバ１４ａは、デジタル署名と公開鍵をメモリ１２ｂに記憶しておく。
次いで、手順Ｓｅ２では、暗号アプリサーバ１４ａは、暗号処理器１２ｃの利用権獲得に関する指示を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ３では、暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデータ断片を暗号アプリサーバ１４ａに送信する。
【００２５】
次いで、手順Ｓｅ４では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにhash処理を行わせるために利用権とデータ断片を暗号処理エンジン１４ｂに出力する。
なお、図２に示すように、手順Ｓｅ３、手順Ｓｅ４については残データが無くなり、最終データ断片となるまで繰り返して行う。
【００２６】
ここで、図２を参照して、最終データ断片の場合の手順について説明する。
手順Ｓｅ５では、暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のために最終データ断片を暗号アプリサーバ１４ａに出力する。
次いで、手順Ｓｅ６では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにhash処理を行わせるために利用権と最終のデータ断片とを暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ７では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにverify処理を行わせるために利用権と公開鍵およびデジタル署名、データhash結果を暗号処理エンジン１４ｂに出力する。
【００２７】
次いで、手順Ｓｅ８では、暗号処理エンジン１４ｂは、暗号処理器１２ｃで行ったverify処理結果（）となる真／偽値を暗号アプリサーバ１４ａに出力する。
次いで、手順Ｓｅ８では、暗号アプリサーバ１４ａは、暗号処理エンジン１４ｂから受け取ったＦ／Ｗ正当性確認の結果応答（）となる真／偽値を暗号利用アプリ１３ａに出力する。
【００２８】
ここで、ファームウエア正当性検証の対象となるファームウエアデータのデータ構造の概要について説明する。
署名は、HeaderとしてSignatureBとデータ、CertificateとしてSignatureAとpublic-keyB、イメージデータを含む。
ファームウエアデータは、例えば３つのファームウエアをひとまとめにした構成に対して１つの署名を付加するように構成してもよい。
【００２９】
次に、デジタル署名検証における各データの役割について説明する。
例えば、デジタル署名検証は２段階で行われる。
第１段階のVerify処理では、正当性を確認する範囲となるpublic-keyBを対象として、public-keyAを用いVerify処理を行う。
第２段階のVerify処理では、正当性を確認する範囲となるデータとイメージデータとを連結したデータを対象として、public-keyBを用いVerify処理を行う。
【００３０】
詳しくは、「検証したいバイト列」に対し、「public-keyA（公開鍵）とSignature（デジタル署名）のペア」を用いて検証する。
２段階目にあたるイメージデータの検証の際は、Headerのデータとバイナリ結合したデータを、「検証したいバイト列」と見なす。
この処理のアルゴリズムは、例えばECDSA(楕円曲線暗号アルゴリズムによるDSA署名)を用いる。
【００３１】
ここで、暗号処理エンジン１４ｂによる任意長データ断片の処理について説明する。署名検証のコンテキストを表す構造体(SingedObjContext)のフィールド定義としては、例えば、コンテキスト、署名用公開鍵、hashコンテキスト、署名用バッファ、署名、検証用公開鍵、端数データ一次格納領域などを用いるのが好ましい。
サブシステム１２において、検証対象のデータは、メインシステム１１の外部接続端子１１ｄであるUSBバス、接続端子１２ｄを通して受信バッファ１２ｆに一部の断片（任意長）ずつ格納（上書き）される。
【００３２】
一方で、暗号処理エンジン１４ｂでは、hash操作は複数回のhash関数呼び出しで最終的なhash値を求めることができるが、最後のhash関数呼び出し以外では、64Bの倍数分ずつしかhash処理ができない。
そこで、ACCLでは署名検証時に64B長の受信バッファ１２ｆを用意し、署名検証途中で出る64B以下の端数のデータをここにバッファする。
【００３３】
この受信バッファ１２ｆにより、断片データが入力されたときのサブシステム１２の暗号処理エンジン１４ｂによる動作は、以下の３つのステップ（Ｓｂ１〜Ｓｂ３）となる。
Ｓｂ１：受信バッファ１２ｆが空でないときは、受信バッファ１２ｆをフルにして64B分だけhash処理を行う。
Ｓｂ２：断片データの残余のうち64の倍数分を一括してhash処理を行う。
Ｓｂ３：１，２の残余データ（64B以下）を再び受信バッファ１２ｆに格納する。
【００３４】
ここで、ステップＳｂ１，Ｓｂ２で２回hash実行している点については、「機器」モジュールが受信バッファ１２ｆの処理サイズの最適化を図ることにより、ステップＳｂ１を省略することができる。
なお、上記の最適化は効果が不明なため、実際に行うかはSoC上での実測結果を待つ必要がある。
【００３５】
ここで、図３を参照して、デジタル著名および公開鍵に関するデータ構造について説明する。
正当性検証アルゴリズムに必要なデータは、主に、デジタル著名、公開鍵、検証の対象となるデータプログラムである。
ＡＰＩでは、デジタル署名およびデジタル署名検証の対象データは、例えば１組にして作成する。
公開鍵は、１つの構造体であり、メインシステム１１側のストレージ１１ｃ（マスクＲＯＭ）に記憶されているプログラムに内蔵されている。
【００３６】
署名オブジェクトは、[HeaderSection]、[CertificateList]、[ImageSection]で構成される。
[HeaderSection]は、定義されたフォーマットであり、バージョンや署名などが格納されている。
[CertificateList]は、署名検証チェーンを利用する場合に必要なCertificateを格納する領域であり、領域サイズは可変であるが、本実施形態ではCertificateは１つだけ使用する。
[ImageSection]は、実行するプログラムを格納する領域、サイズは未定であるが、プログラムサイズが１６Byteの倍数でない場合、Oによるパディングが実施されている。
【００３７】
このように、暗号処理対象データを分割したデータ断片ごとに１回の転送手順により順次にサブシステム１２の受信バッファ１２ｆに転送し、hash処理させることで、メインシステムの暗号処理対象データのサイズがサブシステムのメモリ量よりも大きい場合であっても、暗号処理対象データサイズ、サブシステム１２の搭載メモリ量、メインシステムとサブシステム間のデータ転送能力等によらず暗号処理を実現することができる。
将来の様々なメインシステム１１との接続性を確保しつつ、サブシステム１２のメモリ１２ｂのメモリ量を低減することができ、コスト低減を実現することができる。
【００３８】
＜第２実施形態＞
図４、図５を参照して、本発明の第２実施形態に係る複合システムについて説明する。
第２実施形態に用いる図４、図５は、第１実施形態において用いたブロック図（図１）シーケンス図（図２）の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
第２実施形態では、図４に示すように、サブシステム１２にストレージ（セキュア）１２ｅ、セキュアＤＢ１４ｃを備え、図５に示すように、手順Ｓｅ２１を有することを特徴とする。
【００３９】
図４に示すように、サブシステム１２にはストレージ（セキュア）１２ｅを備えており、ストレージ（セキュア）１２ｅにはセキュアＤＢ１４ｃとして公開鍵が格納されている。
図５に示すように、手順Ｓｅ２１では、暗号利用アプリ１３ａは、公開鍵に関する参照（）指示をセキュアＤＢ１４ｃに送信する。この参照（）指示を受けたセキュアＤＢ１４ｃは、公開鍵を暗号利用アプリ１３ａに返信する。
【００４０】
このように、サブシステム１２にセキュアDB１４ｃを追加することで、メインシステム１１側でセキュリティ用データ（公開鍵）の安全な管理を必要とせずに、重要データ（F/W）のセキュリティを確保できる。同時に、メインシステムの開発コストを低減することができる。
【００４１】
＜第３実施形態＞
図４、図６を参照して、本発明の第３実施形態に係る複合システムについて説明する。
第３実施形態に用いる図４、図６は、第１実施形態において用いたシステム図（図１）、シーケンス図（図２）の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
第２実施形態では、図６に示すように、手順Ｓｅ１−１を有することを特徴とする。
図４に示すように、サブシステム１２にはストレージ（セキュア）１２ｅを備えており、ストレージ（セキュア）１２ｅにはセキュアＤＢ１４ｃとして公開鍵が格納されている。
【００４２】
手順Ｓｅ１−１では、ＣＰＵ１１ａにより実行される暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデジタル署名を、外部接続端子１１ｄ、接続端子１２ｄを介してサブシステム１２に設けられたＣＰＵ１２ａにより実行される暗号アプリサーバ１４ａに送信する。
【００４３】
暗号アプリサーバ１４ａは、セキュアＤＢ１４ｃから公開鍵を読み出すことで、手順Ｓｅ７において公開鍵に用いることができる。
このように、サブシステム１２に設けられた暗号アプリサーバ１４ａのみがセキュアDB１４ｃにアクセス可能にすることで、効率の良い、すなわち、暗号利用アプリの手順減少や、わずかに高速化した暗号処理を実行することができる。
【００４４】
＜第４実施形態＞
図７を参照して、本発明の第４実施形態に係る複合システムについて説明する。
第４実施形態に用いる図７は、第１実施形態において用いたシーケンス図（図２）の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
暗号アプリサーバ１４ａには、データ整列ルール（例えば、hashはデータサイズが64の倍数であること）を保持していることとする。
【００４５】
第４実施形態では、図７に示すように、手順Ｓｅ４−１に加えて手順Ｓｅ４−２、手順Ｓｅ６−１に加えて手順Ｓｅ６−２を有していることを特徴とする。
手順Ｓｅ３に用いる断片データは、整列不要、すなわち、整列の例として、例えばデータサイズが６４バイトの倍数であることである。
【００４６】
手順Ｓｅ４−１でのhash処理では、前回のhash処理で整列した余りと、今回のhash処理の冒頭データを結合してhash処理させる。
手順Ｓｅ４−２でのhash処理では、今回の冒頭を除いたデータの整列可能な最大サイズまでhash処理させる。
なお、整列した余り(例： datasize % 64)を一時的にメモリ１２ｂに格納する。
【００４７】
このように、暗号アプリサーバ１４ａがデータ整列に関するルール情報を持つことで、暗号利用アプリ１３ａがサブシステム１２の暗号処理エンジン１４ｂの制約（例えばhash処理は６４の倍数で入力など）を考慮せず、任意サイズでデータ転送できるようになり、サブシステム１２の暗号処理エンジン１４ｂに対する改訂の影響、すなわち、暗号利用アプリ１３ａの改訂コストを低減することができる。
【００４８】
＜第５実施形態＞
図８を参照して、本発明の第５実施形態に係る複合システムについて説明する。
第５実施形態に用いる図８は、第４実施形態において用いたシーケンス図（図７）の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
第５実施形態では、セキュアＤＢ１４ｃに公開鍵を予め保持していることを特徴とする。
図４に示すように、サブシステム１２にはストレージ（セキュア）１２ｅを備えており、ストレージ（セキュア）１２ｅにはセキュアＤＢ１４ｃとして公開鍵が格納されている。
【００４９】
手順Ｓｅ１−２では、ＣＰＵ１１ａにより実行される暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデジタル署名を、外部接続端子１１ｄ、接続端子１２ｄを介してサブシステム１２に設けられたＣＰＵ１２ａにより実行される暗号アプリサーバ１４ａに送信する。
【００５０】
暗号アプリサーバ１４ａは、セキュアＤＢ１４ｃから公開鍵を読み出すことで、手順Ｓｅ７において公開鍵に用いることができる。
手順Ｓｅ３−２に用いる断片データは、整列不要、すなわち、整列の例としてデータサイズが６４バイトの倍数である必要はない。
【００５１】
このように、サブシステム１２にセキュアDB１４ｃを追加することで、メインシステム１１側でセキュリティ用データ（公開鍵）の安全な管理を必要とせずに、重要データ（F/W）のセキュリティを確保できる。同時に、メインシステムの開発コストを低減することができ、さらに、暗号アプリサーバ１４ａがデータ整列に関するルール情報を持つことで、暗号利用アプリ１３ａがサブシステム１２の暗号処理エンジン１４ｂの制約（例えばhash処理は６４の倍数で入力など）を考慮せず、任意サイズでデータ転送できるようになり、サブシステム１２の暗号処理エンジン１４ｂに対する改訂の影響、すなわち、暗号利用アプリ１３ａの改訂コストを低減することができる。
これに加えて、暗号利用アプリ１３ａが暗号仕様をほとんど意識しなくて良いように構成することができる。
【００５２】
＜第６実施形態＞
図９を参照して、本発明の第６実施形態に係る複合システムについて説明する。
第６実施形態に用いる図９は、第２実施形態において用いたシーケンス図（図２）の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
【００５３】
第６実施形態では、手順Ｓｅ１１において、暗号アプリサーバ１４ａが整列サイズ仕様を暗号利用アプリ１３ａへ送信することを特徴とする。ここで、整列サイズ仕様は、
仕様＝｛整列サイズ基数、最小値、最大値｝
と定義し、例えば、｛例：64B, 64B, 128KB｝と設定するのが好ましい。
【００５４】
また、手順Ｓｅ３−３、４−３、５−３、６−３において転送されるデータ断片は、上記仕様により整列済みのデータ断片であることを特徴とする。
ここで、例えば、手順Ｓｅ４−３では、hash処理の回数が減少するので、整列のコスト（メモリ１１ｂと受信バッファ１２ｆとの間、受信バッファ１２ｆとメモリ１２ｂとの間のメモリコピー）も減少する。
【００５５】
このように、転送に先立って、暗号利用アプリ１３ａが暗号アプリサーバ１４ａからデータ整列ルールを取得することで、暗号利用アプリ１３ａはサブシステム１２におけるデータ整列のコスト（hash回数増）を回避しつつ、サブシステム１２の仕様変更（例えばhashは６４の倍数から１６の倍数で入力への変更など）の影響（暗号利用アプリの改訂コスト）を低減することができる。
【００５６】
＜第７実施形態＞
図１０を参照して、本発明の第７実施形態に係る複合システムについて説明する。
第７実施形態に用いる図１０は、第１実施形態において用いたシステム図およびフローチャート（図２）の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
【００５７】
第７実施形態では、図１０（ａ）に示すように、メインシステム１１が分割判定部１３ｂをソフトウエアとして有することを特徴とする。
分割判定部１３ｂでは、バスの種別から分割転送の必要性を判定する。なお、外部接続端子１１ｄとしては、例えばPCIe（Peripheral Component Interconnect Express）バス、USBバスを備えていることとする。
【００５８】
図１０（ｂ）に示すフローチャートにおいて、ステップＳ１１０では、メモリ共有が可能か否かを判断する。すなわち、バス種別(例えば、PCIｅバス?／USBバス?)に基づいてメモリ共有が可能か否かを判定する。ここで、バス種別がPCIバスの場合にはデータ共有が可能なのでステップＳ１２０に進む。一方、バス種別がUSBバスの場合にはデータ共有が不可能なのでステップＳ２０に進む。
【００５９】
次いで、バス種別がPCIeバスの場合には、メインシステム１１とサブシステム１２との間でデータ共有が可能なので、ステップＳ１２０では、大データに対する一括の中間の暗号処理を行う。
一方、バス種別がUSBバスの場合にはデータ共有が不可能であるので、ステップＳ２０では、データ分割が必要か否かを判断する。すなわち、データの大きさに基づく判定を行う。
【００６０】
次に、図１１を参照して、メインシステム１１とサブシステム１２との間における転送シーケンスについて説明する。
まず、手順Ｓｅ２１では、ＣＰＵ１１ａにより実行される暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデジタル署名と公開鍵を、分割判定部１３ｂに出力する。
次いで、手順Ｓｅ２２では、分割判定部１３ｂは、Ｆ／Ｗ正当性確認のためにデジタル署名と公開鍵を、外部接続端子１１ｄ、接続端子１２ｄを介してサブシステム１２に設けられたＣＰＵ１２ａにより実行される暗号アプリサーバ１４ａに送信する。
【００６１】
次いで、ＣＰＵ１２ａにより実行される暗号アプリサーバ１４ａは、デジタル署名と公開鍵をメモリ１２ｂに記憶しておく。
次いで、手順Ｓｅ２３では、暗号アプリサーバ１４ａは、暗号処理器１２ｃの利用権獲得に関する指示を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ２４では、暗号利用アプリ１３ａは、分割が必要か否かを問い合わせる分割必要？（）指示を分割判定部１３ｂに出力する。分割判定部１３ｂでの処理は、図１３（ｂ）に示す通りである。
【００６２】
以下、分割が不要な場合の処理について説明する。
次いで、手順Ｓｅ２５では、暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデータ全体を分割判定部１３ｂに出力する。
次いで、手順Ｓｅ２６では、分割判定部１３ｂは、Ｆ／Ｗ正当性確認のためにデータ全体を暗号アプリサーバ１４ａに送信する。
【００６３】
次いで、手順Ｓｅ２７では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにhash処理を行わせるために利用権とデータ断片を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ２８では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにverify処理を行わせるために利用権と公開鍵およびデジタル署名、データhash結果を暗号処理エンジン１４ｂに出力する。
【００６４】
次いで、手順Ｓｅ２９では、暗号処理エンジン１４ｂは、暗号処理器１２ｃで行ったverify処理結果（）となる真／偽値を暗号アプリサーバ１４ａに出力する。
次いで、手順Ｓｅ３０では、暗号アプリサーバ１４ａは、暗号処理エンジン１４ｂから受け取ったＦ／Ｗ正当性確認の結果応答（）となる真／偽値を分割判定部１３ｂに出力する。
次いで、手順Ｓｅ３１では、分割判定部１３ｂは、暗号アプリサーバ１４ａから受け取ったＦ／Ｗ正当性確認の結果応答（）となる真／偽値を暗号利用アプリ１３ａに出力する。
【００６５】
このように、バス種類を判定する分割判定部１３ｂを有することで、システム間の接続形態となるバス種類によって、例えばPCIeバスの場合、高速化が可能になる。すなわち、PCIeバスではメインシステム１１とサブシステム１２との間でメモリ共有が可能であり、そもそも分割転送が不要となるため、高速化が可能になる。
【００６６】
＜第８実施形態＞
図１２を参照して、本発明の第８実施形態に係る複合システムについて説明する。
第８実施形態に用いる図１２は、第７実施形態において用いたシステム図（図１０）の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
第８実施形態では、図１２に示すように、メインシステム１１が暗号プロキシ１３ｃ（分割判定部１３ｂを含む）をソフトウエアとして有することを特徴とする。
暗号プロキシ１３ｃは、メインシステムに設けておくことで、分割処理を暗号利用アプリから隠蔽するように動作する。
【００６７】
次に、図１３を参照して、メインシステム１１とサブシステム１２との間における転送シーケンスについて説明する。
まず、手順Ｓｅ３１では、ＣＰＵ１１ａにより実行される暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデジタル署名と公開鍵を、暗号プロキシ１３ｃに出力する。
次いで、手順Ｓｅ３２では、暗号プロキシ１３ｃは、Ｆ／Ｗ正当性確認のためにデジタル署名と公開鍵を、外部接続端子１１ｄ、接続端子１２ｄを介してサブシステム１２に設けられたＣＰＵ１２ａにより実行される暗号アプリサーバ１４ａに送信する。
【００６８】
次いで、ＣＰＵ１２ａにより実行される暗号アプリサーバ１４ａは、デジタル署名と公開鍵をメモリ１２ｂに記憶しておく。
次いで、手順Ｓｅ３３では、暗号アプリサーバ１４ａは、暗号処理器１２ｃの利用権獲得に関する指示を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ３４では、暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデータ全体を、暗号プロキシ１３ｃに出力する。
【００６９】
以下、分割が必要な場合の処理について説明する。
次いで、手順Ｓｅ３５では、暗号プロキシ１３ｃは、Ｆ／Ｗ正当性確認のためにデータ断片を暗号アプリサーバ１４ａに送信する。
次いで、手順Ｓｅ３６では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにhash処理を行わせるために利用権と整列済みデータ断片を暗号処理エンジン１４ｂに出力する。
【００７０】
次いで、手順Ｓｅ３７では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにhash処理を行わせるために利用権と整列済みデータ断片を暗号処理エンジン１４ｂに出力する。
なお、手順Ｓｅ３７での処理は残データがなくなるまで繰り返す。
【００７１】
最終データ断片の場合、手順Ｓｅ３８では、暗号プロキシ１３ｃは、Ｆ／Ｗ正当性確認のためにデータ断片を暗号アプリサーバ１４ａに送信する。
次いで、手順Ｓｅ３９では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにhash処理を行わせるために利用権と整列済みデータ断片を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ４０では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにhash処理を行わせるために利用権と整列済みデータ断片を暗号処理エンジン１４ｂに出力する。
【００７２】
次いで、手順Ｓｅ４１では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにverify処理を行わせるために利用権と公開鍵およびデジタル署名、データhash結果を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ４２では、暗号処理エンジン１４ｂは、暗号処理器１２ｃで行ったverify処理結果（）となる真／偽値を暗号アプリサーバ１４ａに出力する。
【００７３】
次いで、手順Ｓｅ４３では、暗号アプリサーバ１４ａは、暗号処理エンジン１４ｂから受け取ったＦ／Ｗ正当性確認の結果応答（）となる真／偽値を暗号プロキシ１３ｃに出力する。
次いで、手順Ｓｅ４４では、暗号プロキシ１３ｃは、暗号アプリサーバ１４ａから受け取ったＦ／Ｗ正当性確認の結果応答（）となる真／偽値を暗号利用アプリ１３ａに出力する。
【００７４】
このように、メインシステム１２に暗号プロキシ１３ｃを設けることで、分割処理を暗号利用アプリから隠蔽することができる。暗号利用アプリ１３ａは、バス仕様による分割を考慮が不要になるため、サブシステム１２の暗号処理エンジン１４ｂの改訂の影響（暗号利用アプリの改訂コスト）を低減することができる。
【００７５】
＜第９実施形態＞
図１４を参照して、本発明の第９実施形態に係る複合システムについて説明する。
第８実施形態に用いる図１４は、第１実施形態において用いたシステム図（図１）および第７実施形態において用いたフローチャート（図１０（ｂ））の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
【００７６】
図１４に示すフローチャートにおいて、ステップＳ２１０では、暗号利用アプリ１３ａは、転送方式の選択処理と、改変データ生成処理とを行う。
本実施形態は、図１５に示すデータ定義のように、転送方式ＩＤに応じてデジタル著名および公開鍵を用意する。正当性検証時に、転送方式ＩＤに応じて、動的にF／Wデータ改変版をオリジナルとは別に生成することを特徴とする。
【００７７】
本実施形態は、図１６に示すシーケンス図のように、暗号利用アプリ１３ａにおいて、ステップＳ２１０−１では、転送方式ＩＤに応じて転送方式の選択処理を行う。
また、ステップＳ２１０−２では、転送方式ＩＤに応じて改変データ生成処理を行う。なお、転送方式ＩＤに応じて、新たに改変データ（ビット反転したファームウエアデータ）を生成する能力があるとする。例えば、転送方式ＩＤがＸＯＲの場合、転送方式（XOR）に応じたデジタル署名を暗号利用アプリ１３ａが暗号アプリサーバ１４ａに送付する。
【００７８】
このように、メインシステム１１において、対象データを変換した結果に対するデジタル署名をストレージ１１ｃに複数保持することで、データ転送経路上で盗聴されても、簡単には元データに復元できなくなるため、セキュリティ性能を向上することができる。
【符号の説明】
【００７９】
１１    メインシステム
１１ａ    ＣＰＵ
１１ｂ    メモリ
１１ｃ    ストレージ
１１ｄ    外部接続端子
１２    サブシステム
１２ａ    ＣＰＵ
１２ｂ    メモリ
１２ｃ    暗号処理器
１２ｄ    接続端子
１２ｆ    受信バッファ
【先行技術文献】
【特許文献】
【００８０】
【特許文献１】特開２０１１−１６４８１０号公報
【特許文献２】特開２０００−１４８５０２号公報
【図１】
2013141137.tif 000003
【図２】
2013141137.tif 000004
【図３】
2013141137.tif 000005
【図４】
2013141137.tif 000006
【図５】
2013141137.tif 000007
【図６】
2013141137.tif 000008
【図７】
2013141137.tif 000009
【図８】
2013141137.tif 000010
【図９】
2013141137.tif 000011
【図１０】
2013141137.tif 000012
【図１１】
2013141137.tif 000013
【図１２】
2013141137.tif 000014
【図１３】
2013141137.tif 000015
【図１４】
2013141137.tif 000016
【図１５】
2013141137.tif 000017
【図１６】
2013141137.tif 000018