JP2010258993A - データ処理装置 - Google Patents

Abstract

【課題】機器間通信のためのデータの秘匿化処理と並行して実施できるデータの完全性認証処理を実現し、処理時間を低減させる。
【解決手段】制御装置１がデータを送信する場合は、送信データの認証範囲を先頭から１ＢｙｔｅずつウィンドウをスライドさせてストリームＨＡＳＨ計算部４３１がウィンドウサイズ分のＨＡＳＨ値を生成し、演算値累積加算部４３０が、ＨＡＳＨ値が算出される度に、ＨＡＳＨ演算の順序に従って累積加算していき、演算値累積加算部４３０の最終的な累積加算値を認証値として送信データに付加して、送信する。制御装置１がデータを受信する場合は、同様の手順によりストリームＨＡＳＨ計算部４３１がＨＡＳＨ値を算出するとともに演算値累積加算部４３０がＨＡＳＨ値を累積加算していき、演算値累積加算部４３０の最終的な累積加算値と受信データに付加されている認証値とを照合して、データの改ざんの有無を検証する。
【選択図】図１

Description

本発明は、データ処理装置での通信における機器認証、データ完全性認証、データ秘匿化に関し、特に、ＬＣＮＡ（Ｌｏｗ Ｃｏｓｔ Ｎｅｔｗｏｒｋ Ａｐｐｌｉａｎｃｅ：以下ＬＣＮＡ）間通信に求められるセキュリティ強度を保ちながら、機器間通信の機器認証、データ完全性認証、データ秘匿化を軽量に行う技術に関する。

ビル設備（ファシリティ）機器とその管理機器からなるファシリティネットワークでは、空調管理や入退室管理といった各々の機能を実現するための多数の設備機器がビル内に存在し、これらは機能毎に制御装置により管理される。
制御装置は、管理サーバあるいは管理センタにより管理される。
制御装置は設備機器から取得したビル内の各種情報を管理サーバなどに送信すると共に、管理サーバからの各種コマンドに従い設備機器を制御する。

制御装置は、コスト面の制約から一般にＬＣＮＡが用いられる。

近年のファシリティネットワークではシステムのオープン化が求められている。
オープン化は機器コストや施設作業コストの低減が期待できる半面、接続の容易性からセキュリティの確保が必達である。

近年、ファシリティネットワーク内のＬＣＮＡ間の通信では、オープンなプロトコルの１つであるＩＰｖ６プロトコルが普及しつつある。
その理由として、ＩＰｖ６は多棟管理性、群管理性に優れ、広大なアドレス空間は大量の管理点数を管理する必要性に合致し、またアクセス制御に優れたサービス網を比較的安価に構築可能であることが挙げられる。

また、ＩＰｖ６プロトコルスタックはＩＰｓｅｃを実装することが必須であるため、セキュリティの面においてもファシリティネットワークの要求に合致する。

しかしながら、ＩＰｖ６はパーソナルコンピュータ（ＰＣ）がインターネットにアクセスすることを前提に作られた経緯がある。
従い、ＩＰｓｅｃで用いられる暗号アルゴリズム、認証アルゴリズムは、高いセキュリティ強度を実現する反面、高い演算処理能力と計算容量を必要とする。

計算資源が豊富にあるＰＣと異なり、ＬＣＮＡでＩＰｓｅｃを用いると、不必要に高いセキュリティ強度のために性能を犠牲とすることとなり、通信性能が数十分の一にまで低下してしまう。

ファシリティネットワークに求められるセキュリティは、インターネットなど広域網に求められるセキュリティとは異なる。
これはデータを保護すべき期間によるものである。

ファシリティネットワークにおいて機器認証及び秘匿通信を行う理由の１つは、緊急停止などの管理者コマンドを第三者が任意に発行することを防ぐことである。

顧客がファシリティネットワーク内の各種情報を閲覧する際、リアルタイムに第三者が傍受可能であれば、スプーフィング技術などを用いて第三者が顧客に事実と異なる情報を見せる恐れもある。
これを防ぐこともまた機器認証及び秘匿通信を行う理由の１つである。

一方、インターネットなどの広域網において機器認証及び秘匿通信が用いられる場合には、非公開文書の送受信やキャッシュカードの暗証番号の送信などがある。
こうした情報は、通信が終了した後でも長期間守られる必要がある。これに反して、ファシリティネットワークでは安全性の保証を必要とする期間が短く、通信する両者において送受信が完了した段階で完了する。

一例として、秘密鍵を３ヶ月毎に交換する場合、ファシリティネットワークの通信では、仮に秘匿通信内容が４ヶ月後に解読されたとしても、その時には既に秘密鍵は交換されており、従い緊急停止コマンドを送りつけて誤動作を引き起こすことを計画しても実施することは不可能である。

反して、秘密鍵を３ヶ月毎に交換するとしても、長期間守られる必要のある情報の場合は鍵交換後に解読されても有意な情報である。
こうした情報を秘匿するためには暗号論的秘匿強度が必要となるが、ファシリティネットワークの通信では必ずしも必要では無い。

また、ファシリティネットワークは通常数ヶ月周期でメンテナンスを行うため、自動的な秘密鍵交換プロトコルを有さないＬＣＮＡであっても、メンテナンス作業の一環としてこの周期で秘密鍵の交換が行えることが期待できる。

秘密鍵は数ヶ月毎の交換が期待できるため、仮にアルゴリズム自体に暗号論的秘匿強度が期待できないとしても、高々数ヶ月程度の秘匿強度さえ保証できれば、ファシリティネットワーク内のＬＣＮＡとの通信では秘密鍵の交換により第三者の脅威を防ぐことが可能である。

岡部ほか「非ＰＣ系ディジタル機器への適用に向けたＩＰｖ６最小要求仕様の検討」情報処理学会誌，Ｖｏｌ．４２，Ｎｏ．９，ｐｐ．９２０−９２５，２００１．

以上の如く、ＬＣＮＡの通信では必ずしも暗号論的秘匿強度は必要ではない。
処理に要する計算量が少ない代わりに数ヶ月程度の強度しか無いアルゴリズムであっても、数ヶ月程度の強度が保証できるのであれば、秘密鍵の管理を行う限りファシリティネットワークでは永続的にセキュリティ強度を保つことが可能である。
注意として、この時間的前提は秘匿通信の鍵をビル設備のメンテナンス周期毎に交換することに依存するため、上記程度の強度は保証できなければならない。

ここで秘匿通信は、送信元認証とメッセージの改ざん検知機能もまた有する必要がある。
こうした処理を追加するために新たなハードウェアを追加することはコスト増加となるため、ＬＣＮＡでは通常これらの処理をソフトウェア（以下、Ｓ／Ｗ）にて行う。

本質的に、メッセージ認証はメッセージパケットが秘匿化処理を完了していなければ実施できない。
単一のＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）により秘匿化処理と認証処理を行う場合、各々の処理のために異なるアルゴリズムを用いるのであれば、両処理は別々に行う必要がある。
すなわち、秘匿化処理中に該メッセージの認証処理を行うことは出来ず、メッセージの認証処理中に次のメッセージの秘匿化処理を行うことは出来ない。

通信の秘匿化処理や認証処理が如何に軽量であっても、秘匿化処理と認証処理が別々に動作する場合、こうした処理の排他性により処理時間が増加して通信性能が劣化する。

本発明は、上記の課題に鑑みたものであり、機器間通信のためのデータの秘匿化処理と並行して実施できるデータの完全性認証処理を実現し、データ秘匿化処理とデータ完全性認証処理を並行して実施することにより、処理時間を低減させる仕組みを実現することを主な目的とする。
なお、ＩＰｓｅｃプロトコルでは暗号アルゴリズム、認証アルゴリズムはプロトコル自身と独立して実装可能である。上記の課題を解決する仕組みがＩＰｓｅｃプロトコルから利用可能であれば、ＩＰｖ６のＩＰｓｅｃ通信をＬＣＮＡで利用することが可能となる。

本発明に係るデータ処理装置は、
データの改ざん検知に用いられる認証値を生成するデータ処理装置であって、
改ざん検知の対象となる改ざん検知対象データの一方向演算を所定の演算対象データ長ごとに行って、演算対象データ長ごとの一方向演算値を複数算出する一方向演算部と、
前記一方向演算部により算出された複数の一方向演算値のうちの２以上の一方向演算値を一方向演算の順序に従って累積加算する演算値累積加算部と、
前記演算値累積加算部により累積加算された累積加算値を前記改ざん検知対象データの認証値とする認証値指定部とを有することを特徴とする。

本発明によれば、一方向演算値を順次算出するとともに、一方向演算値を累積加算することでデータ改ざん検知のための認証値を生成することができ、これにより、データ秘匿化処理と認証値を生成する処理とを並行して実施することができ、処理時間を低減させることができる。

実施の形態１〜６に係るファシリティネットワークの構成例を示す図。 実施の形態１に係る制御装置の構成例を示す図。 実施の形態１に係るストリームＨＡＳＨを説明する図。 実施の形態１に係る制御装置のデータ送信時の処理例を示す図。 実施の形態１に係る制御装置のデータ受信時の処理例を示す図。 実施の形態１に係る制御装置の認証値の計算の流れを示す図。 実施の形態２に係る送信データの例を示す図。 実施の形態２に係る制御装置の構成例を示す図。 実施の形態２に係る制御装置のデータ送信時の処理例を示すフローチャート図。 実施の形態２に係る初期位置秘匿処理を示すフローチャート図。 実施の形態２に係る初期秘匿処理を示すフローチャート図。 実施の形態２に係る秘匿認証処理を示すフローチャート図。 実施の形態２に係る制御装置の認証値の計算と秘匿化処理の流れを示す図。 実施の形態２に係る制御装置の認証値の計算と秘匿化処理の流れを示す図。 実施の形態２に係る受信データの例を示す図。 実施の形態２に係る制御装置のデータ受信時の処理例を示すフローチャート図。 実施の形態２に係る初期位置復号処理を示すフローチャート図。 実施の形態２に係る復号処理を示すフローチャート図。 実施の形態２に係るスライディング処理を示すフローチャート図。 実施の形態２に係る制御装置の認証値の計算と復号処理の流れを示す図。 実施の形態２に係る制御装置の認証値の計算と復号処理の流れを示す図。 実施の形態２に係る制御装置の認証値の計算と復号処理の流れを示す図。 実施の形態２に係る認証値を判定する動作を示す図。 実施の形態２に係る認証値判定後の動作を示す図。

実施の形態１．
図１は、本実施の形態及び以降の実施の形態で説明するファシリティネットワークの構成例を示す。
ビル側ネットワークでは、空調管理や入退室管理といった各々の機能を実現するための多数の設備機器がビル内に存在し、これらは機能毎に制御装置１により管理される。
制御装置１は、管理サーバあるいは管理センタにより管理される。
制御装置１は設備機器から取得したビル内の各種情報を管理サーバなどに送信すると共に、管理サーバからの各種コマンドに従い設備機器を制御する。

制御装置１は、コスト面の制約から一般にＬＣＮＡが用いられる。
制御装置１は、データ処理装置の例である。

本実施の形態では、制御装置１においてデータの完全性を保持するための構成と方式について述べる。
つまり、本実施の形態では、データ秘匿化処理と並行して実施できるデータの完全性を保持するための処理（以下、データ完全性認証処理ともいう）を説明する。
本実施の形態で説明するデータ完全性認証処理と並行してデータ秘匿化処理を行う例は実施の形態２以降で説明する。
換言すると、実施の形態２以降に示す制御装置１の動作からデータ秘匿化処理を捨象してデータ完全性認証処理を抽出すると、抽出されたデータ完全性認証処理は本実施の形態で説明するデータ完全性認証処理と同じ内容である。
実施の形態２以降で説明するようにデータ秘匿化処理とデータ完全性認証処理を並行して実行することにより、処理時間を短縮することができる。
なお、データ完全性認証処理とは、制御装置１がデータの送信側である場合は、制御装置１が送信データの改ざん検知に用いられる認証値を生成し、送信データに認証値を付加することであり、制御装置１がデータの受信側である場合は、受信データに対して演算を行って認証値を算出するとともに、受信データに付加されている認証値と算出した認証値とを照合して受信データの改ざんを検知することである。

図２は、本実施の形態に係る制御装置１の構成例を示す。
制御装置１は設備機器制御部２と通信制御部３の間にデータ完全性確保手段４が設けられている。
なお、通信制御部３は、データ送信部及びデータ受信部の例である。

データ完全性確保手段４は、その内部に送信側秘匿処理制御部４１と、受信側秘匿処理制御部４２、及びＨＡＳＨ計算部４３を持つ。

送信側秘匿処理制御部４１は、ＨＡＳＨ計算管理部４１１と、送信側秘匿通信処理部４１２を持つ。
本実施の形態では、送信側秘匿通信処理部４１２は、データの秘匿化処理は行わずに、データ送信時に、ＨＡＳＨ計算管理部４１１、ストリームＨＡＳＨ計算部４３１、演算値累積加算部４３０の制御を行う。また、送信側秘匿通信処理部４１２は、認証値を決定し、認証値を送信データに付加する。送信側秘匿通信処理部４１２は、認証値指定部の例である。

受信側秘匿処理制御部４２は、ＨＡＳＨ計算管理部４２１と、受信側秘匿通信処理部４２２を持つ。
このＨＡＳＨ計算管理部４２１は送信側秘匿処理制御部４１が有するＨＡＳＨ計算管理部４１１と同じ機構である。
本実施の形態では、受信側秘匿通信処理部４２２は、データの復号処理は行わずに、データ受信時に、ＨＡＳＨ計算管理部４２１、ストリームＨＡＳＨ計算部４３１、演算値累積加算部４３０の制御を行う。また、受信側秘匿通信処理部４２２は、受信データに付加されている認証値と、ＨＡＳＨ演算により導出された認証値とを照合して、データの改ざんの有無を検証する。受信側秘匿通信処理部４２２は、照合部の例である。

ＨＡＳＨ計算部４３は、その内部にストリームＨＡＳＨ計算部４３１と演算値累積加算部４３０を有する。
ストリームＨＡＳＨ計算部４３１は、一方向演算であるＨＡＳＨ演算を行う。ストリームＨＡＳＨ計算部４３１は、一方向演算部の例である。
なお、ストリームＨＡＳＨ計算部４３１は、必ずしもストリームＨＡＳＨを計算する必要は無く、ＨＡＳＨ値を計算する手段を提供するものであれば良い。しかしながら、計算量の点からストリームＨＡＳＨを採用することが好ましい。
本実施の形態ではＲａｂｉｎ−Ｋａｒｐ法に基づくＲａｂｉｎ ＦｉｎｇｅｒｐｒｉｎｔｉｎｇをＨＡＳＨ関数として採用する。
このＨＡＳＨ関数は、非特許文献２に述べられるものであり、出力長は６４ｂｉｔである。Ｒａｂｉｎ Ｆｉｎｇｅｒｐｒｉｎｔｉｎｇの演算量は、データ１Ｂｙｔｅ辺りＸＯＲ２回、シフト２回、ＯＲ１回である。
また、演算値累積加算部４３０は、ストリームＨＡＳＨ計算部４３１によりＨＡＳＨ値が計算される度に、計算されたＨＡＳＨ値を順次累積加算していく。
演算値累積加算部４３０は、例えば、累積加算レジスタを用いて構成される。

非特許文献２：Ｍ．Ｒａｂｉｎ，“Ｆｉｎｇｅｒｐｒｉｎｔｉｎｇ ｂｙ ｒａｎｄｏｍ ｐｏｌｙｎｏｍｉａｌｓ，” Ｔｅｃｈｎｉｃａｌ Ｒｅｐｏｒｔ ＴＲ−１５−８１，Ｈａｒｖａｒｄ Ｕｎｉｖｅｒｓｉｔｙ， Ｄｅｐａｒｔｍｅｎｔ ｏｆ Ｃｏｍｐｕｔｅｒ Ｓｃｉｅｎｃｅ，１９８１．

図３は、ストリームＨＡＳＨについての説明を示す図である。
ＨＡＳＨ値を計算する計算対象データ５から、ウィンドウサイズと呼ぶ一定の入力長のデータを切り出してＨＡＳＨ関数６に入力する。ウィンドウサイズは、ハッシュ演算の対象となるデータ長であり、演算対象データ長の例である。
切り出し方は５１、５２、５３の如く、１Ｂｙｔｅずつスライディングして切り出す。
５１、５２、５３の如く切り出されたデータは、各々について、６１、６２、６３の如くＨＡＳＨ値が生成される。
なお、本明細書では、ウィンドウのスライド量を１Ｂｙｔｅとして説明するが、ウィンドウサイズよりもスライド量が少なければ（スライド量＜ウィンドウサイズ）、スライド量は１Ｂｙｔｅでなくてもよい。

ＨＡＳＨ関数６は６４ｂｉｔの鍵により初期化されるため、異なる鍵で初期化されたＨＡＳＨ関数は同じ入力値であっても異なるＨＡＳＨ値を出力する。
また逆に、同じ鍵を用いて初期化されたＨＡＳＨ関数であっても、ウィンドウサイズが異なるＨＡＳＨ関数であれば異なる値を出力する。
すなわち、ストリームＨＡＳＨは鍵とウィンドウサイズが一致することで初めて同じＨＡＳＨ関数が構成できる。

制御装置１は、設備機器からのデータを他の機器へ送信する際、前記データ完全性確保手段４を経由して、データの認証対象範囲（改ざん検知対象データ）に従い認証値を計算する。
この動作を図４に示す。
ここで、認証範囲は必ずしもＭＳＢ（Ｍｏｓｔ Ｓｉｇｎｉｆｉｃａｎｔ Ｂｉｔ）から送信データ全域である必要は無く、その一部であっても良い。
指定可能な最大範囲は送信データ全域であり、最小範囲は１ｂｉｔである。
ただし実用上の最小単位は１Ｂｙｔｅであるため、本明細書の以降の説明では最小範囲を１Ｂｙｔｅで説明する。
認証開始位置と認証範囲を指定する方法は本実施の形態では問わないが、通常、送信データが有するヘッダに格納されているか、あるいは事前の取り決めによりなされる。

制御装置１は、他の機器からデータを受取った際、前記データ完全性確保手段４により受信データの完全性を検証する。
この動作を図５に示す。
認証範囲に従って受信データの認証値を計算した後、受信データが保持する認証値との比較を行う。
認証値が一致した場合、受信データは送信元から送信されたままのデータであるため正しい受信データとして扱う。
認証値が不一致の場合、受信データは経路の途中で改ざんされたか、あるいはデータが破損した場合である。
いずれの場合であっても受信データとして採用することは出来ず、ゆえにデータを破棄する。
受信側においても、認証開始位置と認証範囲を指定する方法は本実施の形態では特に問わない。

従来、メッセージに誤りが含まれていないことを確認する手段として、確認対象領域の全体に対するチェックサムが広く用いられている。
しかしながらチェックサムは容易に再計算可能であるため、データの改ざんを狙う第三者が通信路上に存在した場合、チェックサムも改ざんされていることが考えられる。
そこで本実施の形態では、データのチェックサムを用いる替わりに、改ざん検出したいデータの全域に対してＨＡＳＨ値を計算し、その総和を、データの完全性を保証する認証値として用いている。
認証値は共有する情報を知らなければ容易に再計算することは出来ない。
本実施の形態では、非特許文献２に基づきＨＡＳＨ値を計算するので、通信端点の両者において多項式の基数とウィンドウサイズの２つの情報を共有する必要がある。
本実施の形態では多項式の基数を鍵として用いる。

該基数の選択は、多項式であるＨＡＳＨ関数が既約となるように定めることが望ましい。

次に、データ完全性確保手段４が認証値を計算するまでの処理の流れを説明する。

まず、制御装置１が送信側である場合の制御装置１の処理について記述する。
送信側秘匿処理制御部４１内のＨＡＳＨ計算管理部４１１では、通信端点の両者で共有すべき情報を管理し、最低限、認証値の計算に用いる鍵を含む。
本例の如くＲａｂｉｎ ＦｉｎｇｅｒｐｒｉｎｔｉｎｇをＨＡＳＨ関数として採用する場合、６４ｂｉｔの鍵と、ウィンドウサイズ、鍵より計算される係数テーブルである。これらが必要である理由は非特許文献２に依る。
係数テーブルは鍵が替わる毎に計算される。

送信側秘匿通信処理部４１２は認証値を計算すべき送信データが発生すると、ＨＡＳＨ計算部４３のストリームＨＡＳＨ計算部４３１と、ＨＡＳＨ計算管理部４１１を用いて認証値の計算を行う。

認証開始位置と認証範囲は事前設定あるいは送信データヘッダに情報が格納されているものとする。
認証値の計算に先立ち、送信側秘匿通信処理部４１２はストリームＨＡＳＨ計算部４３１の初期化を行う。
この処理はＨＡＳＨ計算管理部４１１の係数テーブルをストリームＨＡＳＨ計算部４３１に設定することと、ウィンドウサイズ分の値０をストリームＨＡＳＨ計算部４３１に与えることで実現される。

初期化を終えた後、送信側秘匿通信処理部４１２は認証値の計算を行う。
この流れを図６に示す。
累積加算レジスタ４１２１の初期値は０である。累積加算レジスタ４１２１は、演算値累積加算部４３０を構成するレジスタである。
認証範囲の先頭からウィンドウサイズ分をストリームＨＡＳＨ計算部４３１に入力するとＨＡＳＨ値が出力されるため、この値を累積加算レジスタ４１２１に加算する。
本実施の形態では認証値のｂｉｔ幅を６４ｂｉｔと想定しており、従い累積加算レジスタ４１２１もまた６４ｂｉｔである。
ただし、該ｂｉｔ幅は利用に際して適切な幅を選択してもよい。

認証範囲７０１がウィンドウサイズに満たない場合、認証範囲以外を０と見なしてストリームＨＡＳＨ計算部４３１に入力する。

ウィンドウサイズの次の１ＢｙｔｅをストリームＨＡＳＨ計算部４３１に入力することで、ストリームＨＡＳＨは１Ｂｙｔｅ分スライディングすることとなる。
以降、ストリームＨＡＳＨ計算部４３１はスライディングするたびにＨＡＳＨ値を出力するため、累積加算レジスタ４１２１にて、ＨＡＳＨ演算の順序に従って順次累積加算を行う。

ウィンドウの端が認証範囲の終点に到達し、その時に出力されたＨＡＳＨ値を累積加算レジスタ４１２１にて加算し終えると、送信側秘匿通信処理部４１２が累積加算レジスタの最終値（最終的な累積加算値）を認証値として採用する。
送信データ７００を通信路に送信する際、送信側秘匿通信処理部４１２がこの認証値７１２を送信データ７００に続けて送信する。
以上で送信側の認証値の計算を完了する。

受信側の処理は、通信制御部３がデータを受信した後、データ完全性確保手段４に渡されることで開始される。

認証値の計算方法は送信側の計算方法と同一である。
つまり、受信データの認証範囲（改ざん検知対象データ）を先頭から１ＢｙｔｅずつウィンドウをスライドさせながらストリームＨＡＳＨ計算部４３１がウィンドウサイズ分のＨＡＳＨ値を生成し、演算値累積加算部４３０が、ストリームＨＡＳＨ計算部４３１によりＨＡＳＨ値が算出される度に、ＨＡＳＨ演算の順序に従って累積加算していく。
ただし、受信データは送信側で計算した認証値が付与されているため、受信側秘匿通信処理部４２２は、自身が計算した認証値（演算値累積加算部４３０の最終的な累積加算値）と送信側が付与した認証値との照合を行い、その結果をもって受信データの完全性の判定を行う。

送信側と受信側で同じ値となるためには同じＨＡＳＨ関数を構成する必要があり、そのためには通信端点の両者で同じ鍵とウィンドウサイズを共有する必要がある。
受信側で計算した認証値が、送信側から付加された認証値と一致するならば、認証範囲のデータは通信経路上で改ざんされていないといえる。
通信路上でデータが改ざんされると受信側で計算した認証値と送信側で付与した認証値が一致せず、改ざんを検出することが可能である。

秘密情報を共有していなければ認証値が一致しないため、当該処理は相手認証としても機能する。以上により、データ完全性機能、相手認証機能が実現できる。

国や地域によってはデータの秘匿化が禁止されている場合もあり、本実施の形態はこうした場合に対応することが可能である。
上記に述べた方法により、秘匿化処理を行わずに、平文に対するデータ完全性機能、相手認証機能を提供することが可能である。

なお、以上では、ＨＡＳＨ値の累積加算値の最終値を認証値とする例を説明したが、途中の累積加算値を認証値にしてもよい。
例えば、送信側と受信側がＮ（Ｎ≧２）回目に算出された累積加算値を認証値とする旨を事前に取り決めておけば、Ｎ回目の累積加算値を認証値として用いることができる。

実施の形態２．
本実施の形態では、実施の形態１で説明したデータ完全性認証処理と同時にデータ秘匿化処理を行う例を説明する。
ここで、秘匿通信におけるデータの完全性機能とは、秘匿処理後のデータに対して提供されなければならないことに注意されたい。
つまり、本実施の形態では、データ送信時には、秘匿化処理がされた後のデータに対してＨＡＳＨ値を算出し、算出したＨＡＳＨ値の累積加算を行う。また、秘匿化処理は、ＨＡＳＨ値の累積加算値を用いて行われる。
また、データ受信時には、復号処理が行われていない（秘匿化されたままの状態の）データに対してＨＡＳＨ値を算出し、算出したＨＡＳＨ値の累積加算を行う。また、復号処理は、ＨＡＳＨ値の累積加算値を用いて行われる。

以降では、処理の一例として図７に示す送信データ７００の秘匿化処理及び認証計算を行う。
本実施の形態で述べる秘匿化計算では、ソフトウェア（Ｓ／Ｗ）実装であっても秘匿化処理と認証計算を同時処理することが可能である。
これにより、秘匿処理と認証計算に各々別のアルゴリズムを用いる場合と比較して高速に処理を終えることが可能となる。

秘匿通信機能まで提供する制御装置１の構成を図８に示す。
図２の構成と比較して、ＨＡＳＨ計算部４３に初期ＨＡＳＨ計算部４３２を取り付ける。
初期ＨＡＳＨ計算部４３２はストリームＨＡＳＨ計算部４３１と異なるＨＡＳＨ計算部であれば任意であるが、本実施の形態では該手段の実装としてＡｄｌｅｒ−３２やＣＲＣ−３２などの３２ｂｉｔチェックサム計算手段の実装を想定する。
この理由は、Ｓ／Ｗ実装であっても処理が高速であり、かつ、鍵などの事前に既知とする前提条件が不要な計算部だからである。
なお、初期ＨＡＳＨ計算部４３２もストリームＨＡＳＨ計算部４３１とともに一方向演算部の例である。

送信側は通信データを秘匿化し、そして受信側は秘匿化されたデータを復号する必要がある。
そのため、送信側秘匿通信処理部４１２と受信側秘匿通信処理部４２２の処理内容もまた実施の形態１で示した処理と異なる。
実施の形態１と異なり、送信側秘匿通信処理部４１２はデータ秘匿化処理を行い、受信側秘匿通信処理部４２２はデータの復号処理を行う。
本実施の形態に係る送信側秘匿通信処理部４１２は秘匿化処理部及び認証値指定部の例であり、本実施の形態に係る受信側秘匿通信処理部４２２は復号処理部及び照合部の例である。
以降、送信側秘匿通信処理部４１２及び受信側秘匿通信処理部４２２の処理の詳細を述べる。

送信側秘匿通信処理部４１２のフローチャートを図９、図１０、図１１、図１２に示す。
また、フローチャートが述べる処理の内容を図１３、図１４に示す。
以下、これらの図面をもとに説明を行う。

まず、ＨＡＳＨ計算管理部４１１に保持した係数テーブルをストリームＨＡＳＨ計算部４３１に設定することで初期化を行う。
送信データ７００の秘匿認証範囲７０２の秘匿化と認証値計算のためにストリームＨＡＳＨ計算部４３１を用いるが、範囲７０２の先頭からウィンドウサイズ分はストリームＨＡＳＨの性質上ストリームＨＡＳＨ計算部４３１を用いて秘匿化することが出来ない。
そのため、該部分の秘匿化処理は初期位置秘匿処理を用いて行う。

図９の初期位置秘匿処理では秘匿認証範囲７０２の先頭からウィンドウサイズ分のデータの秘匿処理を行う。
この初期位置秘匿処理のフローチャートは図１０及び図１１である。
ここで、図１３は図１１の動作を説明するための図である。
範囲７０２の先頭からウィンドウサイズ分の秘匿処理を行うために、送信側秘匿通信処理部４１２は、共有情報である鍵値４１１１を初期ＨＡＳＨ計算部４３２に入力して、鍵値から計算した３２ｂｉｔ値４３２１を得る。
この値４３２１を初期ＨＡＳＨ計算部４３２の入力に用い、新たな３２ｂｉｔ値４３２２を得る。この値４３２２と、送信データの先頭から３２ｂｉｔ分とを送信側秘匿通信処理部４１２がＸＯＲし、その結果値を秘匿済みデータとする。
なお、図１３〜図１５において、秘匿認証範囲の着色部分は秘匿化済みのデータ部分を示している。

本実施の形態のウィンドウサイズは６Ｂｙｔｅなので、残り２Ｂｙｔｅが未だ平文のままである。
この領域を秘匿処理するために、送信側秘匿通信処理部４１２は、３２ｂｉｔ値４３２２を初期ＨＡＳＨ計算部４３２に入力して次の３２ｂｉｔ値４３２３を得る。
この値４３２３と２Ｂｙｔｅ分の秘匿認証処理対象データを送信側秘匿通信処理部４１２がＸＯＲし、その結果値を秘匿済みデータとする。
以上によりウィンドウサイズ分の秘匿処理が完了する。

図９の秘匿認証処理では、ウィンドウサイズ分の秘匿処理を終えた後、秘匿認証範囲７０２全域の秘匿化と認証値計算を行う。
フローチャートは図１２であり、その説明は図１４である。

図１４を用いて説明を行う。
送信側秘匿通信処理部４１２は、ウィンドウサイズ分の秘匿化済みデータをストリームＨＡＳＨ計算部４３１に入力し、その結果を累積加算レジスタ４１２１に加算する。
累積加算レジスタ４１２１の初期値は０である。
その後、ウィンドウの次の位置から８Ｂｙｔｅ分の送信データと、累積加算レジスタ４１２１の累積加算値とで送信側秘匿通信処理部４１２がＸＯＲ計算を行い、得られた結果を秘匿化データとする。

引き続き、送信側秘匿通信処理部４１２は、１Ｂｙｔｅ分スライディングし、前記同様にウィンドウサイズ分の秘匿化済みデータをストリームＨＡＳＨ計算部４３１に入力し、その結果を累積加算レジスタ４１２１に加算する。
その後、ウィンドウの次のデータから８Ｂｙｔｅ分の送信データと、累積加算レジスタ４１２１の累積加算値とで送信側秘匿通信処理部４１２がＸＯＲ計算を行い、得られた結果を秘匿化データとする。
注意として、ＸＯＲ計算対象である８Ｂｙｔｅ分の送信データのうち７Ｂｙｔｅは、スライディングする前にＸＯＲ計算を実施済みの領域である。重複してＸＯＲを行うことで、ビット系列の攪拌性が向上すると期待できる。

以降、送信側秘匿通信処理部４１２は、秘匿認証範囲７０２の終端から１Ｂｙｔｅ手前まで同様の処理を行い、範囲７０２の全域を秘匿化する。
その後、最後の１ＢｙｔｅについてＨＡＳＨ計算とＨＡＳＨ値の累積加算を行う。
この、累積加算レジスタ４１２１の最後の値を送信側秘匿通信処理部４１２が認証値７１２として送信データに付加する。
なお、データ秘匿化処理（ＸＯＲ）がＨＡＳＨ演算に先行するため、秘匿認証範囲７０２の終端に近づくと７Ｂｙｔｅの範囲でＸＯＲ計算を行い、更に１Ｂｙｔｅスライドさせて６Ｂｙｔｅの範囲でＸＯＲ計算を行うというように、１Ｂｙｔｅスライドさせる度にＸＯＲの対象となるデータ量が１Ｂｙｔｅずつ減少していく。

以上で送信側秘匿通信処理部４１２の処理を終了する。
送信側秘匿通信処理部４１２の処理において、秘匿処理と認証処理が同時に行われることがわかる。
つまり、本実施の形態では、ストリームＨＡＳＨ計算部４３１は、秘匿認証範囲（改ざん検知対象データ）の前方から順に、ウィンドウサイズ（演算対象データ長）分のデータのＨＡＳＨ演算を行ってＨＡＳＨ値を算出するとともに、送信側秘匿通信処理部４１２による秘匿化処理が行われる度に、所定のスライド量（スライド量＜ウィンドウサイズ）分ウィンドウの対象範囲を後方にスライドさせスライド後のウィンドウサイズ分のデータのＨＡＳＨ演算を行ってＨＡＳＨ値を算出する。また、演算値累積加算部４３０は、ストリームＨＡＳＨ計算部４３１によりＨＡＳＨ値が新たに算出される度に、新たに算出されたＨＡＳＨと、それまでに算出されているＨＡＳＨの累積加算値とを累積加算して新たな累積加算値を算出し、送信側秘匿通信処理部４１２は、演算値累積加算部４３０により新たに累積加算値が算出される度に、新たに算出された累積加算値を用いて秘匿認証範囲の秘匿化処理を行う。
このようにして、本実施の形態では、データ完全性認証処理（ＨＡＳＨ値の累積加算）とデータ秘匿化処理を並行して行っている。

次に受信側秘匿通信処理部４２２の処理について述べる。
図１５は受信データの一例であり、本図の受信データ８００を例に復号側の処理を述べる。
注意として、受信側秘匿通信処理部４２２は、認証値と同じサイズのデータを、｛ウィンドウサイズ＋認証値のサイズ｝で計算されるエントリだけ格納可能なＦＩＦＯ（Ｆｉｒｓｔ Ｉｎ Ｆｉｒｓｔ Ｏｕｔ）（ＦＩＦＯ蓄積部）を有する。
本例ではウィンドウサイズは６Ｂｙｔｅ、認証値のサイズは８Ｂｙｔｅなので、８Ｂｙｔｅ×１４エントリ格納可能なＦＩＦＯを有するものとする。

受信側秘匿通信処理部４２２のフローチャートを図１６、図１７、図１８、図１９に示す。
また、これらフローチャートに従い、受信側秘匿通信処理部４２２が受信データ８００を復号しながら認証値の判定も併せて行う動作を図２０、図２１、図２２、図２３、図２４に示す。

復号処理の開始直後の動作を図２０に示す。
処理の全体を示すフローチャートである図１６のうち、初期位置復号処理、及び復号処理は直ちに終了する。
その理由は、スライディング処理が｛ウィンドウサイズ＋認証値のサイズ｝で計算されるＢｙｔｅ長まで処理を終えなければ、フラグ条件が成立しないためである。
スライディング処理は、未だ秘匿化が為されたままのデータの上を、ウィンドウをスライドしながら順次ＨＡＳＨを計算して累積加算レジスタを更新する処理である。

スライディング処理は、受信側秘匿通信処理部４２２による復号処理の開始に先立ち、図２０に示すように、ストリームＨＡＳＨ計算部４３１が、秘匿化処理が行われている秘匿認証範囲の先頭から順に、ウィンドウサイズ分のデータのＨＡＳＨ演算を行ってＨＡＳＨ値を算出するとともに、スライド量（１Ｂｙｔｅ）分ウィンドウの対象範囲を後方にスライドさせスライド後のウィンドウサイズ分のデータのＨＡＳＨ演算を行ってＨＡＳＨ値を算出し、演算値累積加算部４３０は、ストリームＨＡＳＨ計算部４３１により算出されたＨＡＳＨ値をＨＡＳＨ演算の順序に従って累積加算する。
ストリームＨＡＳＨ計算部４３１は、６４ｂｉｔのＨＡＳＨ値を順次１４個算出し、演算値累積加算部４３０は、１４個のＨＡＳＨ値を順次累積加算して、１４個の累積加算値を算出し、１４個の６４ｂｉｔ累積加算値を６４ｂｉｔ×１４段ＦＩＦＯ４２２２に出力し、６４ｂｉｔ×１４段ＦＩＦＯ４２２２が１４個の６４ｂｉｔ累積加算値を蓄積する。
なお、図２０〜図２４において、秘匿認証範囲の着色部分は秘匿化済み（未復号）のデータ部分を示している。

スライディング処理が｛ウィンドウサイズ＋認証値のサイズ｝を超えると、初期位置復号処理と復号処理が開始される。

図２１は初期位置復号処理の動作を示す図である。またフローチャートは図１７である。
この処理は、送信側の初期位置秘匿処理に対応する処理であり、秘匿化されている受信データに送信側と同じ操作を行うことで復号する。
この処理は、スライディング処理におけるストリームＨＡＳＨのスライディングウィンドウの左端が、秘匿認証範囲の開始位置から｛ウィンドウサイズ＋認証値のサイズ｝Ｂｙｔｅ進んだ時に一度だけ実行される。

復号処理のフローチャートを図１８に示す。この処理は、初期位置秘匿処理が終了した以降から行われる。この段階でＦＩＦＯエントリはフル状態である。

図２２は、初期位置秘匿処理が終了した後、図１６のループにおいて復号処理とスライディング処理が行われている場合の処理動作を図示したものである。
この動作は、スライディング処理におけるストリームＨＡＳＨのスライディングウィンドウの右端が、秘匿認証範囲の右端に到達するまで為される。

図２２では、まず復号処理が為され、次いでスライディング処理が為される。
初めて復号処理が為された時、初期位置秘匿処理の終了直後であり、復号の開始位置は秘匿認証範囲の開始位置からスライディングウィンドウサイズだけ進んだ位置である。
受信側秘匿通信処理部４２２は、ＦＩＦＯ４２２２からエントリを１つ取り出し、該位置から認証値と同じＢｙｔｅ長の受信データとＸＯＲ演算を行う。
本例では８ＢｙｔｅのＸＯＲ演算が為される。
この際、復号されるのは、左側の１Ｂｙｔｅ分であり、残り７Ｂｙｔｅ及びその他の秘匿認証範囲の全域は以降の処理により１Ｂｙｔｅずつ順次復号される。
一方、復号処理が終わると、スライディング処理が行われ、ストリームＨＡＳＨ計算部４３１によりＨＡＳＨ値が算出され、更に累積加算レジスタ４２２１がＨＡＳＨ値の累積加算を行い、累積加算値が、新たなエントリとしてＦＩＦＯ４２２２へ格納される。

図２３は、スライディング処理におけるストリームＨＡＳＨのスライディングウィンドウの右端が、秘匿認証範囲の右端に到達した際の図である。
受信データ８００が、秘密情報を共有する送信者が送信した時のまま、通信路上で改ざんされていないならば、このとき得られるＨＡＳＨ値を累積加算レジスタ４２２１に加算することで累積加算レジスタ４２２１の値は認証値８１２と一致するはずである。
受信側秘匿通信処理部４２２は、累積加算レジスタ４２２１の値と認証値８１２とを照合して秘匿認証範囲の改ざん有無を判定する。
もし一致しない場合、受信データは通信路上で欠損あるいは何らかの操作が為されたものであり、廃棄して受信側秘匿通信処理部４２２の処理を終了する。

右端に到達した際の累積加算レジスタ４２２１の値は認証値の判定にのみ用いられ、ＦＩＦＯ４２２２には格納しない。
また、図１８ではＳｆｌｇがＯＮとなりスライディング処理が停止する。

図２４は図２３の後、未だ秘匿されている領域を復号する際の図である。
図１８に従い、受信側秘匿通信処理部４２２は、ＦＩＦＯ４２２２からデータを抜き出し、秘匿化が為されているデータとＸＯＲ処理を行う。
１Ｂｙｔｅずつずらしながらこの処理を行い全ての領域を復号する。
処理対象のデータが８Ｂｙｔｅに満たない場合、送信側の処理との対応からＦＩＦＯエントリの右端側を用いてＸＯＲ処理を行う。

以上により、受信側の認証値判定と復号処理を終了する。
受信側においても、送信側と同様に復号処理と認証処理が同時に行われることがわかる。

つまり、本実施の形態では、受信側秘匿通信処理部４２２は、ＦＩＦＯ４２２２から累積加算値を順に取得し、取得した累積加算値を用いて、秘匿化処理が行われている秘匿認証範囲の前方から順に８Ｂｙｔｅ（復号対象データ長）分のデータの復号処理を行い、ストリームＨＡＳＨ計算部４３１は、受信側秘匿通信処理部４２２により８Ｂｙｔｅ分のデータの復号処理が行われる度に、秘匿認証範囲の前方から順に、所定のスライド量（スライド量＜ウィンドウサイズ）分ウィンドウの対象範囲を後方にスライドさせながら、ウィンドウサイズ（演算対象データ長）分の復号されていないデータのＨＡＳＨ演算を行ってＨＡＳＨ値を算出し、演算値累積加算部４３０は、ストリームＨＡＳＨ計算部４３１によりＨＡＳＨ値が新たに算出される度に、新たに算出されたＨＡＳＨ値と、それまでに算出されているＨＡＳＨ値の累積加算値とを累積加算して新たな累積加算値を算出し、算出した新たな累積加算値をＦＩＦＯ４２２２に出力する。
このようにして、本実施の形態では、データ完全性認証処理（ＨＡＳＨ値の累積加算）とデータ復号処理を並行して行っている。

次に秘匿強度を考える。
注意として、ウィンドウサイズと鍵によりＨＡＳＨ関数が構成される。
いま、ウィンドウサイズを既知の固定長とし、鍵によってのみＨＡＳＨ関数が変化すると仮定する。また、解読に用いる計算機の演算能力は約５６２００ＭＩＰＳ程度と仮定する。この演算能力は現時点で現実的に入手可能な計算機のうち、演算能力の高い計算機の演算能力と同等である。非現実的な演算能力ではなく現実的な演算能力を想定することで、実際に攻撃を受けた場合を想定して強度の検証を行うことが可能となる。

ＨＡＳＨ関数自体の計算量は１Ｂｙｔｅあたり｛ＸＯＲ２回、シフト２回、ＯＲ１回｝である。また、鍵によりＨＡＳＨ関数の出力値が変わるため、全数探索を行うためには、鍵を変えながらＨＡＳＨ関数のコリジョンを探索する必要がある。

まず、鍵が定まりＨＡＳＨ関数が定まっている場合、コリジョンを計算するためには、いわゆる誕生日攻撃により、２＾（６４／２）通りを計算すれば、コリジョンを起こすデータを５０％の確立で特定できる。
すなわち、鍵を固定した場合、平文の冒頭の候補を見つけるまで凡そ０．３８２（秒）である。
しかし鍵が一致しない場合、スライディング計算を行うと値が異なるため全体を解読できない。
そして鍵が異なればＨＡＳＨ関数の出力値も変化するため、コリジョンを起こすための候補値を再計算し直す必要がある。

ゆえに、１つの鍵に対して０．３８２（秒）必要で、鍵の試行に２＾６４回必要である。ただし、非特許文献３、非特許文献４に述べるＤＥＳ Ｃｈａｌｌｅｎｇｅ ＩＩＩの事例より、探索領域の２０％程度で特定できると仮定する。

以上により、全数探索に掛かる時間は０．３８６×（（２＾（６４））×０．２０）（秒）＝１．１１７×１０＾（１０）（年）となるため、全数探索が非常に困難であるとわかる。

ここで、全数探索で鍵を特定する確率は、探索領域に対して一様である。
２０％の探索で特定するという仮定は、過去の公式な解読事例のうち高速に解読が為された事例である非特許文献４より設定した値である。

非特許文献３：独立行政法人 情報処理推進機構「暗号の危殆化に関する調査報告書」
非特許文献４：ＲＳＡ（登録商標） Ｌａｂｏｒａｔｏｒｉｅｓ， ＤＥＳ Ｃｈａｌｌｅｎｇｅ ＩＩＩ：ｈｔｔｐ：／／ｗｗｗ．ｒｓａ．ｃｏｍ／ｒｓａｌａｂｓ／ｎｏｄｅ．ａｓｐ？ｉｄ＝２１０８

このように、本実施の形態によれば、高い演算処理能力と計算容量を持たないＬＣＮＡにおいて、ＬＣＮＡの通信で要求される程度の秘匿強度、認証強度が保障できるスクランブル通信を提供することができる。

さらに、ソフトウェア実装であってもデータの秘匿化と認証計算が同時進行するため、高速な秘匿通信を実現することが可能である。
つまり、データ秘匿化処理とデータ完全性認証処理とを並行して実行することができるので、処理時間を低減させることができ、これにより、通信性能が劣化することを回避することができる。

本実施の形態に示したアルゴリズムはデータの秘匿化と完全性認証値計算を行うため、ＩＰｓｅｃの暗号アルゴリズム及びデータ完全性認証アルゴリズムとして用いることが可能である。

ＩＰｓｅｃ自体は秘匿化アルゴリズム、データ完全性認証アルゴリズム共に特に規定しておらず、ただ実装必須アルゴリズム（ＤＥＳ、ＭＤ５、ＳＨＡ−１）を定めているのみである。
しかしながら、ＩＰｓｅｃ自体がＰＣ間通信を想定して設計されたため、実装必須アルゴリズムの計算負荷は高い。
ＩＰｓｅｃはデータの秘匿化、完全性認証のみならず、リプレイ攻撃の防止などセキュリティ上優れた性質を有する。
しかしながらＬＣＮＡにてＩＰｓｅｃを用いると、セキュアな通信を実現できる一方、秘匿化、完全性認証処理が重く通信性能が低下する。

本実施の形態に係るアルゴリズムをＩＰｓｅｃ処理に用いれば、計算量が少ないのみならず、秘匿化と完全性認証計算を一度に行うことが可能なので、秘匿化と認証計算が切り離された従来法よりも高速な処理が可能となる。

秘匿強度は通常のＩＰｓｅｃで利用されるアルゴリズムと比較して脆弱だが、ＬＣＮＡ間の通信に求められる強度としては十分である。

以上、本実施の形態では、機器認証、データ完全性認証、データ秘匿化を行う非ＰＣ系の安価な機器において、
鍵値とウィンドウサイズを特定することで構成可能なストリームＨＡＳＨ計算部と、Ａｄｌｅｒ３２演算論理と、ストリームＨＡＳＨの出力値を累積して加算する加算装置とを含み、加算装置は値０で初期化され、通信路上で改ざんされたことを検出したい領域全体についてＨＡＳＨ計算を行い、ＨＡＳＨ値を累積加算し、その結果の値をデータ完全性認証とすることで改ざんを検出する改ざん検出機能を有する通信方式および通信装置を説明した。

また、本実施の形態では、ストリームＨＡＳＨの鍵値とウィンドウサイズを共有することで、送信側と受信側が同じ計算を行うことが可能となり、これにより機器認証を行う通信方式および通信装置を説明した。

また、本実施の形態では、加算装置の値を用いることで、改ざん検出機能と機器認証を行いながら、送信側であれば秘匿化処理を、受信側であれば復号処理を同時に行うことを可能とし、これにより高速な処理を行うことを可能とする通信方式および通信装置を説明した。

また、本実施の形態に係る通信方式および通信装置の秘匿強度は、全数探索に対して机上計算可能であり、該計算により秘匿強度が十分であるかを検討可能であることを説明した。

また、本実施の形態に係る通信方式はＩＰｓｅｃの暗号アルゴリズム及びデータ完全性認証アルゴリズムとして用いることが可能であることを説明した。

なお、上記では、ウィンドウサイズ（６Ｂｙｔｅ）とＸＯＲ演算の対象範囲（８Ｂｙｔｅ）が異なっている例を説明したが、ウィンドウサイズとＸＯＲ演算の対象範囲が同じＢｙｔｅ数であってもよい。

実施の形態３．
実施の形態２では、図１４の最初の処理が終了した段階で、認証値のサイズまで、即ち本例では８Ｂｙｔｅ先までは秘匿化が行われている。
そのため、図１２の如く１Ｂｙｔｅ毎に秘匿計算を行うことを止め、秘匿化を行った後７Ｂｙｔｅ分のスライディングは出力されるＨＡＳＨ値の加算のみを行い、秘匿化は８Ｂｙｔｅスライディング周期で行うこともまた可能である。
つまり、秘匿化は８Ｂｙｔｅごとにウィンドウをスライドさせ、ＨＡＳＨ値の計算は１Ｂｙｔｅごとにウィンドウをスライドさせ、ＨＡＳＨ値の累積加算は、算出されたすべてのＨＡＳＨ値を順次累積加算する。
これにより計算量を削減することが可能である。
すなわち、重複してＸＯＲ演算を行いビット系列の攪拌性向上を期待することを止めることに相当する。

この実装の場合、復号側のＦＩＦＯはＣＥＩＬ｛（ウィンドウサイズ＋認証値のサイズ）／認証値のサイズ｝分のエントリのみ用意すればよい。
ここでＣＥＩＬ｛数値｝はその数値以上でかつ最も近い整数である。復号側ではＦＩＦＯに保持するエントリ数が少なくなるため、計算量のみならず記憶容量も削減される。

この場合もまた、メッセージとのＸＯＲを取らなければ、実施の形態１と同様に、秘匿化処理を行わず平文に対するデータ完全性機能、相手認証機能を提供する。

実施の形態４．
実施の形態２では、図１４の最初の処理が終了した段階で、認証値のサイズまで、即ち本例では８Ｂｙｔｅ先までは秘匿化が行われている。
そのため、図１２の如く１Ｂｙｔｅ毎に秘匿計算を行うことを止め、スライディングのみ行い、秘匿化を行った後７Ｂｙｔｅ分のスライディングは出力されるＨＡＳＨ値の加算も行わず、秘匿化と累積加算を８Ｂｙｔｅスライディング周期で行うこともまた可能である。
つまり、秘匿化は８Ｂｙｔｅごとにウィンドウをスライドさせ、ＨＡＳＨ値の計算は１Ｂｙｔｅごとにウィンドウをスライドさせ、ＨＡＳＨ値の累積加算は８Ｂｙｔｅごとに行う。

この場合もまた、復号側のＦＩＦＯはＣＥＩＬ｛（ウィンドウサイズ＋認証値のサイズ）／認証値のサイズ｝分のエントリのみ用意すればよい。
ここでＣＥＩＬ｛数値｝はその数値以上でかつ最も近い整数である。復号側ではＦＩＦＯに保持するエントリ数が少なくなるため、計算量のみならず記憶容量も削減される。

この場合もまた、メッセージとのＸＯＲを取らなければ、実施の形態１と同様に、秘匿化処理を行わず平文に対するデータ完全性機能、相手認証機能を提供する。

実施の形態５．
前記の実施の形態４からさらに、秘匿化を行った後７Ｂｙｔｅ分はスライディングも行わず、スライディングウィンドウを８ＢｙｔｅステップでＨＡＳＨ値の計算、秘匿化及び累積加算を行うことで、計算量を大幅に削減することもまた可能である。
つまり、秘匿化、ＨＡＳＨ値の計算、ＨＡＳＨ値の累積加算のすべてを８Ｂｙｔｅごとに行う。

上記による計算量の削減では、ＨＡＳＨウィンドウサイズが８Ｂｙｔｅ以上か以下かに注意が必要である。
ウィンドウサイズが８Ｂｙｔｅ以上の場合、上記の処理であっても、メッセージ全域に対してメッセージ完全性が保障できる。

しかしながら８Ｂｙｔｅ以下の場合、ＨＡＳＨスライディングせず８Ｂｙｔｅスキップを行うため、８Ｂｙｔｅ毎に（８−ウィンドウサイズ）分のメッセージ精査抜けが生じる。

この場合、メッセージとのＸＯＲを取らなければ、平文に改ざん可能な余地を残すこととなる。

さらに、メッセージとのＸＯＲにより秘匿化処理が成されているとしても、秘匿化されたデータの完全性が保証できなくなり、第三者により一部のデータが破壊された際にそれを検出できない余地を残す。この場合、受信側ではデータの複号処理を実施してもデータが破壊されており、またそのことはデータの意味的な解釈でしか検出することが出来ない。

ゆえに、この計算量の削減を行う場合、ウィンドウサイズは８Ｂｙｔｅ以上である必要がある。

この場合もまた、メッセージとのＸＯＲを取らなければ、秘匿化処理を行わず平文に対するデータ完全性機能、相手認証機能を提供する。

このように、本実施の形態によれば、Ｒａｂｉｎ Ｆｉｎｇｅｒｐｒｉｎｔｉｎｇに要するＸＯＲ２回、シフト２回、ＯＲ１回と、ＨＡＳＨ値の累積のための加算１回、また秘匿化処理を行う場合、これに要するＸＯＲ演算１回（全て６４ｂｉｔ演算）、を８Ｂｙｔｅ毎に行えばよく、非常に軽量にスクランブル処理を行うことを可能とする。

実施の形態６．
図１６において、Ａｆｌｇの値に従いデータを採用あるいは廃棄する。
Ａｆｌｇは受信データの認証値と受信側で再計算した認証値が一致するかどうかの判定結果を格納したものであり、受信データの認証値と受信側で再計算した認証値が一致した場合は受信データを採用し、そうではない場合は廃棄している。

一致した場合や、一致しない場合の、受信データに対する操作ポリシーを予めメモリ等に格納しておき、そのポリシーにより、各場合の操作を決定することもまた可能である。ポリシーとは各場合に該受信データをどのように扱うかを記述した設定データである。
たとえば、受信データの認証値と受信側で再計算した認証値が一致しない場合に、改ざん状況の解析のためのデータベースに受信データを登録する等の操作ポリシーを設定することが考えられる。
また、操作ポリシーを送信元別に定めることもまた可能である。
たとえば、送信元Ａからの受信データは、認証値が一致しない場合に破棄し、送信元Ｂからの受信データは、認証値が一致しない場合は改ざん状況の解析のためのデータベースに登録する等の操作ポリシーを設定することが考えられる。

なお、実施の形態１〜６の説明では、非ＰＣのＬＣＮＡを対象とする例を説明したが、対象はＬＣＮＡに限らない。例えば、秘匿強度、認証強度等の条件が合致する環境であれば、ＰＣに実施の形態１〜６で説明した方式を適用してもよい。
実施の形態１〜６で説明した方式をＰＣに適用する場合は、ＣＰＵがＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、磁気ディスク装置等に格納されているデータを用いながら、設備機器制御部２、通信制御部３、送信側秘匿処理制御部４１、受信側秘匿処理制御部４２、ＨＡＳＨ計算部４３、ＨＡＳＨ計算管理部４１１、送信側秘匿通信処理部４１２、ＨＡＳＨ計算管理部４２１、受信側秘匿通信処理部４２２、演算値累積加算部４３０、ストリームＨＡＳＨ計算部４３１、初期ＨＡＳＨ計算部４３２の各機能を実現するプログラムを実行して、実施の形態１〜６で示したデータ秘匿化処理及びデータ完全性認証処理を行うことになる。

１ 制御装置、２ 設備機器制御部、３ 通信制御部、４ データ完全性確保手段、４１ 送信側秘匿処理制御部、４２ 受信側秘匿処理制御部、４３ ＨＡＳＨ計算部、４１１ ＨＡＳＨ計算管理部、４１２ 送信側秘匿通信処理部、４２１ ＨＡＳＨ計算管理部、４２２ 受信側秘匿通信処理部、４３０ 演算値累積加算部、４３１ ストリームＨＡＳＨ計算部、４３２ 初期ＨＡＳＨ計算部。

Claims (20)

1. データの改ざん検知に用いられる認証値を生成するデータ処理装置であって、
   改ざん検知の対象となる改ざん検知対象データの一方向演算を所定の演算対象データ長ごとに行って、演算対象データ長ごとの一方向演算値を複数算出する一方向演算部と、
   前記一方向演算部により算出された複数の一方向演算値のうちの２以上の一方向演算値を一方向演算の順序に従って累積加算する演算値累積加算部と、
   前記演算値累積加算部により累積加算された累積加算値を前記改ざん検知対象データの認証値とする認証値指定部とを有することを特徴とするデータ処理装置。
2. 前記一方向演算部は、
   前記改ざん検知対象データの前方から順に、演算対象データ長分のデータの一方向演算を行って一方向演算値を算出するとともに、所定のスライド量（スライド量＜演算対象データ長）分演算対象データ長の対象範囲を後方にスライドさせスライド後の演算対象データ長分のデータの一方向演算を行って一方向演算値を算出することを特徴とする請求項１に記載のデータ処理装置。
3. 前記演算値累積加算部は、
   前記一方向演算部により算出された複数の一方向演算値の全てを一方向演算の順序に従って累積加算し、
   前記認証値指定部は、
   前記演算値累積加算部により全ての一方向演算値が累積加算された後の累積加算値を前記改ざん検知対象データの認証値とすることを特徴とする請求項１又は２に記載のデータ処理装置。
4. 前記データ処理装置は、更に、
   前記一方向演算部による一方向演算値の算出と前記演算値累積加算部による一方向演算値の累積加算と並行して前記改ざん検知対象データの秘匿化処理を行う秘匿化処理部を有することを特徴とする請求項１〜３のいずれかに記載のデータ処理装置。
5. 前記演算値累積加算部は、
   前記一方向演算部により一方向演算値が新たに算出される度に、新たに算出された一方向演算値と、それまでに算出されている一方向演算値の累積加算値とを累積加算して新たな累積加算値を算出し、
   前記秘匿化処理部は、
   前記演算値累積加算部により新たに累積加算値が算出される度に、新たに算出された累積加算値を用いて前記改ざん検知対象データの秘匿化処理を行うことを特徴とする請求項４に記載のデータ処理装置。
6. 前記一方向演算部は、
   前記改ざん検知対象データの前方から順に、演算対象データ長分のデータの一方向演算を行って一方向演算値を算出するとともに、前記秘匿化処理部による秘匿化処理が行われる度に、所定のスライド量（スライド量＜演算対象データ長）分演算対象データ長の対象範囲を後方にスライドさせスライド後の演算対象データ長分のデータの一方向演算を行って一方向演算値を算出することを特徴とする請求項５に記載のデータ処理装置。
7. 前記演算値累積加算部は、
   一方向演算の順序に基づいて、前記一方向演算部により算出された複数の一方向演算値の中から２以上の一方向演算値を選択し、選択した一方向演算値を累積加算し、
   前記認証値指定部は、
   前記演算値累積加算部により選択された全ての一方向演算値が累積加算された後の累積加算値を前記改ざん検知対象データの認証値とすることを特徴とする請求項１又は２に記載のデータ処理装置。
8. 前記データ処理装置は、更に、
   前記改ざん検知対象データに前記認証値指定部により指定された認証値を付加し、認証値が付加された改ざん検知対象データを送信先装置に送信するデータ送信部を有することを特徴とする請求項１〜７のいずれかに記載のデータ処理装置。
9. 前記データ処理装置は、
   演算対象データ長と、前記一方向演算部による最初の一方向演算に用いられる鍵値とを前記送信先装置と共有していることを特徴とする請求項８に記載のデータ処理装置。
10. 前記一方向演算部は、
    一方向演算として、ストリームハッシュ演算を行うことを特徴とする請求項１〜９のいずれかに記載のデータ処理装置。
11. 改ざん検知の対象となる改ざん検知対象データと、前記改ざん検知対象データの改ざん検知に用いられる認証値を受信するデータ受信部と、
    前記改ざん検知対象データの一方向演算を所定の演算対象データ長ごとに行って、演算対象データ長ごとの一方向演算値を複数算出する一方向演算部と、
    前記一方向演算部により算出された複数の一方向演算値のうちの２以上の一方向演算値を一方向演算の順序に従って累積加算する演算値累積加算部と、
    前記演算値累積加算部により累積加算された累積加算値と、前記データ受信部により受信された認証値とを照合する照合部とを有することを特徴とするデータ処理装置。
12. 前記一方向演算部は、
    前記改ざん検知対象データの前方から順に、演算対象データ長分のデータの一方向演算を行って一方向演算値を算出するとともに、所定のスライド量（スライド量＜演算対象データ長）分演算対象データ長の対象範囲を後方にスライドさせスライド後の演算対象データ長分のデータの一方向演算を行って一方向演算値を算出することを特徴とする請求項１１に記載のデータ処理装置。
13. 前記演算値累積加算部は、
    前記一方向演算部により算出された複数の一方向演算値の全てを一方向演算の順序に従って累積加算し、
    前記照合部は、
    前記演算値累積加算部により全ての一方向演算値が累積加算された後の累積加算値と、前記データ受信部により受信された認証値とを照合することを特徴とする請求項１１又は１２に記載のデータ処理装置。
14. 前記データ受信部は、
    秘匿化処理が行われている改ざん検知対象データを受信し、
    前記データ処理装置は、更に、
    前記一方向演算部による一方向演算値の算出と前記演算値累積加算部による一方向演算値の累積加算と並行して秘匿化処理が行われている改ざん検知対象データの復号処理を行う復号処理部を有することを特徴とする請求項１１〜１３のいずれかに記載のデータ処理装置。
15. 前記データ処理装置は、更に、
    前記演算値累積加算部により算出された累積加算値をＦＩＦＯ（Ｆｉｒｓｔ Ｉｎ Ｆｉｒｓｔ Ｏｕｔ）方式により蓄積するＦＩＦＯ蓄積部を有し、
    前記復号処理部は、
    前記ＦＩＦＯ蓄積部から累積加算値を順に取得し、取得した累積加算値を用いて、秘匿化処理が行われている改ざん検知対象データの前方から順に所定の復号対象データ長分のデータの復号処理を行い、
    前記一方向演算部は、
    前記復号処理部により復号対象データ長分のデータの復号処理が行われる度に、前記改ざん検知対象データの前方から順に、演算対象データ長分の復号されていないデータの一方向演算を行って一方向演算値を算出し、
    前記演算値累積加算部は、
    前記一方向演算部により一方向演算値が新たに算出される度に、新たに算出された一方向演算値と、それまでに算出されている一方向演算値の累積加算値とを累積加算して新たな累積加算値を算出し、算出した新たな累積加算値を前記ＦＩＦＯ蓄積部に出力することを特徴とする請求項１４に記載のデータ処理装置。
16. 前記一方向演算部は、
    前記改ざん検知対象データの前方から順に、演算対象データ長分のデータの一方向演算を行って一方向演算値を算出するとともに、前記復号処理部による復号処理が行われる度に、所定のスライド量（スライド量＜演算対象データ長）分演算対象データ長の対象範囲を後方にスライドさせスライド後の演算対象データ長分のデータの一方向演算を行って一方向演算値を算出することを特徴とする請求項１５に記載のデータ処理装置。
17. 前記ＦＩＦＯ蓄積部は、
    複数の蓄積段数を有し、前記複数の蓄積段数分の累積加算値を蓄積可能であり、
    前記一方向演算部は、
    前記復号処理部による復号処理の開始に先立ち、秘匿化処理が行われている改ざん検知対象データの先頭から順に、演算対象データ長分のデータの一方向演算を行って一方向演算値を算出するとともに、前記スライド量分演算対象データ長の対象範囲を後方にスライドさせスライド後の演算対象データ長分のデータの一方向演算を行って一方向演算値を算出し、前記ＦＩＦＯ蓄積部の蓄積段数分の一方向演算値を算出し、
    前記演算値累積加算部は、
    前記復号処理部による復号処理の開始に先立ち、前記一方向演算部により算出された前記ＦＩＦＯ蓄積部の蓄積段数分の一方向演算値を一方向演算の順序に従って累積加算し、前記ＦＩＦＯ蓄積部の蓄積段数分の累積加算値を算出し、算出した累積加算値を前記ＦＩＦＯ蓄積部に出力し、
    前記復号処理部は、
    前記ＦＩＦＯ蓄積部に蓄積段数分の累積加算値が蓄積された後に、復号処理を開始することを特徴とする請求項１６に記載のデータ処理装置。
18. 前記一方向演算部は、
    ｎバイト（ｎは２以上の整数）の演算対象データ長分のデータの一方向演算を行ってｍバイト（ｍは２以上の整数）の一方向演算値を算出し、
    前記ＦＩＦＯ蓄積部は、
    前記複数の蓄積段数として、ｎ×ｍ段の蓄積段数を有することを特徴とする請求項１７に記載のデータ処理装置。
19. 前記データ処理装置は、
    演算対象データ長と、前記一方向演算部による最初の一方向演算に用いられる鍵値とを前記改ざん検知対象データの送信元の装置と共有していることを特徴とする請求項１１〜１８のいずれかに記載のデータ処理装置。
20. 前記一方向演算部は、
    一方向演算として、ストリームハッシュ演算を行うことを特徴とする請求項１１〜１９のいずれかに記載のデータ処理装置。