JP2013141137A - 複合システム - Google Patents
複合システム Download PDFInfo
- Publication number
- JP2013141137A JP2013141137A JP2012000482A JP2012000482A JP2013141137A JP 2013141137 A JP2013141137 A JP 2013141137A JP 2012000482 A JP2012000482 A JP 2012000482A JP 2012000482 A JP2012000482 A JP 2012000482A JP 2013141137 A JP2013141137 A JP 2013141137A
- Authority
- JP
- Japan
- Prior art keywords
- data
- subsystem
- main system
- cryptographic
- encryption
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
- H04L9/3252—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using DSA or related signature schemes, e.g. elliptic based signatures, ElGamal or Schnorr schemes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/572—Secure firmware programming, e.g. of basic input output system [BIOS]
Abstract
【課題】メインシステムの暗号処理対象データのサイズがサブシステムのメモリ容量よりも大きい場合であっても、暗号処理対象データサイズ、サブシステムの搭載メモリ量、メインシステムとサブシステム間のデータ転送能力によらず暗号処理を実現することができる。
【解決手段】メインプログラムで動作するメインシステム１１と、サブプログラムで動作するとともに該メインシステム１１の制御下で動作する複数のサブシステム１２が所定のバスによって離接可能に接続されている複合システムにおいて、メインシステム１１は、暗号処理の対象となるデータを分割したデータ断片ごとにサブシステム１２に転送し、サブシステム１２は、メインシステム１１から受信したデータ断片を一時的に書き込み／読み出し可能な受信バッファ１２ｆを有する。
【選択図】図１
【解決手段】メインプログラムで動作するメインシステム１１と、サブプログラムで動作するとともに該メインシステム１１の制御下で動作する複数のサブシステム１２が所定のバスによって離接可能に接続されている複合システムにおいて、メインシステム１１は、暗号処理の対象となるデータを分割したデータ断片ごとにサブシステム１２に転送し、サブシステム１２は、メインシステム１１から受信したデータ断片を一時的に書き込み／読み出し可能な受信バッファ１２ｆを有する。
【選択図】図１
Description
本発明は、メインシステムから暗号処理の対象となるデータをサブシステムに転送する複合システムに関する。
従来、複数のシステムを複合した複合システムが構築されるようになってきており、サブシステムそれぞれがＣＰＵ（Central Processing Unit ）を搭載して当該サブシステムを制御するとともに、メインシステムのＣＰＵの制御下で全体の動作制御を行うようになってきている。
そして、このような複合システムにおいては、サブシステムの接続と切り離しが容易であることから、複合システム内に蓄積されているユーザの個人的な情報を保護することが重要な問題となってきている。このような複合システムにおいては、サブシステムになりすましたソフトウエアの不正改ざんや情報の漏洩が問題となっている。
また、従来、省エネ高速暗号通信を実現するため、暗号処理ハードウエアを搭載したサブボードが提案されている。
この技術は、メインシステムには暗号処理機能を搭載せず、サブシステムの暗号機能を利用する構成にした。
この技術は、メインシステムには暗号処理機能を搭載せず、サブシステムの暗号機能を利用する構成にした。
このため、ファームウエアデータ（例えば、30MB程度）の正当性を確認する暗号処理をサブシステムで行う必要があった。
しかし、サブシステムのコストダウンのためメモリ量を極小(数百KB程度)にしたため、サブシステムのメモリ上にデータを全て載せられなかった。
しかし、サブシステムのコストダウンのためメモリ量を極小(数百KB程度)にしたため、サブシステムのメモリ上にデータを全て載せられなかった。
特許文献１では、サブシステムになりすました攻撃からセキュリティを確実に確保するメインシステムとサブシステムからなる複合システム、セキュリティ方法、セキュリティプログラム及び記録媒体を提供するという技術が開示されている。
特許文献２では、ファームウエアデータを制御装置を介して記憶装置に書き込む際の通信時間をできるだけ短縮させることができるファームウエアデータの書込み方法を提供するという技術が開示されている。
特許文献２では、ファームウエアデータを制御装置を介して記憶装置に書き込む際の通信時間をできるだけ短縮させることができるファームウエアデータの書込み方法を提供するという技術が開示されている。
しかしながら、特許文献１では、暗号処理の対象となる大きなデータに対して、暗号処理を他のシステムに委譲する構成ではなかった。また、特許文献２では、ファームウエアの書き込み時の分割高速化を行うため、書き込み前の正当性検証時点での分割とは異なっていた。
このため、特許文献１、２では、暗号機能を備えたサブシステム（機種共通）を利用した暗号処理（ファームウエア正当性検証など）において、メインシステムの暗号処理対象データ（ファームウエア）のサイズがサブシステムのメモリ量より大きいため処理ができないといった問題があった。
このため、特許文献１、２では、暗号機能を備えたサブシステム（機種共通）を利用した暗号処理（ファームウエア正当性検証など）において、メインシステムの暗号処理対象データ（ファームウエア）のサイズがサブシステムのメモリ量より大きいため処理ができないといった問題があった。
以上のように、暗号処理対象のデータサイズ、サブシステムの搭載メモリ量、メインシステムとサブシステム間のデータ転送能力に暗号処理が依存しているため、メインシステムの暗号処理対象データ（ファームウエア）のサイズがサブシステムのメモリ容量よりも大きい場合には、暗号処理ができないといった問題があった。
本発明は上記事情に鑑みなされたものであって、メインシステムの暗号処理対象データのサイズがサブシステムのメモリ容量よりも大きい場合であっても、暗号処理対象データサイズ、サブシステムの搭載メモリ量、メインシステムとサブシステム間のデータ転送能力によらず暗号処理を実現することができる複合システムを提供することを目的とする。
上記課題を解決するたに、請求項１記載の発明は、メインプログラムで動作するメインシステムと、サブプログラムで動作するとともに該メインシステムの制御下で動作する複数のサブシステムが所定のバスによって離接可能に接続されている複合システムにおいて、前記メインシステムは、暗号処理の対象となるデータを分割したデータ断片ごとにサブシステムに転送する転送手段を有し、前記サブシステムは、前記メインシステムから受信したデータ断片を一時的に書き込み／読み出し可能な受信バッファを有し、前記メインシステムの暗号処理の対象となるデータのサイズが、前記サブシステムの受信バッファの容量よりも大きい場合であっても、前記メインシステムと前記サブシステムとの間で暗号処理を行う、ことを特徴とする複合システムである。
本発明によれば、メインシステムは、暗号処理の対象となるデータを分割したデータ断片ごとにサブシステムに転送し、サブシステムは、メインシステムから受信したデータ断片を一時的に書き込み／読み出し可能な受信バッファを有し、前記メインシステムの暗号処理の対象となるデータのサイズが、前記サブシステムの受信バッファの容量よりも大きい場合であっても、前記メインシステムと前記サブシステムとの間で暗号処理を行うことで、暗号処理対象データサイズ、サブシステムの搭載メモリ量、メインシステムとサブシステム間のデータ転送能力によらず暗号処理を実現することができる。
以下、本発明を実施するための最良の形態について、図に示す実施形態を参照して説明する。
＜第１実施形態＞
まず、本発明の第１実施形態に係る複合システムについて説明する。
図１は、本発明の第１実施形態に係る複合システムについて説明するためのブロック図である。
図１（ａ）において、複合システム１は、メインシステム１１、サブシステム１２を備えている。ネットワークに接続するネットワーク通信部（図示しない）を備えており、メインシステム１１とサブシステム１２とは、ＵＳＢ（Universal Serial Bus）でそれぞれ接続されており、ＵＳＢは通信手段として機能している。
＜第１実施形態＞
まず、本発明の第１実施形態に係る複合システムについて説明する。
図１は、本発明の第１実施形態に係る複合システムについて説明するためのブロック図である。
図１（ａ）において、複合システム１は、メインシステム１１、サブシステム１２を備えている。ネットワークに接続するネットワーク通信部（図示しない）を備えており、メインシステム１１とサブシステム１２とは、ＵＳＢ（Universal Serial Bus）でそれぞれ接続されており、ＵＳＢは通信手段として機能している。
メインシステム１１は、ＣＰＵ１１ａ、メモリ１１ｂ、ストレージ１１ｃ、外部接続端子１１ｄを備えており、それぞれ内部バスにより接続されている。
ストレージ１１ｃには、ファームウエア（Ｆ／Ｗ）を更新可能なアプリケーションソフトウエアとして暗号利用アプリケーションソフトウエアが記憶されている。メインシステム１１の起動時には、ＣＰＵ１１ａがストレージ１１ｃから暗号利用アプリを順次に読み出して各ステップを実行する。
ストレージ１１ｃには、ファームウエア（Ｆ／Ｗ）を更新可能なアプリケーションソフトウエアとして暗号利用アプリケーションソフトウエアが記憶されている。メインシステム１１の起動時には、ＣＰＵ１１ａがストレージ１１ｃから暗号利用アプリを順次に読み出して各ステップを実行する。
サブシステム１２は、ＣＰＵ１２ａ、メモリ１２ｂ、暗号処理器１２ｃ、接続端子１２ｄ、受信バッファ１２ｆを備えており、それぞれ内部バスにより接続されている。
メモリ１２ｂには、ＣＰＵ１２ａにより暗号アプリサーバ１４ａとして実行されるアプリケーションソフトウエアが記憶されている。
メモリ１２ｂには、ＣＰＵ１２ａにより暗号アプリサーバ１４ａとして実行されるアプリケーションソフトウエアが記憶されている。
サブシステム１２の起動時には、ＣＰＵ１２ａがメモリ１２ｂからアプリケーションソフトウエアを順次に読み出して各ステップを実行することで、暗号アプリサーバ１４ａが実行される。
暗号処理器１２ｃは、暗号処理エンジン１４ｂとして動作する。
受信バッファ１２ｆは、メインシステム１１から受信したデータ断片を一時的に書き込み／読み出しを可能とする。
暗号処理器１２ｃは、暗号処理エンジン１４ｂとして動作する。
受信バッファ１２ｆは、メインシステム１１から受信したデータ断片を一時的に書き込み／読み出しを可能とする。
本実施形態では、サブシステム１２に関する製造コストを削減するため、メモリ１２ｂの容量を極小(数百KB程度)にしたため、サブシステム１２のメモリ１２ｂ上にメインシステムから受信する暗号処理の対象となるデータを全て載せられなかった。
また、本実施形態では、従来技術のように、メモリ１２ｂを用いて暗号処理の対象となるデータ全体を１回だけhashし、後にverify処理を行うという通常の方法では正当性検証ができなくなった。
また、本実施形態では、従来技術のように、メモリ１２ｂを用いて暗号処理の対象となるデータ全体を１回だけhashし、後にverify処理を行うという通常の方法では正当性検証ができなくなった。
そこで、本実施形態では、メインシステム１１からサブシステム１２の受信バッファ１２ｆにデータを分割して転送し、データ断片単位でN回hashし、後にverify処理を行うという、データ断片単位で暗号処理する方法をとった。
次に、図１（ｂ）に示すフローチャートを参照して、メインシステム１１における暗号利用アプリ１３ａによる処理動作を説明する。
まず、ステップＳ１０では、ＣＰＵ１１ａは、暗号利用の初期処理を行う。
次いで、ステップＳ２０では、ＣＰＵ１１ａは、データ分割が必要であるか否かを判断する。
まず、ステップＳ１０では、ＣＰＵ１１ａは、暗号利用の初期処理を行う。
次いで、ステップＳ２０では、ＣＰＵ１１ａは、データ分割が必要であるか否かを判断する。
すなわち、ＣＰＵ１１ａは、サブシステム１２側の受信バッファ１２ｆのサイズ(16KB)とファームウエア（F/W）のデータのサイズ(30MB)が既知であるので、ファームウエアのデータ容量をデータ断片に分割し、分割後のデータ断片のサイズも固定とする。
ここで、データ分割が必要な場合にはステップＳ３０に進む。一方、データ分割が必要ではない場合にはステップＳ５０に進む。
次いで、ステップＳ３０では、ＣＰＵ１１ａは、分割データの転送と、暗号処理を行う。
次いで、ステップＳ４０では、ＣＰＵ１１ａは、残分割データがあるか否かを判断する。
次いで、ステップＳ３０では、ＣＰＵ１１ａは、分割データの転送と、暗号処理を行う。
次いで、ステップＳ４０では、ＣＰＵ１１ａは、残分割データがあるか否かを判断する。
ここで、残分割データがある場合にはステップＳ３０に戻り、上記処理を繰り返す。一方、残分割データがない場合にはステップＳ５０に進む。
次いで、ステップＳ５０では、ＣＰＵ１１ａは、暗号利用の最終処理を行う。
次いで、ステップＳ５０では、ＣＰＵ１１ａは、暗号利用の最終処理を行う。
次に、図２を参照して、メインシステム１１とサブシステム１２との間における転送シーケンスについて説明する。
まず、手順Ｓｅ１では、ＣＰＵ１１ａにより実行される暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデジタル署名と公開鍵を、外部接続端子１１ｄ、接続端子１２ｄを介してサブシステム１２に設けられたＣＰＵ１２ａにより実行される暗号アプリサーバ１４ａに送信する。
まず、手順Ｓｅ１では、ＣＰＵ１１ａにより実行される暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデジタル署名と公開鍵を、外部接続端子１１ｄ、接続端子１２ｄを介してサブシステム１２に設けられたＣＰＵ１２ａにより実行される暗号アプリサーバ１４ａに送信する。
次いで、ＣＰＵ１２ａにより実行される暗号アプリサーバ１４ａは、デジタル署名と公開鍵をメモリ１２ｂに記憶しておく。
次いで、手順Ｓｅ２では、暗号アプリサーバ１４ａは、暗号処理器１２ｃの利用権獲得に関する指示を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ３では、暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデータ断片を暗号アプリサーバ１４ａに送信する。
次いで、手順Ｓｅ２では、暗号アプリサーバ１４ａは、暗号処理器１２ｃの利用権獲得に関する指示を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ３では、暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデータ断片を暗号アプリサーバ１４ａに送信する。
次いで、手順Ｓｅ４では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにhash処理を行わせるために利用権とデータ断片を暗号処理エンジン１４ｂに出力する。
なお、図２に示すように、手順Ｓｅ３、手順Ｓｅ４については残データが無くなり、最終データ断片となるまで繰り返して行う。
なお、図２に示すように、手順Ｓｅ３、手順Ｓｅ４については残データが無くなり、最終データ断片となるまで繰り返して行う。
ここで、図２を参照して、最終データ断片の場合の手順について説明する。
手順Ｓｅ５では、暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のために最終データ断片を暗号アプリサーバ１４ａに出力する。
次いで、手順Ｓｅ６では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにhash処理を行わせるために利用権と最終のデータ断片とを暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ７では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにverify処理を行わせるために利用権と公開鍵およびデジタル署名、データhash結果を暗号処理エンジン１４ｂに出力する。
手順Ｓｅ５では、暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のために最終データ断片を暗号アプリサーバ１４ａに出力する。
次いで、手順Ｓｅ６では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにhash処理を行わせるために利用権と最終のデータ断片とを暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ７では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにverify処理を行わせるために利用権と公開鍵およびデジタル署名、データhash結果を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ８では、暗号処理エンジン１４ｂは、暗号処理器１２ｃで行ったverify処理結果（）となる真／偽値を暗号アプリサーバ１４ａに出力する。
次いで、手順Ｓｅ８では、暗号アプリサーバ１４ａは、暗号処理エンジン１４ｂから受け取ったＦ／Ｗ正当性確認の結果応答（）となる真／偽値を暗号利用アプリ１３ａに出力する。
次いで、手順Ｓｅ８では、暗号アプリサーバ１４ａは、暗号処理エンジン１４ｂから受け取ったＦ／Ｗ正当性確認の結果応答（）となる真／偽値を暗号利用アプリ１３ａに出力する。
ここで、ファームウエア正当性検証の対象となるファームウエアデータのデータ構造の概要について説明する。
署名は、HeaderとしてSignatureBとデータ、CertificateとしてSignatureAとpublic-keyB、イメージデータを含む。
ファームウエアデータは、例えば３つのファームウエアをひとまとめにした構成に対して１つの署名を付加するように構成してもよい。
署名は、HeaderとしてSignatureBとデータ、CertificateとしてSignatureAとpublic-keyB、イメージデータを含む。
ファームウエアデータは、例えば３つのファームウエアをひとまとめにした構成に対して１つの署名を付加するように構成してもよい。
次に、デジタル署名検証における各データの役割について説明する。
例えば、デジタル署名検証は２段階で行われる。
第１段階のVerify処理では、正当性を確認する範囲となるpublic-keyBを対象として、public-keyAを用いVerify処理を行う。
第２段階のVerify処理では、正当性を確認する範囲となるデータとイメージデータとを連結したデータを対象として、public-keyBを用いVerify処理を行う。
例えば、デジタル署名検証は２段階で行われる。
第１段階のVerify処理では、正当性を確認する範囲となるpublic-keyBを対象として、public-keyAを用いVerify処理を行う。
第２段階のVerify処理では、正当性を確認する範囲となるデータとイメージデータとを連結したデータを対象として、public-keyBを用いVerify処理を行う。
詳しくは、「検証したいバイト列」に対し、「public-keyA（公開鍵）とSignature（デジタル署名）のペア」を用いて検証する。
２段階目にあたるイメージデータの検証の際は、Headerのデータとバイナリ結合したデータを、「検証したいバイト列」と見なす。
この処理のアルゴリズムは、例えばECDSA(楕円曲線暗号アルゴリズムによるDSA署名)を用いる。
２段階目にあたるイメージデータの検証の際は、Headerのデータとバイナリ結合したデータを、「検証したいバイト列」と見なす。
この処理のアルゴリズムは、例えばECDSA(楕円曲線暗号アルゴリズムによるDSA署名)を用いる。
ここで、暗号処理エンジン１４ｂによる任意長データ断片の処理について説明する。署名検証のコンテキストを表す構造体(SingedObjContext)のフィールド定義としては、例えば、コンテキスト、署名用公開鍵、hashコンテキスト、署名用バッファ、署名、検証用公開鍵、端数データ一次格納領域などを用いるのが好ましい。
サブシステム１２において、検証対象のデータは、メインシステム１１の外部接続端子１１ｄであるUSBバス、接続端子１２ｄを通して受信バッファ１２ｆに一部の断片（任意長）ずつ格納（上書き）される。
サブシステム１２において、検証対象のデータは、メインシステム１１の外部接続端子１１ｄであるUSBバス、接続端子１２ｄを通して受信バッファ１２ｆに一部の断片（任意長）ずつ格納（上書き）される。
一方で、暗号処理エンジン１４ｂでは、hash操作は複数回のhash関数呼び出しで最終的なhash値を求めることができるが、最後のhash関数呼び出し以外では、64Bの倍数分ずつしかhash処理ができない。
そこで、ACCLでは署名検証時に64B長の受信バッファ１２ｆを用意し、署名検証途中で出る64B以下の端数のデータをここにバッファする。
そこで、ACCLでは署名検証時に64B長の受信バッファ１２ｆを用意し、署名検証途中で出る64B以下の端数のデータをここにバッファする。
この受信バッファ１２ｆにより、断片データが入力されたときのサブシステム１２の暗号処理エンジン１４ｂによる動作は、以下の３つのステップ（Ｓｂ１〜Ｓｂ３）となる。
Ｓｂ１：受信バッファ１２ｆが空でないときは、受信バッファ１２ｆをフルにして64B分だけhash処理を行う。
Ｓｂ２：断片データの残余のうち64の倍数分を一括してhash処理を行う。
Ｓｂ３：１，２の残余データ（64B以下）を再び受信バッファ１２ｆに格納する。
Ｓｂ１：受信バッファ１２ｆが空でないときは、受信バッファ１２ｆをフルにして64B分だけhash処理を行う。
Ｓｂ２：断片データの残余のうち64の倍数分を一括してhash処理を行う。
Ｓｂ３：１，２の残余データ（64B以下）を再び受信バッファ１２ｆに格納する。
ここで、ステップＳｂ１，Ｓｂ２で２回hash実行している点については、「機器」モジュールが受信バッファ１２ｆの処理サイズの最適化を図ることにより、ステップＳｂ１を省略することができる。
なお、上記の最適化は効果が不明なため、実際に行うかはSoC上での実測結果を待つ必要がある。
なお、上記の最適化は効果が不明なため、実際に行うかはSoC上での実測結果を待つ必要がある。
ここで、図３を参照して、デジタル著名および公開鍵に関するデータ構造について説明する。
正当性検証アルゴリズムに必要なデータは、主に、デジタル著名、公開鍵、検証の対象となるデータプログラムである。
ＡＰＩでは、デジタル署名およびデジタル署名検証の対象データは、例えば１組にして作成する。
公開鍵は、１つの構造体であり、メインシステム１１側のストレージ１１ｃ（マスクＲＯＭ）に記憶されているプログラムに内蔵されている。
正当性検証アルゴリズムに必要なデータは、主に、デジタル著名、公開鍵、検証の対象となるデータプログラムである。
ＡＰＩでは、デジタル署名およびデジタル署名検証の対象データは、例えば１組にして作成する。
公開鍵は、１つの構造体であり、メインシステム１１側のストレージ１１ｃ（マスクＲＯＭ）に記憶されているプログラムに内蔵されている。
署名オブジェクトは、[HeaderSection]、[CertificateList]、[ImageSection]で構成される。
[HeaderSection]は、定義されたフォーマットであり、バージョンや署名などが格納されている。
[CertificateList]は、署名検証チェーンを利用する場合に必要なCertificateを格納する領域であり、領域サイズは可変であるが、本実施形態ではCertificateは１つだけ使用する。
[ImageSection]は、実行するプログラムを格納する領域、サイズは未定であるが、プログラムサイズが１６Byteの倍数でない場合、Oによるパディングが実施されている。
[HeaderSection]は、定義されたフォーマットであり、バージョンや署名などが格納されている。
[CertificateList]は、署名検証チェーンを利用する場合に必要なCertificateを格納する領域であり、領域サイズは可変であるが、本実施形態ではCertificateは１つだけ使用する。
[ImageSection]は、実行するプログラムを格納する領域、サイズは未定であるが、プログラムサイズが１６Byteの倍数でない場合、Oによるパディングが実施されている。
このように、暗号処理対象データを分割したデータ断片ごとに１回の転送手順により順次にサブシステム１２の受信バッファ１２ｆに転送し、hash処理させることで、メインシステムの暗号処理対象データのサイズがサブシステムのメモリ量よりも大きい場合であっても、暗号処理対象データサイズ、サブシステム１２の搭載メモリ量、メインシステムとサブシステム間のデータ転送能力等によらず暗号処理を実現することができる。
将来の様々なメインシステム１１との接続性を確保しつつ、サブシステム１２のメモリ１２ｂのメモリ量を低減することができ、コスト低減を実現することができる。
将来の様々なメインシステム１１との接続性を確保しつつ、サブシステム１２のメモリ１２ｂのメモリ量を低減することができ、コスト低減を実現することができる。
＜第２実施形態＞
図４、図５を参照して、本発明の第２実施形態に係る複合システムについて説明する。
第２実施形態に用いる図４、図５は、第１実施形態において用いたブロック図（図１）シーケンス図（図２）の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
第２実施形態では、図４に示すように、サブシステム１２にストレージ（セキュア）１２ｅ、セキュアＤＢ１４ｃを備え、図５に示すように、手順Ｓｅ２１を有することを特徴とする。
図４、図５を参照して、本発明の第２実施形態に係る複合システムについて説明する。
第２実施形態に用いる図４、図５は、第１実施形態において用いたブロック図（図１）シーケンス図（図２）の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
第２実施形態では、図４に示すように、サブシステム１２にストレージ（セキュア）１２ｅ、セキュアＤＢ１４ｃを備え、図５に示すように、手順Ｓｅ２１を有することを特徴とする。
図４に示すように、サブシステム１２にはストレージ（セキュア）１２ｅを備えており、ストレージ（セキュア）１２ｅにはセキュアＤＢ１４ｃとして公開鍵が格納されている。
図５に示すように、手順Ｓｅ２１では、暗号利用アプリ１３ａは、公開鍵に関する参照（）指示をセキュアＤＢ１４ｃに送信する。この参照（）指示を受けたセキュアＤＢ１４ｃは、公開鍵を暗号利用アプリ１３ａに返信する。
図５に示すように、手順Ｓｅ２１では、暗号利用アプリ１３ａは、公開鍵に関する参照（）指示をセキュアＤＢ１４ｃに送信する。この参照（）指示を受けたセキュアＤＢ１４ｃは、公開鍵を暗号利用アプリ１３ａに返信する。
このように、サブシステム１２にセキュアDB１４ｃを追加することで、メインシステム１１側でセキュリティ用データ（公開鍵）の安全な管理を必要とせずに、重要データ（F/W）のセキュリティを確保できる。同時に、メインシステムの開発コストを低減することができる。
＜第３実施形態＞
図４、図６を参照して、本発明の第３実施形態に係る複合システムについて説明する。
第３実施形態に用いる図４、図６は、第１実施形態において用いたシステム図（図１）、シーケンス図（図２）の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
第２実施形態では、図６に示すように、手順Ｓｅ１−１を有することを特徴とする。
図４に示すように、サブシステム１２にはストレージ（セキュア）１２ｅを備えており、ストレージ（セキュア）１２ｅにはセキュアＤＢ１４ｃとして公開鍵が格納されている。
図４、図６を参照して、本発明の第３実施形態に係る複合システムについて説明する。
第３実施形態に用いる図４、図６は、第１実施形態において用いたシステム図（図１）、シーケンス図（図２）の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
第２実施形態では、図６に示すように、手順Ｓｅ１−１を有することを特徴とする。
図４に示すように、サブシステム１２にはストレージ（セキュア）１２ｅを備えており、ストレージ（セキュア）１２ｅにはセキュアＤＢ１４ｃとして公開鍵が格納されている。
手順Ｓｅ１−１では、ＣＰＵ１１ａにより実行される暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデジタル署名を、外部接続端子１１ｄ、接続端子１２ｄを介してサブシステム１２に設けられたＣＰＵ１２ａにより実行される暗号アプリサーバ１４ａに送信する。
暗号アプリサーバ１４ａは、セキュアＤＢ１４ｃから公開鍵を読み出すことで、手順Ｓｅ７において公開鍵に用いることができる。
このように、サブシステム１２に設けられた暗号アプリサーバ１４ａのみがセキュアDB１４ｃにアクセス可能にすることで、効率の良い、すなわち、暗号利用アプリの手順減少や、わずかに高速化した暗号処理を実行することができる。
このように、サブシステム１２に設けられた暗号アプリサーバ１４ａのみがセキュアDB１４ｃにアクセス可能にすることで、効率の良い、すなわち、暗号利用アプリの手順減少や、わずかに高速化した暗号処理を実行することができる。
＜第４実施形態＞
図７を参照して、本発明の第４実施形態に係る複合システムについて説明する。
第４実施形態に用いる図７は、第１実施形態において用いたシーケンス図（図２）の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
暗号アプリサーバ１４ａには、データ整列ルール（例えば、hashはデータサイズが64の倍数であること）を保持していることとする。
図７を参照して、本発明の第４実施形態に係る複合システムについて説明する。
第４実施形態に用いる図７は、第１実施形態において用いたシーケンス図（図２）の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
暗号アプリサーバ１４ａには、データ整列ルール（例えば、hashはデータサイズが64の倍数であること）を保持していることとする。
第４実施形態では、図７に示すように、手順Ｓｅ４−１に加えて手順Ｓｅ４−２、手順Ｓｅ６−１に加えて手順Ｓｅ６−２を有していることを特徴とする。
手順Ｓｅ３に用いる断片データは、整列不要、すなわち、整列の例として、例えばデータサイズが６４バイトの倍数であることである。
手順Ｓｅ３に用いる断片データは、整列不要、すなわち、整列の例として、例えばデータサイズが６４バイトの倍数であることである。
手順Ｓｅ４−１でのhash処理では、前回のhash処理で整列した余りと、今回のhash処理の冒頭データを結合してhash処理させる。
手順Ｓｅ４−２でのhash処理では、今回の冒頭を除いたデータの整列可能な最大サイズまでhash処理させる。
なお、整列した余り(例： datasize % 64)を一時的にメモリ１２ｂに格納する。
手順Ｓｅ４−２でのhash処理では、今回の冒頭を除いたデータの整列可能な最大サイズまでhash処理させる。
なお、整列した余り(例： datasize % 64)を一時的にメモリ１２ｂに格納する。
このように、暗号アプリサーバ１４ａがデータ整列に関するルール情報を持つことで、暗号利用アプリ１３ａがサブシステム１２の暗号処理エンジン１４ｂの制約（例えばhash処理は６４の倍数で入力など）を考慮せず、任意サイズでデータ転送できるようになり、サブシステム１２の暗号処理エンジン１４ｂに対する改訂の影響、すなわち、暗号利用アプリ１３ａの改訂コストを低減することができる。
＜第５実施形態＞
図８を参照して、本発明の第５実施形態に係る複合システムについて説明する。
第５実施形態に用いる図８は、第４実施形態において用いたシーケンス図（図７）の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
第５実施形態では、セキュアＤＢ１４ｃに公開鍵を予め保持していることを特徴とする。
図４に示すように、サブシステム１２にはストレージ（セキュア）１２ｅを備えており、ストレージ（セキュア）１２ｅにはセキュアＤＢ１４ｃとして公開鍵が格納されている。
図８を参照して、本発明の第５実施形態に係る複合システムについて説明する。
第５実施形態に用いる図８は、第４実施形態において用いたシーケンス図（図７）の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
第５実施形態では、セキュアＤＢ１４ｃに公開鍵を予め保持していることを特徴とする。
図４に示すように、サブシステム１２にはストレージ（セキュア）１２ｅを備えており、ストレージ（セキュア）１２ｅにはセキュアＤＢ１４ｃとして公開鍵が格納されている。
手順Ｓｅ１−２では、ＣＰＵ１１ａにより実行される暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデジタル署名を、外部接続端子１１ｄ、接続端子１２ｄを介してサブシステム１２に設けられたＣＰＵ１２ａにより実行される暗号アプリサーバ１４ａに送信する。
暗号アプリサーバ１４ａは、セキュアＤＢ１４ｃから公開鍵を読み出すことで、手順Ｓｅ７において公開鍵に用いることができる。
手順Ｓｅ３−２に用いる断片データは、整列不要、すなわち、整列の例としてデータサイズが６４バイトの倍数である必要はない。
手順Ｓｅ３−２に用いる断片データは、整列不要、すなわち、整列の例としてデータサイズが６４バイトの倍数である必要はない。
このように、サブシステム１２にセキュアDB１４ｃを追加することで、メインシステム１１側でセキュリティ用データ（公開鍵）の安全な管理を必要とせずに、重要データ（F/W）のセキュリティを確保できる。同時に、メインシステムの開発コストを低減することができ、さらに、暗号アプリサーバ１４ａがデータ整列に関するルール情報を持つことで、暗号利用アプリ１３ａがサブシステム１２の暗号処理エンジン１４ｂの制約（例えばhash処理は６４の倍数で入力など）を考慮せず、任意サイズでデータ転送できるようになり、サブシステム１２の暗号処理エンジン１４ｂに対する改訂の影響、すなわち、暗号利用アプリ１３ａの改訂コストを低減することができる。
これに加えて、暗号利用アプリ１３ａが暗号仕様をほとんど意識しなくて良いように構成することができる。
これに加えて、暗号利用アプリ１３ａが暗号仕様をほとんど意識しなくて良いように構成することができる。
＜第６実施形態＞
図９を参照して、本発明の第６実施形態に係る複合システムについて説明する。
第６実施形態に用いる図９は、第２実施形態において用いたシーケンス図（図２）の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
図９を参照して、本発明の第６実施形態に係る複合システムについて説明する。
第６実施形態に用いる図９は、第２実施形態において用いたシーケンス図（図２）の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
第６実施形態では、手順Ｓｅ１１において、暗号アプリサーバ１４ａが整列サイズ仕様を暗号利用アプリ１３ａへ送信することを特徴とする。ここで、整列サイズ仕様は、
仕様＝｛整列サイズ基数、最小値、最大値｝
と定義し、例えば、｛例：64B, 64B, 128KB｝と設定するのが好ましい。
仕様＝｛整列サイズ基数、最小値、最大値｝
と定義し、例えば、｛例：64B, 64B, 128KB｝と設定するのが好ましい。
また、手順Ｓｅ３−３、４−３、５−３、６−３において転送されるデータ断片は、上記仕様により整列済みのデータ断片であることを特徴とする。
ここで、例えば、手順Ｓｅ４−３では、hash処理の回数が減少するので、整列のコスト（メモリ１１ｂと受信バッファ１２ｆとの間、受信バッファ１２ｆとメモリ１２ｂとの間のメモリコピー）も減少する。
ここで、例えば、手順Ｓｅ４−３では、hash処理の回数が減少するので、整列のコスト（メモリ１１ｂと受信バッファ１２ｆとの間、受信バッファ１２ｆとメモリ１２ｂとの間のメモリコピー）も減少する。
このように、転送に先立って、暗号利用アプリ１３ａが暗号アプリサーバ１４ａからデータ整列ルールを取得することで、暗号利用アプリ１３ａはサブシステム１２におけるデータ整列のコスト（hash回数増）を回避しつつ、サブシステム１２の仕様変更（例えばhashは６４の倍数から１６の倍数で入力への変更など）の影響（暗号利用アプリの改訂コスト）を低減することができる。
＜第７実施形態＞
図１０を参照して、本発明の第７実施形態に係る複合システムについて説明する。
第７実施形態に用いる図１０は、第１実施形態において用いたシステム図およびフローチャート（図２）の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
図１０を参照して、本発明の第７実施形態に係る複合システムについて説明する。
第７実施形態に用いる図１０は、第１実施形態において用いたシステム図およびフローチャート（図２）の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
第７実施形態では、図１０（ａ）に示すように、メインシステム１１が分割判定部１３ｂをソフトウエアとして有することを特徴とする。
分割判定部１３ｂでは、バスの種別から分割転送の必要性を判定する。なお、外部接続端子１１ｄとしては、例えばPCIe（Peripheral Component Interconnect Express）バス、USBバスを備えていることとする。
分割判定部１３ｂでは、バスの種別から分割転送の必要性を判定する。なお、外部接続端子１１ｄとしては、例えばPCIe（Peripheral Component Interconnect Express）バス、USBバスを備えていることとする。
図１０（ｂ）に示すフローチャートにおいて、ステップＳ１１０では、メモリ共有が可能か否かを判断する。すなわち、バス種別(例えば、PCIｅバス?／USBバス?)に基づいてメモリ共有が可能か否かを判定する。ここで、バス種別がPCIバスの場合にはデータ共有が可能なのでステップＳ１２０に進む。一方、バス種別がUSBバスの場合にはデータ共有が不可能なのでステップＳ２０に進む。
次いで、バス種別がPCIeバスの場合には、メインシステム１１とサブシステム１２との間でデータ共有が可能なので、ステップＳ１２０では、大データに対する一括の中間の暗号処理を行う。
一方、バス種別がUSBバスの場合にはデータ共有が不可能であるので、ステップＳ２０では、データ分割が必要か否かを判断する。すなわち、データの大きさに基づく判定を行う。
一方、バス種別がUSBバスの場合にはデータ共有が不可能であるので、ステップＳ２０では、データ分割が必要か否かを判断する。すなわち、データの大きさに基づく判定を行う。
次に、図１１を参照して、メインシステム１１とサブシステム１２との間における転送シーケンスについて説明する。
まず、手順Ｓｅ２１では、ＣＰＵ１１ａにより実行される暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデジタル署名と公開鍵を、分割判定部１３ｂに出力する。
次いで、手順Ｓｅ２２では、分割判定部１３ｂは、Ｆ／Ｗ正当性確認のためにデジタル署名と公開鍵を、外部接続端子１１ｄ、接続端子１２ｄを介してサブシステム１２に設けられたＣＰＵ１２ａにより実行される暗号アプリサーバ１４ａに送信する。
まず、手順Ｓｅ２１では、ＣＰＵ１１ａにより実行される暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデジタル署名と公開鍵を、分割判定部１３ｂに出力する。
次いで、手順Ｓｅ２２では、分割判定部１３ｂは、Ｆ／Ｗ正当性確認のためにデジタル署名と公開鍵を、外部接続端子１１ｄ、接続端子１２ｄを介してサブシステム１２に設けられたＣＰＵ１２ａにより実行される暗号アプリサーバ１４ａに送信する。
次いで、ＣＰＵ１２ａにより実行される暗号アプリサーバ１４ａは、デジタル署名と公開鍵をメモリ１２ｂに記憶しておく。
次いで、手順Ｓｅ２３では、暗号アプリサーバ１４ａは、暗号処理器１２ｃの利用権獲得に関する指示を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ２４では、暗号利用アプリ１３ａは、分割が必要か否かを問い合わせる分割必要？（）指示を分割判定部１３ｂに出力する。分割判定部１３ｂでの処理は、図１３（ｂ）に示す通りである。
次いで、手順Ｓｅ２３では、暗号アプリサーバ１４ａは、暗号処理器１２ｃの利用権獲得に関する指示を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ２４では、暗号利用アプリ１３ａは、分割が必要か否かを問い合わせる分割必要？（）指示を分割判定部１３ｂに出力する。分割判定部１３ｂでの処理は、図１３（ｂ）に示す通りである。
以下、分割が不要な場合の処理について説明する。
次いで、手順Ｓｅ２５では、暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデータ全体を分割判定部１３ｂに出力する。
次いで、手順Ｓｅ２６では、分割判定部１３ｂは、Ｆ／Ｗ正当性確認のためにデータ全体を暗号アプリサーバ１４ａに送信する。
次いで、手順Ｓｅ２５では、暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデータ全体を分割判定部１３ｂに出力する。
次いで、手順Ｓｅ２６では、分割判定部１３ｂは、Ｆ／Ｗ正当性確認のためにデータ全体を暗号アプリサーバ１４ａに送信する。
次いで、手順Ｓｅ２７では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにhash処理を行わせるために利用権とデータ断片を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ２８では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにverify処理を行わせるために利用権と公開鍵およびデジタル署名、データhash結果を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ２８では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにverify処理を行わせるために利用権と公開鍵およびデジタル署名、データhash結果を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ２９では、暗号処理エンジン１４ｂは、暗号処理器１２ｃで行ったverify処理結果（）となる真／偽値を暗号アプリサーバ１４ａに出力する。
次いで、手順Ｓｅ３０では、暗号アプリサーバ１４ａは、暗号処理エンジン１４ｂから受け取ったＦ／Ｗ正当性確認の結果応答（）となる真／偽値を分割判定部１３ｂに出力する。
次いで、手順Ｓｅ３１では、分割判定部１３ｂは、暗号アプリサーバ１４ａから受け取ったＦ／Ｗ正当性確認の結果応答（）となる真／偽値を暗号利用アプリ１３ａに出力する。
次いで、手順Ｓｅ３０では、暗号アプリサーバ１４ａは、暗号処理エンジン１４ｂから受け取ったＦ／Ｗ正当性確認の結果応答（）となる真／偽値を分割判定部１３ｂに出力する。
次いで、手順Ｓｅ３１では、分割判定部１３ｂは、暗号アプリサーバ１４ａから受け取ったＦ／Ｗ正当性確認の結果応答（）となる真／偽値を暗号利用アプリ１３ａに出力する。
このように、バス種類を判定する分割判定部１３ｂを有することで、システム間の接続形態となるバス種類によって、例えばPCIeバスの場合、高速化が可能になる。すなわち、PCIeバスではメインシステム１１とサブシステム１２との間でメモリ共有が可能であり、そもそも分割転送が不要となるため、高速化が可能になる。
＜第８実施形態＞
図１２を参照して、本発明の第８実施形態に係る複合システムについて説明する。
第８実施形態に用いる図１２は、第７実施形態において用いたシステム図（図１０）の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
第８実施形態では、図１２に示すように、メインシステム１１が暗号プロキシ１３ｃ（分割判定部１３ｂを含む）をソフトウエアとして有することを特徴とする。
暗号プロキシ１３ｃは、メインシステムに設けておくことで、分割処理を暗号利用アプリから隠蔽するように動作する。
図１２を参照して、本発明の第８実施形態に係る複合システムについて説明する。
第８実施形態に用いる図１２は、第７実施形態において用いたシステム図（図１０）の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
第８実施形態では、図１２に示すように、メインシステム１１が暗号プロキシ１３ｃ（分割判定部１３ｂを含む）をソフトウエアとして有することを特徴とする。
暗号プロキシ１３ｃは、メインシステムに設けておくことで、分割処理を暗号利用アプリから隠蔽するように動作する。
次に、図１３を参照して、メインシステム１１とサブシステム１２との間における転送シーケンスについて説明する。
まず、手順Ｓｅ３１では、ＣＰＵ１１ａにより実行される暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデジタル署名と公開鍵を、暗号プロキシ１３ｃに出力する。
次いで、手順Ｓｅ３２では、暗号プロキシ１３ｃは、Ｆ／Ｗ正当性確認のためにデジタル署名と公開鍵を、外部接続端子１１ｄ、接続端子１２ｄを介してサブシステム１２に設けられたＣＰＵ１２ａにより実行される暗号アプリサーバ１４ａに送信する。
まず、手順Ｓｅ３１では、ＣＰＵ１１ａにより実行される暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデジタル署名と公開鍵を、暗号プロキシ１３ｃに出力する。
次いで、手順Ｓｅ３２では、暗号プロキシ１３ｃは、Ｆ／Ｗ正当性確認のためにデジタル署名と公開鍵を、外部接続端子１１ｄ、接続端子１２ｄを介してサブシステム１２に設けられたＣＰＵ１２ａにより実行される暗号アプリサーバ１４ａに送信する。
次いで、ＣＰＵ１２ａにより実行される暗号アプリサーバ１４ａは、デジタル署名と公開鍵をメモリ１２ｂに記憶しておく。
次いで、手順Ｓｅ３３では、暗号アプリサーバ１４ａは、暗号処理器１２ｃの利用権獲得に関する指示を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ３４では、暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデータ全体を、暗号プロキシ１３ｃに出力する。
次いで、手順Ｓｅ３３では、暗号アプリサーバ１４ａは、暗号処理器１２ｃの利用権獲得に関する指示を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ３４では、暗号利用アプリ１３ａは、Ｆ／Ｗ正当性確認のためにデータ全体を、暗号プロキシ１３ｃに出力する。
以下、分割が必要な場合の処理について説明する。
次いで、手順Ｓｅ３５では、暗号プロキシ１３ｃは、Ｆ／Ｗ正当性確認のためにデータ断片を暗号アプリサーバ１４ａに送信する。
次いで、手順Ｓｅ３６では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにhash処理を行わせるために利用権と整列済みデータ断片を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ３５では、暗号プロキシ１３ｃは、Ｆ／Ｗ正当性確認のためにデータ断片を暗号アプリサーバ１４ａに送信する。
次いで、手順Ｓｅ３６では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにhash処理を行わせるために利用権と整列済みデータ断片を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ３７では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにhash処理を行わせるために利用権と整列済みデータ断片を暗号処理エンジン１４ｂに出力する。
なお、手順Ｓｅ３７での処理は残データがなくなるまで繰り返す。
なお、手順Ｓｅ３７での処理は残データがなくなるまで繰り返す。
最終データ断片の場合、手順Ｓｅ３８では、暗号プロキシ１３ｃは、Ｆ／Ｗ正当性確認のためにデータ断片を暗号アプリサーバ１４ａに送信する。
次いで、手順Ｓｅ３９では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにhash処理を行わせるために利用権と整列済みデータ断片を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ４０では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにhash処理を行わせるために利用権と整列済みデータ断片を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ３９では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにhash処理を行わせるために利用権と整列済みデータ断片を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ４０では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにhash処理を行わせるために利用権と整列済みデータ断片を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ４１では、暗号アプリサーバ１４ａは、暗号処理器１２ｃにverify処理を行わせるために利用権と公開鍵およびデジタル署名、データhash結果を暗号処理エンジン１４ｂに出力する。
次いで、手順Ｓｅ４２では、暗号処理エンジン１４ｂは、暗号処理器１２ｃで行ったverify処理結果（）となる真／偽値を暗号アプリサーバ１４ａに出力する。
次いで、手順Ｓｅ４２では、暗号処理エンジン１４ｂは、暗号処理器１２ｃで行ったverify処理結果（）となる真／偽値を暗号アプリサーバ１４ａに出力する。
次いで、手順Ｓｅ４３では、暗号アプリサーバ１４ａは、暗号処理エンジン１４ｂから受け取ったＦ／Ｗ正当性確認の結果応答（）となる真／偽値を暗号プロキシ１３ｃに出力する。
次いで、手順Ｓｅ４４では、暗号プロキシ１３ｃは、暗号アプリサーバ１４ａから受け取ったＦ／Ｗ正当性確認の結果応答（）となる真／偽値を暗号利用アプリ１３ａに出力する。
次いで、手順Ｓｅ４４では、暗号プロキシ１３ｃは、暗号アプリサーバ１４ａから受け取ったＦ／Ｗ正当性確認の結果応答（）となる真／偽値を暗号利用アプリ１３ａに出力する。
このように、メインシステム１２に暗号プロキシ１３ｃを設けることで、分割処理を暗号利用アプリから隠蔽することができる。暗号利用アプリ１３ａは、バス仕様による分割を考慮が不要になるため、サブシステム１２の暗号処理エンジン１４ｂの改訂の影響（暗号利用アプリの改訂コスト）を低減することができる。
＜第９実施形態＞
図１４を参照して、本発明の第９実施形態に係る複合システムについて説明する。
第８実施形態に用いる図１４は、第１実施形態において用いたシステム図（図１）および第７実施形態において用いたフローチャート（図１０（ｂ））の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
図１４を参照して、本発明の第９実施形態に係る複合システムについて説明する。
第８実施形態に用いる図１４は、第１実施形態において用いたシステム図（図１）および第７実施形態において用いたフローチャート（図１０（ｂ））の一部を変更したものであり、同様の部分については同一符号を付加して、その説明を省略する。
図１４に示すフローチャートにおいて、ステップＳ２１０では、暗号利用アプリ１３ａは、転送方式の選択処理と、改変データ生成処理とを行う。
本実施形態は、図１５に示すデータ定義のように、転送方式ＩＤに応じてデジタル著名および公開鍵を用意する。正当性検証時に、転送方式ＩＤに応じて、動的にF／Wデータ改変版をオリジナルとは別に生成することを特徴とする。
本実施形態は、図１５に示すデータ定義のように、転送方式ＩＤに応じてデジタル著名および公開鍵を用意する。正当性検証時に、転送方式ＩＤに応じて、動的にF／Wデータ改変版をオリジナルとは別に生成することを特徴とする。
本実施形態は、図１６に示すシーケンス図のように、暗号利用アプリ１３ａにおいて、ステップＳ２１０−１では、転送方式ＩＤに応じて転送方式の選択処理を行う。
また、ステップＳ２１０−２では、転送方式ＩＤに応じて改変データ生成処理を行う。なお、転送方式ＩＤに応じて、新たに改変データ（ビット反転したファームウエアデータ）を生成する能力があるとする。例えば、転送方式ＩＤがＸＯＲの場合、転送方式（XOR）に応じたデジタル署名を暗号利用アプリ１３ａが暗号アプリサーバ１４ａに送付する。
また、ステップＳ２１０−２では、転送方式ＩＤに応じて改変データ生成処理を行う。なお、転送方式ＩＤに応じて、新たに改変データ（ビット反転したファームウエアデータ）を生成する能力があるとする。例えば、転送方式ＩＤがＸＯＲの場合、転送方式（XOR）に応じたデジタル署名を暗号利用アプリ１３ａが暗号アプリサーバ１４ａに送付する。
このように、メインシステム１１において、対象データを変換した結果に対するデジタル署名をストレージ１１ｃに複数保持することで、データ転送経路上で盗聴されても、簡単には元データに復元できなくなるため、セキュリティ性能を向上することができる。
１１ メインシステム
１１ａ ＣＰＵ
１１ｂ メモリ
１１ｃ ストレージ
１１ｄ 外部接続端子
１２ サブシステム
１２ａ ＣＰＵ
１２ｂ メモリ
１２ｃ 暗号処理器
１２ｄ 接続端子
１２ｆ 受信バッファ
１１ａ ＣＰＵ
１１ｂ メモリ
１１ｃ ストレージ
１１ｄ 外部接続端子
１２ サブシステム
１２ａ ＣＰＵ
１２ｂ メモリ
１２ｃ 暗号処理器
１２ｄ 接続端子
１２ｆ 受信バッファ
Claims (9)
- メインプログラムで動作するメインシステムと、サブプログラムで動作するとともに該メインシステムの制御下で動作する複数のサブシステムが所定のバスによって離接可能に接続されている複合システムにおいて、
前記メインシステムは、
暗号処理の対象となるデータを分割したデータ断片ごとにサブシステムに転送する転送手段を有し、
前記サブシステムは、
前記メインシステムから受信したデータ断片を一時的に書き込み／読み出し可能な受信バッファを有し、
前記メインシステムの暗号処理の対象となるデータのサイズが、前記サブシステムの受信バッファの容量よりも大きい場合であっても、前記メインシステムと前記サブシステムとの間で暗号処理を行う、ことを特徴とする複合システム。 - 前記サブシステムは、公開鍵を保存するためのセキュアデータベースを有することを特徴とする請求項１記載の複合システム。
- 前記サブシステムは、セキュアデータベースにアクセス可能な暗号アプリサーバを有することを特徴とする請求項２記載の複合システム。
- 前記暗号アプリサーバが、データ整列ルールを示す情報を保存することを特徴とする請求項３記載の複合システム。
- 前記サブシステムは、データ整列ルールを示す情報を保存し、セキュアデータベースにアクセス可能な暗号アプリサーバを実行することを特徴とする請求項２記載の複合システム。
- 前記メインシステムは、暗号アプリサーバからデータ整列ルールを取得する前記暗号利用アプリを実行することを特徴とする請求項５記載の複合システム。
- 前記メインシステムは、前記メインシステムと前記サブシステムとを接続するバスの種類を判定する分割判定部を有することを特徴とする請求項１乃至６の何れか１項に記載の複合システム。
- 前記メインシステムは、前記分割処理を前記暗号利用アプリから隠蔽することが可能な暗号処理プロキシを有することを特徴とする請求項１乃至７の何れか１項に記載の複合システム。
- 前記メインシステムは、前記対象データを変換した結果に対するデジタル署名を複数保持することを特徴とする請求項１乃至８の何れか１項に記載の複合システム。
Priority Applications (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2012000482A JP2013141137A (ja) | 2012-01-05 | 2012-01-05 | 複合システム |
| US13/693,409 US9401809B2 (en) | 2012-01-05 | 2012-12-04 | Composite system, method, and storage medium |
| CN201310002574.8A CN103198258B (zh) | 2012-01-05 | 2013-01-04 | 复合系统以及传输数据的方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2012000482A JP2013141137A (ja) | 2012-01-05 | 2012-01-05 | 複合システム |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2013141137A true JP2013141137A (ja) | 2013-07-18 |
Family
ID=48720805
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2012000482A Pending JP2013141137A (ja) | 2012-01-05 | 2012-01-05 | 複合システム |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US9401809B2 (ja) |
| JP (1) | JP2013141137A (ja) |
| CN (1) | CN103198258B (ja) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11271763B2 (en) | 2018-06-19 | 2022-03-08 | Ricoh Company, Ltd. | Information processing system, information processing apparatus, and information processing method |
| US10887551B2 (en) | 2018-11-29 | 2021-01-05 | Ricoh Company, Ltd. | Information processing apparatus, information processing system and information processing method |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH02184954A (ja) * | 1989-01-11 | 1990-07-19 | Nec Corp | 入出力インターフェース自動認識方式 |
| US5689565A (en) * | 1995-06-29 | 1997-11-18 | Microsoft Corporation | Cryptography system and method for providing cryptographic services for a computer application |
| JPH11225138A (ja) * | 1998-02-06 | 1999-08-17 | Matsushita Electric Ind Co Ltd | 暗号処理装置、暗号処理方法及びその方法を記録した記録媒体 |
| JP2003514464A (ja) * | 1999-11-12 | 2003-04-15 | ジェネラル・インスツルメント・コーポレーション | オブジェクトセキュリティのインプレメンテーション |
| JP2004064665A (ja) * | 2002-07-31 | 2004-02-26 | Canon Inc | データ転送装置及び送信装置及び受信装置及びそれらの制御方法 |
| JP2010016526A (ja) * | 2008-07-02 | 2010-01-21 | Mitsubishi Electric Corp | 通信装置及び暗号通信システム及び通信方法及び通信プログラム |
| JP2011164810A (ja) * | 2010-02-08 | 2011-08-25 | Ricoh Co Ltd | 複合システム、セキュリティ方法、セキュリティプログラム及び記録媒体 |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3305667B2 (ja) | 1998-11-11 | 2002-07-24 | 日本電気株式会社 | ファームウェアデータの書込み方法 |
| US20050152350A1 (en) * | 2003-12-22 | 2005-07-14 | Nak-Woon Sung | System and method for transmitting/receiving automatic repeat request |
| JP4802123B2 (ja) * | 2007-03-07 | 2011-10-26 | 富士通株式会社 | 情報送信装置、情報送信方法、情報送信プログラムおよび該プログラムを記録した記録媒体 |
| CN101110982A (zh) | 2007-06-19 | 2008-01-23 | 李儒耕 | 一种利用无线终端和服务器获取证据的方法 |
| CN101304569A (zh) | 2008-04-24 | 2008-11-12 | 中山大学 | 一种基于智能手机的移动认证系统 |
| CN101770386B (zh) | 2010-03-08 | 2013-06-19 | 飞天诚信科技股份有限公司 | 一种Linux嵌入式系统的安全启动方法 |
-
2012
- 2012-01-05 JP JP2012000482A patent/JP2013141137A/ja active Pending
- 2012-12-04 US US13/693,409 patent/US9401809B2/en not_active Expired - Fee Related
-
2013
- 2013-01-04 CN CN201310002574.8A patent/CN103198258B/zh not_active Expired - Fee Related
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH02184954A (ja) * | 1989-01-11 | 1990-07-19 | Nec Corp | 入出力インターフェース自動認識方式 |
| US5689565A (en) * | 1995-06-29 | 1997-11-18 | Microsoft Corporation | Cryptography system and method for providing cryptographic services for a computer application |
| JPH11225138A (ja) * | 1998-02-06 | 1999-08-17 | Matsushita Electric Ind Co Ltd | 暗号処理装置、暗号処理方法及びその方法を記録した記録媒体 |
| JP2003514464A (ja) * | 1999-11-12 | 2003-04-15 | ジェネラル・インスツルメント・コーポレーション | オブジェクトセキュリティのインプレメンテーション |
| JP2004064665A (ja) * | 2002-07-31 | 2004-02-26 | Canon Inc | データ転送装置及び送信装置及び受信装置及びそれらの制御方法 |
| JP2010016526A (ja) * | 2008-07-02 | 2010-01-21 | Mitsubishi Electric Corp | 通信装置及び暗号通信システム及び通信方法及び通信プログラム |
| JP2011164810A (ja) * | 2010-02-08 | 2011-08-25 | Ricoh Co Ltd | 複合システム、セキュリティ方法、セキュリティプログラム及び記録媒体 |
Non-Patent Citations (2)
| Title |
|---|
| JPN6015032299; 青木克彦，松本博幸: '暗号認証ハードウェアアクセラレータ' ＮＴＴ技術ジャーナル 第１１巻 第３号, 19990301, ｐ．１７-２２ * |
| JPN7015002199; Ｋｅｒｏｍｙｔｉｓ， Ａ． Ｄ． ｅｔ ａｌ，: 'Ｃｒｙｐｔｏｇｒａｐｈｙ Ａｓ Ａｎ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ Ｓｅｒｖｉｃｅ：Ａ Ｃａｓｅ Ｓｔｕｄｙ' ＡＣＭ Ｔｒａｎｓａｃｔｉｏｎｓ ｏｎ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍｓ ｏｌｕｍｅ ２４ Ｉｓｓｕｅ １, 200602, ｐ．１-３８ * |
Also Published As
| Publication number | Publication date |
|---|---|
| US20130179675A1 (en) | 2013-07-11 |
| CN103198258B (zh) | 2016-01-20 |
| US9401809B2 (en) | 2016-07-26 |
| CN103198258A (zh) | 2013-07-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP7372434B2 (ja) | スクリプトに基づくブロックチェーン相互作用 | |
| US10778441B2 (en) | Redactable document signatures | |
| JP6877448B2 (ja) | 分散ハッシュテーブル及びブロックチェーンを用いてコンピュータソフトウェアを保証する方法及びシステム | |
| CN109074433B (zh) | 使用分布式散列表和点对点分布式分类账验证数字资产完整性的方法和系统 | |
| US11347876B2 (en) | Access control | |
| US10956614B2 (en) | Expendable access control | |
| TW202405713A (zh) | 去信任確定性狀態機之電腦實施方法 | |
| KR20210096178A (ko) | 블록체인 상에 저장된 데이터에 접근할 수 있도록 하는 컴퓨터 구현 시스템 및 방법 | |
| EP3739538A1 (en) | System and method of supporting reflection of transactions between blockchain networks | |
| US20230066955A1 (en) | Efficient post-quantum secure software updates tailored to resource-constrained devices | |
| US11575515B2 (en) | Post-quantum secure remote attestation for autonomous systems | |
| CN111295650A (zh) | 在基于区块链的系统中执行映射迭代 | |
| TW202025665A (zh) | 用以移轉數位資源存取權之電腦實施系統及方法 | |
| CN110880143A (zh) | 用于处理去中心化应用中的交易验证操作的系统和方法 | |
| WO2023107776A1 (en) | Efficient hybridization of classical and post-quantum signatures | |
| CN103761487B (zh) | 文件的隐藏方法及装置 | |
| JP2013141137A (ja) | 複合システム | |
| CN109324997B (zh) | 一种基于区块链的数字权利保护方法及装置 | |
| US20220247570A1 (en) | Content use system, permission terminal, browsing terminal, distribution terminal, and content use program | |
| CN112970227A (zh) | 包括公钥组合验证的计算机实现的系统和方法 | |
| JP6939313B2 (ja) | 分散認証システム | |
| US20220109558A1 (en) | Xmss management to address randomized hashing and federal information processing standards | |
| WO2022170973A1 (zh) | 密钥灌装方法、系统、装置、设备以及存储介质 | |
| CN111857883B (zh) | 页面数据校验方法、装置、电子设备及存储介质 | |
| TWI837227B (zh) | 用於透過點對點網路儲存、提取及傳遞資料之電腦實施系統及方法 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20141217 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20150624 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20150818 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20151215 |