Soatokの非公式脅威モデルガイド

 (soatok.blog)
2 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • 脅威モデルは保護対象と攻撃者を書くだけで終わらず、資産同士の関係・前提・意図的に除外した脅威まで明らかにしてこそ、設計判断に使える
  • 良いモデルは資産を単なる一覧ではなくグラフとして捉え、コンポーネントの入力・出力・依存関係を絞り込みながら、リスクと前提を確認する
  • 前提が崩れたら受容したリスクも見直す必要があり、Invisible Salamanders攻撃は、E2EEの不正利用報告機能とAEADの「メッセージごとに有効な鍵は1つ」という前提が衝突したときに問題になる
  • publickey.directoryの事例は前提・資産・行為者・リスク状態を分けて見るが完全ではなく、Matrix v1.18の脅威モデルは攻撃類型の一覧に近く、暗号化・鍵管理が抜けている
  • 脅威モデリングは、passkey認証、分散E2EE設計、PQC論争のような場面で、技術選択の制約と実際のリスクを切り分け、よりよい設計判断を助ける

脅威モデルが答えるべき質問

  • 脅威モデルは正式なサイバーセキュリティ手順にもなり得るが、新しい製品やサービスの設計・アーキテクチャ段階でも非公式に実施できる
  • 少なくとも次の質問に答える必要がある
    • 何を守るのか
    • 誰が、または何が保護対象を害そうとしているのか
    • 攻撃者はどのような方法で攻撃できるのか
    • その攻撃を防ぐために何をするのか
  • この4つだけでも脅威モデルとは呼べるが、実務では重要な詳細が抜け落ちやすい
  • 追加で必要な質問は次のとおり
    • 保護資産はどのようにつながっているのか
    • どのような前提を置いているのか
    • どの脅威は意図的に扱わないのか
  • 将来のあらゆる攻撃をすべて扱うことはできないため、除外した脅威は明記すべき
  • 前提が誤っていればモデルは不完全になり、すでに受容したリスク一覧も再検討しなければならない
  • 脅威モデルは特定時点のスナップショットではなく、必要に応じて更新される生きた文書であるべき

前提が崩れたときに起きる問題

  • Invisible Salamanders attackは、一部のE2EEメッセージング設計で不正利用報告機能を導入すると、その機能を壊し得る
  • この攻撃はAES-GCM、ChaCha20-Poly1305のようなAEADスキームの前提と関わっている
    • これらのスキームには、特定のメッセージに対して有効な鍵は1つだけという前提が含まれている
    • 1つのメッセージに複数の有効鍵を導入したり、confused deputiesを生んだりすると、アルゴリズムのセキュリティ保証の外に出てしまう
  • 前提を明確に書いておくと、自分たちのunknown unknownsを見つける助けになる
  • 完璧である必要はないが、何を前提にしているかは明確であるべき

脅威モデリングを始める手順

  • 専門的に脅威モデリングを行うなら、Threat Modeling Manifestoを読むことが推奨される
  • 実務ではまず、7つの項目をすぐにコピーして使える形式で書き出すところから始める
  • その後、分析対象システムのコンポーネントを紙やデジタルツール上に描く
    • あるウィジェットが別のウィジェットと直接通信・依存・相互作用するなら、その関係を示す
    • 関係の表記方法は、作業者にとって最も有用な形でよい
  • 全体のグラフを箱で囲ったあと、徐々に箱を狭めて各コンポーネントに焦点を当てる
    • 各反復でコンポーネントの入力と出力を記録する
    • 可能な限り7つの質問に答える
  • 抽象化レベルが許すところまで深掘りしたら、それ以上掘り下げていない層について、どのような前提を置いているかをブレインストーミングする
  • データベースがロードバランサと同じ形でX25519の安全性に依存しているとは限らない
  • データベースにRSSフィードが流れ込むような不適切な関係は記録し、可能なら切り離すことが目標となる

publickey.directoryの事例

  • Fediverseに鍵透過性を提供する取り組みは、publickey.directoryで追跡されている
  • この取り組みはp​​ublic-key-directory-specification仕様から始まり、その仕様には脅威モデルが含まれている
  • その脅威モデルは次のセクションで構成されている
    • 前提
    • 資産
    • 攻撃者と守るべき人々を含む行為者および役割名
    • リスクとリスク状態
  • リスク状態は4つに分かれる
    • Prevented by design: 攻撃は設計上成立しない
    • Mitigated: 前提が崩れていなければ攻撃は成功しないはず
    • Addressable: 緩和方法はあるが、努力や注意が必要で、運用者が把握しておく必要がある
    • Open: 緩和できない、または緩和しないリスクであり、その攻撃は成功する
  • この脅威モデルも完全ではない
    • 資産と行為者の関係を、人間が読みやすいグラフとして完全には結び付けていない
    • リスクセクションに、考慮しきれていない盲点があるかもしれない
    • システムの安全性に重要な前提が抜けている可能性がある

MatrixとSignalの対比

  • Matrix v1.18のSecurity Threat Modelは、サービス拒否、スプーフィング、スパム、スパイ行為のような攻撃類型を列挙している
  • この文書には次の問題がある
    • 攻撃類型の一覧に近い
    • 前提一覧がない
    • 資産一覧と資産間の関係がない
    • 攻撃一覧が不完全
    • MatrixはE2EEメッセンジャーとして宣伝されているが、脅威モデルは暗号化や鍵管理を扱っていない
  • Matrixの脅威モデルはv1.1以降ほとんど変わっておらず、その間に脆弱性の公開やLotteによる2つの追加の暗号攻撃があった
  • それでもMatrixには脅威モデルがある
  • Signalは技術仕様を提供しているが、脅威モデルは利用者が自分で把握しなければならない形になっている
  • 悪い脅威モデルでも、脅威モデルがまったくないことよりはまし

脅威モデルが設計を改善する方法

  • セキュリティ実務では、防御側は常に正しくなければならず、攻撃側は一度成功すればよいという格言がよく語られる
  • 防御側が十分に準備していれば、攻撃者が動ける地形を決められる
  • 実際のdefense-in-depthには、脅威モデルを十分理解し、攻撃者を予測可能な袋小路へ追い込むことが含まれる

  • Credential stuffing対策

    • Credential stuffingは現実で過剰なほど効果的な単純攻撃である
    • 原因は、人々がパスワードを使い回すため
    • 利用者は複数のユニークで安全なパスワードを覚えるのが難しいため、パスワードマネージャーは長らく妥当な緩和策だった
    • 現在ではpasskeyがより良い選択肢として扱われている
    • passkeyは認証に公開鍵暗号を使わせる、よりユーザーフレンドリーな方法である
    • 最善のケースではSoloKeysやYubiKeysのようなハードウェアセキュリティトークンを使う
    • 平均的なケースではOSやパスワードマネージャーがこれを提供する
    • credential stuffingや類似の単純攻撃を避けるには、次のような設計が必要
      • アプリケーションがpasskeyを必須とするよう設計する
      • 利用者が複数のpasskeyを登録できるようにするか、少なくともバックアップ用を1つ必須にする
      • すべての認証情報を失った利用者のために、管理者が新しいpasskeyを追加できるbreak glass経路を用意する
      • その管理操作は、管理者が検閲できない形でログに残す
      • 可能なら認証用パスワードを一切サポートしない
      • 暗号鍵導出用のパスワードは別の文脈なら許容される
    • passkeyは登録時に認証情報がドメイン名へ暗号学的に結び付けられるため、フィッシングできない
    • passkey導入のコストがあっても、credential stuffingやフィッシングによるサポート負荷をより大きく減らせる可能性がある
    • 人間が高エントロピーの秘密値を覚え、再利用しないことを求める非現実的な期待を取り除けば、複数の攻撃クラスをなくし、使い勝手も改善できる
    • 「使いやすさを犠牲にしたセキュリティは、セキュリティを犠牲にする」というAvi Douglenの言葉が引用されている

分散E2EEと脅威モデル

  • ダイレクトメッセージ向けE2EEについて、2つの提案が議論されている
    • MastodonのプライベートDMのようなFediverseソフトウェアを対象にしたActivityPub E2EE specification
    • ATProto、たとえばBlueSkyで同じ目標を持つGerm Networkのようなプロジェクト
  • 両プロジェクトとも、ある時点でMLSをE2EE会話の鍵管理プロトコルとして使う案を検討している
  • 非中央集権システムにおいて、MLSには2つの重要な制約がある
    • MLSはAuthentication Serviceという抽象概念を仕様化している
    • MLSのepochを支えるratcheting treeの安全性では、メッセージ順序が重要になる
  • ActivityPubが最初の制約に対して鍵透過性を採用するなら、複数サーバー上で複数のKeyUpdateメッセージが競合したときの処理方法を規定する必要がある
  • ATProtoとBlueSkyの状況はさらに厄介
  • ユーザー間メッセージの機密性がセキュリティ目標であり、かつホスティングを分散したいなら、ATProtoのブロックチェーン的な設計は、現在標準化されている効率的なグループ鍵合意プロトコルの利用を妨げる
  • 脅威モデリングは、この種の設計制約を初期設計の段階で可視化できる

PQC論争で見える脅威モデリングの役割

  • hybrid post-quantum constructionsに関連して、IETF TLSワーキンググループのメーリングリストでは、non-hybrid ML-KEMコードポイントを設けるRFCが議論されている
  • 議論の前提は次のとおり
    • ML-KEMはNSA設計ではない
    • 主提出者はPeter Schwabeで、Daniel J. BernsteinやNaCl暗号ライブラリで協業しており、ドイツ在住
    • 他の提出者も欧州各地にいる
    • Sophie Schmiegの文章が示すように、情報理論はML-KEMバックドアの可能性を否定している
    • ML-KEMはNISTによる公開かつ10年にわたる国際標準化の取り組みで選定された
    • NIST、FIPS、NSAは機密システムでnon-hybrid ML-KEMとML-DSAを要求している
  • このIETFドラフトはnon-hybrid ML-KEMを指定し、Recommend=Nとされている
  • hybrid KEMのRFCはRecommend=Yになる見込みで、hybrid KEMの方がnon-hybrid KEMより推奨される
  • 常にhybrid KEMを使うよう設定されたシステムでは、ML-KEM RFCが出てもセキュリティ低下はない
  • Google Chromeはすでにnon-hybrid ML-KEMをサポートしており、IETF RFCが出なくてもこの事実は変わらない
  • このRFCの実質的な効果は、CNSA 2.0、FIPS 140-3、または類似の規則に従う必要があり、Internet Draftではなく安定したIETF RFC番号を必要とする組織の手続き上の制約を解くことにある
  • この問題は、とくに政府顧客向けに販売する一部事業分野でよく起こり得る

  • Hybrid PQ+ECDHとPure PQの違い

    • KEMで直面するリスクは「Q-Day後に暗号が破られること」ではなく、Harvest Now, Decrypt Laterである
    • Q-Dayは、攻撃者が暗号関連量子コンピューターを持つ時点を指す略語として使われる
    • リスクを分けると次のようになる
      • 純粋なECDH、つまりPQなしは、Q-Dayに遡及的に破られる
      • 純粋なPQは、PQアルゴリズムが先に破綻しないという前提のもとで、Q-Dayでも破られない
      • Hybrid PQ+ECDHは、Q-Day前のアルゴリズム崩壊へのヘッジにはなるが、Q-Day後はPure PQに比べて意味がない
    • ECDH + ML-KEMを主張することは、長期的にML-KEMが安全なアルゴリズムだと認めていることになる
    • hybridを好む理由は2つに整理できる
      • 完全に未知のアルゴリズムより受け入れやすく、PQ導入を早められる
      • ML-KEMまたは格子ベース暗号全体のアルゴリズム崩壊に備えられる
    • 暗号関連量子コンピューターにも耐える形でヘッジしたいなら、PQ+PQ hybridが必要になる
    • アルゴリズム多様性を重視するなら、ML-KEM + HQC + ECDHの3-way hybridの方が、より正直な主張に近い
    • ML-KEMは格子ベースKEMであり、量子攻撃に耐えると考えられている
    • HQCは符号ベースKEMであり、量子攻撃に耐えると考えられている
    • ECDHは現在使われている方式だが、量子攻撃には弱い
    • 脅威モデリングは、このような論争でイデオロギー的反対と技術的リスクを切り分けて判断するために使える

まとめ

  • インターネット上には、脅威モデルと関連手法を正式に扱うガイドが数多くある
  • ここでの目標は、脅威モデル文書の品質と有効性を素早く見分けられるスモークテストを持つこと
  • 良い脅威モデルは、保護対象、攻撃者、攻撃手法、防御策を超えて、資産の関係、前提、受容したリスクまで明らかにすべき

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Lobste.rsの意見
  • 今回は珍しく尊大で不快な態度抜きでブログ記事を書いたのかと思って褒めようとしたが、結局そのブログでおなじみのMatrix批判記事のくだりにたどり着いた。
    「不親切さ」がコメント通報の理由として有効なら、技術系インターネットをより良くするには、この著者がブログであまりにも頻繁に使う攻撃的なトーンをこれ以上消費せず、推薦するのもやめるべきではないだろうか。いっそそのドメインを禁止することも検討に値する。
    • 批判対象の文言をすべて引用し、実質的な反論の根拠を示したかなり理性的な批判だった。たいていの批判よりずっと良い例だと思う。
    • これは軽蔑の文化だ: https://blog.aurynn.com/2015/12/16-contempt-culture
    • 誰かを「尊大で不快な愚か者」と呼びながら、同時に不親切だという理由でその人を禁止しようというのがどう両立するのか分からない。見たい変化を自分で示すべきだ。
    • トーンは問題ないと思う。
      それに「すべてはグラフ」というプロトコルは、実際に研究プロジェクトのように扱うべきだと思う。結論は「しまった、グラフアルゴリズムは実際に推論するのが本当に難しい」だったようなものだ。