コンピュータ システムの信頼できるコンピューティング ベース( TCB )は、セキュリティにとって重要なすべてのハードウェア、ファームウェア、および/またはソフトウェアコンポーネントのセットです。つまり、 TCB 内でバグや脆弱性が発生すると、システム全体のセキュリティ プロパティが危険にさらされる可能性があります。対照的に、TCB の外側にあるコンピュータ システムの部分は、システムのセキュリティ ポリシーに従って付与されている権限以上の権限を漏らすような不正行為を行うことはできません。
システムの信頼できるコンピューティング ベースの慎重な設計と実装は、システムの全体的なセキュリティにとって最も重要です。最新のオペレーティング システムでは、 TCB [本文では検証されていません]のサイズを縮小して、コード ベースの徹底的な検査 (手動またはコンピューターによるソフトウェア監査またはプログラム検証による) が実行可能になるように努めています。
定義と特徴
この用語はジョン・ラシュビー[1]に遡り、彼はこれをオペレーティングシステムカーネルと信頼されたプロセスの組み合わせとして定義しました。後者は、システムのアクセス制御ルールに違反することが許可されているプロセスを指します。古典的な論文「分散システムにおける認証:理論と実践」[2]で、 ランプソンらはコンピュータシステムのTCBを単純に次のように 定義しています。
- セキュリティが依存する少量のソフトウェアとハードウェアであり、セキュリティに影響を与えずに不正な動作をする可能性のある大量のソフトウェアとハードウェアとは区別されます。
どちらの定義も明確で便利ですが、理論的には正確ではなく、またそのように意図されていません。たとえば、 UNIX系オペレーティングシステムのネットワークサーバープロセスは、セキュリティ侵害の犠牲になり、システムのセキュリティの重要な部分を危険にさらす可能性がありますが、オペレーティングシステムのTCBの一部ではありません。そのため、もう1つの古典的なコンピュータセキュリティ文献の参考文献であるオレンジブックでは、コンピュータシステムのTCBのより正式な定義を 提供しています[3] 。
- ハードウェア、ファームウェア、ソフトウェアを含む、コンピュータ内の保護メカニズムの全体であり、これらの組み合わせによってコンピュータ セキュリティ ポリシーが実施されます。
つまり、信頼できるコンピューティング ベース (TCB) は、セキュリティ ポリシーを適用するための信頼できるベースを形成するために連携して動作するハードウェア、ソフトウェア、およびコントロールの組み合わせです。
オレンジブックではさらに次のように説明している。
- 信頼できるコンピューティング ベースが統合セキュリティ ポリシーを正しく実施できるかどうかは、信頼できるコンピューティング ベース内のメカニズムの正確性、それらのメカニズムの正確性を保証するための保護、およびセキュリティ ポリシーに関連するパラメータの正しい入力に依存します。
言い換えれば、ハードウェアやソフトウェアが TCB の一部となるのは、それがコンピュータ システムにセキュリティを提供するメカニズムの一部として設計されている場合に限られます。オペレーティング システムでは、これは通常、カーネル (またはマイクロカーネル) と選択されたシステムユーティリティ セット ( UNIX システムではsetuidプログラムとデーモンなど) で構成されます。JavaやEなど、セキュリティ機能が組み込まれて設計されたプログラミング言語では、TCB は言語ランタイムと標準ライブラリで構成されます。[4]
プロパティ
セキュリティポリシーに基づいて
上記のオレンジブックの定義の結果として、TCB の境界は、セキュリティ ポリシーがどのように具体化されるかという詳細に密接に依存します。上記のネットワーク サーバーの例では、たとえば、マルチユーザーアプリケーションを提供する Web サーバーはオペレーティング システムの TCB の一部ではありませんが、ユーザーが互いの ID と権限を奪取できないようにアクセス制御を実行する責任があります。この意味で、 Web サーバーは、UNIX サーバー、ユーザーのブラウザー、および Web アプリケーションで構成される大規模なコンピュータ システムの TCB の一部であることは間違いありません。つまり、たとえばバッファーオーバーフローによる Web サーバーへの侵入は、オペレーティング システム自体の侵害とは見なされないかもしれませんが、Web アプリケーションに対する 損害を与えるエクスプロイトであることは間違いありません。
TCB の境界のこの基本的な相対性は、 Common Criteriaセキュリティ プロセスにおける「評価対象」(「TOE」) の概念によって例証されます。Common Criteria セキュリティ評価の過程で、最初に行う必要がある決定の 1 つは、精査の対象となるシステム コンポーネントのリストに関する監査の境界です。
セキュリティの前提条件
設計の一部として信頼できるコンピューティング ベースを持たないシステムは、独自のセキュリティを提供しません。外部の手段によってセキュリティが提供される場合に限り、それらのシステムは安全です (たとえば、ネットワークに接続されていない鍵のかかった部屋にあるコンピュータは、実行するソフトウェアに関係なく、ポリシーによっては安全であるとみなされる場合があります)。これは、David J. Farberらが述べているように、[5] [i] コンピュータ システムでは、下位層の整合性は通常、上位層によって自明のこととして扱われるためです。コンピュータ セキュリティに関する限り、コンピュータ システムのセキュリティ プロパティについて推論するには、それができること、そしてさらに重要なことに、できないことについて適切な仮定を立てることができなければなりません。ただし、そうでないと信じる理由がない限り、コンピュータは一般的なフォン ノイマン マシンができることはすべて実行できます。これには、秘密にしておくべき電子メールやパスワードの漏洩など、最も単純なセキュリティ ポリシー以外すべてに反すると見なされる操作が含まれることは明らかです。しかし、システムのアーキテクチャに特別な規定がない限り、コンピュータがこれらの望ましくないタスクを実行するようにプログラムされる可能性があることは否定できません。
特定の種類のアクションが実行されないようにすることを目的としたこれらの特別な規定は、本質的には信頼できるコンピューティング ベースを構成します。このため、オレンジ ブック(2007 年現在でも安全なオペレーティング システムの設計に関する参考資料[アップデート]) では、主に TCB の構造とセキュリティ機能の観点から、定義されるさまざまなセキュリティ保証レベルを特徴付けています。
TCBのソフトウェア部分は自らを保護する必要がある
前述のオレンジブックで概説されているように、トラステッド コンピューティング ベースのソフトウェア部分は、改ざんから保護されて初めて効果を発揮します。これは、ほぼすべての最新コンピューターに実装されているフォン ノイマン アーキテクチャによるものです。マシン コードは他の種類のデータとして処理できるため、どのプログラムでも読み取ったり上書きしたりできます。これは、後で TCB の一部として扱う必要のある特別なメモリ管理規定によって防止できます。具体的には、トラステッド コンピューティング ベースは、少なくともそのソフトウェアへの書き込みを防止しなければなりません。
最近の多くのCPUでは、TCB をホストするメモリの保護は、メモリ管理ユニット(MMU) と呼ばれる特殊なハードウェアを追加することで実現されています。このユニットは、オペレーティング システムによってプログラム可能で、実行中のプログラムによるシステム メモリの特定の範囲へのアクセスを許可または拒否できます。もちろん、オペレーティング システムは、他のプログラムに対してこのようなプログラミングを禁止することもできます。この手法はスーパーバイザー モードと呼ばれます。より粗雑なアプローチ (TCB をROMに格納する、または同等のハーバード アーキテクチャを使用するなど) と比較すると、セキュリティが重要なソフトウェアを現場でアップグレードできるという利点がありますが、信頼できるコンピューティング ベースの安全なアップグレードを許可すると、独自のブートストラップの問題が発生します。[6]
信頼できるか、信頼できるか
前述のように、コンピュータシステムのセキュリティを確かめるには、信頼できるコンピューティング基盤への信頼が必要です。言い換えれば、信頼できるコンピューティング基盤は、信頼できる必要があるという意味で「信頼される」のであり、必ずしも信頼できるという意味ではありません。現実世界のオペレーティングシステムでは、セキュリティ上重大なバグが日常的に発見されており、このような信頼の実際的な限界を証明しています。[7]
代替手段は、バグが存在しないことを示す数学的証明技術を使用する正式なソフトウェア検証です。NICTAとそのスピンアウトであるOpen Kernel Labsの研究者は最近、 L4マイクロカーネルファミリーのメンバーであるseL4のそのような正式な検証を実行し、カーネルのC実装の機能的な正しさを証明しました。[8] これにより、数学的証明にエラーがないと仮定した場合、seL4は信頼性と信頼性のギャップを埋める最初のオペレーティングシステムカーネルになります。
TCB サイズ
前述のように、形式検証や手動レビューなどのコストのかかる技術を適用する必要があるため、TCB のサイズは TCB 保証プロセスの経済性と、結果として得られる製品の信頼性 (検証またはレビュー中に発見されなかったバグの数の数学的期待値の観点から) に直接影響を及ぼします。したがって、コストとセキュリティ リスクを削減するために、TCB は可能な限り小さくする必要があります。これは、モノリシック カーネルよりもマイクロカーネルを優先する議論における重要な論点です。[9]
例
AIXは、インストール時のパッケージ管理システムのオプションコンポーネントとして信頼できるコンピューティングベースを実現します。[10]
参照
参考文献
- ^ Rushby, John (1981)。「セキュアシステムの設計と検証」。第 8 回 ACM オペレーティング システム原則シンポジウム。パシフィック グローブ、カリフォルニア州、米国。pp. 12–21。
- ^ B. Lampson、M. Abadi、M. Burrows、E. Wobber、「分散システムにおける認証:理論と実践」、ACM Transactions on Computer Systems 1992、6 ページ。
- ^ 国防総省の信頼できるコンピュータ システムの評価基準、DoD 5200.28-STD、1985 年。用語集の「Trusted Computing Base (TCB)」の項目。
- ^ M. Miller、C. Morningstar、B. Frantz、「Capability-based Financial Instruments (An Ode to the Granovetter diagram)」の 「Subjective Aggregation」の段落。
- ^ W. Arbaugh、D. Farber、J. Smith、「安全で信頼性の高いブートストラップアーキテクチャ」、1997 年、「aegis 論文」としても知られています。
- ^ 安全で信頼性の高いブートストラップアーキテクチャ、前掲書。
- ^ ブルース・シュナイアー、「セキュリティパッチトレッドミル」(2001)
- ^ Klein, Gerwin; Elphinstone, Kevin; Heiser, Gernot ; Andronick, June; Cock, David; Derrin, Philip; Elkaduwe, Dhammika; Engelhardt, Kai; Kolanski, Rafal; Norrish, Michael; Sewell, Thomas; Tuch, Harvey; Winwood, Simon (2009 年 10 月)。「seL4: OS カーネルの形式検証」(PDF)。第 22 回 ACM オペレーティング システム原則シンポジウム。米国モンタナ州ビッグ スカイ。pp. 207–220。
- ^ アンドリュー・S・タネンバウム、タネンバウム-トーバルズ論争、第2部(2006年5月12日)
- ^ AIX 4.3 セキュリティの要素、2000 年 8 月、第 6 章。
