信頼計算基盤（TCB） - yuuk1's Digital Garden

# 信頼計算基盤（TCB） ## 定義信頼計算基盤(trusted computing base, TCB)とは、正しく動作しなければシステム全体のセキュリティが崩れる、信頼されたモジュールの集合である。*Principles of Computer System Design* 第11章は、システムを「未信頼モジュール」(誤りがあってもセキュリティに影響しない)と「信頼モジュール」(TCBを構成する)に二分するという発想として導入する。TCBはセキュリティモデル(§11.1.6)を実装する際の中心戦略であり、**機構の経済性**の原則(正しく動作すべきモジュールの数を最小化する)と**セーフティネット手法**(be explicit・design for iteration)の適用先である。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.7) あるモジュールがTCBに属するかどうかを機械的に判定する手続きは存在しない。本章はUNIXを例に挙げる。superuserプリンシパルとして動作するモジュールは侵害されれば全権限を攻撃者に渡すためTCBに含まれる可能性が高いが、一般プリンシパルとして動作するモジュールでも、アクセス可否を判断するユーザーレベルサービス(Webサービスなど)であればTCBに含まれうる。TCBの分割を誤ると、TCBが肥大化して(1)セキュリティの妥当性検証が困難になる、(2)一般利用者が変更できる範囲が狭まりユーザー体験が悪化する、(3)信頼された主体しか変更できない部分が増えシステムの進化速度が落ちる、という3つの弊害を招く。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.7) 本章はTCBを構築する4段階の方法を示す。(1) TCBに求めるセキュリティ要件(例: 非信頼ネットワーク越しの安全な通信)と、防御対象の攻撃を明示的に列挙する。(2) 認証論理(§11.7)などの適切な道具を使い、最小のTCBを設計する。(3) 配列境界検査を行う言語を使うなど、適切な道具でTCBを実装する。(4) TCBを実際に動かし、自らそのセキュリティを破ろうと試みる(tiger teamの起用など)。最も困難なのは、設計が仕様を満たすこと・設計が想定した攻撃に耐えること・実装が設計と一致すること・稼働中のシステムが実装と一致することの4つを一貫して検証する部分であり、Thompsonが示したように、コンパイラに精通した攻撃者は検出困難なトロイの木馬を埋め込みうる。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.7) ## 横断的知見 - **ハードウェアのリング機構は、TCBを「正しく動作すべきモジュールの数を最小化する」という原則をハードウェアレベルで具体化した実装戦略だと解釈できる**: *Principles of Computer System Design* はTCBを抽象的な「信頼モジュールの集合」として定義するにとどまるが、*Security Engineering* 第6章はMulticsのリング保護からIntel/Armのリング機構までの具体的な系譜を示す——ring 0(カーネル)だけがセグメントレジスタを自由に書き換えられ、それ以外のリングはゲートを介してのみより高い特権のコードを呼び出せる。これはハードウェアそのものがTCBの境界線をリング番号という物理的な単位で強制する仕組みであり、TCBという抽象概念に「境界をどこに引くか」の具体的な答えの一つを与える。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.7, [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]] ch.6 §6.3) - **SGX・TrustZoneのようなエンクレーブは、TCBを「OS全体」から「CPU内の暗号化された一区画」へ縮小する試みだが、脅威モデルの曖昧さという形で最小化の限界が露呈した**: 第6章は、SGXのエンクレーブがOSカーネルやroot権限プロセスからも隔離されるという意味で、TCBを極限まで小さくする設計だと描く。しかしMichael Schwarz・Samuel Weiser・Daniel Grussは、エンクレーブが「システムコールを発行できないから無害」という想定に反し、ホストアプリへのROP攻撃をエンクレーブから仕掛けられることを示し、「いかなる合理的な脅威モデルも非信頼エンクレーブを含めるべきだ」と論じた。これは *Principles of Computer System Design* が挙げるTCB構築の第1段階(「TCBに求めるセキュリティ要件と防御対象の攻撃を明示的に列挙する」)が不十分だった具体例であり、TCBを小さくすること自体は機構の経済性に資するが、「小さくしたTCBの中身が何をするか」という脅威モデルの設計を怠ると、縮小の効果が無に帰すことを示す。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.7, [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]] ch.6 §6.3.1) - **TPMによるtrusted bootは、TCBの実装検証の第4段階(「実際に動かして自らそのセキュリティを破ろうと試みる」)を回避し、代わりに起動チェーン全体をハッシュで検証するという別の戦略を取る**: 第6章は、TPMが各起動段階のハッシュを検証してから次段階の鍵を渡す仕組みを説明する。これは *Principles of Computer System Design* のTCB構築段階(1)〜(4)のうち、動的な侵入テスト(4)ではなく、静的な測定(measurement)の連鎖によって「稼働中のシステムが実装と一致すること」を保証しようとするアプローチであり、TCBの一貫性検証には複数の戦略がありうることを示す一次資料が加わった。(Source: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.7, [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]] ch.6 §6.2.5) - **TCBの境界は、設計者が意図しないハードウェアのファームウェアにまで静かに広がりうる**: *Security Engineering* 第18章は、Flashメモリのウェアレベリング処理を行うコントローラが「否応なく信頼計算基盤の一部になる(become part of your trusted computing base)」と指摘する——2005年にSergei Skorobogatovが「消去済み」のはずのFlashメモリからデータを抽出できることを発見した文脈でのことである。第11章・第6章が論じる「TCBの分割を誤ると肥大化する」という抽象的な問題に対し、この観察は「サプライヤーが提供するファームウェアそのものが、設計者の意図とは無関係に、気づかぬうちにTCBの一部になる」という具体的な失敗モードを一つ加える。これはTCB構築の第1段階(「TCBに求める要件と防御対象の攻撃を明示的に列挙する」)が、ハードウェアのサプライチェーンの奥深くまで及ばなければ不完全であることを示す。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 18 Tamper Resistance]] ch.18 §18.3, [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]] ch.11 §11.1.7) - **SGXエンクレーブへのROP攻撃(Schwarz et al.)が示した「TCBを縮小しても脅威モデルの誤りは残る」という教訓は、第19章のCachezoom攻撃と突き合わせると、TCB構築の段階(1)(要件・攻撃の明示的列挙)の不備が、制御フロー乗っ取りとサイドチャネルという独立した2つの攻撃面の双方に及んでいたことがわかる**: 第19章は、2017年のCachezoom攻撃がSGXエンクレーブからキャッシュサイドチャネル経由で鍵を抽出したことを報告する。これはSchwarz et al.のROP攻撃(エンクレーブがホストアプリの制御フローを乗っ取る)とは異なる経路——エンクレーブ内部の処理そのものがキャッシュ状態という観測可能な痕跡を残すこと——でTCB縮小の効果を無効化する。前回の未解決の問い(下記参照)はこれで一定の答えを得た: ROP攻撃・キャッシュサイドチャネル攻撃はいずれも段階(1)の不備という同じ根に属するが、その現れ方(能動的な制御フロー乗っ取り対、受動的な観測)は別種であり、TCB設計者は「エンクレーブから何ができるか」だけでなく「エンクレーブから何が漏れるか」も要件定義に含める必要がある。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 19 Side Channels]] ch.19 §19.4.5, [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]] ch.6 §6.3.1) - **第20章は、TCBを最小化するという戦略そのものを持たずに「信頼できる計算機」を成立させた事例(Bitcoin)を提示し、TCB最小化パラダイムの限界を裏側から照らす**: 第11章・第6章・第18章はいずれも「何を信頼モジュールとして残すか」を設計者が決め、その範囲を最小化するという発想を共有する。第20章はこれと対照的な事例として、政府のTCB最小化思想(データダイオード等)・銀行のHSM・エンクレーブという3つの「信頼できる部品を作る」試みが軒並み欠陥を抱えた一方、Bitcoinは事前に信頼された主体を一人も置かず、暗号(プルーフオブワーク)と経済的インセンティブの組み合わせだけから「信頼できる計算機」を相互不信の当事者の共同作業として創発させたと述べる。これは、TCBという概念が前提とする「守るべき信頼モジュールを設計時に指定する」という発想自体が、参加者全員を信頼しないことを前提に設計されたシステムでは成立しないことを示し、TCB最小化とは異なる信頼構築の戦略(経済的インセンティブによる合意)が存在することを本 wiki に加える。(Source: [[@2020__Wiley__Security Engineering 3e - Chapter 20 Advanced Cryptographic Engineering]] ch.20 §20.1, §20.7, §20.9) - **BSRS第6章のウィジェット販売アプリの事例は、既存ソースが集約するTCB分割の抽象論(OS/カーネル・エンクレーブ・ファームウェアという下位レイヤーの具体例)に、「マイクロサービスへの分解」というアプリケーションアーキテクチャ層での具体例を加える**: 本ページの横断的知見はこれまで、TCBの境界をハードウェアのリング機構(*Security Engineering* 第6章)・SGXエンクレーブ(同)・TPMのtrusted boot(同)・Flashファームウェア(第18章)という下位レイヤーで具体化してきた。BSRS第6章は同じ「TCBを小さく保つ」動機を、ウィジェット販売アプリをモノリスからマイクロサービスへ分解する事例で示す——TCB<sub>AddressData</sub>は当初アプリケーション全体・データベース・OSカーネルにまで及んでいたが、購入機能を独立したマイクロサービスへ切り出し専用データベースを持たせることで、カタログバックエンドの脆弱性がTCB<sub>AddressData</sub>の一部にならなくなる。これは、TCB最小化という同一の戦略が、ハードウェア境界(リング・エンクレーブ)からアプリケーション境界(マイクロサービス・データベース分離)まで、抽象化のレイヤーを問わず反復して現れる汎用的な設計パターンであることを示す一次資料が加わったことを意味する。さらにBSRS第6章は、マイクロサービスへ分解しただけではTCBは「フロントエンドをどこまで信頼するか」という新しい問いを生むと指摘し、end-user context ticket(EUC)のような機構でフロントエンドが持つ実効的な権限を絞ることで初めてTCB縮小が実効を持つとする。これは既存ソースのいずれにもない論点であり、「サービス分割はTCB境界を引き直すだけであり、境界を機能させるには呼び出し元の実効的な権限を絞る追加の仕組み(EUC)が要る」ことを本ページに加える。(Source: [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 6 Design for Understandability]], [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]]) ## 未解決の問い - BSRS第6章はTCBの境界を「Webオリジン」という脅威モデルに応じて引き直す例(決済用フロントエンドを別オリジンへ分離し、カタログUIのXSSが決済機能に到達できないようにする)を示すが、これは既存ソースが論じるOS/ハードウェアレベルのTCB(リング機構・エンクレーブ・trusted boot)とは異なる、ブラウザのsame-origin policyという全く別種の隔離機構に依拠する。TCBという概念は、OSプロセス分離・ハードウェアエンクレーブ・ブラウザオリジンという異質な隔離機構を横断してどこまで統一的に扱えるのか、あるいは隔離機構ごとに脅威モデルの記述方法を変える必要があるのか、本ページはまだ整理できていない。 - あるモジュールがTCBに属するかどうかを機械的に判定する手続きは存在しないという本章の指摘は、静的解析やフォーマルメソッドの進歩によってどこまで自動化可能になったか、本章(2009年執筆)の範囲を超える。 - 本章はTCBの実装検証が「一貫性の検証」(仕様↔設計↔実装↔稼働システム)に帰着すると述べるが、この一貫性検証を継続的インテグレーション/デリバリのパイプラインに組み込む具体的な実務は示されない。 - UNIXのsuperuser/一般プリンシパルという二分法だけでTCB境界を判定できない場合(ユーザーレベルサービスがTCBに含まれる例)が本章で明示されているが、そのような判定を体系的に下すための追加の判断基準(§11.6のケアテイカーモデルとの関係など)は本章に示されていない。 - Bitcoinが「信頼モジュールを置かない」ことで頑健性を得たという第20章の観察は、TCBという概念そのものの適用範囲外(TCBが存在しないシステム)を示す例なのか、それとも「マイニングの経済的インセンティブ構造」自体を一種の分散TCBとみなせるのか、本ページの既存の議論だけでは判断できない。 ## 関連 - ソース: [[@2009__MITOCW__Principles of Computer System Design - Chapter 11 Information Security]](§11.1.6, §11.1.7) / [[@2020__Wiley__Security Engineering 3e - Chapter 6 Access Control]](§6.2.5, §6.3, §6.3.1) / [[@2020__Wiley__Security Engineering 3e - Chapter 18 Tamper Resistance]](§18.3) / [[@2020__Wiley__Security Engineering 3e - Chapter 19 Side Channels]](§19.4.5) / [[@2020__Wiley__Security Engineering 3e - Chapter 20 Advanced Cryptographic Engineering]](§20.1, §20.7, §20.9) / [[@2020__OReilly__Building Secure and Reliable Systems - Chapter 6 Design for Understandability]](§System Architecture > Security Boundaries) - 概念: [[セキュリティ設計原則]](機構の経済性の実装戦略としてのTCB) / [[ネットワークセキュリティアーキテクチャ]] / [[認可モデル]] / [[トラステッド実行環境（TEE）]](TCB縮小の現代的なハードウェア実装) / [[耐タンパ性]](TCB境界がハードウェアのファームウェアにまで広がる具体例) / [[投機的実行とマイクロアーキテクチャサイドチャネル（Meltdown・Spectre）]](エンクレーブサイドチャネルの詳細) / [[ブロックチェーン]](TCB最小化を経ずに信頼を創発させた事例) / [[理解容易性のための設計]](TCB最小化と理解容易性の二重の動機づけ) - 実体: [[Jerome H. Saltzer]] / [[Multics]](リング機構によるTCB境界の起源) ## 出典 - Jerome H. Saltzer and M. Frans Kaashoek, *Principles of Computer System Design: An Introduction*, Version 5.0, 2009, Chapter 11 §11.1.6-§11.1.7. MIT OpenCourseWare, CC BY-NC-SA 3.0 US. - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 6, §6.2.5, §6.3, §6.3.1. - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 18, §18.3. - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 19, §19.4.5. - Ross Anderson, *Security Engineering: A Guide to Building Dependable Distributed Systems*, 3rd Edition, John Wiley & Sons, 2020, Chapter 20, §20.1, §20.7, §20.9. - Heather Adkins et al. (eds.), *Building Secure and Reliable Systems*, O'Reilly Media, 2020, Chapter 6, §System Architecture > Security Boundaries.