以下に添付図面を参照して、この発明にかかる情報処理装置、プログラム開発システム、プログラム検証方法及びプログラムの最良な実施の形態を詳細に説明する。
[第1の実施の形態]
(1)構成
まず、本実施の形態にかかるセキュリティプロトコルに従ったプログラムモジュールが実行される、ターゲットシステム101の仕様について説明する。図1は、ターゲットシステム101のソフトウェア構成を示す図である。ターゲットシステム101は、ネットワーク102を介して外部装置103と接続されており、プログラムの集合体であるプログラムモジュール201と、OS301とを備えている。プログラムモジュール201は、命令実行部212と、データ格納用メモリ領域211とを有する。
データ格納用メモリ領域211は、非保護メモリ領域214と、保護メモリ領域215とを有している。非保護メモリ領域214は、アクセスに対して何等制限を設けていない非セキュアな記憶領域である。一方、保護メモリ領域215は、特定のプログラムやプロセス等からのアクセスに対してアクセス制限を設けたセキュアな記憶領域である。なお、非保護メモリ領域214と保護メモリ領域215とは、同一の記憶媒体に形成されている態様としてもよいし、個別の記憶媒体で形成される態様としてもよい。また、このような特定のプログラムやプロセスに対する排他的なアクセス制御の実現は、公知の技術を用いることが可能である。
命令実行部212は、プログラムの実行主体となるCPU(Central Processing Unit)等の制御部であって、プログラム実行時に一時的にデータを格納するためのレジスタ213を有している。命令実行部212は、データの入出力をデータ格納用メモリ領域211のうち非保護メモリ領域214へのデータ読み書きを通じて行う。尚、プログラムモジュール201に入力されるデータについての書き込みとプログラムモジュール201から出力されるデータの読み出しを行うのはOS301である。しかし、非保護メモリ領域214へのアクセスは必ずしもOS301に限定せず、OS301管理下の周辺装置によるDMA(Direct Memory Access)転送等によるものも含まれる。
OS301は、ターゲットシステム101の基本ソフトウェアの実行主体となるCPU等の制御部であって、非保護メモリ領域214にアクセスを行い、入力データ(例えば、外部装置103からネットワーク102を通じて入力されたデータ)の書き込みと、出力データ(例えば、ネットワーク102を通じ外部装置103に出力するデータ)の読み出しを行う。このOS301は、データ格納用メモリ領域211のうち、非保護メモリ領域214には任意のタイミング読み書きが可能であるが、保護メモリ領域215に対してはアクセスが制限され読み書きが禁止されるものとする。このような特定のプログラムあるいはプロセスに対してアクセスを制限する排他的アクセス機構は例えば特許文献1や非特許文献2などで知られている。
注意すべきことは、プログラムモジュール201にとってOS301は、入力データや出力データや非保護メモリ領域214に記憶されたデータに対する盗聴や改ざん(以下これらを総称して攻撃と呼ぶ)を行う可能性があることが本実施の形態における前提である。プログラムモジュール201がネットワーク102を介して外部装置103と通信を行うとき、OS301と非保護メモリ領域214とは盗聴やメッセージの改ざんがありうるという点で、ネットワーク102の延長と考えることができる。このようなシステムにおいて、プログラムモジュール201が行うデータ処理の安全性を確保するには、2種類のメモリ(非保護メモリ領域214及び保護メモリ領域215)へデータを適切に振り分けることが重要である。図1においては、OS301による盗聴や改ざんが禁止された範囲は命令実行部212と保護メモリ領域215とを含む範囲H1である。
尚、本実施の形態では、プログラムモジュール201は命令の実行については安全であることを仮定する。これは命令及び関数呼び出しや復帰アドレス等が記憶されるメモリ領域(図示せず)を、特許文献1や非特許文献1などの文献に記載された手法によってOS301による攻撃から保護することで実現可能であるからである。しかし、それ以外の実現手段によりこのメモリ領域を保護するようにしても差し支えなく、ターゲットシステム101の構成は図1に示した形態に限定されるものではない。
また、プログラムモジュール201の命令実行部212と、OS301とを同一の制御部としてもよいし、それぞれの用途に特化した個別の制御部としてもよい。また、非保護メモリ領域214と、保護メモリ領域215とを同一の記憶デバイス内に設けた態様としても良いし、それぞれを個別の記憶デバイスに設けた態様としても良い。
次に、以上のようなターゲットシステム101において動作するプログラムモジュール201を例として、プログラムで用いる関数に対して保護属性を自動で決定する情報処理装置について説明する。まず、当該情報処理装置のハードウェア構成について説明する。本実施の形態の情報処理装置は、装置全体を制御するCPU(Central Processing Unit)等の制御装置と、各種データや各種プログラムを記憶するROM(Read Only Memory)やRAM(Random Access Memory)等の記憶装置と、各種データや各種プログラムを記憶するHDD(Hard Disk Drive)やCD(Compact Disk)ドライブ装置等の外部記憶装置と、これらを接続するバスとを備えており、通常のコンピュータを利用したハードウェア構成となっている。また、情報処理装置には、情報を表示する表示装置と、ユーザの指示入力を受け付けるキーボードやマウス等の入力装置と、外部装置の通信を制御する通信I/F(interface)とが有線又は無線により各々接続される。
このようなハードウェア構成において、情報処理装置の有するCPUが記憶装置や外部記憶装置に記憶された各種プログラムを実行することにより実現される各種機能について説明する。図2は、情報処理装置1の機能的構成を例示する図である。情報処理装置1は、変換部50と、更新置換部51と、保護属性決定部52とを有する。これらの更新置換部51と保護属性決定部52とは、CPUのプログラム実行時にRAMなどの記憶装置上に生成されるものである。また、保護属性定義14が情報処理装置1の例えばHDDなどの外部記憶装置に記憶される。
この情報処理装置1には、その関数に対して保護属性を自動で決定する対象のプログラムとしてターゲットプログラム11が入力される。ターゲットプログラム11とは、C言語のなどの人間可読な高級言語で記述されたプログラムである。このターゲットプログラム11で用いられる関数に対しては、関数引数保護属性と、依存関係とが定義されている。関数引数保護属性とは、関数による計算における入力及び出力間の計算量的一方向性と完全性の保証との有無に基づいて定められる保護属性である。依存関係とは、以下の条件を満たす決定項と従属項とのペアで定義される。各ペアは、関数引数のうち決定項に含まれるものの値が固定されたとき、従属項に含まれるもののとりうる値を2種類以上見つけることが困難であるという条件である。これらの保護属性及び依存関係の詳細については後述する。ターゲットプログラム11のプログラムリストには、保護すべきデータが記憶されるメモリ領域を表す変数に付与された保護属性が記述されるとともにセキュリティ関数を用いた処理の実行手順が記述されている。セキュリティ関数の詳細についても後述する。
変換部50は、ターゲットプログラム11のプログラムリストを構文解析してデータフローを生成することにより、ターゲットプログラム11をデータフロー21に変換する。データフロー21とは、プログラムにおいて用いられる各関数と、当該関数に入力される引数や変数と、当該関数による計算の結果出力される引数や変数との繋がりを表すものである。更新置換部51には、変換部50がターゲットプログラム11から変換したデータフロー21と、関数引数保護属性の集合である関数引数保護属性セット12と、依存関係の集合である依存関係セット13とが入力される。更新置換部51は、データフロー21に表される関数のうち、ある関数(関数Aとする)におけるある依存関係の決定項に含まれる変数の完全性が他の関数(関数Bとする)により検証されている関数のペア(A,B)を検出し、関数Bの検証が成功したときに限り関数Aにおける当該依存関係の従属項に含まれる変数に完全性を保証する保護属性を付与して出力する関数(関数Cとする)を、ターゲットプログラム11の機能を変えずに生成してこれを付加することにより、データフロー21を更新する。ターゲットプログラム11の機能とは、即ち、ターゲットプログラム11のプログラムリストにおいて実行手順が記述されている処理の作用である。更に、更新置換部51は、関数Cの付加に伴って関数引数保護属性セット12及び依存関係セット13を更新する。保護属性決定部52は、更新置換部51が更新したデータフロー21、関数引数保護属性セット12及び依存関係セット13を用いて、各変数に対して一意に決定された保護属性を記憶する変数保護属性テーブル及び関数多重定義テーブルを出力する。変数保護属性テーブル及び関数多重定義テーブルについては後述の動作欄で詳細に説明する。
保護属性定義14は、変数及び関数の引数(以下総称して変数という)に対して付与される保護属性を定義されているテーブルであり、例えばHDDなどの外部記憶装置に記憶されている。
ここで、保護属性について詳細に説明する。保護属性には、保護の仕方として大きく分けて、非保護と、機密性(のみ)保護と、完全性(のみ)保護と、機密性及び完全性の両方の保護とがある。図3は、本実施の形態にかかる保護属性の一覧を示す図である。同図に示すように、変数に対して6種類の保護属性が与えられる。各保護属性は、完全性と機密性というセキュリティ要件について、それぞれメモリ領域における保護手段の有無と、意味上の確認の有無という直交する2種類の性質を備えている。
メモリ領域の保護手段については、アクセス制御や暗号化・改ざん検証などの保護手段によって達成される項目が異なる。たとえば実行対象のプログラム以外からのアクセスを完全に禁止するアクセス制御機構をそなえた保護メモリ領域215は、完全性と機密性とも保護あり(表の上で+で表記)となる。ただし、全てのメモリ領域について当該実行対象のプログラム以外からのアクセスが禁止されてしまっている場合、OS301が提供する入出力サービスが一切利用できない。このため、図2に示すように、入力及び出力のために完全性及び機密性の保護機構が実現されない非保護メモリ領域214が設けられている。
尚、機密性の保護がメモリアクセス時のハードウェアによる暗号機構によって行われる場合は、機密性のみが保護されたメモリ領域がありえる。また、完全性の保護についてもそれがハードウェアによるMAC生成・検証機構で行われれば完全性のみが保護されたメモリ領域がありえる。もちろん、両方を組み合わせればアクセス制御と同様に完全性と機密性との両方をそなえた保護機構が実現可能である。本実施の形態にかかる構成においてはこれらの保護手段のどれについても適用可能である。
意味上の確認は、その変数に格納される値について、完全性又は機密性のいずれかまたは両方の確認の有無を表す。例えば、ある変数を格納するメモリ領域に完全性や機密性の保護がなされていたとしても、その変数に非保護メモリ領域214から取得した値が代入されるとすれば、その変数に格納される値そのものは、プログラムの実行中のいずれかの時点で改ざんや盗聴がなされているおそれがあり、たとえ保護メモリ領域215に割り当てられた変数であってもその値を、完全性や機密性が保証されたものとすることはできない。代入元の値自体は完全性が保証されたものであったとしても、代入先の変数Xが記憶されるメモリ領域に完全性の保護機構がなければ、変数Xを再度参照したとき、その値が別の値に書き換えられてしまっている可能性があり、当然完全性が保証されたものとして扱うことはできないからである。ある変数の値について完全性や機密性が保証されるには、適切な保護メモリ領域への割り当てと意味上の確認との両方がなされている必要がある。本実施の形態にかかる保護属性はこのような考えに基づいて設定されている。
以降、完全性が必要な情報が不用意に非保護メモリ領域214に記憶され対象のプログラム外からの書き換えを受けることを「情報が汚染される」と表現する。
次に、保護属性の種別について説明する。「exposed」は、入力変数及び出力変数のために設けられたものである。OSがプログラムに入力を与えるには、プログラムが参照可能なメモリ領域にOSが入力の値を書き込む必要がある。また、プログラムが出力を行うためにはOSが参照可能なメモリ領域にプログラムが出力の値を書き込む必要がある。「exposed」は完全性及び機密性ともに保護されていないメモリ領域に保持される変数なので、OSはこの保護属性が付与された変数を自由に読み書きできる。値を保持するメモリ領域に保護機構がないため、意味上でも値の機密性及び完全性は全く保証されない。仮にそれまで秘匿保護された保護メモリ領域に機密性を持って保持された値があったとしても、いったんそれが「exposed」の保護属性が付与された変数にコピーされた瞬間にその値の機密性は損なわれてしまうからである。なお、以下の説明では機密保護された変数(保護変数という)との違いを明確にするために保護属性「exposed」を明示しているが、既存のプログラムとの互換性を維持し、記述の煩雑さを避けるために保護属性「exposed」を省略しても差し支えない。
「fixed」は、改ざん防止されたメモリ領域に記憶されるが、意味上の完全性や機密性は確認されていない値を保持する変数を意味する保護属性である。保護属性「fixed」が付与された変数は、例外的に保護属性「exposed」が付与された変数と相互に変換が可能である。保護属性「exposed」をもつ複数ワードにまたがるデータ構造を参照するとき、参照途中に改ざん攻撃を受けてしまう可能性がある。特に値の完全性を検証中にこのような攻撃が行われると検証の意味がなくなってしまう。このような危険を排除したい場合、一度それらのデータ構造全体を保護属性「fixed」が付与される変数にコピーしたうえで検証を行うことにより、検証途中のデータの改ざんを防止することができる。
「verified」は改ざん防止されたメモリ領域に記憶される、意味上の値の完全性保証があって機密性のない変数を意味する保護属性である。保護属性「verified」が付与された変数への代入は同一属性の変数の計算結果に限定されるが、保護属性「verified」が付与された変数の値を保護属性「exposed」や保護属性「fixed」の変数に代入することは常に許可される。当該変数を介した出力処理を行わない場合、メモリ領域には秘匿保護がなされていても良い。
「hidden」は機密保護された領域に記憶される、意味上の機密性や完全性が不十分な変数を意味する保護属性である。保護属性「fixed」との違いは、保護属性「hidden」を持つ変数は保護属性「exposed」、保護属性「fixed」との間の代入が禁止される点とこれらとの間で入力及び出力は行わない点にある。保護属性「hidden」の変数は、外部からの入力に用いられることはないため、メモリ領域に改ざん防止機構が付加されていても問題ない。
「concealed」は機密保護された領域に記憶される、意味上の機密性はあるが完全性がない変数を意味する保護属性である。保護属性「concealed」の変数も、保護属性「hidden」と同様に外部からの入力に用いられることはないため、メモリ領域に改ざん防止機構が付加されていても問題ない。
「confidential」は機密保護かつ改ざん保護された領域に記憶される、意味上の機密性及び完全性がともに確認された変数を意味する保護属性である。
次に、保護属性と型とについて説明する。なお、保護属性は言語における変数の型とほぼ同じといって良いが、一般の言語では、型はフィールドの数や長さといったデータ型を意味する場合が多い。以下の例では保護属性の型については厳密な一致を要求するが、データ型については説明を簡単にするため厳密な制約を設けていない。本実施の形態においては、データ型の整合性は副次的なため、セキュリティに関しては保護属性という用語を用いている。本実施の形態の適用においては保護属性をデータ型にまとめた形で実施しても差し支えない。
次に、保護属性が付与された変数間の代入について説明する。図4は、保護属性が付与された変数間の代入の可否を表形式で示す図である。機密性を有する「hidden」、「concealed」、「confidential」の各保護属性が付与された変数は、同じ保護属性が付与された以外の相互変換や代入は一切許されない。完全性についてメモリ保護と意味上の確認との両方を持つ保護属性「verified」が付与された変数は、その値を保護属性「fixed」、「exposed」が付与された変数に代入することは許されるが、これらの変数から保護属性「verified」が付与された変数への代入は許されない。保護属性「fixed」、「exposed」間の代入は自由に行うことができる。
次に、データ型と保護属性の解決とについて説明する。保護属性については上述の変数間の代入時におけるルールが適用される。これはデータ型の変換とは独立して、厳密に守られなければならないルールである。データ型と保護属性とをまとめた実施の形態をとる場合、保護属性に関するルールが必ず守られる必要がある。このルールが特に問題となるのは関数の引数や戻り値が多重定義を持つ場合である。本実施の形態では、データ型と保護属性とを独立して記述し、データ型に関する多重定義の解決と保護属性の多重定義の解決とを独立に行い、データ型の多重定義に依存せず保護属性の多重定義の解決を行う例について説明する。データ型と保護属性とをまとめた形で適用する場合は保護属性の変換に関するルールへの注意が必要である。なお、多重定義の詳細については後述する。
次に、本実施の形態で扱う関数引数保護属性について説明する。関数引数保護属性とは、各関数に対して定められた入力引数及び出力引数の保護属性の制約を定義したものである。以下では、関数をセキュリティ関数と非セキュリティ関数(一般関数)とに分け、それぞれについて関数引数保護属性を説明する。まずセキュリティ関数について説明する。セキュリティ関数とは、暗号化や復号、署名検証といった計算量的一方向性を備えたいわゆるセキュリティプリミティブを実現する関数である。計算量的一方向性とは、順方向の計算は容易に行えるが、逆方向の計算を行うことが困難(現実的な時間ではできない)であるということである。図5−1,5−2は、セキュリティ関数の関数引数保護属性の定義の一覧を示す図である。
セキュリティ関数は、大きく分けて7種類ある。各種類は、公開鍵暗号(暗号化、復号)、共通鍵暗号(暗号化、復号)、署名(生成、検証)、MAC(message authentication code) (生成、検証)、ハッシュ関数、KDF (Key Derivation Function、鍵導出関数)、乱数発生である。KDFとは、データ長が十分長い2つ以上の鍵データを入力変数から生成する場合などに用いられる関数である。セキュリティ関数には、入力変数及び出力変数のそれぞれに対して特定の保護属性が付与されている。なお、関数の出力については、「func(input、 output)」のように引数の形になっている場合と、「output = func(input)」のように関数より返される値として扱われる場合との両方を含む。図5−1において、例えば、公開鍵暗号化関数の関数引数保護属性を見てみると、公開鍵の入力には必ず保護属性「verified」が要求される。これは完全性が確認できない公開鍵で暗号化した暗号文は、攻撃者によって解読される恐れがあるためである。また、入力の平文には、外部から読み取られないように、メモリ上の機密性を有する保護属性である「confidential」または「concealed」が要求され、出力の暗号文には、外部から読み取ることができるように、メモリ上の機密性を有さない保護属性である「verified」、「exposed」がそれぞれ付与されるような多重定義がなされている。多重定義がなされているとは、即ち、複数のエントリーによって関数引数保護属性が定義されているということである。
本実施の形態において保護属性を自動で決定する保護属性決定処理では、複数の引数に対して異なる保護属性が付与されたセキュリティ関数を、暗号化、復号や署名生成、検証のような計算量的一方向性を必ず持つセキュリティプリミティブに限定する。異なる保護属性の混在とは、関数の引数の保護属性が統一されていないことを意味している。即ち、入力として保護属性「confidential」が付与されたメッセージと保護属性「verified」が付与された公開鍵とが与えられ、出力が保護属性「verified」となるような場合である。引数の保護属性が統一されていない関数を自由に定義できるようにすると、例えば、機密保護された変数(保護変数)の計算結果が非保護の変数(非保護変数という)に代入され、この非保護変数から元の保護変数の情報が漏れてしまうような場合が生じてしまう。このような計算を無制限に行わせず、暗号化などの処理に限定することが本実施の形態におけるこの仕組みの目的である。なお、ある関数の引数がすべて同じ保護属性の場合、それはセキュリティ関数ではない。関数が多重定義されていてもそれぞれの多重定義で全ての引数の保護属性が一致していればそれはセキュリティ関数ではなく、計算量的一方向性を持つ必要はない。セキュリティ関数は必ず計算量的一方向性を持つ必要があるが、計算量的一方向性を持つ計算を必ずセキュリティ関数として定義する必要はないことを付記しておく。なお、ハッシュ関数及び KDF については、例えば図5−1,5−2における補助分類のハッシュCや KDF C は全引数の保護属性が同じだが、ハッシュDや KDF D のように、入力と出力との保護属性が異なるものが同時に多重定義されている。従って、これらの関数はセキュリティ関数である。
セキュリティ関数の開発、即ち、関数引数保護属性の定義及び実装には、一般のアプリケーションプログラムの開発より慎重に行われなければならない。図6は、セキュリティ関数とアプリケーションプログラムの開発の作業手順を示す図である。セキュリティ関数は、暗号プリミティブとプログラムとのメモリ管理の両方に精通したセキュリティ専門家である専門プログラマによって開発され、動作の正しさだけでなく、その保護属性についても適切な定義がなされているか否かの十分な注意が必要である。その後、一般のプログラマによりセキュリティ関数セットを利用したセキュリティプロトコルが実装される。アプリケーションプログラムによっては使用する暗号アルゴリズムなどが異なる場合があり、その場合は、専門プログラマによりセキュリティ関数の付加や誤使用を防止するための削除が必要である。
また、セキュリティ関数の関数引数保護属性の定義は、プリミティブに使用するアルゴリズムによって変化する。図5−1,5−2に示すような関数の定義は、標準的に要求される安全性を満たすものを基準として行っている。しかし、例えばRSA署名のような、署名からメッセージが簡単に推定できるような弱い公開鍵署名方式の場合、図5−1,5−2における補助分類の署名検証Cのようなエントリーは削除すべきである。なぜならば、メッセージが保護属性「concealed」が保護されるメモリ領域においてあっても、署名に保護属性「exposed」が付与されているのであれば、この署名からメッセージが復元できてしまうからである。また、特殊な方式によっては、多重定義を付加することも可能になる。
次に、セキュリティ関数のうち、特に、署名検証関数及びMAC検証関数について説明する。図7は、本実施の形態における署名検証の手順を概念的に示す図である。一般に署名検証では検証に成功したか否かの情報だけが出力される。だが、図7では出力の保護属性に対応する変数のメモリ領域が確保され、検証対象の変数から値がコピーされ、コピーされた値について検証に成功した場合のみ、新しく確保された変数が出力される。これは検証前の変数が非保護メモリ領域214に確保されている場合、攻撃者が検証中または検証後すぐに検証前の変数を書き換えることが可能なので、検証対象の値を保護メモリ領域215に予めコピーして書き換えを防止するためである。また、検証後の出力は検証前の入力とは異なる保護属性が付与されているため、検証前の変数を検証後に誤って使用してしまうことが避けられる。検証前の変数と検証後の変数とは同じ値を保持しているので、誤って使用しても機能上プログラムは動作してしまう。ところがそのようなプログラムは上述のような攻撃が可能であるという脆弱性を抱えている。上述の検証方式はこのような誤りを排除する効果がある。なお、MAC検証関数も署名検証関数と同様な考え方で、検証された変数が出力される。また、暗号化関数、復号関数、署名生成関数、MAC生成関数では各々、入力と出力との値が異なるので、検証前の変数を検証後に誤って使用してしまうことを避けるための考慮は不要である。
次に、非セキュリティ関数について説明する。非セキュリティ関数とは、セキュリティ関数のように計算量的一方向性を持たず、入力と出力との保護属性が全て一致する関数である。図8は、本実施の形態における非セキュリティ関数である入力関数及び出力関数の関数引数保護属性を示す図である。OSを介した入力を扱う入力関数「Input」及び出力を扱う出力関数「Output」は非保護変数のみを扱う。このほかOSとデータのやりとりを行ういわゆるサービス関数は全て非保護変数のみを扱う。関数「Input」に入力される変数(入力変数)はOSによる書き込みがあるため入力変数は保護属性「exposed」が付与された変数に限定され、出力も保護属性「exposed」が付与された変数に限定される。また、関数「Output」により出力される変数(出力変数)はOSによる書き込み操作が不要なため、「exposed」、「verified」の両方の各保護属性が多重定義される。このとき、出力の保護属性は入力と同じ保護属性に固定される。また、データ型の変換を行う関数なども非セキュリティ関数である。これらはOSを介したデータの入力及び出力は行わず、全ての入力変数及び出力変数の保護属性が同一であるという条件の下で引数に保護変数を取ることができる。そのための関数は、保護属性「exposed」用、保護属性「verified」用のように、保護属性毎に異なる名前で定義しても良いし、関数の多重定義によりそれぞれの保護属性に対する機能を提供しても良い。更に、計算量的一方向性を持たない四則演算や代入などの計算も、全ての変数の保護属性が共通でなければならない非セキュリティ関数である。例えば、「A = B + C」という計算は、A、B、Cの全ての保護属性が共通である必要がある。
本実施の形態においては、以上のような関数引数保護属性の制限等により、上述した、情報の汚染を防止し、セキュリティ関数のみで安全に保護属性の変換が行われるように構成する。
続いて、本実施の形態で扱う依存関係について説明する。そのための準備として、まず、本実施の形態にかかるセキュリティプロトコルのシーケンスについて図9を用いて説明する。同図では、図1に示す外部装置103で動作するシステムA2101と、図1に示すプログラムモジュール201により実現されるシステムB2201とがハイブリッド暗号を利用したメッセージの転送を行う例が示されている。ここで、システムA2101がOSを含むシステム全体を表すのに対し、本実施の形態にかかる後述の保護属性決定処理が行われる対象となるシステムB2201は、アプリケーションプログラムであるプログラムモジュール(図1の201)に限定されていることに注意されたい。以下の説明ではシステムB2201の実装における安全性に注目した説明を行い、システムA2101の内部の動作についての説明は行わない。
まずセキュリティプロトコルの実行に先立って、システムB2201はシステムA2101の公開鍵(pkA)2215を予め取得しておく。システムB2201はCA発行の証明書により公開鍵(pkA)2215の完全性を別途検証するが、図では省略されている。また、システムB2201を実現させるプログラムモジュール201には、自身に割り当てられた秘密鍵(skB)2211とメッセージ(msg)2218とが静的に予め埋め込まれる。
システムA2101は、メッセージ(msg)2218を転送するための共通鍵(一時鍵)(K)2113を生成し、共通鍵(K)2113のハッシュ値に対して、自身に割り当てられた秘密鍵により署名2112を生成してこれをシステムB2201に送信する(2402)。更にシステムA2101は、システムB2201の公開鍵(pkB)により共通鍵(K)2113を暗号化したデータ2111をシステムB2201に送信する(2401)。システムA2101はCA発行の証明書により公開鍵(pkB)の完全性を別途検証するが、図では省略されている。
一方、システムB2201は、2401でシステムA2101から送信されたデータ2111を受信すると、自身に割り当てられた秘密鍵(skB)2211を用いて公開鍵暗号文復号関数2212により共通鍵(K)を取得する。次に、システムB2201は、得られた共通鍵(K)2213を用いてハッシュ関数2214によりハッシュ値を計算し、完全性を予め確認した公開鍵(pkA)2215と、2402で受信した署名2112とを用いて署名検証関数2216により署名検証を行う。署名検証が成功した場合、共通鍵(K)は、システムB2201自身に割り当てられた秘密鍵(skB)2211による復号及び完全性が確認された公開鍵(pkA)2215による署名検証により機密性及び完全性が裏付けられる。この点については以下で詳しく説明する。このため、メッセージ(msg)2218を共通鍵暗号方式により暗号化するための暗号化鍵として共通鍵(K)2213を用いることができる。そして、システムB2201は、共通鍵(K)2213を用いて共通鍵暗号化関数2217によりメッセージ(msg)2218を暗号化して暗号文を生成し、当該暗号文をシステムA2101に送信する(2403)。システムA2101は、2403でシステムB2201から送信された暗号文を受信すると、共通鍵(K)2213を用いて共通鍵復号関数2114により当該暗号文を復号して、メッセージ(msg)2215を得る。
次に、図9で説明したセキュリティプロトコルのシーケンスにおいて依存関係について説明する。当該セキュリティプロトコルで注目すべき点は、署名検証による共通鍵(K)の完全性の保証である。このセキュリティプロトコルでは、共通鍵(K)2113を署名検証関数2216に直接入力しておらず、共通鍵(K)2113のハッシュ値が署名検証関数2216に入力されている。またシステムA2101が2402でシステムB2201に対して送信するのも、共通鍵(K)2113のハッシュ値に対する署名2112である。よって、署名検証関数2216で直接検証されるのは、共通鍵(K)2113のハッシュ値の完全性である。ここで、ハッシュ関数が衝突困難性を有すると仮定する。衝突困難性とは、同じ出力の値をとる複数の入力の値を見つけることが困難であるという性質である。この衝突困難性は、暗号プリミティブとして利用されるハッシュ関数が有するべき基本的な性質である。このように仮定した場合、共通鍵(K)2113以外でハッシュ値が共通鍵(K)2113のハッシュ値と同じになるような入力の値を見つけることは困難であり、ハッシュ値の出力を変えずに入力である共通鍵(K)2113のみが置き換えられているという危険性が排除される。よって、ハッシュ値の完全性が検証されると、同時にハッシュ関数2214への入力である共通鍵(K)2113の完全性も確認できる。以上のように、このセキュリティプロトコルは共通鍵(K)2113を直接検証することなく、共通鍵(K)2113の完全性を間接的に確認していると解釈できる。
別の言い方をすれば、このセキュリティプロトコルでは、ハッシュ関数によって入力と出力との間に計算量的な一対一関係が生成されている。このため、関係をもつ片方である、ハッシュ関数の出力の完全性が検証されることにより、もう一方である、ハッシュ関数の入力の完全性も検証されている。依存関係とは、関数によって生成されるこのような関係のことである。このような依存関係を考慮することにより、直接検証されている変数だけではなく、間接的に検証されている変数を検出し、その完全性を考慮することが可能となる。このような解釈は、セキュリティの専門家であれば、ハッシュ関数と署名検証関数とを連携させて考えることにより導き出すことは可能であるかもしれないが、セキュリティに詳しくないプログラマにとっては難しい。しかも、このような依存関係を考慮すべき事例が発生するプロトコルは数多く存在し、例えばメールの送受信プロトコルである PGP や S/MIME、あるいは暗号通信に標準的に利用される SSL、TLSでも同様な事例が見て取れる。保護属性と関数引数保護属性だけを用いて保護属性を自動で決定する従来の方法では、このような事例を考慮することはできず、適切な保護属性を付与することができない恐れがある。本実施の形態では、依存関係を考慮すべき事例を取り扱うことができ、セキュリティに詳しくないプログラマでも各変数に適切な保護属性を付与することが可能となる。
ここで、本実施の形態における依存関係について詳細に定義する。上述したように、依存関係とは、関数の入力変数及び出力変数の一方の完全性を検証することにより、他方の完全性が確認されるということを保証するためのものである。この依存関係は、決定項(determinant set)と従属項 (dependent attribute)とにより定義され、これらの項はそれぞれ関数の入力変数及び出力変数の部分集合からなる。また、依存関係の決定項と従属項とは、決定項に含まれる変数の値が全く同じになるような従属項に含まれる変数の値を2種類以上求めることが困難であるという性質を有する。より具体的には、決定項と従属項とは、以下の(a),(b)のいずれかの性質を有している。
(a)決定項の変数の値が決定すると、それに対応する従属項の変数の値が一意に決まる。
(b)決定項の変数の値が決定しても、それに対応する従属項の変数の値は複数存在するが、そのような従属項の変数の値を複数求めることが困難である。
なお、決定項、従属項という用語は、コンピュータの関係データベースにおいて用いられる関数従属性の用語を引用している。関数従属性は、上述の(a)の性質に相当し、決定項の変数値が決定すると、従属項の変数値が一意に決定する。本実施の形態における依存関係は、上述の(a)の性質に加え、(b)の性質が加わっている。これは、計算量的な一対一関係と捉えることができ、ハッシュ関数等における衝突困難性に対応する。前述したハッシュ関数は、出力が決定項、入力が従属項となる依存関係を有することになる。
このように依存関係を定義すると、完全性の間接的な検証を検出することが可能になる。具体的には、依存関係における決定項の変数の値の完全性がある検証関数により検証されると、それに対応する従属項の変数の完全性が間接的に検証されることが保証されるのである。
次に、依存関係がどのように定義されるかについて具体的な例を用いて説明する。例えば、入力ビット列Xをビット反転してYに出力する関数「bitwise_negation(X、Y)」は、入力Xと出力Yとが一対一に対応する関数である。よって、決定項が入力Xのとき従属項が出力Y、あるいは、決定項が出力Yのとき従属項が入力Xという依存関係が定義できる。
次に、AとBとの値を足してCに出力する関数「plus(A、 B、 C)」を考える。このとき、決定項が出力C、従属項が入力Aと入力Bという依存関係は定義できない。なぜなら、出力Cの値が固定されたとしても、入力Aと入力Bとは複数のペアが考えられ、さらにそれら複数のペアは誰でも容易に計算できるからである。例えば、「C=5」であれば、「A=2、B=3」や、「A=1、B=4」が考えられる。よって、仮に出力Cの完全性が確認されたとしても、入力Aと入力Bとの完全性は確認することができない。より具体的に言えば、関数「plus」による計算時に「A = 2、B = 3、C = 5」であったとし、署名検証等により出力Cの完全性が確認できたとしても、実は関数「plus」による計算前に入力が例えば「A = 1、B = 4」等のように改ざんされてしまっているかもしれない。
一方、出力Bの値と入力Cの値とが固定されると、それに対応する入力Aの値は1つしか存在しない。つまり、関数「plus」の場合は、2つの変数から残り1つの変数への依存関係が存在することになる。具体的には、「決定項:入力A,B、従属項:出力C」、「決定項: 入力B,出力C、従属項:入力A」及び「決定項: 出力C,入力A、従属項: 入力B」の3通りが依存関係として定義される。
図10は、図5−1,5−2に示すように定義されたセキュリティ関数の一部である公開鍵暗号文復号関数、共通鍵復号関数、KDF及びMAC検証関数が生成する依存関係の定義を示す図である。公開鍵暗号文復号関数及び共通鍵復号関数では、暗号文と鍵(秘密鍵又は共通鍵)の値とが決まれば、復号結果が一意に定まる。よって、決定項が暗号文と鍵との2変数、従属項が復号結果となる。この依存関係が意味することは、暗号文と鍵との「両方」の完全性が確認できたとき、復号結果の完全性が確認できるということである。この関係は、例えば鍵の完全性が事前に確認済みであり、暗号文の完全性が後になって確認される場合に考慮される。この時は、暗号文の完全性が確認されてはじめて復号結果の完全性が保証されることになる。また。通常の復号関数では鍵の完全性は事前に確認されているが、ハイブリッド暗号のように鍵が通信相手から送信されてくるようなものの場合は、復号の計算の時点では鍵の完全性が確認できていない場合がある。このような場合は、復号後に暗号文及び鍵の完全性を確認し、依存関係よりそこで初めて復号結果の完全性が保証される。
上述の例で扱ったハッシュ関数の場合、入力及び出力は各々1つであるが、出力の値が固定されたとしても、それに対応する入力の値は一意には決まらない。なぜなら、出力の値が同じになる入力の値が複数存在するからである。しかしながら、ハッシュ関数の場合は関数plusとは異なり、上述で衝突困難性について説明した通り、同じ出力の値をとる複数の入力の値を見つけることは攻撃者にとって困難である。よって、ハッシュ関数においても、出力が決定項、入力が従属項となる依存関係を定義することができる。なお、入力が決まれば出力が一意に決まるので、入力が決定項、出力が従属項となる依存関係も存在する。
KDFについては、入力1つに対して出力が2つであるが、入力の値が定まれば出力の値が一意に決まるという点はハッシュ関数と同じである。さらにKDFは、出力の一部だけ、すなわち2つの出力のうち一方を固定したとしても、出力の一部が固定した値になるような入力の値を複数見つけることが困難である。よって、出力の一部を決定項とすると、入力が従属項となる依存関係が定義できる。さらに入力の値が決まれば出力の値が一意に定まることから、結果として、出力の一方が決定項、入力及び他方の出力が従属項という依存関係が定義できる。
図10には、一部のセキュリティ関数に対して依存関係が定義されているが,ここに挙げられていないセキュリティ関数についても、上述した依存関係が有するべき性質(a),(b)をセキュリティの専門家がチェックすることにより、各セキュリティ関数に対して依存関係を定義することができる。また、依存関係が有するべき性質(a),(b)のいずれかを有するとしても、その依存関係が有用でない場合がある。例えば、入力及び出力として常に完全性を有するものしか許可しない関数があった場合、その入力変数及び出力変数の完全性が後になって間接的に検証されることはない。これは完全性がすでに保証されているためである。よって、依存関係が定義できたとしても、保護属性を自動で決定する後述のアルゴリズムの効率化などの観点から、有用でない依存関係をあえて定義しないこともある。
更に、図10には非セキュリティ関数の依存関係の定義を示していないが、それらについても上述の関数「plus」のように一意性を考慮することによって定義することができる。また、関数の形で定義されていなくても、演算子による計算(例えば、「C =A+B」)においても同様に依存関係を考えることが可能である。尚、変数の間に依存関係が生成された後で、それらの変数が改ざんされてしまったとしたら、その依存関係は無効になってしまうのは明らかである。よって、依存関係を生成する場合は、それぞれの入力変数及び出力変数に対して改ざん防止の処理が施された状態で関数の計算が行われなければならないことを付記しておく。
次に、図9に示すセキュリティプロトコルにおけるシステムB2201の行う処理の手順を記述した擬似プログラムについて図11を用いて説明する。同図において、2〜4行目は初期値が与えられた変数宣言を表す。6行目では出力のためのパラメータが与えられている。8〜16行目は作業変数の変数宣言を表す。19〜33行で処理の手順が記述される。具体的には、19行目の関数「Input」でOSを経由して、「buf」で確保された領域に共通鍵(K)を暗号化したデータ「Cipher_From_A」(図9におけるデータ2111)が入力され、そのデータサイズが sizeに記憶される。その後いくつかの処理が行われた後、最後に関数「Output」によりOS経由でデータを出力して、処理が完了する。ここで、2〜4行目の変数には保護属性が付与されているが、それ以外のパラメータ及び変数には保護属性が付与されていない。本実施の形態では、必要に応じてプログラムを書き換えながら、保護属性が付与されていない変数に対して、その保護属性を自動で決定する。また、この擬似プログラムでは、多くの変数に対してフィールドの数や長さといったデータ型を省略しているが、実際はデータ型の定義並びにその一致が必要となる。しかし、上述の通り、保護属性とデータ型とは独立に考えることができる。このため、ここでは保護属性のみに注目して記載している。本実施の形態の適用に関しては、保護属性をデータ型にまとめた形態としても差し支えない。
(2)動作
次に、本実施の形態にかかる情報処理装置1の行う保護属性決定処理の手順について図12を用いて説明する。この保護属性決定処理では、情報処理装置1は、与えられたプログラムの各変数に対して、上述の保護属性の計算ルールや変数の代入ルール、並びにセキュリティ関数及び非セキュリティ関数の関数引数保護属性を有する保護属性を、依存関係を考慮しながら適切に付与する。このため、まず、情報処理装置1は、処理対象のプログラムであるターゲットプログラムが入力されると、当該プログラムにかかる関数引数保護属性セットを取得する(ステップS1)。この関数引数保護属性セットは、当該プログラムで用いられる各関数に対する関数引数保護属性の集合である。次に、情報処理装置1は、プログラムの変数やセキュリティ定数、パラメータ宣言から与えられた初期状態の保護属性を取得する(ステップS2)。そして情報処理装置1は、処理対象のプログラムのプログラムリストを構文解析して、データフローを生成する(ステップS3)。
図13は、図11で示される擬似プログラムのデータフローを例示する図である。図9と略同様であるため、図9と同様の関数及び変数に対しては同一の符号を用いている。尚、システムA2101からの入力(図9の2401〜2402)については、入力関数「Input」2401,2402として各々表している。また、公開鍵暗号文復号関数2212は、関数「SKDecrypt」2212として表し、署名検証関数2216は、関数「PKVerify」2216として表し、共通鍵暗号化関数2217は、関数「CKEncrypt」2217として表している。また、システムB2201からの出力(図9の2403)については、出力関数「Output」2403として表している。そして、非セキュリティ関数である関数「Input」2401,2402へは、図1に示す外部装置103から変数(入力変数)が入力され、関数「Output」2403から外部装置103へ変数(出力変数)が出力される。セキュリティに関連する保護情報は、当該擬似プログラムにより実現されるシステムB2201に割り当てられた秘密鍵(skB)2211、メッセージ(msg)2218及び公開鍵(pkA)2215であり、各々四角のシンボルで表されている。セキュリティ関数のうち、署名検証関数2216は山形のシンボルで表され、公開鍵暗号文復号関数2212及び共通鍵暗号化関数2217は五角形のシンボルで表され、ハッシュ関数2214は三角形のシンボルで表されている。また、データフローの終端となる変数であり以降用いられていない変数は角丸四角形で表されている。
図12の説明に戻る。ステップS3の後、情報処理装置1は、ステップS3で生成したデータフローを用いて、まず、依存関係を考慮せずに保護属性を自動で決定する基本保護属性決定処理を行う(ステップS4)。この基本保護属性決定処理において、保護属性の決定に成功した場合(ステップS5:YES)、情報処理装置1は、処理を終了するが、保護属性の決定に失敗した場合(ステップS5:NO)、本実施の形態にかかる依存関係を考慮した関数拡張つき保護属性決定処理を行う(ステップS6)。この関数拡張つき保護属性決定処理において、保護属性の決定に成功した場合(ステップS7:YES)、情報処理装置1は、処理を正常に終了し、保護属性の決定が失敗した場合(ステップS7:NO)、異常であるとして処理を終了する。関数拡張つき保護属性決定処理の詳細については後述する。
ここで、ステップS4の基本保護属性決定処理について図14を用いて詳細に説明する。この基本保護属性決定処理は、特願2007-303765に記載されているものと略同様であるが、本実施の形態の構成の理解のためにここで説明する。情報処理装置1は、図12のステップS4で生成されたデータフローから、それをセキュリティ関数毎に分割した部分データフローを生成する(ステップS10)。例えば、図13に示す一繋がりのデータフローを、図15の表に示すような12個の部分データフローに情報処理装置1は分割する。図15は、分割された部分データフローを模式的に示す図である。同図においては、各部分データフローにはこれらを各々一意に識別するために部分データフロー番号を付与している。なお、情報処理装置1は、部分データフローに関する図15に示すような情報をテーブル形式で例えばRAMなどの記憶装置やHDDなどの外部記憶装置に記憶するようにしても良い。各部分データフローの各端点は、入力、出力、初期値(非保護又は保護)、セキュリティ関数の引数及び終端変数のうちいずれかになるはずである。ここでの終端変数とは、ある関数から出力された後、どの関数でも用いられないような変数のことである。各部分データフローは、少なくとも2つの端点を構成要素として含むものとなる。図15では、図13に示した変数及び関数(セキュリティ関数、非セキュリティ関数)については、その識別番号を「#符号_変数名」の形式で表している。更に、関数の場合、引数について「#符号_変数名(#引数番号)」として表している。これは各引数の保護属性の違いを明確化するためである。非セキュリティ関数についてもどの変数がプログラムに対する明示的な入力であり、どの変数が出力であるかを明示するために引数番号を用いて表されている。変数レベルでプログラムの入力及び出力を見たとき、単なる入力だけの操作であっても、OSに対して入力バッファのサイズやパラメータなどの暗黙の出力がなければ操作は行えない。引数の明示はこのような区別を行うためのものである。
次に、分割された部分データフローについて具体的に説明する。部分データフロー番号が「1」の部分データフローは、関数「#2401_Input」の第1引数である「buf」の値が「Cipher_From_A」に代入され、関数「#2212_SKDecrypt」の第1引数として入力される。関数「SKDecrypt」はセキュリティ関数なので、部分データフロー番号が「1」の部分データフローはここまで区切られる。また、部分データフロー番号が「2」の部分データフローでは、初期値「#2211_skB」がそのまま関数「#2212_SKDecrypt」の第2引数として代入されており、構成要素が2個の部分データフローとなる。このとき、機密情報である秘密鍵「skB」には初期値として保護属性「confidential」が付与されている。部分データフロー番号が「3」の部分データフローでは、関数「#2212_SKDecrypt」の第3引数が、関数「#2217_CKEncrypt」の第2引数及び関数「#2214_Hash」の第1引数として入力される。部分データフロー番号が「7」の部分データフローでは、関数「#2216_PKVerify」の第4引数と「Cert_SignMsg_A」からなる。「Cert_SignMsg_A」は出力されて以降用いられない終端変数であり、それ以降のデータフローは構築されない。
図14の説明に戻る。ステップS10の後、情報処理装置1は、未決定部分データフローテーブル、変数保護属性テーブル及び関数多重定義テーブルの初期化を行う(ステップS11)。未決定部分データフローテーブルは、保護属性が一意に決定していない部分データフローを記憶するテーブルであり、例えばRAMなどの記憶装置やHDDなどの外部記憶装置に記憶される。初期化では、情報処理装置1は、ステップS10で分割した部分データフローを全て未決定部分データフローテーブルに書き込む。変数保護属性テーブルは、各変数及びパラメータ毎に、保護属性の一意な決定が完了したか否かを示す完了未完了状態と一意に決定された保護属性とを記憶するテーブルであり、例えばRAMなどの記憶装置やHDDなどの外部記憶装置に記憶される。初期化では、情報処理装置1は、図12のステップS2で取得した保護属性の初期値を当該変数の保護属性として書き込み、それ以外の変数の保護属性を未決定とする。関数多重定義テーブルは、図12のステップS1で入力された処理対象のプログラム中において、多重定義がなされた関数の呼び出し毎に、各引数の保護属性の一意な決定が完了したか否かを示す完了未完了状態と、決定された、引数の保護属性とを記憶するテーブルであり、例えばRAMなどの記憶装置やHDDなどの外部記憶装置に記憶される。ここで注意すべきことは、関数多重定義テーブルのエントリーは、多重定義がなされた関数の呼び出し毎に繰り返し生成されることである。例えば、プログラム中に公開鍵暗号化関数が2つ存在する場合は、エントリーが2つ生成され、各エントリーは独立に扱われる。初期化では、情報処理装置1は、各セキュリティ関数と、入力関数及び出力関数を除く非セキュリティ関数とについて関数多重定義テーブルに記憶する。セキュリティ関数の引数の保護属性は、引数毎に異なるが、非セキュリティ関数では全て同一の保護属性である。セキュリティ関数の引数には鍵の値のように保護属性が予め決定されているものとそうでないものとがある。入力関数の保護属性は必ず「exposed」であり、出力関数の保護属性は「exposed」、「fixed」又は「verified」に限定される。
次いで、情報処理装置1は、未決定部分データフローテーブルから、次に検査対象とする部分データフローを1つ選択する(ステップS12)。続いて、情報処理装置1は、部分データフローに含まれる構成要素の保護属性に基づいた一致判定が可能か否かを判定する(ステップS13)。一致判定が可能か否かとは、部分データフローにおいて、保護属性が既に一意に決定されている変数、引数及びパラメータが1つでも存在するかということである。たとえば図15に示す部分データフロー番号「1」の部分データフローは、セキュリティ関数「SKDecrypt」の仮引数「#2212_SKDecrypt(#1)」は多重定義を有するので保護属性は一意には決まらない。だが、関数「Input」の第1引数「#2401_Input(#1)」は保護属性が「exposed」に限定されるため、上述の変数の保護属性「exposed」との一致を調べることで当該部分データフロー内の保護属性が一致しているか否かの判定が可能となる。逆に、多重定義がなされた関数のみで構成されるような部分データフローでは上述のような一致判定はできない。例えば、図15に示す部分データフロー番号「10」のデータフローでは、関数「CKEncrypt」の第3引数「#2217_CKEncrypt(#3)」及び関数「Output」の第1引数「#2403_Output(#1)」が共に保護属性「verified」又は「exposed」をとるため、この段階では一致判定を行うことができない。このような場合は、他の部分データフローの保護属性を先に決定することにより、当該部分データフローの保護属性が決定可能になることがある。
一致判定が可能な場合(ステップS13:YES)、情報処理装置1は、一致判定を行う(ステップS14)。具体的には、情報処理装置1は、まず、部分データフローの構成要素のうち、一意決定済みの構成要素についてその保護属性が全て一致するか否かを判定する(ステップS14)。一意決定済みの構成要素とは、保護属性が明示的に付与された変数か、別の部分データフローの解析における関数の多重定義の解決により、保護属性が決定された仮引数を意味する。さらに、一意決定済みの構成要素の保護属性が全て一致し、部分データフロー中に保護属性が未決定の、多重定義がなされた関数の引数が存在する場合は、情報処理装置1は、一意決定済みの保護属性が、保護属性が未決定の多重定義関数の引数の保護属性の候補と一致可能か否かを判定する。一意決定済みの構成要素についてその保護属性が全て一致する場合、又は、一意決定済みの保護属性が、一意決定済みの構成要素についてその保護属性が全て一致し且つ保護属性が未決定の、多重定義がなされた関数の引数の保護属性の候補と一致可能である場合、ステップS15に進む。このようにして部分データフローの全ての構成要素について一意決定され、かつ一致した保護属性を当該部分データフローの確定保護属性と呼ぶ。
一意決定済みの構成要素についていずれか1つでも保護属性の不一致があった場合(ステップS14:NO)、検査は失敗となる。この結果、図12では、ステップS5の判定結果が否定的となり、情報処理装置1は、後述の関数拡張つき保護属性決定処理を行うことになる。一方、ステップS15では、情報処理装置1は、当該部分データフローを未決定データフローテーブルから削除する。次に、情報処理装置1は、当該部分データフローに含まれる未決定の多重定義関数の引数について、関数多重定義テーブルの対応フィールドに、確定した保護属性(確定保護属性という)を登録する。さらに、1つの引数の保護属性が一意に決定されたことで、その関数の多重定義に基づいて別の引数の保護属性が派生的に一意に決定される場合(これは部分データフローの確定保護属性とは必ずしも一致しない)には、その引数の対応フィールドに、派生的に一意に決定された保護属性を情報処理装置1は登録する。例えば、図15に示す部分データフロー番号「1」の部分データフローの場合、確定保護属性の登録として、関数多重定義テーブルの関数「SKDecrypt」の第1引数「#2212_SKDecrypt(#1)」に対応するフィールドに保護属性「exposed」を情報処理装置1は書き込む。また、関数「SKDecrypt」の多重定義から、第3引数の保護属性が「concealed」に一意に決定され、情報処理装置1はこれを「#2212_SKDecrypt(#3)」に対応するフィールドに書き込む。この引数の保護属性が一意決定済みとなる。
その後、情報処理装置1は、未決定部分データフローテーブルに保護属性が未決定の部分データフローが存在するか否かを判定する(ステップS16)。保護属性が未決定の部分データフローが存在しない場合(ステップS16:NO)、保護属性の決定は成功となり、情報処理装置1は、決定済みの変数保護属性テーブル及び関数多重定義テーブルを出力して(ステップS17)、処理を終了する。この場合、図12では、ステップS5の判定結果が肯定的となり、情報処理装置1は処理を正常に終了する。一方、保護属性が未決定の部分データフローが存在する場合(ステップS16:YES)、ステップS12に戻り、情報処理装置1は上述の処理を繰り返す。このような処理を繰り返すにつれ、関数多重定義テーブルにおいて保護属性が未決定の状態である引数のフィールドには一意決定済みのものが増加し、全ての部分データフローの検査が完了するまでには必ず全てのフィールドが一意決定済みとなる。
ここでは、セキュリティ関数以外の操作は、それぞれ分割された部分データフローに対応する。上述の検査を行うことにより、セキュリティ関数以外では異なる保護属性が付与された変数・定数間の計算が行われないことが保証できるため、機密情報の攻撃者に対する間接的な漏れや、攻撃者により改変された情報によって保護対象の情報が汚染されることが防止できる。
ステップS4で説明した基本保護属性決定処理では、多くのプログラムでその保護属性を自動で決定することが可能であるが、保護属性を自動で決定できない例も存在する。図16は、図15に示す部分データフローについて自動決定の過程を示す図である。同図において、網掛け部分は、処理対象として選択された部分データフローを表し、太字は、決定された保護属性(派生的に決定されたものを含む)を表す。この例では、最初に部分データフロー番号「1」の部分データフローが選択され、保護属性が「exposed」に決定される。すると、上述したように、公開鍵暗号文復号関数の関数引数保護属性の定義から、部分データフロー番号「3」の部分データフローにおいて公開鍵暗号文復号関数である関数「SKDecrypt」の第3引数「#2212_SKDecrypt(#3)」の保護属性が「concealed」に決定される。しかし、暗号化関数である関数「CKEncrypt」の第2引数「#2217_CKEncrypt(#2)」は暗号化関数の関数引数保護属性の定義より保護属性「confidential」でなければならないため、部分データフロー番号「3」の部分データフローでは保護属性を一致させることができない。なお、部分データフロー番号「1」の部分データフローの前に部分データフロー番号「3」の部分データフローが選択された場合は、関数「SKDecrypt」の第3引数「#2212_SKDecrypt(#3)」の保護属性が「confidential」と決定される。すると今度は部分データフロー番号「1」の部分データフローにおいて保護属性の一致が不可能となり、いずれの場合でも保護属性の決定は失敗する。
ここで注目すべき点は、依存関係の部分で説明したように、このプロトコルが安全なものであるにもかかわらず、保護属性を決定できていないということである。本実施の形態では、依存関係を考慮することにより、このような事例に対して1つの解決策を与えている。図12に示すように、ステップS4の基本保護属性決定処理で保護属性の決定に失敗した場合、情報処理装置1は、ステップS6で、依存関係を考慮した関数拡張つき保護属性決定処理を行う。
ここで、関数拡張つき保護属性決定処理の詳細について図17を用いて説明する。この関数拡張つき保護属性決定処理の目的は、保護変数及び非保護変数の適切な分離が行われていない図13に示すデータフロー及びそれに対応する関数引数保護属性セットと依存関係セットとに対し、依存関係を考慮した完全性の間接的な検証(完全性間接的検証という)を検出し、その完全性間接的検証の発生した部分の関数を拡張することにより再構築して、保護変数及び非保護変数を分離可能なデータフローとそれに対応する関数引数保護属性セットと依存関係セットとを生成することである。この関数の拡張を本実施の形態においては関数の合成により実現する。
まず、情報処理装置1は、処理対象のプログラムから構築されたデータフローで用いられている関数と、図10に示すように定義された依存関係とに従って、依存関係セットを取得する(ステップS20)。次に、情報処理装置1は、関数ペアテーブル及び当該関数拡張つき保護属性決定処理で構築される合成関数V’の関数引数保護属性テーブルの初期化を行う(ステップS21)。関数ペアテーブルとは、依存関係を生成する関数と、完全性間接的検証を発生させる検証関数とのペア(関数ペアという)が登録されたテーブルであり、例えばRAMなどの記憶装置やHDDなどの外部記憶装置に記憶される。初期化では、情報処理装置1は、図10に示す依存関係を生成する関数(依存関係生成関数という)と、検証関数(署名検証または MAC 検証)とのペア全てを関数ペアテーブルに登録する。図11に示す擬似プログラムの例では、依存関係生成関数Fの候補は関数「SKDecrypt」、関数「Hash」及び関数「CKEncrypt」の3つである。検証関数Vの候補は関数「PKVerify」のみである。このため、情報処理装置1は、関数ペアとして(SKDecrypt、 PKVerify)、(Hash、 PKVerify)、(CKEncrypt、 PKVerify) の3つを関数ペアテーブルに登録する。合成関数V’の関数引数保護属性テーブルとは、合成関数V’の関数引数保護属性を記憶するテーブルであり、例えばRAMなどの記憶装置やHDDなどの外部記憶装置に記憶される。合成関数V’の初期化では、情報処理装置1は、関数引数保護属性テーブルにおいて関数引数保護属性を全てリセットし、エントリーが何も登録されていない状態にする。
ステップS22〜S36の処理はループであり、情報処理装置1は、関数ペアテーブルに含まれる全ての関数ペア(F、V)について処理を行う。まず、ステップS23で、情報処理装置1は、依存関係生成関数Fの入力変数及び出力変数のうち、少なくとも1つが検証関数Vに入力されているかを判定する。この意味は、依存関係生成関数Fの出力が検証関数V に入力されるのか、あるいは、依存関係生成関数Fの入力が検証関数Vにも入力される(即ち、依存関係生成関数Fと検証関数Vとに共通に入力がなされる)のいずれかを満たすか否かを判定するということである。当該判定結果が否定的である場合(ステップS23:NO)、依存関係により完全性間接的検証が発生することはないので、次の関数ペア(F、 V)に処理が移る。ステップS23の判断結果が肯定的である場合(ステップS23:YES)、ステップS24に進む。図11に示す擬似プログラムの例では、関数ペアとして(SKDecrypt、 PKVerify)、(Hash、 PKVerify)、(CKEncrypt、 PKVerify)のうち、関数ペア(Hash、 PKVerify) のみがデータフローにおいてつながっており、関数「Hash」の出力が関数「PKVerify」に入力されている。このため、この関数ペア(Hash、 PKVerify)に対してのみステップS23の判定結果が肯定的となる。
ステップS24〜S27の処理はループであり、情報処理装置1は、ステップS23の判定結果が肯定的となった関数ペア(F,V)について、依存関係生成関数Fの依存関係表に含まれる1つのエントリーと、依存関係性関数Fの多重定義の1つと、検証関数Vの多重定義の1つとを各々選択し、その全ての組み合わせについて、ステップS25以降の処理を行う。まず、ステップS25では、情報処理装置1は、依存関係による完全性間接的検証が発生するか否かを判定する。依存関係による完全性間接的検証が発生するのは検証前の段階では依存関係の決定項に含まれる変数のうち完全性を有さないものが存在し、検証後にそれらが全て完全性を有しているときである。言い方を変えると、以下の2つの条件を満たすときである。
(条件1)依存関係の決定項の変数のうち、少なくとも1変数が検証関数に入力され、それが検証されることにより出力時に完全性を有する。
(条件2)検証関数に入力されていない決定項の変数が、完全性を既に有している。
更に、依存関係生成関数Fと検証関数Vとを合成するためには、決定項の変数の保護属性が、依存関係生成関数Fの入力及び出力と検証関数Vの入力とで一致していなければならない。よって、以下の条件をチェックする必要がある。
(条件3)検証関数に入力された決定項の変数(依存関係生成関数Fから出力されて検証関数Vに入力される変数、あるいは依存関係生成関数Fと検証関数Vとに共通に入力がなされる変数)の保護属性が一致している。
以上のことから、ステップS25では、情報処理装置1は、以下の(c),(d)をチェックしている。(c)は条件3及び条件1を満たすか否かのチェックである。(d)は条件2を満たすか否かのチェックである。
(c)依存関係のエントリーの決定項の変数のうち少なくとも1つが検証関数Vに入力されており、当該変数の保護属性が依存関係生成関数Fの入力及び出力と検証関数Vの入力とで一致し、かつ当該変数が検証関数Vの出力で完全性を有しているか
(d)依存関係のエントリーの決定項の変数のうち、検証関数Vに入力されていないものが、依存関係生成関数Fの入力の定義及び出力の定義において全て真正性を有しているか。
図18は、図11に示す擬似プログラムについて、情報処理装置1が、関数「Hash」の依存関係、関数「Hash」の関数定義及び関数「PKVerify」の関数定義をそれぞれひとつずつ選びチェックを行った結果を例示する図である。この例では、決定項の変数が1つのため、条件2は満たされるので、(d)のチェックは無条件でパスする。復号関数のように、決定項の変数が複数存在する場合は、条件2が満たされない場合がある。
ステップS25のチェックをパスした場合(ステップS25:YES)、依存関係による完全性間接的検証が発生することが確認することができる。そして、次のステップS26で、情報処理装置1は、ステップS25のチェックをパスした関数ペアに対して、依存関係生成関数Fと検証関数Vとを合成し、これらを合成した合成関数V’を新たなセキュリティ検証関数として定義する。こうすることにより、セキュリティの専門家によるデータフロー解析を行うことなく、セキュリティ関数を安全に拡張することができる。そして、情報処理装置1は、新たなセキュリティ検証関数V’について、関数引数保護属性テーブルへエントリーを登録することにより、関数定義を行う。図18に示す例では、ステップS25のチェックをパスするのは、(Hash の依存関係,Hash の関数定義,PKVerify の関数定義)について、(b, A, B),(b, D, B),(b, C, A) 及び(b, C, C)の4つである。そしてステップS26の終了時点で、新たなセキュリティ検証関数V’として、署名検証関数「Hash_and_PKVerify」が定義される。図19は、署名検証関数「Hash_and_PKVerify」の定義を示す図である。尚、以下で説明する処理を行うと、(b, D, B) と (b, C, C)とからは同じ多重定義のエントリーが生成されるため、図19に示す表は3つのエントリーによる多重定義になっている。以下、情報処理装置1がステップS26で行う関数の定義について具体的に説明する。
まず、情報処理装置1は、新たなセキュリティ検証関数V’の入力を、「依存関係生成関数Fの入力変数+(検証関数Vの入力変数-依存関係生成関数Fの出力変数)」で定義する。また、情報処理装置1は、セキュリティ検証関数V’の出力を「(依存関係生成関数Fの出力変数-検証関数Vの入力変数)+ 検証関数Vの出力変数」で定義する。入力から依存関係生成関数Fの出力変数を取り除き、出力から検証関数Vの入力変数を取り除いているのは、依存関係生成関数Fと検証関数Vとの中間変数を取り除くためである。中間変数は、関数のなかに閉じ込められてしまうため、定義する必要がないのである。また、各変数の保護属性については、依存関係生成関数Fの依存関係エントリーf並びに検証関数Vの依存関係エントリーvにおける定義をそのまま引き継ぐ。図11に示す擬似プログラムの例では、ここまでで図19に示す入力変数「Cert_ComKey」と「結果」以外の変数が定義される。
ここで、出力変数に従属項の変数が含まれるか含まれないかで処理が異なる。出力変数に従属項の変数が含まれる場合、その変数は完全性が間接的に検証される変数であるから、出力される時点では完全性を有する保護属性を付与する必要がある。そこで、情報処理装置1は、当該変数の保護属性を、依存関係エントリーfから引き継いだものから、機密性を維持したまま、完全性を有する保護属性に変更して置き換える。逆に、出力中に従属項の変数がない場合、当該変数は依存関係生成関数Fの入力に含まれており、その変数が検証関数Vから完全性を検証されて出力されるように、情報処理装置1は、入力とは異なる名前に変更して、セキュリティ検証関数V’の出力に付加する。このとき、その変数の保護属性は、依存関係エントリーfの入力における保護属性であり、名前変更前の当該変数の保護属性を、機密性を維持したまま完全性を有するものに変更したものとする。図11に示す擬似プログラムの例では、出力変数に従属項の変数が含まれない場合であるため、情報処理装置1は、従属項の変数「ComKey」の名前を変数「Cert_ComKey」に変えて出力に付加する。このとき、その保護属性は、依存関係生成関数Fの入力定義における変数「ComKey」の保護属性(「exposed」あるいは「concealed」)を完全性を有する保護属性に変更したもの(「exposed」から「verified」に変更あるいは「concealed」から「confidential」に変更)となる。
最後に、補助出力である結果については、情報処理装置1は、入力中にひとつでも機密性を有するものがあればその保護属性を「confidential」に再定義し、入力中にひとつでも機密性を有するものがなければその保護属性を「verified」に再定義する。図11に示す擬似プログラムの例では、入力及び出力に機密性を有するものを含まないもの(図19の拡張公開鍵署名検証1-A)については、保護属性は「verified」となっており、それ以外については、保護属性は「confidential」となっている。以上のようにして、情報処理装置1は、図19に示すような新たなセキュリティ検証関数V’として署名検証関数「Hash_and_PKVerify」を定義する。
ステップS24〜S27のループでセキュリティ検証関数V’が定義された場合(ステップS28:YES)、それに応じてデータフローの拡張を情報処理装置1は行う(ステップS29)。情報処理装置1は、まず、依存関係生成関数関数F及び検証関数Vを削除し、代わりに新たなセキュリティ検証関数V’を付加する。セキュリティ検証関数V’の依存関係は検証関数Vの依存関係をそのまま引き継ぐ。
図20は、図11に示す擬似プログラムについて、ステップS29で拡張されたデータフローを示す図である。同図において新たなセキュリティ検証関数V’として、関数「Hash_and_PKVerify」2501が付加されている。また、関数「PKVerify」は署名検証関数なので依存関係がないため、関数「Hash_and_PKVerify」の依存関係も定義されない。またこの時、依存関係が考慮されたことにより、プログラム並びにデータフローにおける引数の変更が発生する場合がある。具体的には、情報処理装置1は、完全性の検証以前の従属項の変数を入力とする関数について、計算順序を考慮した上で、新たなセキュリティ検証関数V’より出力された完全性の有する従属項の変数を入力とするように変更する。図11に示す擬似プログラムの例では、変数「ComKey」がそれに該当する。プログラムリストより関数「PKVerify」のほうが関数「CKEncrypt」より先に用いられて計算されることから、関数「CKEncrypt」には変数「ComKey」ではなく完全性が確認された変数「Cert_ComKey」が入力される。
このようにデータフローを拡張した後、情報処理装置1は、セキュリティ検証関数V’の不要な変数の枝刈りを行う(ステップS30)。この枝刈りとは、セキュリティ検証関数V’の入力及び出力のうち、セキュリティ検証関数V’以外のどの関数にも入力又は出力されていない変数を削除するということである。これにより、変数の数を減らして、保護属性の決定並びにプログラムの実行の効率と安全性とを高めることができる。図20においては、Hash_and_Verify から出力され、かつ角丸四角形のシンボルで表される「Cert_Sign_A」及び「Cert_SigMsg_A」の2変数が、セキュリティ検証関数V’から出力されるものの、その後どこにも入力されない変数であるため、枝刈りの対象となる。ここで注意すべきことは、変数「Cer_Sign_A」は、セキュリティ検証関数V’に入力された変数「Sign_A」の完全性が検証されて出力されたものであるということである。このように、セキュリティ検証関数V’に入力され、その完全性が検証されて出力されるような変数の場合、「Cert_Sign_A」だけではなく、入力側の「Sign_A」も依存関係生成関数Fに入力又は出力されていないかをチェックすることにより、枝刈りが可能か否かを情報処理装置1は判定する。変数「Cert_Sign_A」については、入力関数「Input」は依存関係生成関数に含まれないので、枝刈り可能となる。よって、情報処理装置1は、「Cert_SigMsg_A」と「Cert_Sign_A」との2変数を枝刈りする。これに応じて、情報処理装置1は、図19に示すセキュリティ検証関数V’である関数「Hash_and_PKVerify」の出力定義からも当該2変数を削除する。
図21は、図20に示すデータフローから情報処理装置1が枝刈りを行ったデータフローを示す図である。関数「PKVerify」により関数「CKEncrypt」への入力(ComKey)の完全性が保証されることが検出されているため、図21では、関数「Hash」と関数「PKVerify」とが合成された関数「Hash_and_PKVerify」から完全性の確認された値が出力され、それが関数「CKEncrypt」へ入力されていることが示されている。また、枝刈りにより、関数「Hash_and_PKVerify」の出力から「Cert_SigMsg_A」と「Cert_Sign_A」との2変数が削除されていることが示されている。尚、この枝刈りは必須ではなく、必ずしも行う必要はない。
次いで、情報処理装置1は、ステップS29で拡張しステップS30で枝刈りを行った後のデータフローに対して、図12のステップS4と同様の基本保護属性決定処理を改めて行う(ステップS31)。当該基本保護属性決定処理において保護属性の決定に成功した場合(ステップS32:YES)、情報処理装置1は、当該データフロー並びに決定した各引数の保護属性を出力する(ステップS33)。一方、ステップS31の基本保護属性決定処理において保護属性の決定に失敗した場合(ステップS32:NO)、情報処理装置1は、処理対象の関数ペア(F, V)を合成してセキュリティ検証関数V’を新たに定義しても、保護属性を自動で決定できないということになる。この場合、情報処理装置1は、ステップS29で行った拡張、並びにステップS30で行った枝刈りを全て戻し、即ち、ステップS29の処理を行う直前の状態に戻して、セキュリティ検証関数V’の関数引数保護属性を初期化する(ステップS35)。このようにして、情報処理装置1は、全ての関数(F, V)について、依存関係を考慮した関数の拡張並びに保護属性の決定を試みる(ステップS36)。いずれの関数ペアについても保護属性を自動で決定ができない場合、保護属性の決定は失敗する。ここでの失敗は、関数ペアについて、関数の拡張として1回の合成を考慮しても、セキュリティの観点から安全でないデータフローが存在するということを意味している。この場合、図12のステップS7が否定的となり、異常であるとして情報処理装置1は処理を終了する。尚、関数ペアについて複数回の合成を行う例については、第3の実施の形態で説明する。
次に、図21に示すように2変数の枝刈りが行われたとして説明を続ける。同図に示す一繋がりのデータフローは、図22に示すように10個の部分データフローに分割される。図22は、分割された部分データフローを模式的に示す図である。部分データフロー番号「3」の部分データフローには、検証前の鍵である変数「ComKey」があり、部分データフロー番号「6」の部分データフローには、検証後の鍵である変数「Cert_Comkey」があり、検証前後での分離が行われていることが分かる。図23は、この部分データフローについて、図12のステップS4の基本保護属性決定処理を行う過程を示す図である。ステップS29で拡張されたデータフローは、図20に示す通り、公開鍵暗号文復号関数である関数「SKDecrypt」 の復号結果である完全性を有さない変数「ComKey」と、共通鍵暗号化関数である関数「CKEncrypt」に入力される完全性を有する変数「Cert_ComKey」とが分離されており、保護属性の決定が適切に行われ、全ての変数への保護属性の付与が成功する。尚、ここでは枝刈りを行った場合について説明したが、枝刈りを行わない場合でも同様に、保護属性の決定は成功する。例えば、図22に示すデータフローにおいて枝刈りが行われない場合、変数「Cert_SigMsg_A」の保護属性及び変数「Cert_Sign_A」の保護属性は共に「verified」に一意に決定される。
以上のように、本実施の形態においては、複数の関数の関係性を依存関係として考慮して、各変数に付与すべき保護属性を決定する。例えば、図11に示す擬似プログラムの例の場合では、ハッシュ関数と署名検証関数とを連携させて考えることにより、署名検証後のハッシュ関数の入力の完全性を確認することが可能である。より具体的には、ハッシュ関数の入力を、署名検証前は完全性のないものとして扱い、署名検証後は、その署名検証が成功した場合に限り完全性があるものとして別々に扱うことが可能となる。データフローにおいて保護変数及び非保護変数の分離を実現することができる。この結果、各変数に適切な保護属性を付与することができる。
また、セキュリティプロトコルの記述で用いる各変数に完全性や機密性に関する保護属性を付与し、関数による計算は同一の保護属性の変数間に限定する。これにより、保護データと非保護データとが分離される。更に、暗号化処理による保護属性の変換に対応するため、異なる保護属性間での計算を、計算量的一方向性を有する関数(例えば、暗号化関数、復号関数、署名生成関数、署名検証関数など)によるものに限定し、計算の種別ごとに入力及び出力の保護属性を制限する。例えば、公開鍵暗号文復号関数においては、秘密鍵は機密性と完全性との両方が要求される。また、入力される暗号文は非保護データであるのに対して、復号された結果である出力は、機密性を有する保護データとなる。これにより、保護属性の変換が安全な計算のみに限定され、例えば特許文献1の技術のように保護データを誤って外部に出力してしまう恐れを排除して、保護属性の変換誤りを低減することができる。
また、本実施の形態によれば、外部からの入力に対して検証と復号との両方の処理を行えば、これらを行ったときのみ、その値の完全性と機密性との両方が保証される。よって非特許文献1の技術では対応できなかった、機密性を有するデータを暗号化する際の暗号鍵に外部からの入力を安全に利用するようなプロトコルに対応することができる。以上のように本実施の形態においては、(R1)異なる保護属性の計算を禁止する、(R2)一方向性計算での保護属性の変換及び入力及び出力の保護属性を限定する、という2つのルールをベースとし、更に、(R3)完全性間接的検証を考慮して保護属性を決定することにより、各変数に対して保護属性を適切に付与することができる。完全性間接的検証とは、上述したように、例えば、ハッシュ関数と署名検証関数とを組み合わせて利用した処理において発生するものである。このような処理では、検証したいメッセージmをハッシュ関数Hに入力し、その出力である変数H(m)を署名検証関数に入力する。ここで署名検証に成功すると、署名検証関数の性質から、署名検証関数に入力された変数H(m)の完全性が保証される。するとこのとき、ハッシュ関数Hの衝突困難性により、ハッシュ関数の出力である変数H(m)だけでなく、これに対応する、ハッシュ関数の入力であるメッセージmの完全性も保証される。この処理では、以上のような考えに基づきメッセージmの完全性が確認できるが、上述の(R1),(R2)の2つのルールだけでは、メッセージmに完全性があることを検出できず、適切な保護属性を付与することができない。ところが、本実施の形態においては、出力の完全性が保証されると、対応する入力の完全性も間接的に保証されるような関係(依存関係)に注目することで、入力の完全性が間接的に確認することができる値を検出できる。よって、例えば、ハッシュ関数と署名検証関数とを組み合わせた処理を行うプロトコルにおいて、保護属性を適切に付与することができる。このようなプロトコルには、例えば、メールにおける標準的なプロトコルである PGP,S/MIMEや、インターネットにおける標準的なプロトコルである SSLがあり、これらのプロトロトコルに本実施の形態の構成を適用することは有用である。
以上のことから、例えば、特許文献1や非特許文献2に示すように、保護メモリ領域及び非保護メモリ領域の2種類のメモリ領域にアクセス可能なプログラミングモデルにおいて、保護メモリ領域を活用した一般的なセキュリティプロトコルの安全な実装の支援することができる。つまり、本実施の形態においては、このようなプログラミングモデル上で、一般的なセキュリティプロトコルにおいて保護メモリ領域に記憶すべき保護データと非保護メモリ領域に記憶すべき非保護データとの分離を適切に行うために、データの流れ(データフロー)だけではなく、途中で行われる暗号化処理などの各処理に注目して、各変数に対する保護属性を適切に決定している。この結果、これらの変数を保護属性に応じて保護メモリ領域又は非保護メモリ領域に適切に記憶させることができ、非保護メモリ領域を利用した外部からの入出力と内部に保持すべき変数に対する保護メモリ領域における保護とを両立させることができる。
[第2の実施の形態]
次に、情報処理装置、プログラム開発システム、プログラム検証方法及びプログラムの第2の実施の形態について説明する。なお、上述の第1の実施の形態と共通する部分については、同一の符号を使用して説明したり、説明を省略したりする。
上述の第1の実施の形態においては、関数の拡張として、依存関係生成関数及び検証関数を合成する例について説明した。本実施の形態においては、関数の拡張として、検証関数自体を拡張して新たな検証関数を生成する例について説明する。この例では、依存関係生成関数Fは削除しないが、関数引数保護属性については変更が伴う。
次に、本実施の形態にかかる情報処理装置1が保護属性を自動で決定する処理の手順について説明する。本実施の形態における当該処理の手順は図12に示したものと略同様であり、ステップS6の詳細な手順が第1の実施の形態と異なる。本実施の形態においては、ステップS6の関数拡張つき保護属性決定処理では、情報処理装置1は、依存関係生成関数及び検証関数の関数ペアを合成するのではなく、当該関数ペアの検証関数自体を拡張する。この関数拡張つき保護属性決定処理自体の手順の概要は、図17に示したものと略同様である。本実施の形態においては、図17に示したステップS26,S29の処理の詳細が上述の第1の実施の形態と異なる。
ステップS20〜S25は上述の第1の実施の形態と同様である。ステップS26では、情報処理装置1は、上述の第1の実施の形態と同様のステップS25のチェックをパスした関数ペアに対して、(依存関係生成関数Fの依存関係,Fの関数定義,検証関数Vの関数定義)の3つ組に対して、関数定義を行う。本実施の形態では、依存関係生成関数Fと検証関数Vとを合成するのではなく、依存関係生成関数Fをそのままにして検証関数Vのみを拡張して新たなセキュリティ検証関数V’を生成するため、情報処理装置1は、検証関数Vの入力変数及び出力変数に従属項の変数をそれぞれ加える。このとき、入力変数と出力変数とは異なる名前になるようにする。また、情報処理装置1は、これらの各変数の保護属性には、依存関係生成関数Fの関数引数保護属性エントリーfにおいて定義されている入力の保護属性及び出力の保護属性を引き継ぐ。例えば、第1の実施の形態の説明で用いた図13に示すデータフローの場合、情報処理装置1は、関数「PKVerify」を拡張した新たなセキュリティ検証関数である「Modified_PKVerify」の入力の定義及び出力の定義として関数「PKVerify」の入力及び出力を各々引き継ぐと同時に、従属項の変数「ComKey」を入力へ加え、更にその名前を変更した変数「Cert_ComKey」を出力へ加える。入力変数及び出力変数は、関数「PKVerify」から引き継ぎ、入力変数である「ComKey」については、関数「PKVerify」及び関数「Hash」の保護属性をそのまま引き継ぐ。一方、出力変数である「Cert_ComKey」については、情報処理装置1は、関数「Hash」における保護属性(「exposed」,「concealed」)を、機密性を維持したまま完全性の有する保護属性に変更する(保護属性「exposed」から保護属性「verified」に変更あるいは保護属性「concealed」から保護属性「confidential」に変更)。図24は、検証関数Vである関数「PKVerify」を拡張した関数である新たなセキュリティ検証関数「Modified_PKVerify」の定義を示す図である。同図においては、入力3に入力変数「Com_Key」が付加されており、出力3「Cert_ComKey」に出力変数が付加されている。
ステップS27〜S28は上述の第1の実施の形態と同様である。ステップS29では、情報処理装置1は、ステップS26で得られたセキュリティ検証関数V’を元にデータフローを拡張する。本実施の形態では、第1の実施の形態と異なり、情報処理装置1は、依存関係生成関数Fは削除せず、検証関数Vのみをセキュリティ検証関数V’に置き換える。更に、情報処理装置1は、第1の実施の形態と同様に、セキュリティ検証関数V’への依存関係の引継ぎ及び引数の変更によるデータフローの書き換えを行う。更に、本実施の形態においては、情報処理装置1は、関数ペア(F, V’)の中間変数へ特殊属性を付与する。中間変数とは、依存関係生成関数Fから出力され、新たなセキュリティ検証関数V’ に入力され、更に関数ペア(F, V’)以外では参照されない変数である。この中間変数に対しては、意味上の機密性並びに完全性に関わらず、外部から読み取れず改ざんもできないような処理を施す。尚、第1の実施の形態においては、このような中間変数は外部から読み取れないように削除していた。一方、本実施の形態においては、依存関係生成関数Fの出力に関する定義並びに検証関数Vの入力に関する定義において、特殊属性「capsulated」を定義している。ここで注意すべきは、特殊属性「capsulated」とは、関数ペア(F, V’)の中間変数以外のどんな変数との計算も許可されない属性である。即ち、特殊属性「capsulated」が付与される変数は、関数ペア(F, V’)の中間変数以外のどんな変数との計算も許可されないということである。そのため、関数ペア(F, V’)によって特殊属性「capslated」を区別して定義する必要がある。例えば、特殊属性を「capslated_1」「capslated_2」などのように関数ペア(F, V’)毎に識別可能に付与する必要がある。図11に示す擬似プログラムの例では、関数「Hash」と関数「Modified_PKVerify」との間でのみ使用される変数「SigMsg_A」がこの中間変数に該当する。このため、情報処理装置1は、関数「Hash」並びに関数「Modified_PKVerify」の多重定義テーブルにおいて、変数「SigMsg_A」の保護属性を特殊属性「capsulated_1」に書き換える。このとき、情報処理装置1は、関数「Hash」の出力変数に対する保護属性を「capslated_1」に書き換えるが、仮にプログラム中に関数「Hash」以外の別のハッシュ関数が使われていたとしても、そのハッシュ関数の出力変数に対する保護属性は書き換えない。あくまでもここで対象としている依存関係生成関数である関数「Hash」のみが書き換えの対象であることを注意しておく。
尚、上述したように、依存関係を生成するときは、その入力変数及び出力変数が改ざん防止された状態で行わなければならない。これを実現するためには、決定項の変数並びに従属項の変数に対して、改ざん防止処理を施す必要がある。例えば保護属性「exposed」が付与された変数は、署名検証のときと同様に、依存関係生成関数Fの計算が行われる直前に保護属性「fixed」にコピーし、保護属性「hidden」あるいは保護属性「concealed」が付与された変数については、改ざん防止処理をはじめから施しておけば良い。本実施の形態において図11に示す擬似プログラムの例では、このような処理によって、関数「Hash」に入力される変数「Comkey」の値と、関数「Modified_PKVerify」に入力される変数「Comkey」の値とが同じであることが保証される。尚、検証に成功した場合は、出力変数「Cert_Comkey」の値もそれらの値と同じになる。
データフローを拡張した後、ステップS30では、情報処理装置1は、セキュリティ検証関数V’が出力する不要な変数の枝刈りを行う。本実施の形態において図11に示す擬似プログラムの例では、「Cert_SigMsg_A」及び「Cert_Sign_A」の2変数が枝刈りの候補だが、これらはいずれもセキュリティ検証関数V’により完全性が検証されて出力された変数である。このうち、変数「Cert_Sign_A」に対応する変数「Sign_A」は依存関係を生成しない関数「Input」にしか繋がっていないため、枝刈り可能である。また、変数「Cert_SigMsg_A」の方は、対応する変数「SigMsg_A」が関数「Hash」及び関数「 Modified_PKVerify」の中間変数であるから、やはり枝刈り可能である。従って、情報処理装置1は、「Cert_SigMsg_A」及び「Cert_Sign_A」の2変数を枝刈りする。図25は、図11に示す擬似プログラムのデータフローを拡張して、当該2変数を枝刈りしたデータフローを示す図である。同図においては、関数「PKVerify」自体が拡張された関数「Modified_PKVerify」から完全性の確認された値が出力され、それが関数「CKEncrypt」へ入力されていることが示されている。また、枝刈りにより、関数「Modified_PKVerify」の出力から「Cert_SigMsg_A」と「Cert_Sign_A」との2変数が削除されていることが示されている。図26は、関数「Hash」及びセキュリティ検証関数「Modified_PKVerify」の定義を示す図である。その後の処理の手順は上述の第1の実施の形態と同様であり、情報処理装置1は、ステップS29で拡張しステップS30で枝刈りを行ったデータフローに対して、基本保護属性決定処理を行う。図27は、本実施の形態において上述の第1の実施の形態と同様にして分割された部分データフローについて、基本保護属性決定処理を行う過程を示す図である。同図に示すように、各変数に対して、保護属性が一意に決定されている。尚、上述した通り、依存関係を保持するため、変数「ComKey」には、保護属性が「concealed」が付与されているが、改ざん防止処理が施されていることに注意しておく。
以上のように、依存関係生成関数及び検証関数を合成するのではなく、検証関数自体を拡張することによっても、各変数に対する保護属性を適切に決定することができる。この結果、これらの変数を保護属性に応じて保護メモリ領域又は非保護メモリ領域に適切に記憶させることができ、非保護メモリ領域を利用した外部からの入出力と内部に保持すべき変数に対する保護メモリ領域における保護とを両立させることができる。
[第3の実施の形態]
次に、情報処理装置、プログラム開発システム、プログラム検証方法及びプログラムの第3の実施の形態について説明する。なお、上述の第1の実施の形態又は第2の実施の形態と共通する部分については、同一の符号を使用して説明したり、説明を省略したりする。
(1)構成
上述の第1の実施の形態及び第2の実施の形態では、完全性間接的検証の検出が1回だけ発生する場合を扱った。本実施の形態においては、完全性間接的検証の検出が複数回発生し得る場合について説明する。以下では、第1の実施の形態の関数を合成することにより関数を拡張する構成において、複数箇所の依存関係を考慮して保護属性を自動で決定する構成について説明する。また、入れ子状態となっている関数を合成することも可能である。
図28は、本実施の形態で用いるセキュリティプロトコルのシーケンスを示す図である。当該セキュリティプロトコルは第1の実施形態及び第2の実施の形態で用いた、図9に示すハイブリッド暗号のセキュリティプロトコルと略同様であるが、KDFを用いる点が異なる。また、同図において、システムA7101は、図2に示す外部装置103で動作し、システムB7201は、図2に示すプログラムモジュール212によって実現される。まず、セキュリティプロトコルの実行に先立って、システムB7201はシステムA7103の公開鍵(pkA)7215を予め取得する。システムB7201は、CA発行の証明書により公開鍵(pkA)7215の完全性を別途検証するが、図では省略されている。また、システムB2201を実現させるプログラムモジュール201には、自身に割り当てられた秘密鍵(skB)7211とメッセージ(msg)7218とが静的に予め埋め込まれる。
システムA7101は、メッセージ(msg)7218を転送するための共通鍵(一時鍵)(K)を生成し、共通鍵(K)7113をKDFに通すことで、KDF(K)の第1要素及び第2要素として第1要素(K1)7113Aと第2要素(K2)7113Bと得る。更に、システムA7101は、第1要素(K1)7113Aのハッシュ値に対して自身の秘密鍵により署名7112を生成して、これをシステム7201に送信する(7402)。更に、システムA7101は、システムB7201の公開鍵(pkB)により共通鍵(K)7113を暗号化したデータ7111をシステム7201に送信する(7401)。システムA7101は、CA 発行の証明書により公開鍵(pkB)の完全性を別途検証するが、図では省略されている。
一方、システムB7201は、7401でシステムA7101から送信されたデータ7111を受信すると、自身に割り当てられた秘密鍵(skB)7211を用いて公開鍵暗号分復号関数7212により共通鍵(K)7213を取得する。次に、システムB2201は、共通鍵(K)7213をKDF7231に通し、KDF(K)の第1要素及び第2要素として第1要素(K1)7232と第2要素(K2)7233とを得る。更に、システムB2201は、第1要素(K1)7232を用いてハッシュ関数7214によりハッシュ値を計算し、事前に完全性を確認した公開鍵(pkA)7215と、7402で受信した署名7112とを用いて署名検証関数7216により署名検証を行う。署名検証が成功した場合、図10において説明したハッシュ関数の性質から第1要素(K1)7232の完全性が確認され、更に依存関係の定義において説明したKDFの性質から、共通鍵(K)7213並びに第2要素(K2)7233の完全性が確認される。すると、第2要素(K2)7233を、メッセージ(msg)7218を、共通鍵暗号化するための暗号化鍵として用いることができる。そして、システムB7201は、メッセージ(msg)7218を、第2要素(K2)7233を用いて共通鍵暗号化関数7217により暗号化して暗号文を生成し、当該暗号文をシステムA7101に送信する(7403)。システムA7101は、7403でシステムB7201から送信された暗号文を受信すると、自身が保持する共通鍵(K)7113をKDFに通して、第2要素(K2)7233を得て、これを用いて共通鍵復号関数7114により当該暗号文を復号して、メッセージ(msg)7115を得る。尚、このデータフローが生成される元となる擬似プログラムは図11に示すものと異なるが、ここではその図示を省略する。
次に、本実施の形態において、図2で示した情報処理装置1の構成が上述の第1の実施の形態と異なる点について説明する。更新置換部51は、データフロー21,関数引数保護属性セット12及び依存関係セット13を複数回更新し得る。保護属性決定部52には、更新置換部51が更新したデータフロー21、関数引数保護属性セット12及び依存関係セット13が複数回入力され得る。そして、保護属性決定部52は、上述の第1の実施の形態と同様にして、更新置換部51が更新したデータフロー21、関数引数保護属性セット12及び依存関係セット13を用いて、各変数に対して一意に決定された保護属性を記憶する変数保護属性テーブル及び関数多重定義テーブルを出力する。
(2)動作
次に、本実施の形態にかかる情報処理装置1の行う保護属性決定処理の手順について図29を用いて説明する。本実施の形態における当該処理の手順は図12に示したものと略同様であり、ステップS6’の手順が第1の実施の形態と異なる。本実施の形態においては、ステップS6’では、関数拡張つき保護属性決定処理ではなく複数回関数拡張つき保護属性決定処理を行う。図30は、複数回関数拡張つき保護属性決定処理の手順を示すフローチャートである。複数回関数拡張つき保護属性決定処理の手順が、図17に示した関数拡張つき保護属性決定処理と異なる点は、ステップS31で行った基本保護属性決定処理において保護属性の決定に失敗した場合(ステップS32:NO)、ステップS40で、ステップS6’で行う当該複数回関数拡張つき保護属性決定処理自体を再帰的に行う点である。再帰的に行ったステップS40の複数回関数拡張つき保護属性決定処理で保護属性の決定に成功した場合(ステップS41:YES)、情報処理装置1は、処理を正常に終了し、保護属性の決定に失敗した場合(ステップS41:NO)、ステップS35に進み、ステップS29で行った拡張並びにステップS30で行った枝刈りを全て戻す。このような処理を行うことにより、複数個所において関数の拡張を扱うことが可能となる。拡張する箇所は、全く別のところになることも、入れ子状態になることもある。
次に、データフローの具体例を用いて処理の流れについて説明する。図31は、本実施の形態にかかるデータフローを例示する図である。図28と略同様であるため、図28と同様の関数及び変数に対しては同一の符号を用いている。尚、システムA7101からの入力(図28の7401〜7402)については、入力関数「Input」7401,7402として各々表している。また、公開鍵暗号文復号関数7212は、関数「SKDecrypt」7212として表し、署名検証関数7216は、関数「PKVerify」7216として表し、共通鍵暗号化関数7217は、関数「CKEncrypt」7217として表している。また、システムB7201からの出力(図28の7403)については、出力関数「Output」7403として表している。同図に示されるデータフローでは、KDFの出力変数と関数「CKEncrypt」の入力変数とが繋がっており、前者は未検証のため完全性が保証されず、後者は完全性を必要とするため、保護属性の決定は不可能である。ここで、第1の実施の形態と同様に、関数「Hash」と関数「PKVerify」との間に依存関係が認められる。このため、依存生成関数「Hash」と検証関数「PKVerify」とが合成され、新たなセキュリティ関数として関数「Hash_and_PKVerify」が生成される。
図32は、図30のステップS29でデータフローの拡張が行われた結果得られるデータフローを示す図である。同図においては、新たなセキュリティ関数として関数「Hash_and_PKVerify」が新たに構成されていることが示されており、その出力変数として従属項の変数である「Cert_K1」7252が示されている。これらは図30のステップS26で定義される。また、ステップS30において「SigMsg_A」及び「Cert_Sign_A」の2変数が第1の実施の形態と同様の理由で枝刈りされている。尚、この枝刈りも第1の実施の形態と同様に必ずしも行う必要はない。しかし変数「Cert_K1」については、関数「Hash_and_PKVerify」に入力され、この関数により検証されて出力される変数であり、且つ、対応する、KDFの第1要素であるK1が依存関係生成関数であるKDFと繋がっているため、削除することができないことに注意しておく。この拡張後、図30のステップS31で保護属性の決定が再度行われるが、上述のKDFの出力変数と関数「CKEncrypt」の入力変数との間の保護属性の不一致の解決には至っていない。よってステップS40で、複数回関数拡張つき保護属性決定処理が再度行われる。
尚、このステップS40で、2回目となる複数回関数拡張つき保護属性決定処理を開始時点で、情報処理装置1は、ステップS21において関数ペアテーブルの初期化を行うが、これ以前に、1回目に処理対象となっていた関数ペア(F,V)を削除しておき、代わりに1目の複数回関数拡張つき保護属性決定処理で生成したセキュリティ検証関数V’をリストに加えておく。図31の例では、1回目の複数回関数拡張つき保護属性決定処理における関数ペアテーブルは、(SKDecrypt, PKVerify), (KDF, PKVerify), (Hash, PKVerify), (CKEncrypt, PKVerify) に初期化されるが、2回目の複数回関数拡張つき保護属性決定処理における関数ペアテーブルは、(SKDecrypt, Hash_and_PKVerify),(KDF, Hash_and_PKVerify), (CKEncrypt, Hash_and_PKVerify) に初期化されることになる。すると、2回目の複数回関数拡張つき保護属性決定処理においては、KDFと、1回目の複数回関数拡張つき保護属性決定処理で生成されたセキュリティ検証関数「Hash_and_PKVerify」との間に依存関係が認められる。この依存関係により、KDFと、セキュリティ検証関数「Hash_and_PKVerify」とが合成され、新たなセキュリティ検証関数として関数「KDF_and_Hash_and_PKVerify」が生成される。そして、入れ子状態となっているデータフローの拡張が再度行われる。図33は、拡張が行われた結果得られるデータフローを示す図である。この図では、新たなセキュリティ検証関数として関数「KDF_and_Hash_and_PKVerify」7261が新たに構成されていることが示されている。また、その出力変数には、従属項の変数である「Cert_K」7262と「Cert_K2」とが加わり、変数「Cert_K2」はKDFからの出力変数である「K2」に代わって関数「CKEncrypt」7217に入力される。変数「Cert_K1」は、対応するK1が関数の拡張によって内部変数となり、関数「KDF_and_Hash_and_PKVerify」への入力ではなくなったため、枝刈りによって削除されている。このようなデータフローの拡張後、ステップS31の基本保護属性決定処理が行われると、今度は、1回目の複数回関数拡張つき保護属性決定処理後に発生していた問題が解決されており、保護属性の決定が適切に行われる。この結果、保護属性の決定が成功して、処理が正常に終了する。図34は、本実施の形態において上述の第1の実施の形態と同様にして分割された部分データフローについて、基本保護属性決定処理を行う過程を示す図である。同図に示すように、各変数に対して、保護属性が一意に決定されている。
以上のような構成によれば、完全性の間接的な検証の検出が複数回発生する場合であっても、複数個所において関数の拡張を行うことにより、保護属性を適切に決定することができる。
尚、上述の実施の形態においては、複数個所の関数の拡張を再帰的に行うようにしたが、これに限らず、必要な情報を管理しながら処理を繰り返し実行することによっても、保護属性を適切に決定することはできる。
また、本実施の形態においては、第2の実施の形態の構成を適用して複数箇所の関数の拡張や入れ子状態の関数の拡張を行うことが可能である。この場合、一度行った拡張を再度行わないようにする必要がある。これは、関数ペア(F, V)の拡張を行い、検証関数Vを新たなセキュリティ検証関数 V’に置換した後、関数ペア(F, V’)で拡張を再度行わない、ということである。この拡張を行おうとすると、セキュリティ検証関数V’に変化はないが、図30に示した複数回関数拡張つき保護属性決定処理において無限ループに陥ることになるからである。これを回避するためには、例えば複数回関数拡張つき保護属性決定処理を再帰的に行うことに加え、拡張済みの関数ペアを記憶するテーブル等を用意し、それを元に拡張済みかどうかをチェックすれば良い。また、同じ処理を繰り返し行わないようにするその他の方法を適用しても良い。
[第4の実施の形態]
次に、情報処理装置、プログラム開発システム、プログラム検証方法及びプログラムの第4の実施の形態について説明する。なお、上述の第1の実施の形態乃至第3の実施の形態と共通する部分については、同一の符号を使用して説明したり、説明を省略したりする。
本実施の形態においては、機械語プログラムの生成と開発とを行うシステムについて説明する。上述の第1の実施の形態乃至第3の実施の形態における保護属性決定処理においては、ターゲットプログラムのプログラムリストを解析し、各変数に対して適切な保護属性を決定して付与した。しかし、この決定が適切に行われるためには、ターゲットプログラムのプログラムリストの記述において、セキュリティプロトコルにかかるデータフローが正しく記述されていることが前提である。当然セキュリティプロトコルの仕様自体が機密情報を不用意に漏らしてしまうような欠陥を持たないこともこれ以前の前提として含まれるが、セキュリティプロトコルの仕様自体の安全性検証についてはいくつかの手法が既に知られており、本実施の形態においては実装対象のセキュリティプロトコルが安全性について予め検証済みであることを前提とする。このような技術の例として、以下の参考文献1に形式的手法を用いたプロトコル検証の例が開示されている。本実施の形態では実装対象のセキュリティプロトコルの仕様はこの参考文献1の手法に限定せず、なんらかの安全性検証が予め行われていることを前提とする。
(参考文献1)“Reasoning About Belief in Cryptographic Protocols”Li Gong,Roger Needham,Raphael Yahalom 1990 IEEE Symposium on Security and Privacy,1990
さて、セキュリティプロトコルにかかるデータフローが正しく実装されているかを検証する場合、通常、ターゲットプログラムを実行して入力及び出力が仕様に正しく従うかを判定するいわゆる機能検証が用いられる。一方、本実施の形態においては、変数の保護属性を自動で決定することができるが、適切に保護属性が決定されるためには、プロトコルのデータフローが正しく実装されていることが前提である。よって、プログラマはまず第1段階でデータフローの誤りを排除し、第2段階で、本実施の形態にかかる情報処理装置1により保護属性を自動で決定する。
図35は、本実施の形態にかかる保護属性決定処理を適用したプログラム開発フローである。開発フローは大きく2つに分かれている。1つは、プログラマがデータフローの誤りを排除して機能検証を行うフェーズ1100であり、当該データフローの各変数に対して情報処理装置1が保護属性を自動で決定して実行可能な形式のプログラムを自動的に生成するフェーズ1200とである。フェーズ1100では、プログラマは、セキュリティプロトコルにかかるプログラムの開発を開始して、データフローの正しさに注意してプログラムのプログラムリストを記述する(ステップS1101)。この段階では、プログラマは変数に対して保護属性を付与しないでプログラムのプログラムリストを記述する。ただし、プログラマはデータフローの実装において基本的な変数、例えば、自身の秘密鍵のような信頼の基点(Root of Trust)となる変数については、この時点で適切な保護属性を把握しておくことが一般的であると考えられる。
次にプログラマはコンパイラで当該プログラムの実行形式を生成し(ステップS1102)、それを実行して、機能試験用の入力データに対して所望の出力データが得られるかの機能試験を行う(ステップS1103)。この機能試験に失敗した場合(ステップS1104:NO)、プログラマはデータフローの誤りを修正し(ステップS1151)、ステップS1102〜S1103でコンパイル及び機能試験を再度行い、機能試験の結果が正しくなるまで(ステップS1104:YES)ステップS1151,S1102〜S1103を繰り返す。機能試験用の適切な入力データが与えられていれば、この機能試験の結果が正しくなった段階ではデータフローの誤りは排除されているはずである。次にプログラマは、情報処理装置1に当該プログラムをターゲットプログラムとして入力して、上述の第1の実施の形態乃至第3の実施の形態で説明し図12,29に示した依存関係を考慮した保護属性決定処理を情報処理装置1に行わせる。情報処理装置1への入力として、プログラマがステップS1101の段階において把握している上述のRoot of Trustの保護属性を初期値として与えることもある。そして、保護属性決定処理の結果、保護属性の決定に失敗した場合は(ステップS1202:NO)、セキュリティプロトコルの仕様に従ってデータフローが正しく記述されていても、プログラマが余分な変数やデータフローを実装のために付加してしまったため、機密情報を外部に出力したり漏洩したりている、あるいは保護すべき変数を信用できない入力で汚染してしまうようなプログラムとなっていると考えられる。
一方、保護属性の決定に成功した場合は(ステップS1202:YES)、情報処理装置1は、ターゲットプログラムのプログラムリストを書き換える。上述の第1の実施の形態乃至第3の実施の形態で説明したような関数の拡張を行った場合には、情報処理装置1は、その拡張に応じてプログラムリストを書き換えると共に、各変数に対して自動で決定した保護属性をプログラムリストに付加する(ステップS1203)。図36は、図11に示した擬似プログラムのプログラムリストを書き換えた例を示す図である。同図においては、6行目のパラメータ、及び8〜13行目の変数に保護属性が付加され、15〜23行目では関数の拡張によるセキュリティ検証関数が定義されていることが示されている。この関数の定義部分については、ユーザに見せる必然性はなく、新たなセキュリティ検証関数として別に提供しても良い。最後に、情報処理装置1は、ステップS1203でプログラムリストを書き換えたプログラムをコンパイルする(ステップS1204)。この結果、保護属性に応じて保護メモリ領域又は非保護メモリ領域に適切に記憶させることができる実行可能な形式のプログラムが生成される。
以上のような構成によれば、セキュリティに詳しくないプログラマがセキュリティプロトコルにかかるプログラムを開発したとしても、情報処理装置1が各変数に対して適切な保護属性を自動で付与することが可能である。このため、セキュリティプロトコルにかかるプログラムの開発環境を向上させることができる。
尚、フェーズ1200のうち、ステップS1201〜S1202を情報処理装置1が行い、ステップS1203以降の処理についてはプログラマが行うようにしても良い。
[変形例]
なお、本発明は前記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、前記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示す全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。また、以下に例示するような種々の変形が可能である。
上述した各実施の形態において、情報処理装置1で実行される各種プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成しても良い。また、当該各種プログラムを、インストール可能な形式又は実行可能な形式のファイルでCD−ROM、フレキシブルディスク(FD)、CD−R、DVD(Digital Versatile Disk)等のコンピュータで読み取り可能な記録媒体に記録して提供するように構成しても良い。
上述した各実施の形態においては、図12のステップS4で行う基本保護属性決定処理として、分割された部分データフローに対して逐次的に保護属性を決定しているが、この基本保護属性決定処理の実施の形態はこれに限らない。例えば、データフローを論理式に変換し、それに対して論理式の解導出アルゴリズムを適用することで、保護属性を求める方法も考えられる。論理式への変換方法はNP問題における論理式への変換から容易に推測でき、論理式解導出アルゴリズムも数多く提案されている。
図15に示した部分データフローの例を用いてその概要を説明する。まず、部分データフローに登場する全ての変数及び引数に対して、各保護属性に対応する論理変数を用意する。例えば、図15に示した「buf」であれば、用意する論理変数は「exposed_buf」,「fixed_buf」,・・・,「confidential_buf」のようにすれば良い。次に、論理式を生成する。論理式は、例えば以下の(e)〜(h)すべてを∧ (and を意味する論理記号)で繋げたものにすればよい。
(e)各部分データフローについて、それらの保護属性が同じになるような制約条件を論理式で表現したもの。例えば、図15の部分データフロー番号「1」の部分データフローであれば、
(exposed_#2401_Input(#1) ∧ exposed_buf ∧ exposed_Cipher_From_A ∧exposed_#2212_SKDecrypt(#1) )
∨ (fixed_#2401_Input(#1) ∧ fixed_buf ∧fixed_Cipher_From_A ∧ fixed_#2212_SKDecrypt(#1) )
∨ ・・・
∨ (confidential_#2401_Input(#1) ∧confidential_buf ∧ confidential_Cipher_From_A ∧ confidential_#2212_SKDecrypt(#1))
のようにすれば良い(∨ は or を意味する論理記号)。
(f)各セキュリティ関数の引数に対して、その制約を論理式で表現したもの。例えば共通鍵復号関数「SKDecrypt」の場合は、図5−1,5−2における入出力制約から
(exposed_#2212_SKDecrypt(#1) ∧ confidential_#2212_SKDecrypt(#2) ∧concealed_#2212_SKDecrypt(#3))
∨ (verified_#2212_SKDecrypt(#1) ∧confidential_#2212_SKDecrypt(#2) ∧ confidential_#2212_SKDecrypt(#3))
のようにすれば良い。
(g)各初期値について、該当する保護属性と変数をそのまま表したもの。例えば、関数「Input」の第1引数「#2401_Input(#1)」に付与された保護属性の初期値は「exposed」なので、「exposed_#2401_Input(#1)」を繋げる。
(h)各変数がただ1つの保護属性をもつことを保証するための制約を論理式で表現したもの。例えば「buf」については、「exposed_buf」,「fixed_buf」,・・・,「confidential_buf」のうち、いずれか1つだけが真で、それ以外が偽となるような論理式を生成すれば良く、これは簡単に生成可能である。
以上の手順からなる論理式を論理式の解導出アルゴリズムに入力すると、解が得られる。そして、解のなかで(e)が割り当てられた論理変数を探し、そこから保護属性を決定する。例えば、上の例では「exposed_buf」には「1」が割り当てられるので、「buf」の保護属性が「exposed」に決定される。このとき、「exposed_buf」以外の「buf」に対応する論理変数(「fixed_buf」や「confidential_buf」など)には、すべて「0」が割り当てられることが上述の(g)の条件により保証される。
更に、より効率的な論理式への変換方法や、別の論理式への変換方法も数多く考えられるが、それらは上述から容易に類推可能である。
上述した各実施の形態においては、セキュリティ関数として、公開鍵暗号文復号関数、署名検証関数、共通鍵暗号化関数、共通鍵復号関数及びハッシュ関数を取り扱ったが、これらに限らず、例えば、公開鍵暗号化関数、秘密鍵暗号化関数、共通鍵暗号文復号関数、署名生成関数、前記MAC生成関数、MAC検証関数及び鍵導出関数のうち少なくとも1つを取り扱うようにしても良い。各関数の関数引数保護属性は例えば以下のように定義される。
公開鍵暗号化関数の関数引数保護属性に関し、公開鍵が完全性保護、暗号化対象の入力に係る引数が機密性保護及び暗号化された出力に係る引数が非保護で各々定義され、又は、公開鍵が完全性保護、暗号化対象の入力に係る引数が機密性保護且つ完全性保護及び暗号化された出力に係る引数が完全性保護で各々定義される。
秘密鍵暗号化関数の関数引数保護属性に関し、秘密鍵が機密性保護且つ完全性保護、暗号化対象の入力に係る引数が機密性保護及び暗号化された出力に係る引数が非保護で各々定義され、又は、秘密鍵が機密性保護且つ完全性保護、暗号化対象の入力に係る引数が機密性保護且つ完全性保護及び暗号化された出力に係る引数が完全性保護で各々定義される。
共通鍵暗号文復号関数の関数引数保護属性に関し、復号鍵が機密性且つ完全性保護、復号対象の入力に係る引数が完全性保護及び復号された出力に係る引数が機密性保護且つ完全性保護で各々定義され、又は、復号鍵が機密性保護且つ完全性保護、復号対象の入力に係る引数が非保護及び復号された出力に係る引数が機密性保護で各々定義される。
MAC生成関数の関数引数保護属性に関し、MACの生成鍵が機密性保護且つ完全性保護、生成対象の入力に係る引数が完全性保護及びMACが完全性保護で各々定義され、又は、MACの生成鍵が機密性保護且つ完全性保護、生成対象の入力に係る引数が機密性保護且つ完全性保護、及びMACが機密性保護且つ完全性保護で各々定義される。
MAC検証関数の関数引数保護属性に関し、MACの検証鍵が機密性保護且つ完全性保護、メッセージが機密性保護、MACの入力に係る引数が機密性保護及び検証に成功した場合にメッセージとMACとの2つをコピーした出力に係る引数がそれぞれ共に機密性且つ完全性保護で各々定義され、又は、MACの検証鍵が機密性保護且つ完全性保護、メッセージが非保護、MACの入力に係る引数が非保護及び検証に成功した場合にメッセージとMACとの2つをコピーした出力に係る引数がそれぞれ共に完全性保護で各々定義される。
鍵導出関数の関数引数保護属性に関し、入力に係る引数及び出力に係る引数の保護属性がすべて同一に定義され、入力に係る引数が機密性保護で出力に係る引数が非保護で各々定義され、又は、入力に係る引数が機密性保護且つ完全性保護で出力に係る引数が完全性保護で各々定義される。
また、依存関係については以下の通りに定義される。共通鍵復号関数について、決定項が暗号化された出力と復号鍵とのとき従属項が暗号化対象の入力と定義される。鍵導出関数について、決定項が入力のとき従属項が2つの出力と定義され、又は、決定項が2つの出力のうち一方のとき従属項が入力と2つの出力のうち他方と定義される。MAC検証関数について、MAC検証が成功した場合、決定項が入力とMACのとき従属項が検証鍵と定義され、又は、決定項が検証鍵のときは従属項が入力とMACで定義される。