JP2010508567A - コンピューティングデバイスにおけるマルウェアの無効化 - Google Patents

Abstract

コンピューティングデバイスは、これからロードされるソフトウェアアプリケーションに係る認証の証明書が失効されたか否かを決定する改良チェックを実施する方法を備え、動作する。失効情報を含まない信頼できる一連の証明書の場合、このデバイスは、デバイスが選択したＡＩＡ（Authority Info Access）エクステンションを用いてチェックする。特に自己署名の証明書を含む信頼できない一連の証明書の場合、このデバイスはソフトウェアアプリケーションに備えられた全ての認証失効情報を無視し、常にこのデバイスに格納された情報を用いるように制御される。

Description

本発明は、コンピューティングデバイスにおけるマルウェアを無効にさせる改善された方法に関する。特に、悪意のある、または安全でないソフトウェアのインストレーションを検出して避けることができる、マルウェア無効化の改善された方法に関する。

「コンピューティングデバイス」と言う用語は、制限なく、デスクトップやラップトップコンピュータ、パーソナルデジタルアシスタント（ＰＤＡ）、携帯電話、スマートフォン、デジタルカメラおよびデジタルミュージックプレーヤを含んでいる。またこの単語は、その他多くの工業用および家庭用電子機器を一緒にした、これらの種別の機器の１つ以上からなる機能を組み込む装置も含んでいる。

コンピューティングデバイスを用いると、購入後にユーザがソフトウェアをインストールでき、新しいソフトウェアが利用可能、または新しい機能が提供される、このコンピューティングデバイスを、オープンデバイスと定義する。

この方法で、デバイスの有用性を広げるというはっきりとした利益があるが、この容易さによりデバイスのオーナまたはユーザは大きなセキュリティリスクを被っている。当業者やこの分野にそれほど詳しくない人も、ひどい記載のプログラム、あるいは悪意のあるプログラム（マルウェア）がオープンコンピューティングデバイスに影響を与えるという大きなリスクのあることに気付いている。ネットワーク上で、このコンピューティングデバイスが他のデバイスと接続されると、このリスクはこのネットワークに接続された他のあらゆるデバイスに広がり得る。そして、ネットワーク自体の保全性をも脅かすことになる。このようなマルウェアには、多くの種類がある。すなわち、一般のタイプとして、ウィルス、トロイの木馬（trojan）、スパイウェアやアドウェアなど、無制限にある。

オープンコンピューティングデバイスに含まれる様々なタイプのマルウェアの検出、予防および失効をユーザに提供するソフトウェアパッケージがたくさん出回っている。アンチウィルスソフトウェアは、数１０億ドルの市場となっている。しかし、一般的に当業者に理解されているように、もし実現可能なら、まずはマルフェアに感染することを防ぐ方が良い。

あらゆるオープンコンピューティングデバイスに対して感染を防ぐのに鍵となる原理の１つに、ソフトウェアのアイテムを全て点検することがある。ここでソフトウェアは、次のような過程を経てインストールされる。
ａ）ソフトウェアの同一性を認証し、ソフトウェアがマルウェアでなく、真正のソフトウェアを提供する信頼されたソースを起源とすることを裏付ける。
ｂ）ソフトウェアが、その信頼されたソースを離れ、エンドユーザに渡されデバイスにロードされるまでの期間に、どんなタイプのマルウェアにも改ざんを受けたり、感染を受けたりすることがなかったことを確かめる。

変更検出を保証する方法の１つとして、インストールすべきパッケージのハッシュまたはダイジェストを、そのパッケージの信頼された著者または販売業者により刊行された類似のハッシュと比較することがある。インターネット標準ＲＦＣ１３２１に記載されているこの保証を提供する標準的方法の１つは、ロナルド・リベスト（Ronald Rivest）のＭＤ５であった。もう１つの標準的方法は、米国安全保障局（US National Security Agency）により刊行されたＳＨＡアルゴリズムである。しかし、これらの方法の保全性は、有効として信頼されるこの刊行されたハッシュが、実際は、それ自体が感染にさらされ得ないソースに基づいている、という保証に依存する。

感染検出のこれに代わるもう１つの方法として、悪いと周知されたパッケージのハッシュの信頼できるリストとパッケージのハッシュとを比較することがある。しかし、この解決法は、以下の理由から不十分なものである。
−この方法は、実際、予防策というより、受身的な策である。
−この方法は、あまりにも簡単に回避し過ぎている。なぜなら、マルウェアの作者は、必ず異なるハッシュが計算されるようにデータの僅少部分をランダムに変化させている。この変化により、簡単にパッケージの明瞭な同一性を変化させて、この信頼されるリストと比較すると許容できる結果を導いてしまう。

以上の後者の理由からわかるのは、実際上は、変更検出のための技術が、この完全性を保証する同一性を証明することに依存しているという結論に導かれる。

ソフトウェアのアイテムの完全性を証明し、有効とする最も周知された技術は、鍵（キー）要素として、非対称または公開鍵（公開鍵）の暗号を用いた署名および証明書に依存している。公開鍵基盤（public key infrastructure、以下ＰＫＩと言う）に関するＩＴＵ-Ｔ Ｘ．５０９標準は、この方法を規定する１つの例である。インストールすべきソフトウェアの全アイテムに対する認証に適用されるこの技術は、概略、次のように実行される。

１．公共の場で利用できるようになったコンピューティングデバイスのためのソフトウェアアプリケーションは、そのソフトウェアの著者、開発者あるいは販売者によりデジタル署名された第１インスタンス内にあるパッケージにコンパイルされ、これには、公開鍵とコンテンツの保全ハッシュの両方が埋め込まれる。そして、著者、開発者あるいは販売者は、このパッケージを信頼できるパーティへ送ることで、認証機関（Certification Authority、以下「ＣＡ」と言う）を制定できる。

２．ＣＡはパッケージに再び署名することで、パッケージの第１の署名が、ＣＡによって信頼できる然るべき人間であることを示す。理想的には、ソフトウェアアプリケーションは、ＣＡによって、診断、試験あるいはチェックされ、ソフトウェアは、記述に不具合や悪意のないことが保証される。次に、再び署名されたパッケージは、元の著者、開発者あるいは販売者に戻され、公共の場で販売することができるようになる。

３．Ｘ．５０９ ＰＫＩ の方法の長所によりコンピューティングデバイスは、ＣＡによるデジタル証明書（ルート証明書）が供与される。この証明書は、このデバイスのファームウェアの中で供与されるか、あるいはブラウザのようなネットワークアプリケーションにより供与される。
コンピューティングデバイスのユーザは、このソフトウェアのインストーラへインストールを要求すると、インストーラは、ソフトウェアの識別、およびその著者を確認し、また何かに感染していないかを検出するためにソフトウェアに埋め込まれた証明書を検査する。このコンピューティングデバイスは、既にルート証明書を含んでいるので、インストーラはこれを参照してパッケージの同一性および完全性を確認する。そして、ソフトウェアアプリケーションは、これが真正のアプリケーションであるという高次の保証を付けてコンピューティングデバイスにインストールされる。

Ｘ．５０９ ＰＫＩ に使用された一連の認証は、この例で説明されたものよりも一般的に長いが、その原理は同じであり、署名された一連の証明書に従って信頼できるＣＡに最後に戻る。

パッケージの署名の全てが、以上述べた階層構造を持つＸ．５０９ ＰＫＩに一致するわけではない。その主な理由のひとつとして、Ｘ．５０９対応の証明書が無料のプロセスで決してないことにある。ＣＡをリードするベリサイン（Verisign）では、現在米国において発行する各証明書毎に４００ドルかかる（htpp://www.verisign.com/products-services/security-services/code-signing /digital-ids-code-signing/index.html参照）。そしてこの料金はわずかな額ではないため、多くのオープンデバイスの開発者が、この階層構造をもつＰＫＩスキームへ参加することへの妨げとなっている。提出されたソフトウェアをチェックし診断する証明書スキームは一般にかなりの仕事量であることをカバーするために課金される必要がある。すなわち、多くのスキームに関して、完全に無料にすることは、経済的に現実的でない。

代替の証明書モデルは、連署者として活動する特別な状態を必要としない複数パーティによって証明書に署名がなされるという、ウェブ・オブ・トラスト（Web of Trust）に依存している。その連署者の少なくとも一人が、そのユーザに知られ、信頼されたエンティティである限り、連署者は、その証明書を有効にする署名者の公開鍵のコピーを使用できる。

ソフトウェアパッケージは、またその著者自身により署名されることもできる。これは、ＰＫＩやウェブ・オブ・トラストにより確認される署名と同じ程度の信頼度を確立できないが、著者自身による自己署名による証明書は、価値のないものとは言えない。それは、非対称暗号（asymmetric cryptography）を用いているので、著者自身による自己署名のパッケージを依然として唯一識別し、それ故サードパーティによる変更に対して比較的堅牢な保証をしている。

ここで以上をまとめると、デジタル署名は、次の３つのゴールを目指している。
１．与えられたパッケージをその公開鍵とシリアル番号により直接的に識別する。
２．デジタル署名により含まれているハッシュまたはダイジェストを確認することにより、パッケージに変更がないか直接的に識別する。
３．この署名の存在は、パッケージが再署名されず、パッケージを他のパッケージと直接的に似させたものではない。そして、オリジナルバージョンの署名に使用された秘密鍵の処理者のみによりこの署名がなし得たものである。

しかしそれにもかかわらず、デジタル署名および証明書に依存するあらゆる技術に関し、ソフトウェアパッケージが誤って署名されてしまうことが知られている。このプロセスの脆弱性を示すいくつかの例として以下のことがある。
−ＣＡあるいは他の中間署名機関によりパッケージの起草者に設定されたトラスト（信頼）は、誤って設定されているかもしれない。
−パッケージのオリジネータにより、被雇用者あるいはエージェントのうちの一人に設定されたトラスト（信頼）は、誤って設定されているかもしれない。
−Ｘ．５０９チェインの複数の秘密鍵の１つは、感染に犯されているかもしれない。チェイン（繋がり）が長ければ長いほど、リスクが大きい。
−パッケージは過去に疑われたことがなかったかもしれないが、これに続く予期しないセキュリティの欠陥により、パッケージをマルウェアによる攻略に対して弱くしてしまい、供給業者がパッケージを回収することになり得る。

証明書は誤って発行された可能性があるので、証明書を失効させることができるシステムがある。そのシステムには、証明書が実際に今も有効かどうかを調査する、Ｘ．５０９手順が存在する。

オリジナルのＸ．５０９標準は、証明書失効リスト（Certificate Revocation List、以下ＣＲＬと言う）を必要とし、認証チェインの各署名オーソリティによりダウンロードされる。このリストは、過去に取り消された証明書の全てに関するエントリを含んでいる。更にインターネット標準ＲＦＣ１４２２は、プライバシー向上電子メール（ＰＲＩＶＡＣＹ-ＥＮＨＡＮＣＥＤ ＥＬＥＣＴＲＯＮＩＣ ＭＡＩＬ 、以下ＰＥＭと言う）で利用されるＣＲＬの形式を定義している。

失効のため証明書をチェックする許可を行う、更に最近の標準的方法は、インターネット標準ＲＦＣ２５６０において定義された、オンライン証明書ステータスプロトコル（Online Certificate Status Protocol 、以下ＯＣＳＰと言う）である。ＯＣＳＰは、証明書の有効性を確認しようとするエンティティにその許可を与えるため、ＯＳＣＰレスポンダ（応答者）へ送る、単一の証明書のステータスを調査するためリクエストを作成する。このシステムの恩恵として、長いＣＲＬを検索し調査する必要がもはやないことがある。この結果、ネットワークのオーバーヘッドがより小さくなり、またたった一つの証明書における情報を見つけ出すためにリスト全体を分析する必要がなくなる。

どの失効チェック方法が使われようと、これを実行するエンティティは、ＣＲＬの場合には最新の失効リストを得るために行くべきところ、あるいはＯＳＣＰリクエストを作成したいときにコンタクトすべき応答者、のどちらかを知っておくことが必要である。この情報を決定する方法は、インターネット標準、ＲＦＣ３２８０により提供されており、このＲＦＣ３２８０はこの目的のためＸ．５０９の証明書エクステンション（Certificate Extensions）を定義している。

ＣＲＬに関し、Ｘ．５０９の「cRL Distribution Points」 エクステンションは、ＣＲＬを検索するときその正しい位置を指示する。一方、ＯＳＣＰに関し、「Authority Info Access」 エクステンション（ＡＩＡ）は、その証明書の発行者に関する情報とサービスを得るためにコンタクトすべき応答者を示し、可能な失効リクエストについて問合せを行う。（ＯＳＣＰリクエストは何らかの環境で他の応答者と繋がり得るが）もし応答者が存在するならば、エンティティは、一般的に、これらのフィールドを用いてこのチェインにおける各証明書に関する問合せを分離する。

この既知の方法の記載で、ユーザがインストールを望むあらゆるソフトウェアパッケージのための強制的な署名および証明書によって、任意のオープンコンピューティングデバイスを、より安全なものにすることができる。この手段によって、インストール可能なパッケージの識別は認証され、その内容は本質的に変更のないことが確認される。次の段階でマルウェアに犯されたパッケージは、これらの証明書の手段により識別でき、以上に述べた失効のインフラストラクチャにより取り除かれる。

Ｘ．５０９により定義された確認方法を用いると、それ自身の失効についてチェックする手段を含む証明書は、巡回的になる。その巡回性の最も顕著なケースは、パッケージの著者、製作者あるいは販売者によって自己署名されているか、あるいはだれによっても署名されていないソフトウェアのパッケージに関するものである。ここで誤解を避けるために説明するが、このようなパッケージのための１つの証明書チェインとは、「たまたま、それが単一の証明書で構成されている」といういもので、これは明細書の記載のためのものである。

このようなパッケージは、全ての他のパッケージと同じゴールを目指す環境で、曖昧に識別され、また署名がなされているので変更がないとして確認されてしまう可能性があり、証明書エクステンションに含まれた情報を用いた失効のための信頼し得るチェックを受けることができない。マルウェアに犯されたパッケージの署名はすべて、ＣＲＬあるいはＯＳＣＰのサーバおよび応答者に対して証明書の有効性をチェックしようとする人は誰でも、あまりにも簡単にこのエクステンションを利用でき、そしてこの場合はもちろん、マルウェアの署名によって統制されているので、好ましいステータスレポートが常に返されることになる。

ＣＲＬおよびＯＳＣＰのようなメカニズムは、ルート証明書に戻し得る証明書と一緒に動作するようにのみ実際設計されている。自己署名の証明書も、ＣＲＬまたはＯＳＣＰクライアントをそれらのサーバに案内する標準エクステンションを用いることができる。もちろんこのサーバも自身のソフトウェアのステータスを好ましくレポートするように設計されることになる。この先行技術は、明らかに発行者の署名した証明書にのみ適切なものであり、もし自己署名の証明書が同じスキームに取り入れられると、新しい振る舞いが必要となる。

自己署名されたソフトウェアパッケージにより効果的に働くように、コンピューティングデバイスに証明書失効技術を拡張する方法は、それ故必要である。

本発明の第１の実施形態によれば、１つあるいは複数のセットの予め格納された情報を利用させることを可能にさせ、ソフトウェアパッケージに含まれる１つあるいは複数の一連の証明書によって提供される証明書の失効に係る情報を補足するか、交換するか、あるいは無効にするように、コンピューティングデバイスを動作させる方法がある。そしてこの方法は、コンピューティングデバイスに対して以下の２つの場合において証明書の失効に係る予め格納された情報を利用するようにさせるステップを備える。
ａ．このソフトウェアパッケージに含まれる前記一連の証明書にこのデバイスに格納された信頼できる証明書が含まれると解明される。
ｂ．このソフトウェアパッケージに含まれる前記証明書のどれもが、失効の情報を含まない。

本発明の第２の実施形態によれば、第１の実施形態の方法に従って動作するように構成されたコンピューティングデバイスが提供される。

本発明の第３の実施形態によれば、実施形態１の方法に従ってコンピューティングデバイスを動作させるオペレーティングシステムが提供される。

本発明の好ましい実施形態において、証明書の失効に係る情報のための処理を示すフローチャート図である。

さて、図１を参照し例を紹介しながら、本発明の実施形態を説明する。

図１は、本発明の好ましい実施形態を示すものである。この実施形態において、このデバイスの中のＣＲＬまたはＯＣＳＰクライアントは、２つの異なる方法を用いて無効化のためのチェックを行う。どちらの方法を選択するかは２つの条件のうちの１つが以下を保有するかに依存する。
（ａ）その証明書チェインは、信頼できる診断下にあるか？
そのデバイスにおいて既知のルート証明書または他の信頼できるアンカーと解明されるか？
（ｂ）その証明書チェインは、信頼できない診断に基づいていないか？
そのデバイスにおいて既知のルート証明書ではないか、あるいは他の信頼できるアンカーではないと解明されるか？
以上は、図１のステップ１０により示される。

もし上記の条件（ａ）に当てはまり、認証関連のＸ．５０９エクステンション（「cRL Distribution Points」 または 「AIA」）が存在するならば、このＣＲＬまたはＯＣＳＰクライアントは、図１のステップ１２および１４に示されように、提供された失効情報を用いてどのエクステンションも受け入れて処理することになる。もしエクステンションが存在しなければ、このデバイスのＯＣＳＰクライアントは好みによってデフォルトの「信頼できるＡＩＡの設定」を用い、それによって図１のステップ１６に示されるように、それ自身の選択によるＯＳＣＰ応答者とコンタクトする。

もし上記の条件（ｂ）に当てはまるなら、ＣＲＬまたはＯＣＳＰクライアントが、存在する証明書において与えられた全ての認証関連のＸ．５０９エクステンション（「cRL Distribution Points」 または 「AIA」）を無視し、ステップ１８のように、その代わりにデフォルトの「信頼されないＡＩＡの設定」を用い、それによってそれ自身の選択によるＯＳＣＰ応答者とコンタクトする。この「信頼されないＡＩＡの設定」には、既知の失効した証明書の信頼できるリストが含まれる。

この信頼できるＡＩＡ設定および信頼されないＡＩＡ設定は、異なるＯＳＣＰ応答者を必ずしも指定する必要はない。実際、同じＯＳＣＰ応答者であってよい。

しかし、もし異なるＯＳＣＰ応答者を指定すると、それに付随的する性能改善が可能となる。「信頼されないＡＩＡ」の役割を果たす任意のサーバは、ＯＳＣＰの有効性チェックに突発的に失敗する誤りに対してリジェクトするようデバイスに実行させる応答を返すよりも、むしろ良く知られていない証明書に対して正しい応答を返すように改修することができる。この改善の背後には、特別クラスのデバイスためのソフトウェアの配布に係るユーザおよび他のパーティが、既知のマルウェアのケースを報告することに卓越しているという仮定がある。しかし、彼らがソフトウェアに対して良性であると判断するという知らせを返信する義務があるという状況には置かることはないであろうし、置かれるべきでない。

もちろん代替方法として、ＣＲＬにより「trusted cRL Distribution Points」および「untrusted cRL Distribution Points」の設定を用いて本発明を実施することも可能であるが、このようにしても以上に述べたＯＳＣＰ改修よりも効率的でないことには、注意を要する。

本発明を用いることで次のような多くの有利な点が生じる。
−マルウェア作成者は、非マルウェアを除去する目的で署名をクローンすることができない。
−ＣＲＬ／ＯＳＣＰクライアントの振る舞いを改造することで、標準スキームにより自己署名の証明書を失効させることができる。好適なレスポンスを生成するために、マルウェア作成者は、クライアントを証明により指定されたサーバに積極的に向かわせることができない。
−自己署名の証明書は、本質的に発行者不在であるので、任意の自己署名の証明書を扱うように設計されたサーバを、特にこのブラックリスト上での証明書についての失敗のみを返すように改造することができる。
−このスキームはどの失効ドメインにも適用できる。
−オープンデバイスに関し、自己署名の証明書は実質的に無料であるので、この失効スキームは、より広い範囲のソフトウェア開発を可能にする。
−このスキームは更に、証明書チェインが信頼できるアンカー（Ｘ．５０９またはウェブ・オブ・トラスト）にトレースして戻れない場合に、どんなソフトウェアのインストールも拒絶する、高いセキュリティ・レベルを望む人にも対応できる。

本発明についてこれまで特別な実施形態につき記載してきたが、以下に記載する請求項によって定義された本発明の範囲内にとどまる限り、その修正に対し影響が及ぶことに留意いただきたい。

Claims (10)

1. コンピューティングデバイスを動作させる方法であって、
   予め格納された１以上の情報セットを前記コンピューティングデバイスに利用させることにより、ソフトウェアパッケージに含まれる１以上の一連の証明書により提供される証明書失効に係る情報を補足、交換、または無視することを特徴とするコンピューティングデバイスを動作させる方法。
2. 前記ソフトウェアパッケージに含まれた前記一連の証明書が、前記コンピューティングデバイスに予め格納された信頼できる証明書を含むと解明されない場合、予め格納された証明書失効に係る情報を前記コンピューティングデバイスに利用させることを特徴とする請求項１に記載の方法。
3. 前記予め格納された証明書失効に係る情報が、
   ａ．前記ソフトウェアに含まれる前記一連の証明書が前記デバイスに格納された証明書を含むと解明された場合と、
   ｂ．前記ソフトウェアに含まれる前記証明書のどれもが、失効情報を含んでいない場合と
   において使用される前記予め格納された証明書失効に係る情報とは異なることを特徴とする請求項２に記載の方法。
4. 前記予め格納された証明書失効に係る情報が、
   ａ．前記ソフトウェアに含まれる前記一連の証明書が、前記デバイスに格納された証明書を含むと解明された場合と、
   ｂ．前記ソフトウェアに含まれる前記証明書のどれもが、失効情報を含んでいない場合と
   において使用される前記予め格納された証明書失効に係る情報と同じであることを特徴とする請求項２に記載の方法。
5. 前記ソフトウェアパッケージに含まれた前記一連の証明書が、Ｘ．５０９の証明書を備え、前記証明書失効に係る情報は、ＣＲＬ関連エクステンションかＯＳＣＰ失効関連エクステンションのどちらかにより供給されることを特徴とする請求項１から４のいずれか１項に記載の方法。
6. 前記予めコンピューティングデバイスに格納された情報は、
   ａ．ＣＲＬサーバにアクセスするための「cRL Distribution Points」のようなＣＲＬ関連エクステンション、
   および／または
   ｂ．ＯＳＣＰ応答者またはＯＳＣＰサーバにアクセスするための「Authority Info Access」のようなＯＳＣＰ失効関連エクステンション、
   を備えることを特徴とする請求項１から５のいずれか１項に記載の方法。
7. 前記予め格納された情報がＣＲＬ関連エクステンションおよびＯＳＣＰ失効関連エクステンションを備える場合、前記コンピューティングデバイスは前記ＣＲＬ関連エクステンションを優先し、前記ＯＳＣＰ失効関連エクステンションを利用するように構成されることを特徴とする請求項６に記載の方法。
8. 前記ソフトウェアに含まれた前記一連の証明書が信頼できる証明書の１つであると解明されない場合に利用された前記予め格納された情報が、非既知の証明書に対する肯定的応答を返信するためにＯＳＣＰ応答者またはＯＳＣＰサーバへアクセスするために利用されることを特徴とする請求項１から７のいずれか１項に記載の方法。
9. 請求項１から請求項８のいずれか１項に記載の方法を実行するように構成されたコンピューティングデバイス。
10. 請求項１から請求項８のいずれか１項に記載の方法をコンピューティングデバイスに実行させるオペレーティングシステム。

Images