自己修正計算機コードのチェックサム検証のための方法、装置およびコンピュータ・プログラム担体
【課題】再配置された関数に対するチェックサムの計算を、該関数の詳細を開示することなく可能にする。
【解決手段】ソフトウェア・プログラムの関数２２０が、該ソフトウェア・プログラムのデバイスにおける実行中にメモリ２００Ａ内に記憶される。プロセッサが、前記メモリ２００Ａの、ダミー・コード２３１Ａ、２３２Ａを含む領域Ｒ内で、前記関数２２０を再配置し、前記ダミー・コード２３１Ａ、２３２Ａを予測可能な仕方で変換し、以前のチェックサムに基づいて前記領域Ｒについての予測されたチェックサムを生成し、前記領域Ｒに対する計算されたチェックサムを生成し、前記予測されたチェックサムと前記計算されたチェックサムとを比較することによって前記関数２２０の完全性を検証する。
【解決手段】ソフトウェア・プログラムの関数２２０が、該ソフトウェア・プログラムのデバイスにおける実行中にメモリ２００Ａ内に記憶される。プロセッサが、前記メモリ２００Ａの、ダミー・コード２３１Ａ、２３２Ａを含む領域Ｒ内で、前記関数２２０を再配置し、前記ダミー・コード２３１Ａ、２３２Ａを予測可能な仕方で変換し、以前のチェックサムに基づいて前記領域Ｒについての予測されたチェックサムを生成し、前記領域Ｒに対する計算されたチェックサムを生成し、前記予測されたチェックサムと前記計算されたチェックサムとを比較することによって前記関数２２０の完全性を検証する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概括的にはソフトウェアに、詳細には動的に再配置される（relocated）ソフトウェアの完全性（integrity）を保証することに関する。
【背景技術】
【０００２】
この節は、読者に技術の諸側面を紹介するために意図されている。それらの側面は以下に記載され、特許請求される本発明のさまざまな側面に関係することがありうる。この議論は、読者に、本発明のさまざまな側面のよりよい理解を容易にする背景情報を与える助けになると思われる。よって、これらの陳述はこの観点で読まれるべきであって、従来技術の自認として読まれるべきではないことを理解しておくべきである。
【０００３】
ソフトウェア提供者が、プログラムが意図されたとおりに実行されることを保証することを目標としてコンピュータ・プログラムの完全性を保護することは比較的一般的である。しかしながら、ハッカーは、一般に、プログラムを違った仕方で実行させようとしてハックしようとする。一例として、ハッカーは時に、プログラムを必要なアクセス権なしに使うことができるよう、プログラムのアクセス制御機能を迂回するためにコードを修正することを望む。
【０００４】
保護されたソフトウェアのそのようなリバース・エンジニアリングはいくつかの理由により逐次反復的プロセスである。第一に、アプリケーションは通例、ステップごとに完全に実行するには大きすぎる。第二に、保護機構がリバース活動を検出すると、ハッカーは解析を続けるにはアプリケーションの実行をはじめからやり直さなければならない。ハッカーがある実行から次の実行へと学習することを防止する効率的な手段は、アドレス空間ランダム化である。アドレス空間ランダム化は、既知のアドレスにおいて前に特定された関数に対するブレークポイントの使用を阻む。
【０００５】
現在のところ、アドレス空間ランダム化は主として、バッファ・オーバーフロー攻撃を防止するためにスタックにおけるアドレス空間レイアウト・ランダム化（ASLR: address space layout randomization）のようなコンテキストにおいて使われている。たとえば、ASLRは、リプレイ攻撃に対して耐性をもつために、セクションの位置を予測不可能にする。さらに一ステップ進めて、いくつかのアプリケーションは、コードの一部分をランダムなアドレスに動的に配置し直す。非特許文献１は、コード保護のためにアドレス空間ランダム化を使う異なる方法を提起している。しかしながら、この文献は、コード・セグメントより小さな粒度でランダム化アドレス空間を導入することは不可能であると考えている。
【０００６】
さらに、アドレス空間ランダム化は、コードがメモリ空間内で動くことになるので、ソフトウェア完全性の検証を難しくするという側面もある。
【０００７】
工作しようとする攻撃に対抗するため、コードが修正されていないことを保証するそのような完全性検証技法が使用される。
【０００８】
プログラムの完全性を検証する従来技術の方法は、コードの少なくともいくつかの部分に対してシグネチャ（チェックサムともいう）を計算する。シグネチャはたとえば、コードのそれらの部分に対して計算され、秘密鍵を使って署名されたハッシュ値であってもよい。当業者は、数多くの他の可能性が存在することを理解するであろう。プログラム実行の間、コードのシグネチャは少なくとも一回計算される。セキュリティ・レベルを上げるためには、シグネチャを計算する関数はネストされ、それにより各関数の完全性は少なくとも一つの他の関数によって検証される。このように、ただ一つの関数が無傷で残っていれば、それは少なくとも一つの他の関数についての工作を探知できる。さらなる詳細および説明はたとえば特許文献１および特許文献２に見出すことができ、特許文献３は再配置可能なコードの完全性をどのようにして判別するかを教示している。
【０００９】
残念ながら、完全性検証技法は、ハードウェア・ブレークポイントの使用などのリバース・エンジニアリングに弱い。
【００１０】
ソフトウェア完全性検証もリバース・エンジニアリングに対する有用なツールであるが、アドレス空間ランダム化を使うソフトウェア・プログラムの完全性を保証することが望まれる状況があることは理解されるであろう。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】米国特許出願公開第2003/188231号明細書
【特許文献２】欧州特許出願公開第1942431号明細書
【特許文献３】米国特許出願公開第2002/138748号明細書
【非特許文献】
【００１２】
【非特許文献１】Sandeep Bhatkar, Daniel C. DuVarney, and R. Sekar, 'Address Obfuscation: An Efficient Approach to Combat a Broad Range of Memory Error Exploits', Proceedings of the USENIX Security Symposium, USENIX, 2003
【発明の概要】
【発明が解決しようとする課題】
【００１３】
このように、動的に再配置されるコードの完全性を検査することが問題である。
【００１４】
自明な解決策は、再配置されたコードの範囲を入力パラメータとしてチェックサム関数に渡すことである。セキュリティの観点からは、これは、保護される関数の範囲および参照値をハッカーに対して開示するので、受け容れられるものではない。
【００１５】
よって、再配置された関数に対するチェックサムの計算を、該関数のそのような詳細を開示することなく可能にする解決策が必要とされていることは理解されるであろう。本願はそのような解決策を提供する。
【課題を解決するための手段】
【００１６】
第一の側面では、本発明は、関数コードを、該関数コードを有するソフトウェア・プログラムのデバイスにおける実行中にメモリ内で再配置する方法に向けられる。プロセッサが関数コードを、メモリの、ダミー・コードを有する領域内で再配置し、ダミー・コードを予測可能な仕方で変換し、以前のチェックサムに基づいてその領域についての予測されたチェックサムを生成し、その領域に対する計算されたチェックサムを生成し、予測されたチェックサムと計算されたチェックサムとを比較することによって関数コードの完全性を検証する。
【００１７】
ある好ましい実施形態では、領域についてのチェックサムは、関数コードについてのチェックサムとダミー・コードについてのチェックサムとの組み合わせである。
【００１８】
関数コードが一定のチェックサム値をもって位置独立であることが有利である。また、予測されたチェックサムについての関数コードのチェックサムが再配置テーブルを使って計算されることも有利である。ダミー・コードの変換（transformation）が置換（permutation）を含むことがさらに有利である；好ましくはダミー・コードのチェックサムが変換によって不変であり、好ましくはダミー・コードの変換は所定サイズの諸ブロックとしての置換を含む。また、変換が、ダミー・コードのチェックサムに対する予測可能な効果をもち、線形であることも、代替として有利である。
【００１９】
第二の好ましい実施形態では、ダミー・コードは本物のコードである。
【００２０】
第三の好ましい実施形態では、関数コードはモジュールまたは命令ブロックとして実装される。
【００２１】
第二の好ましい実施形態では、メモリの領域は、やはりチェックサム値が計算されるときに使われるさらなる関数コードおよびさらなるダミー・コードを有する。
【００２２】
第二の側面では、本発明は、ソフトウェア・プログラムの実行および該ソフトウェア・プログラムの実行中のメモリにおける該ソフトウェア・プログラムの関数コードの再配置のためのデバイスに向けられる。本デバイスはメモリおよびプロセッサを有し、該メモリの領域内に関数コードとダミー・コードを記憶する。前記プロセッサは、前記メモリの前記領域内で関数コードを再配置し、ダミー・コードを予測可能な仕方で変換し、以前のチェックサムに基づいてその領域についての予測されたチェックサムを生成し、その領域に対する計算されたチェックサムを生成し、予測されたチェックサムと計算されたチェックサムとを比較することによって関数コードの完全性を検証する。
【００２３】
第三の側面では、本発明は、ソフトウェア・プログラムの命令を記憶しているコンピュータ・プログラム・プロダクトに向けられる。前記命令は、メモリに記憶されてプロセッサによって実行されたときに、本発明の第一の側面の方法を実行する。
【図面の簡単な説明】
【００２４】
本発明の好ましい特徴についてこれから限定しない例として付属の図面を参照しつつ説明する。
【図１】本発明が実装されうる例示的なコンピューティング・デバイスを示す図である。
【図２】本発明のある好ましい実施形態に基づく、再配置可能なコードの完全性検証を示す図である。
【図３】本発明のある好ましい実施形態に基づく、複数の範囲を使ったコード保護のためのさらなる可能性を示す図である。
【図４】本発明のある好ましい実施形態に基づく、保護されたプログラム実行のための方法のフローチャートを示す図である。
【発明を実施するための形態】
【００２５】
図１は、本発明が実装されうる例示的なコンピューティング・デバイス（「コンピュータ」）１００を示している。コンピュータ１００は、標準的なパーソナル・コンピュータ（PC）のような、計算を実行する機能をもつ任意の種類の好適なコンピュータまたは装置であることができる。コンピュータ１００は少なくとも一つのプロセッサ１１０、RAMメモリ１２０、ユーザーと対話するためのユーザー・インターフェース１３０および本発明の方法を実行するためのソフトウェア・プログラムをデジタル・データ担体１５０から読むための第二のインターフェース１４０を有する。当業者は、図示したコンピュータは明確のため非常に簡略化されていること、本物のコンピュータはさらにネットワーク接続および持続的記憶装置といった特徴を有するであろうことを理解するであろう。
【００２６】
図２は、本発明のある好ましい実施形態に基づく自己修正する再配置可能なコードの完全性検証を示している。図２は、二つの異なる時点tAおよびtBにおけるメモリ２００の内容を示している。ここで、tAはtBより前である。tAにおけるメモリは２００Ａと表されており、tBにおけるメモリは２００Ｂと表されているがこれは通常は同じ物理的メモリであることは理解されるであろう。tAは初期状態に対応する、つまり、関数コード〔あるいは機能コード〕をもとの位置にもつのでもよいが、関数コードが少なくとも一回再配置された「再配置された」状態に対応してもよい。
【００２７】
tAにおいて、メモリ２００Ａは呼び出し命令２１０、ダミー・コードをもつ第一の領域２３１Ａ、保護された関数コード２２０およびダミー・コードをもつ第二の領域２３２Ａを有する。ダミー・コードの領域２３１Ａ、２３２Ａおよび保護された関数コード２２０はメモリ中で隣接し合っており、チェックサム範囲（checksum range）として使われる領域Rを形成している。チェックサム検証は、チェックサム関数２６０によって実行される。実行中に、呼び出し命令２１０は保護された関数２２０のアドレスを呼び出す（２４０Ａ）。斜線を付した領域は、本発明の本好ましい実施形態に重要でないメモリ領域――たとえば空のまたは他の関数／機能を記憶しているメモリ領域――を示すことが意図されている。保護された関数２２０はたとえば、モジュール、すなわち命令の（ブロックの）群または一つまたは複数の命令のブロックであってもよい。
【００２８】
tBでは、保護された関数２２０は、メモリ２００Ｂにおいて、第二の、好ましくはランダムな、アドレスに再配置２５０されている。メモリ２００Ｂはさらに、呼び出し命令２１０、ダミー・コードをもつ第一の領域２３１Ｂおよびダミー・コードをもつ第二の領域２３２Ｂを有する。この第二のアドレスは、保護された関数２２０の全体がいまだ領域R内にあり、ダミー・コードの領域２３１Ｂ、２３２Ｂおよび保護された関数コード２２０がメモリ中で隣接し合って領域Rを形成しているようなものである。アドレスの差はジッタJとして示されている。実行中に、呼び出し命令２１０が再配置された保護された関数２２０のアドレス（すなわち第二のアドレス）を呼び出す（２４０Ｂ）。チェックサム検証は、チェックサム関数２６０によって実行される。
【００２９】
ダミー・コードの第一の領域２３１Ａ、２３１Ｂまたはダミー・コードの第二の領域２３２Ａ、２３２Ｂが存在しなくてもよいことは理解されるであろう。これはつまり、保護された関数が領域Rのちょうど先頭から始まる、あるいは領域Rのちょうど末尾で終わるということである。また、保護された関数コード２２０が再配置前と後とで同一であっても、（たとえば関数呼び出しのための調整されたアドレスを有することにより）異なっていてもよいことも理解されるであろう。さらに、呼び出し関数は再配置前と後で同一であっても異なって（変換されて）いてもよいことも理解されるであろう。
【００３０】
このように、ハードウェア・ブレークポイントに基づくリバース・エンジニアリング攻撃は、保護される関数のアドレスのまわりにジッタJを加えることによって対抗される。保護される関数は、ダミー・コードで満たされた領域R内の異なる、好ましくはランダムなアドレスに――規則的に、変化する間隔で、または少なくとも一度――再配置される。二つ以上の領域Rがソフトウェア・プログラムを保護するために使われてもよい。工作防止を保証するために、領域Rはチェックサム関数２６０と組み合わされる。
【００３１】
一つの言い方では、本発明は二つの役者に関わる：チェックサム関数２６０とコード修正エンジンである。
【００３２】
チェックサム関数２６０は好ましくは、保護すべき領域R専用である。領域Rは、保護すべき関数のコードのほかダミー・コードを含む。任意の時点において、Rのチェックサム値は、保護される関数コードが時間的に変化しなければ予測可能であり、一定のチェックサム値をもち、（あるいは変化が予測可能であれば）ダミー・コードは時間的に、予測可能な仕方で変換されて、チェックサム値の決定論的な予測を可能にする。
【００３３】
コード修正エンジンは、好ましくはアプリケーション内に埋め込まれており、（図２に示されるように）領域R内の保護される関数を再配置することによって、保護される関数の呼び出しポイントを新しいシフトされたオフセットにフィックスすることによって、およびダミー・コードを変換することによって、少なくとも保護される関数コードを自動修正する。ダミー・コードの変換は好ましくは、置換を実行し、および可能性としては予測可能な出力を生成する暗号化方法を使ってダミー・コードを暗号化するために第二の関数を使うことを含み、それによりチェックサム値の予測を可能にする。このように、ダミー・コードの完全性値は予測可能な仕方で時間とともに変化する。
【００３４】
ある好ましい実施形態では、保護される関数のチェックサム値は、再配置後でも変化しない。これは、関数が、たとえばコンパイラーのコンパイル・オプション（-fpic）を使って生成されうる位置独立なコードを含む場合に可能である。
【００３５】
位置独立なコードを達成する一つの方法は、たとえば、インポート・アドレス・テーブル（IAT: Import Address Table）中のジャンプ・アドレスを参照することによって、保護される関数１２０の呼び出しを間接的にすることである。このようにして、ジャンプ・アドレスがシフトされても呼び出し命令は変化せず、呼び出し側の保護された命令のチェックサム値は一定となる。
【００３６】
しかしながら、位置独立なコードを得ることが可能でない場合、それでも、再配置された保護された関数のチェックサム値を予測することが可能である。これの欠点は、チェックサム関数がより複雑であり、アプリケーションのバイナリー・ヘッダ（ウィンドウズ（登録商標）についてはセクション.reloc）に埋め込まれた再配置テーブルにアクセスする必要があるということである。この情報を使って、保護される関数の完全性を検証するために使われるチェックサム関数２６０に頼ることなく再配置された関数のチェックサム値を計算することが可能である。
【００３７】
すでに述べたように、保護されたプログラムは複数の保護された領域Rをもってもよい。たとえば、重なり合わない二つの相異なる領域R1およびR2をもつことが可能である。ここで、各領域は、図２を参照して記載したような保護された関数を収容する。
【００３８】
関数は好ましくは、少なくとも一つ（好ましくはちょうど一つ）の入口ポイントと少なくとも一つの出口ポイントを有する一組の命令である。関数が、関数自身がトリビアルでない程度のいくつかの命令を有するが、関数が再配置するのに「重く」なるほど多くはない命令を有することが有利である。
【００３９】
図３は、本発明のある好ましい実施形態に基づく、複数の範囲を使うコード保護のためのもう一つの可能性を示している。メモリ３００は、第一の保護される関数３２１への第一の呼び出し命令３１１および第二の保護される関数３２２への第二の呼び出し命令３１２を有している。各保護される関数３２１、３２２は、ダミー・コード３３１、３３２、３３３、３３４によって囲まれており、各関数３２１、３２２は、それぞれの呼び出し命令３１１、３１２に、保護される関数３２１、３２２のアドレスを呼び出させる（３４１、３４２）ことによって実行される。
【００４０】
見て取れるように、メモリ３００は二つの領域R1およびR2を含んでおり、各領域はチェックサムによって保護される。領域R1は保護された関数３２１および取り囲むダミー・コード３３１、３３２を含む。各領域が異なる関数に対応する先述した実施形態とは異なり、領域R2は領域R1と、第二の保護される関数３２２とその取り囲むダミー・コード３３３、３３４とを含む。領域R1とダミー・コード・エリア３３３との間の斜線を付したエリアは変化しないことが好ましいことは理解されるであろう。変化するとしたら、予測可能な仕方で変化するべきである。最も簡単な解決策は、領域R1と領域R2を隣接させることであるが、もちろん、この斜線を付したエリアが決して触れられないことを保証することも可能である。
【００４１】
このように、チェックサム範囲は、チェックサム範囲が他の領域といかなる部分的交わりももたず、いかなる領域への呼び出しポイントも含まないのである限り、いくつかの領域を含んでいてもよい。これらの要件が満足されないのであれば、完全性値が時間的に一定ではなく、予測不可能である可能性が高い。
【００４２】
チェックサム関数については、チェックサム予測可能性およびチェックサム整列の要件を満足させるよう選ばれることが好ましい。
【００４３】
チェックサム予測可能性（checksum predictability）とは、チェックサム関数が、以前のチェックサム値、すなわち最新の変換の前のチェックサム値から現在のチェックサム値を得ることができるということを意味する。これを表すもう一つの方法は、チェックサム関数は現在のチェックサム値から次のチェックサム値を得ることができるというものである。ある領域のチェックサム値は好ましくは二つのソース：ダミー・コードのチェックサムと保護された関数のチェックサムの組み合わせである。
【００４４】
先述したように、保護された関数が修正なしに再配置されうる――たとえばリナックスの再配置可能コード――場合、そのチェックサムは不変である。これは好ましい特徴である。この場合、チェックサムは再配置前と後で同じままである。しかしながら、保護される関数がチェックサム不変でない場合、チェックサム関数がプログラムの再配置テーブルに頼ってコードに対する再配置の影響を計算し、それによって正しいチェックサム値を生成できることも可能である。
【００４５】
さらに、ダミー・コードのチェックサムは決定論的（deterministic）でなければならない。各変換において、ダミー・コード（M）はE(M)で置き換えられる。n回の変換後、チェックサム値Cは
【数１】
に等しい。C＝En(M)＝n×E0(M)となるような単純な線形変換を選ぶことが可能である。
【００４６】
すると、n回の変換後、
Cn(領域)＝Cn(関数)＋Cn(ダミー・コード)
＝C(関数)＋n×E0(M)
＝A0＋n×B0
ここで、A0はチェックサム不変な保護された関数のチェックサム値であり、B0は初期ダミー・コードのチェックサムである。
【００４７】
よって、領域Rのチェックサム値は、入力nに依存する多項式によって見出しうる。ここで、nは時間にわたる変換の数である。
【００４８】
チェックサム整列（checksum alignment）とは、保護された関数を囲む二つの（あるいは可能性としては一つだけの）ダミー・コード・エリアのチェックサム値が、保護された関数が領域R内のどこに位置されようとも、つまり、保護された関数がダミー・コード・エリアをどのように分割しようとも、一定であることを意味する。これは、ブロックごとにチェックサム関数を選んで分割ジッタ（splitting jitter）Jが単位チェックサム・ブロック・サイズの倍数となるようにすることによって達成されうる。典型的には、４バイトのブロック・サイズに対して作用するチェックサムは、４バイトの倍数であるアドレスをランダムに分割することを許容する。少なくともこの場合においては、関数にパディングして関数の長さが４バイトの倍数となるようにすることが必要であることがありうる。それにより、関数とダミー・コードが領域R全体を占める。
【００４９】
コード修正エンジンは、プログラムの実行中に領域R内部の保護される関数を再配置するよう適応される。これを行うために、コード修正エンジンは、保護された関数が呼び出される呼び出し点を知るべきである。これは、ポスト・ビルド・ツールによって達成されうる。該ポスト・ビルド・ツールは：
コンパイル時において
・プログラムの静的解析を実行して呼び出しグラフ（call graph）および命令ブロックを推定し、
・保護された関数への前記呼び出しグラフ中の呼び出し点（invocation points）を決定し、
・各領域のチェックサム参照値を計算し、
実行時において
コード修正エンジンが保護された関数を再配置するとき、関数への呼び出し命令（呼び出し点）のオフセットをもフィックスするべきである。
【００５０】
典型的には、各変換において、コード修正エンジンは：
・ランダム・オフセットを生成し、
・ランダム・オフセットを使って領域R内部で保護された関数をシフトし、
・特定の変換アルゴリズムを用いて領域R内部のダミー・コードを変換し（本稿ですでに述べたように）、
・保護される関数のすべての呼び出し点のオフセットをランダム・オフセットにフィックスし、
・現在の変換の番号nを、好ましくはセキュアな場所に、記憶する。この番号は、のちにチェックサム・ルーチンによって、ダミー・コードのチェックサム値を計算するために使われうる。
【００５１】
実際上は、変換中に、ダミー・コード、関数またはダミー・コードと関数の両方を一時的に記憶することが、どれかが他のものによって上書きされないことを保証するために必要になることがありうることは理解されるであろう。
【００５２】
チェックサム関数は好ましくはコード修正エンジンとは独立である；チェックサムが計算されるときは常に、それは設計によって不変である。
【００５３】
好ましくは、プログラム中の追加的なスレッドによって複数のチェックサム関数が、ランダムな間隔で、あるいは所定の諸実行ポイントにおいて、呼び出される。
【００５４】
ポスト・ビルド・ツールは、チェックサム検証を可能にするために、（いかなる変換も行う前に）保護された各領域について初期チェックサム値をプログラム中に注入するべきである。
【００５５】
図４は、本発明のある好ましい実施形態に基づく保護されたプログラム実行のための方法のフローチャートを示している。プログラムはステップ４１０において通常通りに実行される。所与の点において、一つまたは複数の保護される関数が、本稿において先述したように、再配置４２０される。次いで、本稿において先述したように、再配置された関数のチェックサムが計算４３０される。チェックサム関数２６０が再配置された関数の完全性を少なくとも一回検証４４０することが好ましい。次いでステップ４１０において「通常」のプログラム実行が再開される。
【００５６】
当業者は、本発明によって保護されるプログラムが自動修正的（auto-modifying）であることを理解するであろう：諸領域の内容は時間にわたって変換され、これが典型的なトランスレーション・ルックアサイド・バッファ（TLB: translation lookaside buffer）攻撃に対して耐性にすることができる。ここでは、ハードウェアが物理アドレスで機能するのに対してプログラムは仮想アドレスを操作する。TLBは、そのようなアドレス間の変換（translation）を許容するテーブルである。
【００５７】
当業者はまた、本発明が関数の開始アドレスに何らかのジッタを加えることをも理解するであろう。これは、関数をハードウェア・ブレークポイントおよびリプレイ攻撃に対して耐性にする。
【００５８】
当業者は、本発明が保護される関数のまわりの何らかのダミー・コードを使うことをも理解するであろう。これは、コードのディスアセンブルに対抗することができる。
【００５９】
当業者はまた、ソフトウェア完全性が内緒である（stealthy）ことができることをも理解するであろう。関数マッピングのランダム化は、ヒープではなく、コードのセクションにおいて起こる。別の実装では、関数を（malloc()で割り当てられたバッファーにおいて）ヒープ中のランダムなアドレスにおいて再配置することも可能であるが、その場合、内緒な仕方で関数の完全性を計算することはより難しくなる。本発明のある好ましい実施形態によれば、保護される領域は他のレガシー・コード内部に挿入され、当該領域の始点および範囲を明示的に述べることなく、当該領域を包含するより大きなエリアに対してチェックサム範囲を適用することが可能になる。
【００６０】
当業者はまた、領域の完全性が決定論的であり、設計により予測可能であることをも理解するであろう。コード修正および完全性属性はリンクしていない。任意の時点でクロスオーバーできる複数のチェックされる範囲をもって完全性を実装することが可能である。というのも、領域の完全性値はたとえランダム化されていても予測可能だからである。
【００６１】
当業者はまた、本稿において使われるところの「ダミー・コード」という表現が、ランダムに生成された無意味コードに近いランダムまたは擬似ランダムなデータであってもよいが、本物の機能コード（たとえばもはや使用されない古いプログラムから取られたもの）であってもよいことをも理解するであろう。ダミー・コードは本物のコードに似ていることが好ましい。そのほうが攻撃者にとってメモリの内容を解析するのが難しいからである。もう一つの見方は、ダミー・コードは、機能コードに対応しない領域中のデータである、つまり非機能データであり、チェックサムは機能コードを含まない領域の部分について生成されるというものである。
【００６２】
本発明が、再配置されたソフトウェア・コードの完全性を検証する方法を提供できることは理解されるであろう。
【００６３】
本記述および（適切な場合には）請求項および図面において開示される各特徴は、独立して設けられても、いかなる適切な組み合わせにおいて設けられてもよい。ハードウェアにおいて実装されると記載されている特徴はソフトウェアにおいて実装されてもよく、逆にソフトウェアにおいて実装されると記載されている特徴はハードウェアにおいて実装されてもよい。請求項に現れる参照符号は単に例示のためであって、請求項の範囲に対する限定する効果はもたない。
【符号の説明】
【００６４】
１００ コンピュータ
１１０ プロセッサ
１２０ メモリ
１３０ ユーザー・インターフェース
１４０ 入出力インターフェース
２００ メモリ
２１０ 呼び出し命令
２２０ 保護された関数コード
２３１ ダミー・コード
２３２ ダミー・コード
２４０ 呼び出し
２５０ ジッタ
２６０ チェックサム関数
３００ メモリ
３１１ 呼び出し命令１
３１２ 呼び出し命令２
３３１ ダミー・コード
３２１ 保護された関数コード１
３２２ 保護された関数コード２
３３２ ダミー・コード
３３３ ダミー・コード
３３４ ダミー・コード
４１０ プログラムを実行
４２０ 保護された関数を再配置
４３０ チェックサムを計算
４４０ 完全性チェック
【技術分野】
【０００１】
本発明は、概括的にはソフトウェアに、詳細には動的に再配置される（relocated）ソフトウェアの完全性（integrity）を保証することに関する。
【背景技術】
【０００２】
この節は、読者に技術の諸側面を紹介するために意図されている。それらの側面は以下に記載され、特許請求される本発明のさまざまな側面に関係することがありうる。この議論は、読者に、本発明のさまざまな側面のよりよい理解を容易にする背景情報を与える助けになると思われる。よって、これらの陳述はこの観点で読まれるべきであって、従来技術の自認として読まれるべきではないことを理解しておくべきである。
【０００３】
ソフトウェア提供者が、プログラムが意図されたとおりに実行されることを保証することを目標としてコンピュータ・プログラムの完全性を保護することは比較的一般的である。しかしながら、ハッカーは、一般に、プログラムを違った仕方で実行させようとしてハックしようとする。一例として、ハッカーは時に、プログラムを必要なアクセス権なしに使うことができるよう、プログラムのアクセス制御機能を迂回するためにコードを修正することを望む。
【０００４】
保護されたソフトウェアのそのようなリバース・エンジニアリングはいくつかの理由により逐次反復的プロセスである。第一に、アプリケーションは通例、ステップごとに完全に実行するには大きすぎる。第二に、保護機構がリバース活動を検出すると、ハッカーは解析を続けるにはアプリケーションの実行をはじめからやり直さなければならない。ハッカーがある実行から次の実行へと学習することを防止する効率的な手段は、アドレス空間ランダム化である。アドレス空間ランダム化は、既知のアドレスにおいて前に特定された関数に対するブレークポイントの使用を阻む。
【０００５】
現在のところ、アドレス空間ランダム化は主として、バッファ・オーバーフロー攻撃を防止するためにスタックにおけるアドレス空間レイアウト・ランダム化（ASLR: address space layout randomization）のようなコンテキストにおいて使われている。たとえば、ASLRは、リプレイ攻撃に対して耐性をもつために、セクションの位置を予測不可能にする。さらに一ステップ進めて、いくつかのアプリケーションは、コードの一部分をランダムなアドレスに動的に配置し直す。非特許文献１は、コード保護のためにアドレス空間ランダム化を使う異なる方法を提起している。しかしながら、この文献は、コード・セグメントより小さな粒度でランダム化アドレス空間を導入することは不可能であると考えている。
【０００６】
さらに、アドレス空間ランダム化は、コードがメモリ空間内で動くことになるので、ソフトウェア完全性の検証を難しくするという側面もある。
【０００７】
工作しようとする攻撃に対抗するため、コードが修正されていないことを保証するそのような完全性検証技法が使用される。
【０００８】
プログラムの完全性を検証する従来技術の方法は、コードの少なくともいくつかの部分に対してシグネチャ（チェックサムともいう）を計算する。シグネチャはたとえば、コードのそれらの部分に対して計算され、秘密鍵を使って署名されたハッシュ値であってもよい。当業者は、数多くの他の可能性が存在することを理解するであろう。プログラム実行の間、コードのシグネチャは少なくとも一回計算される。セキュリティ・レベルを上げるためには、シグネチャを計算する関数はネストされ、それにより各関数の完全性は少なくとも一つの他の関数によって検証される。このように、ただ一つの関数が無傷で残っていれば、それは少なくとも一つの他の関数についての工作を探知できる。さらなる詳細および説明はたとえば特許文献１および特許文献２に見出すことができ、特許文献３は再配置可能なコードの完全性をどのようにして判別するかを教示している。
【０００９】
残念ながら、完全性検証技法は、ハードウェア・ブレークポイントの使用などのリバース・エンジニアリングに弱い。
【００１０】
ソフトウェア完全性検証もリバース・エンジニアリングに対する有用なツールであるが、アドレス空間ランダム化を使うソフトウェア・プログラムの完全性を保証することが望まれる状況があることは理解されるであろう。
【先行技術文献】
【特許文献】
【００１１】
【特許文献１】米国特許出願公開第2003/188231号明細書
【特許文献２】欧州特許出願公開第1942431号明細書
【特許文献３】米国特許出願公開第2002/138748号明細書
【非特許文献】
【００１２】
【非特許文献１】Sandeep Bhatkar, Daniel C. DuVarney, and R. Sekar, 'Address Obfuscation: An Efficient Approach to Combat a Broad Range of Memory Error Exploits', Proceedings of the USENIX Security Symposium, USENIX, 2003
【発明の概要】
【発明が解決しようとする課題】
【００１３】
このように、動的に再配置されるコードの完全性を検査することが問題である。
【００１４】
自明な解決策は、再配置されたコードの範囲を入力パラメータとしてチェックサム関数に渡すことである。セキュリティの観点からは、これは、保護される関数の範囲および参照値をハッカーに対して開示するので、受け容れられるものではない。
【００１５】
よって、再配置された関数に対するチェックサムの計算を、該関数のそのような詳細を開示することなく可能にする解決策が必要とされていることは理解されるであろう。本願はそのような解決策を提供する。
【課題を解決するための手段】
【００１６】
第一の側面では、本発明は、関数コードを、該関数コードを有するソフトウェア・プログラムのデバイスにおける実行中にメモリ内で再配置する方法に向けられる。プロセッサが関数コードを、メモリの、ダミー・コードを有する領域内で再配置し、ダミー・コードを予測可能な仕方で変換し、以前のチェックサムに基づいてその領域についての予測されたチェックサムを生成し、その領域に対する計算されたチェックサムを生成し、予測されたチェックサムと計算されたチェックサムとを比較することによって関数コードの完全性を検証する。
【００１７】
ある好ましい実施形態では、領域についてのチェックサムは、関数コードについてのチェックサムとダミー・コードについてのチェックサムとの組み合わせである。
【００１８】
関数コードが一定のチェックサム値をもって位置独立であることが有利である。また、予測されたチェックサムについての関数コードのチェックサムが再配置テーブルを使って計算されることも有利である。ダミー・コードの変換（transformation）が置換（permutation）を含むことがさらに有利である；好ましくはダミー・コードのチェックサムが変換によって不変であり、好ましくはダミー・コードの変換は所定サイズの諸ブロックとしての置換を含む。また、変換が、ダミー・コードのチェックサムに対する予測可能な効果をもち、線形であることも、代替として有利である。
【００１９】
第二の好ましい実施形態では、ダミー・コードは本物のコードである。
【００２０】
第三の好ましい実施形態では、関数コードはモジュールまたは命令ブロックとして実装される。
【００２１】
第二の好ましい実施形態では、メモリの領域は、やはりチェックサム値が計算されるときに使われるさらなる関数コードおよびさらなるダミー・コードを有する。
【００２２】
第二の側面では、本発明は、ソフトウェア・プログラムの実行および該ソフトウェア・プログラムの実行中のメモリにおける該ソフトウェア・プログラムの関数コードの再配置のためのデバイスに向けられる。本デバイスはメモリおよびプロセッサを有し、該メモリの領域内に関数コードとダミー・コードを記憶する。前記プロセッサは、前記メモリの前記領域内で関数コードを再配置し、ダミー・コードを予測可能な仕方で変換し、以前のチェックサムに基づいてその領域についての予測されたチェックサムを生成し、その領域に対する計算されたチェックサムを生成し、予測されたチェックサムと計算されたチェックサムとを比較することによって関数コードの完全性を検証する。
【００２３】
第三の側面では、本発明は、ソフトウェア・プログラムの命令を記憶しているコンピュータ・プログラム・プロダクトに向けられる。前記命令は、メモリに記憶されてプロセッサによって実行されたときに、本発明の第一の側面の方法を実行する。
【図面の簡単な説明】
【００２４】
本発明の好ましい特徴についてこれから限定しない例として付属の図面を参照しつつ説明する。
【図１】本発明が実装されうる例示的なコンピューティング・デバイスを示す図である。
【図２】本発明のある好ましい実施形態に基づく、再配置可能なコードの完全性検証を示す図である。
【図３】本発明のある好ましい実施形態に基づく、複数の範囲を使ったコード保護のためのさらなる可能性を示す図である。
【図４】本発明のある好ましい実施形態に基づく、保護されたプログラム実行のための方法のフローチャートを示す図である。
【発明を実施するための形態】
【００２５】
図１は、本発明が実装されうる例示的なコンピューティング・デバイス（「コンピュータ」）１００を示している。コンピュータ１００は、標準的なパーソナル・コンピュータ（PC）のような、計算を実行する機能をもつ任意の種類の好適なコンピュータまたは装置であることができる。コンピュータ１００は少なくとも一つのプロセッサ１１０、RAMメモリ１２０、ユーザーと対話するためのユーザー・インターフェース１３０および本発明の方法を実行するためのソフトウェア・プログラムをデジタル・データ担体１５０から読むための第二のインターフェース１４０を有する。当業者は、図示したコンピュータは明確のため非常に簡略化されていること、本物のコンピュータはさらにネットワーク接続および持続的記憶装置といった特徴を有するであろうことを理解するであろう。
【００２６】
図２は、本発明のある好ましい実施形態に基づく自己修正する再配置可能なコードの完全性検証を示している。図２は、二つの異なる時点tAおよびtBにおけるメモリ２００の内容を示している。ここで、tAはtBより前である。tAにおけるメモリは２００Ａと表されており、tBにおけるメモリは２００Ｂと表されているがこれは通常は同じ物理的メモリであることは理解されるであろう。tAは初期状態に対応する、つまり、関数コード〔あるいは機能コード〕をもとの位置にもつのでもよいが、関数コードが少なくとも一回再配置された「再配置された」状態に対応してもよい。
【００２７】
tAにおいて、メモリ２００Ａは呼び出し命令２１０、ダミー・コードをもつ第一の領域２３１Ａ、保護された関数コード２２０およびダミー・コードをもつ第二の領域２３２Ａを有する。ダミー・コードの領域２３１Ａ、２３２Ａおよび保護された関数コード２２０はメモリ中で隣接し合っており、チェックサム範囲（checksum range）として使われる領域Rを形成している。チェックサム検証は、チェックサム関数２６０によって実行される。実行中に、呼び出し命令２１０は保護された関数２２０のアドレスを呼び出す（２４０Ａ）。斜線を付した領域は、本発明の本好ましい実施形態に重要でないメモリ領域――たとえば空のまたは他の関数／機能を記憶しているメモリ領域――を示すことが意図されている。保護された関数２２０はたとえば、モジュール、すなわち命令の（ブロックの）群または一つまたは複数の命令のブロックであってもよい。
【００２８】
tBでは、保護された関数２２０は、メモリ２００Ｂにおいて、第二の、好ましくはランダムな、アドレスに再配置２５０されている。メモリ２００Ｂはさらに、呼び出し命令２１０、ダミー・コードをもつ第一の領域２３１Ｂおよびダミー・コードをもつ第二の領域２３２Ｂを有する。この第二のアドレスは、保護された関数２２０の全体がいまだ領域R内にあり、ダミー・コードの領域２３１Ｂ、２３２Ｂおよび保護された関数コード２２０がメモリ中で隣接し合って領域Rを形成しているようなものである。アドレスの差はジッタJとして示されている。実行中に、呼び出し命令２１０が再配置された保護された関数２２０のアドレス（すなわち第二のアドレス）を呼び出す（２４０Ｂ）。チェックサム検証は、チェックサム関数２６０によって実行される。
【００２９】
ダミー・コードの第一の領域２３１Ａ、２３１Ｂまたはダミー・コードの第二の領域２３２Ａ、２３２Ｂが存在しなくてもよいことは理解されるであろう。これはつまり、保護された関数が領域Rのちょうど先頭から始まる、あるいは領域Rのちょうど末尾で終わるということである。また、保護された関数コード２２０が再配置前と後とで同一であっても、（たとえば関数呼び出しのための調整されたアドレスを有することにより）異なっていてもよいことも理解されるであろう。さらに、呼び出し関数は再配置前と後で同一であっても異なって（変換されて）いてもよいことも理解されるであろう。
【００３０】
このように、ハードウェア・ブレークポイントに基づくリバース・エンジニアリング攻撃は、保護される関数のアドレスのまわりにジッタJを加えることによって対抗される。保護される関数は、ダミー・コードで満たされた領域R内の異なる、好ましくはランダムなアドレスに――規則的に、変化する間隔で、または少なくとも一度――再配置される。二つ以上の領域Rがソフトウェア・プログラムを保護するために使われてもよい。工作防止を保証するために、領域Rはチェックサム関数２６０と組み合わされる。
【００３１】
一つの言い方では、本発明は二つの役者に関わる：チェックサム関数２６０とコード修正エンジンである。
【００３２】
チェックサム関数２６０は好ましくは、保護すべき領域R専用である。領域Rは、保護すべき関数のコードのほかダミー・コードを含む。任意の時点において、Rのチェックサム値は、保護される関数コードが時間的に変化しなければ予測可能であり、一定のチェックサム値をもち、（あるいは変化が予測可能であれば）ダミー・コードは時間的に、予測可能な仕方で変換されて、チェックサム値の決定論的な予測を可能にする。
【００３３】
コード修正エンジンは、好ましくはアプリケーション内に埋め込まれており、（図２に示されるように）領域R内の保護される関数を再配置することによって、保護される関数の呼び出しポイントを新しいシフトされたオフセットにフィックスすることによって、およびダミー・コードを変換することによって、少なくとも保護される関数コードを自動修正する。ダミー・コードの変換は好ましくは、置換を実行し、および可能性としては予測可能な出力を生成する暗号化方法を使ってダミー・コードを暗号化するために第二の関数を使うことを含み、それによりチェックサム値の予測を可能にする。このように、ダミー・コードの完全性値は予測可能な仕方で時間とともに変化する。
【００３４】
ある好ましい実施形態では、保護される関数のチェックサム値は、再配置後でも変化しない。これは、関数が、たとえばコンパイラーのコンパイル・オプション（-fpic）を使って生成されうる位置独立なコードを含む場合に可能である。
【００３５】
位置独立なコードを達成する一つの方法は、たとえば、インポート・アドレス・テーブル（IAT: Import Address Table）中のジャンプ・アドレスを参照することによって、保護される関数１２０の呼び出しを間接的にすることである。このようにして、ジャンプ・アドレスがシフトされても呼び出し命令は変化せず、呼び出し側の保護された命令のチェックサム値は一定となる。
【００３６】
しかしながら、位置独立なコードを得ることが可能でない場合、それでも、再配置された保護された関数のチェックサム値を予測することが可能である。これの欠点は、チェックサム関数がより複雑であり、アプリケーションのバイナリー・ヘッダ（ウィンドウズ（登録商標）についてはセクション.reloc）に埋め込まれた再配置テーブルにアクセスする必要があるということである。この情報を使って、保護される関数の完全性を検証するために使われるチェックサム関数２６０に頼ることなく再配置された関数のチェックサム値を計算することが可能である。
【００３７】
すでに述べたように、保護されたプログラムは複数の保護された領域Rをもってもよい。たとえば、重なり合わない二つの相異なる領域R1およびR2をもつことが可能である。ここで、各領域は、図２を参照して記載したような保護された関数を収容する。
【００３８】
関数は好ましくは、少なくとも一つ（好ましくはちょうど一つ）の入口ポイントと少なくとも一つの出口ポイントを有する一組の命令である。関数が、関数自身がトリビアルでない程度のいくつかの命令を有するが、関数が再配置するのに「重く」なるほど多くはない命令を有することが有利である。
【００３９】
図３は、本発明のある好ましい実施形態に基づく、複数の範囲を使うコード保護のためのもう一つの可能性を示している。メモリ３００は、第一の保護される関数３２１への第一の呼び出し命令３１１および第二の保護される関数３２２への第二の呼び出し命令３１２を有している。各保護される関数３２１、３２２は、ダミー・コード３３１、３３２、３３３、３３４によって囲まれており、各関数３２１、３２２は、それぞれの呼び出し命令３１１、３１２に、保護される関数３２１、３２２のアドレスを呼び出させる（３４１、３４２）ことによって実行される。
【００４０】
見て取れるように、メモリ３００は二つの領域R1およびR2を含んでおり、各領域はチェックサムによって保護される。領域R1は保護された関数３２１および取り囲むダミー・コード３３１、３３２を含む。各領域が異なる関数に対応する先述した実施形態とは異なり、領域R2は領域R1と、第二の保護される関数３２２とその取り囲むダミー・コード３３３、３３４とを含む。領域R1とダミー・コード・エリア３３３との間の斜線を付したエリアは変化しないことが好ましいことは理解されるであろう。変化するとしたら、予測可能な仕方で変化するべきである。最も簡単な解決策は、領域R1と領域R2を隣接させることであるが、もちろん、この斜線を付したエリアが決して触れられないことを保証することも可能である。
【００４１】
このように、チェックサム範囲は、チェックサム範囲が他の領域といかなる部分的交わりももたず、いかなる領域への呼び出しポイントも含まないのである限り、いくつかの領域を含んでいてもよい。これらの要件が満足されないのであれば、完全性値が時間的に一定ではなく、予測不可能である可能性が高い。
【００４２】
チェックサム関数については、チェックサム予測可能性およびチェックサム整列の要件を満足させるよう選ばれることが好ましい。
【００４３】
チェックサム予測可能性（checksum predictability）とは、チェックサム関数が、以前のチェックサム値、すなわち最新の変換の前のチェックサム値から現在のチェックサム値を得ることができるということを意味する。これを表すもう一つの方法は、チェックサム関数は現在のチェックサム値から次のチェックサム値を得ることができるというものである。ある領域のチェックサム値は好ましくは二つのソース：ダミー・コードのチェックサムと保護された関数のチェックサムの組み合わせである。
【００４４】
先述したように、保護された関数が修正なしに再配置されうる――たとえばリナックスの再配置可能コード――場合、そのチェックサムは不変である。これは好ましい特徴である。この場合、チェックサムは再配置前と後で同じままである。しかしながら、保護される関数がチェックサム不変でない場合、チェックサム関数がプログラムの再配置テーブルに頼ってコードに対する再配置の影響を計算し、それによって正しいチェックサム値を生成できることも可能である。
【００４５】
さらに、ダミー・コードのチェックサムは決定論的（deterministic）でなければならない。各変換において、ダミー・コード（M）はE(M)で置き換えられる。n回の変換後、チェックサム値Cは
【数１】
に等しい。C＝En(M)＝n×E0(M)となるような単純な線形変換を選ぶことが可能である。
【００４６】
すると、n回の変換後、
Cn(領域)＝Cn(関数)＋Cn(ダミー・コード)
＝C(関数)＋n×E0(M)
＝A0＋n×B0
ここで、A0はチェックサム不変な保護された関数のチェックサム値であり、B0は初期ダミー・コードのチェックサムである。
【００４７】
よって、領域Rのチェックサム値は、入力nに依存する多項式によって見出しうる。ここで、nは時間にわたる変換の数である。
【００４８】
チェックサム整列（checksum alignment）とは、保護された関数を囲む二つの（あるいは可能性としては一つだけの）ダミー・コード・エリアのチェックサム値が、保護された関数が領域R内のどこに位置されようとも、つまり、保護された関数がダミー・コード・エリアをどのように分割しようとも、一定であることを意味する。これは、ブロックごとにチェックサム関数を選んで分割ジッタ（splitting jitter）Jが単位チェックサム・ブロック・サイズの倍数となるようにすることによって達成されうる。典型的には、４バイトのブロック・サイズに対して作用するチェックサムは、４バイトの倍数であるアドレスをランダムに分割することを許容する。少なくともこの場合においては、関数にパディングして関数の長さが４バイトの倍数となるようにすることが必要であることがありうる。それにより、関数とダミー・コードが領域R全体を占める。
【００４９】
コード修正エンジンは、プログラムの実行中に領域R内部の保護される関数を再配置するよう適応される。これを行うために、コード修正エンジンは、保護された関数が呼び出される呼び出し点を知るべきである。これは、ポスト・ビルド・ツールによって達成されうる。該ポスト・ビルド・ツールは：
コンパイル時において
・プログラムの静的解析を実行して呼び出しグラフ（call graph）および命令ブロックを推定し、
・保護された関数への前記呼び出しグラフ中の呼び出し点（invocation points）を決定し、
・各領域のチェックサム参照値を計算し、
実行時において
コード修正エンジンが保護された関数を再配置するとき、関数への呼び出し命令（呼び出し点）のオフセットをもフィックスするべきである。
【００５０】
典型的には、各変換において、コード修正エンジンは：
・ランダム・オフセットを生成し、
・ランダム・オフセットを使って領域R内部で保護された関数をシフトし、
・特定の変換アルゴリズムを用いて領域R内部のダミー・コードを変換し（本稿ですでに述べたように）、
・保護される関数のすべての呼び出し点のオフセットをランダム・オフセットにフィックスし、
・現在の変換の番号nを、好ましくはセキュアな場所に、記憶する。この番号は、のちにチェックサム・ルーチンによって、ダミー・コードのチェックサム値を計算するために使われうる。
【００５１】
実際上は、変換中に、ダミー・コード、関数またはダミー・コードと関数の両方を一時的に記憶することが、どれかが他のものによって上書きされないことを保証するために必要になることがありうることは理解されるであろう。
【００５２】
チェックサム関数は好ましくはコード修正エンジンとは独立である；チェックサムが計算されるときは常に、それは設計によって不変である。
【００５３】
好ましくは、プログラム中の追加的なスレッドによって複数のチェックサム関数が、ランダムな間隔で、あるいは所定の諸実行ポイントにおいて、呼び出される。
【００５４】
ポスト・ビルド・ツールは、チェックサム検証を可能にするために、（いかなる変換も行う前に）保護された各領域について初期チェックサム値をプログラム中に注入するべきである。
【００５５】
図４は、本発明のある好ましい実施形態に基づく保護されたプログラム実行のための方法のフローチャートを示している。プログラムはステップ４１０において通常通りに実行される。所与の点において、一つまたは複数の保護される関数が、本稿において先述したように、再配置４２０される。次いで、本稿において先述したように、再配置された関数のチェックサムが計算４３０される。チェックサム関数２６０が再配置された関数の完全性を少なくとも一回検証４４０することが好ましい。次いでステップ４１０において「通常」のプログラム実行が再開される。
【００５６】
当業者は、本発明によって保護されるプログラムが自動修正的（auto-modifying）であることを理解するであろう：諸領域の内容は時間にわたって変換され、これが典型的なトランスレーション・ルックアサイド・バッファ（TLB: translation lookaside buffer）攻撃に対して耐性にすることができる。ここでは、ハードウェアが物理アドレスで機能するのに対してプログラムは仮想アドレスを操作する。TLBは、そのようなアドレス間の変換（translation）を許容するテーブルである。
【００５７】
当業者はまた、本発明が関数の開始アドレスに何らかのジッタを加えることをも理解するであろう。これは、関数をハードウェア・ブレークポイントおよびリプレイ攻撃に対して耐性にする。
【００５８】
当業者は、本発明が保護される関数のまわりの何らかのダミー・コードを使うことをも理解するであろう。これは、コードのディスアセンブルに対抗することができる。
【００５９】
当業者はまた、ソフトウェア完全性が内緒である（stealthy）ことができることをも理解するであろう。関数マッピングのランダム化は、ヒープではなく、コードのセクションにおいて起こる。別の実装では、関数を（malloc()で割り当てられたバッファーにおいて）ヒープ中のランダムなアドレスにおいて再配置することも可能であるが、その場合、内緒な仕方で関数の完全性を計算することはより難しくなる。本発明のある好ましい実施形態によれば、保護される領域は他のレガシー・コード内部に挿入され、当該領域の始点および範囲を明示的に述べることなく、当該領域を包含するより大きなエリアに対してチェックサム範囲を適用することが可能になる。
【００６０】
当業者はまた、領域の完全性が決定論的であり、設計により予測可能であることをも理解するであろう。コード修正および完全性属性はリンクしていない。任意の時点でクロスオーバーできる複数のチェックされる範囲をもって完全性を実装することが可能である。というのも、領域の完全性値はたとえランダム化されていても予測可能だからである。
【００６１】
当業者はまた、本稿において使われるところの「ダミー・コード」という表現が、ランダムに生成された無意味コードに近いランダムまたは擬似ランダムなデータであってもよいが、本物の機能コード（たとえばもはや使用されない古いプログラムから取られたもの）であってもよいことをも理解するであろう。ダミー・コードは本物のコードに似ていることが好ましい。そのほうが攻撃者にとってメモリの内容を解析するのが難しいからである。もう一つの見方は、ダミー・コードは、機能コードに対応しない領域中のデータである、つまり非機能データであり、チェックサムは機能コードを含まない領域の部分について生成されるというものである。
【００６２】
本発明が、再配置されたソフトウェア・コードの完全性を検証する方法を提供できることは理解されるであろう。
【００６３】
本記述および（適切な場合には）請求項および図面において開示される各特徴は、独立して設けられても、いかなる適切な組み合わせにおいて設けられてもよい。ハードウェアにおいて実装されると記載されている特徴はソフトウェアにおいて実装されてもよく、逆にソフトウェアにおいて実装されると記載されている特徴はハードウェアにおいて実装されてもよい。請求項に現れる参照符号は単に例示のためであって、請求項の範囲に対する限定する効果はもたない。
【符号の説明】
【００６４】
１００ コンピュータ
１１０ プロセッサ
１２０ メモリ
１３０ ユーザー・インターフェース
１４０ 入出力インターフェース
２００ メモリ
２１０ 呼び出し命令
２２０ 保護された関数コード
２３１ ダミー・コード
２３２ ダミー・コード
２４０ 呼び出し
２５０ ジッタ
２６０ チェックサム関数
３００ メモリ
３１１ 呼び出し命令１
３１２ 呼び出し命令２
３３１ ダミー・コード
３２１ 保護された関数コード１
３２２ 保護された関数コード２
３３２ ダミー・コード
３３３ ダミー・コード
３３４ ダミー・コード
４１０ プログラムを実行
４２０ 保護された関数を再配置
４３０ チェックサムを計算
４４０ 完全性チェック
【特許請求の範囲】
【請求項１】
関数コードを、該関数コードを有するソフトウェア・プログラムのデバイスにおける実行中にメモリ内で再配置する方法であって：
・前記関数コードを、前記メモリの、ダミー・コードを有する領域内で再配置する段階と；
・前記ダミー・コードを予測可能な仕方で変換する段階と；
・以前のチェックサムに基づいて前記領域についての予測されたチェックサムを生成する段階と；
・前記領域に対する計算されたチェックサムを生成する段階と；
・前記予測されたチェックサムと前記計算されたチェックサムとを比較することによって前記関数コードの完全性を検証する段階とを含む、
方法。
【請求項２】
前記領域についての前記チェックサムは、前記関数コードについてのチェックサムと前記ダミー・コードについてのチェックサムとの組み合わせである、請求項１記載の方法。
【請求項３】
前記関数コードが一定のチェックサム値をもって位置独立である、請求項２記載の方法。
【請求項４】
前記予測されたチェックサムについての前記関数コードの前記チェックサムが再配置テーブルを使って計算される、請求項２記載の方法。
【請求項５】
前記ダミー・コードの前記変換が置換を含む、請求項２記載の方法。
【請求項６】
前記ダミー・コードの前記チェックサムが前記変換によって不変である、請求項５記載の方法。
【請求項７】
前記ダミー・コードの前記変換は所定サイズの諸ブロックとしての置換を含む、請求項５記載の方法。
【請求項８】
前記変換が、前記ダミー・コードの前記チェックサムに対する予測可能な効果をもち、線形である、請求項２記載の方法。
【請求項９】
前記メモリの前記領域が、やはりチェックサム値が計算されるときに使われるさらなる関数コードおよびさらなるダミー・コードを有する、請求項１記載の方法。
【請求項１０】
前記ダミー・コードが本物のコードである、請求項１記載の方法。
【請求項１１】
前記関数コードがモジュールまたは命令ブロックとして実装される、請求項１記載の方法。
【請求項１２】
ソフトウェア・プログラムの実行および該ソフトウェア・プログラムの実行中のメモリにおける該ソフトウェア・プログラムの関数コードの再配置のためのデバイスであって：
メモリおよびプロセッサを有し、前記メモリは前記メモリのある領域内に関数コードおよびダミー・コードを記憶し、
前記プロセッサは、
・前記メモリの前記領域内で前記関数コードを再配置し、
・前記ダミー・コードを予測可能な仕方で変換し、
・以前のチェックサムに基づいて前記領域についての予測されたチェックサムを生成し、
・前記領域に対する計算されたチェックサムを生成し、
・前記予測されたチェックサムと前記計算されたチェックサムとを比較することによって前記関数コードの完全性を検証する、
デバイス。
【請求項１３】
ソフトウェア・プログラムの命令を記憶しているコンピュータ・プログラム・プロダクトであって、前記命令は、メモリに記憶されてプロセッサによって実行されたときに、
・前記ソフトウェア・プログラムの関数コードを、前記メモリの、ダミー・コードを有する領域内で再配置する段階と；
・前記ダミー・コードを予測可能な仕方で変換する段階と；
・以前のチェックサムに基づいて前記領域についての予測されたチェックサムを生成する段階と；
・前記領域に対する計算されたチェックサムを生成する段階と；
・前記予測されたチェックサムと前記計算されたチェックサムとを比較することによって前記関数コードの完全性を検証する段階と実行する、
コンピュータ・プログラム・プロダクト。
【請求項１】
関数コードを、該関数コードを有するソフトウェア・プログラムのデバイスにおける実行中にメモリ内で再配置する方法であって：
・前記関数コードを、前記メモリの、ダミー・コードを有する領域内で再配置する段階と；
・前記ダミー・コードを予測可能な仕方で変換する段階と；
・以前のチェックサムに基づいて前記領域についての予測されたチェックサムを生成する段階と；
・前記領域に対する計算されたチェックサムを生成する段階と；
・前記予測されたチェックサムと前記計算されたチェックサムとを比較することによって前記関数コードの完全性を検証する段階とを含む、
方法。
【請求項２】
前記領域についての前記チェックサムは、前記関数コードについてのチェックサムと前記ダミー・コードについてのチェックサムとの組み合わせである、請求項１記載の方法。
【請求項３】
前記関数コードが一定のチェックサム値をもって位置独立である、請求項２記載の方法。
【請求項４】
前記予測されたチェックサムについての前記関数コードの前記チェックサムが再配置テーブルを使って計算される、請求項２記載の方法。
【請求項５】
前記ダミー・コードの前記変換が置換を含む、請求項２記載の方法。
【請求項６】
前記ダミー・コードの前記チェックサムが前記変換によって不変である、請求項５記載の方法。
【請求項７】
前記ダミー・コードの前記変換は所定サイズの諸ブロックとしての置換を含む、請求項５記載の方法。
【請求項８】
前記変換が、前記ダミー・コードの前記チェックサムに対する予測可能な効果をもち、線形である、請求項２記載の方法。
【請求項９】
前記メモリの前記領域が、やはりチェックサム値が計算されるときに使われるさらなる関数コードおよびさらなるダミー・コードを有する、請求項１記載の方法。
【請求項１０】
前記ダミー・コードが本物のコードである、請求項１記載の方法。
【請求項１１】
前記関数コードがモジュールまたは命令ブロックとして実装される、請求項１記載の方法。
【請求項１２】
ソフトウェア・プログラムの実行および該ソフトウェア・プログラムの実行中のメモリにおける該ソフトウェア・プログラムの関数コードの再配置のためのデバイスであって：
メモリおよびプロセッサを有し、前記メモリは前記メモリのある領域内に関数コードおよびダミー・コードを記憶し、
前記プロセッサは、
・前記メモリの前記領域内で前記関数コードを再配置し、
・前記ダミー・コードを予測可能な仕方で変換し、
・以前のチェックサムに基づいて前記領域についての予測されたチェックサムを生成し、
・前記領域に対する計算されたチェックサムを生成し、
・前記予測されたチェックサムと前記計算されたチェックサムとを比較することによって前記関数コードの完全性を検証する、
デバイス。
【請求項１３】
ソフトウェア・プログラムの命令を記憶しているコンピュータ・プログラム・プロダクトであって、前記命令は、メモリに記憶されてプロセッサによって実行されたときに、
・前記ソフトウェア・プログラムの関数コードを、前記メモリの、ダミー・コードを有する領域内で再配置する段階と；
・前記ダミー・コードを予測可能な仕方で変換する段階と；
・以前のチェックサムに基づいて前記領域についての予測されたチェックサムを生成する段階と；
・前記領域に対する計算されたチェックサムを生成する段階と；
・前記予測されたチェックサムと前記計算されたチェックサムとを比較することによって前記関数コードの完全性を検証する段階と実行する、
コンピュータ・プログラム・プロダクト。
【図１】
【図２】
【図３】
【図４】
【図２】
【図３】
【図４】
【公開番号】特開２０１１−２２７８９７（Ｐ２０１１−２２７８９７Ａ）
【公開日】平成２３年１１月１０日（２０１１．１１．１０）
【国際特許分類】
【外国語出願】
【出願番号】特願２０１１−９０５３８（Ｐ２０１１−９０５３８）
【出願日】平成２３年４月１５日（２０１１．４．１５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．リナックス
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
【公開日】平成２３年１１月１０日（２０１１．１１．１０）
【国際特許分類】
【出願番号】特願２０１１−９０５３８（Ｐ２０１１−９０５３８）
【出願日】平成２３年４月１５日（２０１１．４．１５）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．リナックス
【出願人】（５０１２６３８１０）トムソン ライセンシング (2,848)
【氏名又は名称原語表記】Ｔｈｏｍｓｏｎ Ｌｉｃｅｎｓｉｎｇ
【住所又は居所原語表記】１−５， ｒｕｅ Ｊｅａｎｎｅ ｄ’Ａｒｃ， ９２１３０ ＩＳＳＹ ＬＥＳ ＭＯＵＬＩＮＥＡＵＸ， Ｆｒａｎｃｅ
【Ｆターム（参考）】
[ Back to top ]