Open6

The Messaging Layer Security (MLS) Architecture

抄録

本文書では、Messaging Layer Security (MLS) プロトコルのリファレンスアーキテクチャ、機能、およびセキュリティ要件について説明します。MLS は、クライアントの数が 2 から多数に及ぶグループメッセージングアプリケーション用のセキュリティ層を提供します。MLS は、盗聴、改ざん、およびメッセージの偽造から保護することを目的としています。

1. 序章

エンドツーエンドのセキュリティはインスタントメッセージングシステムの要件であり、多くのシステムで一般的に導入されています。この文脈では、「エンドツーエンド」とは、システムのユーザーがあるレベルのセキュリティを享受しているという概念を表しています(正確なレベルはシステムの設計によりますが)。

Messaging Layer Security (MLS) は,このような設定でエンドツーエンドのセキュリティを提供するためのアーキテクチャ (本文書) と抽象プロトコル [MLSPROTO] を規定しています.MLSは完全なインスタントメッセージングプロトコルではなく、XMPP [RFC6120]のような具体的なプロトコルに組み込まれることを意図している。さらに、MLS は完全なワイヤエンコーディングを指定しているわけではなく、TLS [RFC8446]、CBOR [RFC7049]、JSON [RFC7159] などのさまざまな具体的なエンコーディングにマッピングできる抽象的なデータ構造のセットを指定しています。互換性のあるエンコーディングを採用する実装は、互換性のない ID/認証インフラストラクチャを持っていても、メッセージレベルではある程度の相互運用性を持つことになる。MLS プロトコルは、たとえそれが 2 人のユーザーだけに縮小されたとしても、すべてのユーザーに、すべての グループサイズに対して同じセキュリティ保証を提供するように設計されている。

この文書は、MLS プロトコルが機能的なシステムを実現するために必要な運用要件を含めて、MLS プロトコルが適合する全体的なメッセージングシステムアーキテクチャを記述し、MLS プロトコルが達成することを意図したセキュリティ目標を記述することを目的としています。

2. 一般的な設定

非公式には、グループとは、複数のエンドポイントデバイスを使用してサービスプロバイダ(SP)とやり取りする可能性のあるユーザーのセットのことです。グループは、2人のメンバー(個人間メッセージングの単純な場合)から数千人のメンバーまであります。

安全に通信するために、ユーザは最初に、暗号化と認証に必要な値とクレデンシャルを確立するために、自由に使えるサービスと対話します。

サービスプロバイダは、クライアントがメッセージを安全に送受信するための準備をすることを可能にする2つの抽象的なサービスを提示します。

  • 認証サービス(AS)は、ユーザの長期的なアイデンティティを維持し、ユーザ同士の認証を可能にするクレデンシャルを発行し、ユーザがお互いの長期的なアイデンティティキーを発見できるようにすることを可能にする。
  • デリバリーサービス(DS)は、グループメンバー間でメッセージの受信と再配布を担当します。グループメッセージングの場合、配信サービスは、送信者がグループに単一のメッセージを送信し、DS がグループ内の各受信者に転送する「ブロードキャスター」としての役割を果たすこともあります。また、DS は、グループ秘密鍵の確立プロセスを進めるためにクライアントが必要とする初期公開鍵を保存し、配信する責任を負う。
      ----------------      --------------
     | Authentication |    | Delivery     |
     | Service (AS)   |    | Service (DS) |
      ----------------      --------------
                         /        |         \            Group
                        / ************************************
                       /  *       |           \              *
            ----------    *   ----------        ----------   *
           | Client 0 |   *  | Member 1 |      | Member N |  *
            ----------    *   ----------        ----------   *
           ............   *  ............      ............  *
           User 0         *  User 0            User 1        *
                          *                                  *
                          ************************************

多くのシステムでは、ASとDSは実際には同じエンティティによって運用されており、同じサーバである可能性さえある。しかし、これらは論理的には別個のものであり、他のシステムでは、異なるエンティティによって運用されている可能性があるので、ここでは別個のエンティティとして表示しています。別々のディレクトリサーバを持つなど、他のパーティションも可能である。

典型的なグループメッセージングのシナリオは次のようなものです。

典型的なグループメッセージングのシナリオは次のようなものです。

  1. アリス、ボブ、チャーリーがサービスプロバイダにアカウントを作成し、AS から認証情報を取得する。
  2. アリス、ボブ、チャーリーは DS に対して認証を行い、最初に暗号化されたメッセージを送信するために使用できる初期の鍵情報を保存します。このキーイング材料は、彼らの長期的な資格情報で認証されます。
  3. アリスがボブとチャーリーにメッセージを送信したいとき、彼女は DS に連絡して、彼らの初期の鍵情報を調べる。アリスはこれらの鍵を使用して、ボブとチャーリーに暗号化されたメッセージを送信するために使用できる新しい鍵を確立します。彼女は暗号化されたメッセージを DS に送信し、DS は受信者に転送する。
  4. ボブとチャーリーはアリスのメッセージに応答する。さらに、彼らは、妥協後セキュリティセクション3.2.2.1.1を提供する鍵材料を更新することを選択するかもしれない。その変更の結果として、グループの秘密は更新される。

クライアントは以下のことをしたいと思うかもしれません。

  • 他のクライアントを招待してグループを作成する。
  • 既存のグループにクライアントを追加する。
  • 既存のグループからメンバーを削除する。
  • 自分のキーマテリアルを更新する
  • 既存のグループに参加する。
  • グループから離れる。
  • グループ内の全員にメッセージを送る。
  • グループ内の誰かからメッセージを受け取る。

暗号化レベルでは、クライアント(およびグループ内のメンバー)は同等の権限を持っています。例えば、どのメンバーもグループ内の別のクライアントを追加したり削除したりすることができます。これは、グループを変更できるグループコントローラが一人である場合とは対照的です。MLS は、グループ管理を特定のユーザに制限することに対応していますが、その制限はアプリケーション層での認証とアクセス制御によって強制されていると仮定しています。

したがって、例えば、MLS プロトコルは、グループの既存のメンバーであれば誰でも新しいクライアントを追加することができますが、MLS を使用するアプリケーションは、メンバーのサブセットのみが資格を得ることができる追加の制限を強制する可能性があり、そのため、アプリケーションレベルでグループポリシー(ユーザーがグループに新しいユーザーを追加することを許可されているかどうかを決定するなど)の強制を処理することになります。

2.1. グループ・メンバー・クライアント

非公式には、グループとは、サービスプロバイダと対話するために複数のエンドポイントデバイスを使用しているユーザの集合であると考えることができますが、この定義はあまりにも単純です。

形式的には、クライアントは名前(ID)、公開暗号化キー、公開署名キーなどの公開値で構成される暗号オブジェクトのセットです。ユーザーによるクライアントの所有権は、ユーザーが関連する秘密の値を知っているかどうかで決まります。クライアントがグループの一部である場合、クライアントはメンバーと呼ばれ、その署名キーペアは、 グループ内の他のクライアントやメンバーに対して一意にアイデンティティを定義します。一部のメッセージングシステムでは、同じユーザーに属するクライアントはすべて同じ ID キーペアを共有しなければなりませんが、MLS はこれを前提としていません。

ユーザーは通常、複数のクライアントを所有しており、エンドユーザーのデバイス(電話、ウェブクライア ント、その他のデバイスなど)ごとに 1 つまたは複数のクライアントを所有している可能性があります。

MLS におけるグループの正式な定義は、プロトコルのグループ鍵確立段階で確立された共有グループ秘密を知り、それに貢献したクライアントの集合です。メンバーがグループ秘密に貢献するまでは、他のメンバーは自分がグループのメンバーであると考えることはできません。

2.2. 認証サービス

認証サービス(AS)の基本的な機能は、ユーザID(ユーザ名、電話番号など)から長期的なIDキーへの信頼できるマッピングを提供することです。

認証サービス(AS)は、アーキテクチャで複数の役割を果たすことが期待されています。

  • 認証局または類似のサービスで、ID を署名キーにバインドするある種のポータブルなクレデンシャルに 署名する。
  • 所定の ID 用の鍵を提供するディレクトリ・サーバー(この接続は TLS などの何らかの形式のトランスポート・セキュリ ティによって保護されていると思われる)。

MLS プロトコルは、メッセージの認証のために署名鍵ペアを想定している。この署名鍵ペアは、ID 鍵ペアそのものである場合もあれば、公開鍵がたとえば ID 秘密鍵によって署名された別の署名鍵ペアである場合もあることに注意することが重要である。この柔軟性により、複数のインフラストラクチャを考慮することが可能になり、階層的な認証鍵を使用することで、異なるグループ間で異なる署名鍵を使用する方法を提供できるという利点がある。この柔軟性はまた、「セキュリティの考慮事項」で説明されているように、グループ間で署名鍵がリンクされな い可能性と、デバイスが漏洩した後にメッセージの認証と秘密性を回復するのに必要な時間との間で、セキュリ ティ上のトレードオフの代償を伴うことになる。

最終的には、アプリケーションがプロトコル署名鍵を含むクレデンシャルとアイデンティティを認証サービスに対していつでもチェックできることが唯一の要件となります。

定義により、認証サービスには大量の信頼が投資されています。悪意のあるASは、システムのどのユーザにもなりすますことができる。これに関連して、グループのメンバーであることを許可されたIDになりすますことで、ASは機密性を破ることができます。

このリスクは、鍵の透明性(KT) [KeyTransparency]のような公開ログでIDと鍵の結合を公開することで軽減されます。公開鍵のロギングを一切行わずに機能的な MLS システムを構築することも可能であるが、そのようなシステムは、悪意のある AS や信頼されていない AS からの攻撃に対して、必然的に多少の脆弱性を持つことになる。

2.3. デリバリーサービス

デリバリーサービス(DS)は、サービスプロバイダのアーキテクチャにおいて複数の役割を果たすことが期待されています。

  • クライアントが使用するための初期キーイング素材を提供するディレクトリサービスとして機能します。これにより、クライアントは共有鍵を確立し、他のクライアントがオフラインの場合でも暗号化されたメッセージを他のクライアントに送信することができます。
  • クライアント間でメッセージをルーティングし、メッセージのブロードキャスタとして機能し、一つのメッセージを取り込み、複数のクライアントに転送します(「サーバサイドファンアウト」としても知られています)。

MLS プロトコルは、クライアントがアプリケーションメッセージを非同期的に送受信する方法を提供するため、送信者からのアプリケーションメッセージの因果的な順序付けのみを提供する一方で、グループアグリーメントを提供するためにグループ操作のグローバルな順序付けを強制しなければなりません。

グループがデリバリサービスに与える信頼度に応じて、MLS が提供する機能保証とプライバシー保証は異なりますが、認証と機密性の保証は変わりません。

認証と機密性を信頼されている認証サービスとは異なり、デリバリサービスは本物件に関しては全く信頼されていません。DS サーバのファンアウトの場合にはグループメンバーのプライバシーが問題になるかもしれませんが、セキュリティ解析の観点からは、デリバリーサービスは能動的な適応型ネットワーク攻撃者と考えることができます。

2.3.1. 鍵の保管

システムに参加すると、各クライアントは最初の暗号鍵素材をデリバリーサービスに保存します。この鍵素材は、KeyPackage と呼ばれ、クライアントの機能能力(サポートされているプロトコルのバージョンや拡張機能、以下の暗号情報など)を宣伝します。

  • 認証サービスからのクレデンシャル アイデンティティとクライアントの署名鍵の結合を証明する認証サービスからのクレデンシャル。
  • クライアントの非対称暗号化キーは、クレデンシャルに関連付けられた署名キーで署名されている。

上述したように、ユーザーは複数のクライアントを所有することができ、それぞれが独自のキーイング・マテリアルを 持つため、各ユーザーによって格納されるエントリが複数存在する可能性がある。

配信サービスはまた、ユーザが初期のキーイング資料を追加、削除、更新できるようにし、これらの鍵の 識別子が DS に格納されているすべての鍵にわたって一意であることを保証する責任を負う。

2.3.2. 鍵の検索

クライアントがグループの確立を希望する場合、クライアントはまず DS に連絡して、他の各クライアントの KeyPackage を要求し、署名鍵を使用して認証を行い、それらを使用してグループを形成することができる。

2.3.3. メッセージと添付ファイルの配信

デリバリーサービスの主な責任は、メッセージの配信を確実に行うことである。具体的には、DSが提供することを想定しています。

  • 信頼性の高い配信: メッセージがDSに提供されると,最終的にすべてのクライアントに配信される.
  • インオーダー配信: メッセージは,配信サービスが受信した順番でグループに配信され,クライアントが送信した順番とほぼ同じ順番でグループに配信される.後者は、複数のクライアントが同時にメッセージを送信する可能性があるため、DSはクライアント間での順序付けを強制する際にある程度の余裕が必要となるため、おおよその保証となります。
  • 一貫性のある順序: DSは、すべてのクライアントが暗号に関連した操作のためのメッセージの 順序について同じ見解を持っていることを保証しなければならない。これは、DSがグループ操作メッセージの順序のグローバルな一貫性を強制しなければならない[MUST]ことを意味する。

このプロトコルでは、MLSCiphertext メッセージの中で、3つの重要な情報を提供しています。

  • グループ識別子(GID) メッセージが送信されたグループを識別するためのグループ識別子(GID)です.
  • エポック番号は、特定のGIDに関連付けられたグループの変更回数(バージョン)を表し、同じグループからの2つのメッセージの辞書的順序付けを可能にします。
  • メッセージのコンテンツタイプ。これにより、DS はメッセージの順序付け要件を決定することができます。

MLS プロトコル自体がこれらの特性を検証することができます。例えば、DS がクライアントからのメッセージを再注文したり、異なるクライアントに矛盾した順序を提供したりした場合、クライアントはこの不正行為を検出することができます。しかし、プロトコルは、クライアントに進化するグループステートの一貫したビューを提供するために、エポックごとに 1 つの正直なグループ操作メッセージのみがクライアントに送信されるという事実に依存しています。

DS の誤動作のいくつかの形態はまだ可能性があり、検出するのが難しいことに注意してください。例えば、DS はクライアントとのメッセージの中継を拒否することができます。ある種のサイド情報がないと、他のクライアントは一般的にこの形式のDoS攻撃を区別することができません。

2.3.4. メンバーシップの知識

グループのメンバーシップはそれ自体が機密情報であり、MLS は永続化されたメタデータの量を大幅に制限するように設計されています。しかし、大規模なグループでは、サーバのファンアウトを提供するインフラストラクチャが必要になることがよくあります。クライアントファンアウトの場合、メッセージの送信先はすべてのクライアントが知っているため、サーバは通常この情報を必要としません。しかし、トラフィック分析を通してこの情報を知ることができるかもしれません。残念ながら、サーバ側のファンアウトモデルでは、あるクライアントが他のクライアントに同じメッセージを送信していることをDSが知ることができます。さらに、MLS のアプリケーションの中には、グループメンバーのリストが DS に関連付けられたいくつかのサーバに格納されているものもあるかもしれません。

このような知識は、認証や機密性を破るものではありませんが、プライバシー上の重大な問題となります。機能のためにメタデータを保持しなければならない場合には,メタデータは暗号化して保存されるべきである[SHOULD].

2.3.5. メンバーシップとオフラインメンバー

Forward Secrecy (FS) と Post-Cromise Security (PCS) は、キーイング素材の能動的な削除と交換に依存しているため、持続的にオフラインになっているクライア ントは古いキーイング素材を保持している可能性があり、後にそれが危殆化した場合、FS と PCS の両方にとって脅威となります。

MLS は、特にクライアントがメッセージを処理していない場合、この問題を本質的に防御することはできませんが、MLS を使用するシステムは、これらのプロパティを保持するために何らかのメカニズムを強制することができます。一般的には、長すぎる時間アイドル状態にあるクライアントを退避させることで、 危殆化の脅威を回避することができます。このようなメカニズムの正確な詳細は、ローカルポリシーの問題であり、この文書の範囲を超えています。

3. システム要件

3.1. 機能要件

MLS は大規模なグループメッセージングプロトコルとして設計されており、ユーザに性能と安全性を提供することを目的としています。MLS を実装したメッセージングシステムは、2 人以上のメンバーを含む会話をサポートし、50,000 人規模のグループ、通常は複数のデバイスを使用する多くのユーザを含むグループへの拡張を目指しています。

3.1.1. 非同期利用

MLS の操作では、2つの異なるクライアントやメンバーが同時にオンラインになっている必要はありません。特に、MLS を使用して保護された会話に参加しているメンバーは、共有鍵を更新したり、新しいメンバーを追加したり削除したり、他のユーザーからの返信を待つことなくメッセージや添付ファイルを送信することができます。

MLS を実装するメッセージングシステムは,メッセージを非同期かつ確実に配信するためのトランスポート層を提供しなければなりません.

3.1.2. 状態喪失後の復旧

ローカルMLSの状態が失われたり破損したりした会話参加者は、状態を再初期化して会話に参加し続けることができます。

[[OPEN ISSUE: 前の文は強すぎるようですが、状態回復に関してどのような正確な機能要件があるのかを確立してください。前回までは "これはある程度のレベルのメッセージ損失を伴うかもしれないが、グループからの永久的な排除にはならない"]]

3.1.3. 複数デバイスへの対応

通常、グループ内のユーザーが異なるデバイスを所有することが期待されています。

新しいデバイスはグループに追加され、プロトコルによって新しいクライアントとみなされます。このクライアントは、たとえそれがグループの他のメンバーを所有している人が所有していても、履歴にアクセスすることはできません。履歴の復元は通常、プロトコルレベルでは許可されていませんが、アプリケーションは MLS の外でそのようなメカニズムを提供することを選択することができます。このようなメカニズムを使用すると、MLS が提供する FS や PCS の保証が損なわれる可能性があります。

3.1.4. 拡張性/プラグイン性

グループの状態に影響を与えないメッセージは、そのペイロードをグループメンバー間で共有する目的で任意のペイロードを運ぶことができる。ペイロードの形式については何も仮定しない。

3.1.5. プライバシー

プロトコルは、サーバー側(ASとDS)のメタデータのフットプリントを制限するように設計されています。DS はメッセージの配信に必要なデータのみを保持し、個人識別情報(PII)やその他の機密性の高いメタデータを可能な限り回避します。ASとDSの両方を制御しているサービスプロバイダは、DSが転送する暗号化されたメッセージを、ASが署名した初期公開鍵と相関させることはできない。

[[OPEN ISSUE: これらのプライバシーに関する声明は非常に強いように見える。BB. Server-Assistドラフトに解決策の例があるので、私はそれらを要件として保持しても構わないと思います。]

3.1.6. フェデレーション

本プロトコルは、フェデレーション環境との互換性を目的としている。本文書では、フェデレーションに必要なすべてのメカニズムを規定しているわけではないが、複数の MLS 実装が互換性のある認証メカニズムとインフラストラクチャ機能を使用していれば、相互運用してフェデレーションシステムを形成することが可能である。

3.1.7. 将来のバージョンの MLS との互換性

将来的には、MLS の複数のバージョンが共存できるようにすることが重要です。このメカニズムは、攻撃者がエンドポイントから提供されたバージョンよりも低いプロトコルバージョンのメッセージを積極的に書き換えようとするバージョンダウングレード攻撃を防ぎます。MLS の複数のバージョンが利用可能な場合、ネゴシエーションプロトコルは、合意されたバージョンがそのグループで共通にサポートされている最高バージョンであることを保証します。

MLS 1.0 では、グループの作成者は、クライアント間で提案された最適な暗号スイートを選択する責任があります。各クライアントは、少なくとも最初のグループ操作メッセージを受信すると、常にプロトコルのバージョン、暗号スイート、拡張機能の可用性を確認することができます。

3.2. セキュリティ要件

3.2.1. クライアントとサーバー間の接続(1 対 1)

すべてのトランスポート接続は、TLS(参考文献[RFC8446])のような何らかのトランスポート層のセキュリ ティメカニズムを介してセキュリティが確保されていると仮定する。しかし、上述したように、MLSのセキュリティは、ASによって提供されたID鍵が最低限認証されている限り、一般的にはトランスポート層の危殆化を免れるだろう。ただし、MLS の暗号文には、グループ識別子、エポック番号、コンテンツタイプが含まれており、グループのプライバシーに対する攻撃を改善するために使用される可能性がある。

3.2.2. メッセージの秘密性と認証

MLS プロトコルの信頼確立ステップの後には、会話保護ステップがあり、ここではクライアントが暗号化を使用して認証済みメッセージを DS を介して他のクライアントに送信します。これにより、DS がグループのプライベートコンテンツにアクセスできないようにします。

MLS は、すべてのメッセージに対して機密性、完全性、認証を提供することを目的としています。

MLS の文脈におけるメッセージの秘密性とは、意図した受信者(現在のグループメンバー)のみが、グループに送信されたメッセージを読み取ることができることを意味し、たとえ脅威モデルで説明されているようなアクティブな攻撃者の文脈であっても、グループに送信されたメッセージを読み取ることができることを意味します。

メッセージの完全性と認証とは、誠実なクライアントはグループのメンバーから送られたメッセージのみを受 け取ることができ、他のクライアントが他のクライアントからのメッセージであると受け入れることができない ことを意味します。

この記述の裏返しとして、AS と DS はグループのメンバーではないので、メンバー間で送信されたメッセージの内容を読み取ることはできません。MLS は、攻撃者やメッセージングシステムの漏洩したメンバーがメッセージのサイズに応じてメッセージの内容を推理する能力を減らすために、 トラフィック解析に関する追加の保護機能をオプションで提供しています(例えば、メッセージのサイズに応じてメッセージの内容を推理することができます)。これらの保護の一つには、標準的な長さの暗号文を生成するためにメッセージをパディングすることが含まれています。この保護は非常に推奨されていますが、クライアントと SP のパフォーマンスの点でコストがかかるため、必須ではありません。

メッセージに署名する前に、署名鍵が否認可能なチャネルで交換されていれば、メッセージの内容は否認可能である可能性がある。

3.2.2.1. フォワードおよび妥協後のセキュリティ

MLS は、過去のメッセージと将来のメッセージの秘密性に関する追加の保護を提供します。これらの暗号セキュリティ特性は、Forward Secrecy (FS) と Post-Cromise Security (PCS) です。

FS とは、すべての暗号化されたトラフィックの履歴へのアクセスと、クライアント上のすべての現在のキーイング材料へのアクセスを組み合わせても、漏洩したクライアントの最古のキーよりも古いメッセージの秘密性の特性は破られないことを意味します。これは、クライアントが期待されるメッセージで使用されたらすぐに適切な鍵を削除するという極めて重要な役割を持っていることを意味します。

PCS とは、ある時刻 t でグループメンバーの状態が危殆化したが、その後、ある時刻 t' にグループメンバーが更新を行った場合、時刻 t' 以降にそのメンバーが送信したメッセージと、他のメンバーが更新を処理した後に送信したメッセージには、すべての MLS の保証が適用されることを意味しています。例えば、攻撃者が時刻 t において、アリスの長期秘密鍵と共有グループ鍵の両方を含む、 アリスが知っているすべての秘密を学習したが、アリスが時刻 t' に鍵の更新を行った場合、更新が処理された後では、攻撃者は MLS のセキュリティ特性のいずれにも違反することができない。

これらの特性は、侵害された DS や AS に対しても満たされる。

3.2.2.2. メンバーシップの変更

MLS は、グループメンバーの合意を提供することを目的としています。これは、グループメンバー全員が現在のグループメンバーのリストに合意していることを意味します。

アプリケーションによっては、特権を持つクライアントやユーザにグループメンバーの追加や削除を制限するために、ACL を実施したい場合もあるでしょう。また、現在のグループメンバーまたはそのサブセットからの承認を要求したい場合もあるでしょう。いずれにしても、MLS は、他のすべてのメンバーに通知することなく、グループメンバーの追加や削除を許可しません。

クライアントがグループの一部になると、ユーザーが管理するデバイスのセットを変更できるのは、グループの承認を受けた メンバーのみです。アプリケーションによっては、グループの特定のメンバーが他のメンバーに代わってデバイスを追加または削除することを許可したい場合もあれば、より厳格なポリシーを要求し、PCS 保証が弱くなる可能性を犠牲にしてデバイスの所有者のみにデバイスの追加または削除を許可する場合もあります。

グループから削除されたメンバーは特別な特権を享受しない。削除されたグループメンバーの危殆化は、削除後に送信されたメッセージのセキュリティには影響しないが、グループの秘密が適切に削除されていない場合、以前のメッセージに影響を与える可能性がある。

3.2.2.3. 並列グループ

どのユーザーも、同時に複数のグループのメンバーを持つことができます。いずれかのグループのメンバーの集合は、他のグループのメンバーのサブセットを形成してもしなくても構いません。MLS は、ユーザが複数のグループに所属していることによって、FS と PCS の目標が維持され、弱体化することがないことを保証します。

3.2.2.4. 添付ファイルのセキュリティ

MLS プロトコルにおける添付ファイルに期待されるセキュリティ特性は、メッセージに期待されるものと非常によく似ています。メッセージと添付ファイルの間の区別は、メッセージのダウンロードと添付ファイルのダウンロードの間の典型的な平均時間が異なる可能性があるという事実に由来します。多くの理由(高帯域幅のネットワーク接続がないことが典型的な理由)から、添付ファイルの暗号鍵の寿命は通常、メッセージよりも高く、そのため、添付ファイルのPCS保証がわずかに弱くなる。

3.2.2.5. サービス拒否

一般的に、サービス拒否(DoS)に対する耐性はプロトコルの責任とは考えていません。しかし、DS 以外の誰もが、回復が困難な些細な DoS 攻撃を行うことはできないはずである。

3.2.2.6. 非否認性と否認性

セクション 4.4 で説明したように、MLS は、グループ内での強力な認証を提供しています。さらに、サービスによっては、不正使用を報告するために、受信者がサービス提供者に対して、そのメッセージが特定のクライアン トから送信されたものであることを証明することを要求する場合もあります。MLS は、これらのユースケースの両方をサポートしています。いくつかの配備では、これらのサービスは受信者がメッセージの出所を第三者に証明できるようなメカニズムによって提供されています(これはしばしば「否認防止」と呼ばれています)が、そのような証明が不可能な「否認可能」モードで MLS を運用することも可能であるべきです。[[OPEN ISSUE: 正確には、これをどのように提供するかはまだプロトコルの問題である。]

4. セキュリティに関する考察

MLS は、インターネット脅威モデル [RFC3552] を採用しているため、攻撃者がネットワークを完全に制御していることを前提としています。MLS は、そのような攻撃者に直面して記述されたセキュリティサービスを提供することを意図している。さらに、このセクションの残りの部分で説明するように、トランスポートセキュリティリンクやクライアン ト、メッセージングシステムのエレメントの両方が侵害された場合、これらの保証は緩やかに劣化することを意図しています。

4.1. トランスポートセキュリティリンク

TODO: DoS、メッセージ抑制、グループメンバーの漏洩がほとんど]

4.2. 配信サービスの妥協

MLS は、DS が危殆化した場合に強力な保証を提供することを目的としています。完全に危殆化した DS であっても、正当なクライアントが受け入れられるようなメッセージを読み取ったり、メッセージを注入したりすることはできないはずです。また、検出不能なほどにメッセージを削除したり、並べ替えたり、再生したりすることもできないはずである。

しかし、DS はシステム上でさまざまな DoS 攻撃を行うことができます。これには、全体的な DoS 攻撃(メッセージの転送を単純に拒否する)や部分的な DoS 攻撃(特定のクライアントとの間でメッセージの転送を拒否する)などがあります。セクション2.3.3で述べたように、これらの攻撃は、帯域外チャネルを持たないクライアントでは部分的にしか検出できない。最終的には、DSが合理的なサービスを提供できなかった場合は、技術的な問題ではなく、顧客サービスの問題として対処しなければならない。

DS はクライアントに初期の鍵作成材料を提供する責任があるため、古い鍵を提供する可能性がある。これは本質的にはメッセージストリームの漏洩にはつながらないが、限られた範囲でフォワードセキュリティを 攻撃することは可能である。この脅威は、初期鍵の有効期限が切れるようにすることで緩和できる。

4.3. 認証サービスの危殆化

侵害されたASは、ASが誤った、または攻撃者が提供したIDをクライアントに提供する可能性があ るため、深刻な問題である。セクション 2.2 で述べたように、この形式の攻撃を検出するには、何らかの透過性/ロギングのメカニズムが必要である。このようなメカニズムがなければ、MLS は漏洩した AS を検出することができません。

4.4. クライアントの危殆化

MLS は PCS を通じて、漏洩したクライアントに対する限定的な保護を提供しています。クライアントが完全に侵害されると、攻撃者はクライアントが所属するグループのメッセージを復号化し、 侵害されたクライアントになりすましてメッセージを送信することができます。ただし、クライアントがその後でキーイング材料を更新した場合(3.2.2.2.1 参照) (攻撃者が知らない新しいランダム性を使用して)、PCS プロパティでクライアントを回復することができます。

さらに、クライアントは、異なる ID を持つ別のクライアントからのメッセージをグループに送信することはできません。同じユーザーのデバイスがキーイング材料を共有している場合、1 つのデバイスが別のデバイスになりすますことができることに注意してください。

最後に、クライアントはDoS攻撃を実行できないようにすべきではありません。

作成者以外のコメントは許可されていません