Messaging Layer Security
グループ通信のための暗号化プロトコル
From Wikipedia, the free encyclopedia
Messaging Layer Security（メッセージング・レイヤー・セキュリティ、MLS）は、エンドツーエンド暗号化されたグループメッセージングのためのIETF標準プロトコルである。2023年7月に RFC 9420 として公開された。MLSは、盗聴・改竄・メッセージ偽造への耐性に加え、前方秘匿性と侵害後安全性（post-compromise security）を備えたグループ鍵合意を提供するよう設計されている。[1][2]
- Richard Barnes
- Benjamin Beurdouche
- Raphael Robert
- Jon Millican
- Emad Omara
- Katriel Cohn-Gordon
MLSは、1対1通信向けの暗号プロトコルを単純に拡張した場合に生じる、参加者数の増加に伴う鍵更新コストの増大を抑えることを目的とする。RFC 9420 では、木構造を用いた非同期グループ鍵共有により、グループ状態の更新コストを概ね参加者数の対数オーダーで扱える方式として規定されている。[1]
概要
MLSは、メッセージングアプリケーション向けのグループ鍵合意プロトコルである。各クライアントはグループに参加する際に公開鍵や能力情報を含む KeyPackage を用い、グループは一定時点ごとの共有状態を epoch（エポック）として管理する。メンバー追加・削除・鍵更新などの変更は Proposal と Commit によって反映され、各エポックごとに共有秘密が更新される。[1]
RFC 9750 では、MLSそのものが標準化するのは主としてグループ内の暗号状態共有であり、配送サービス（Delivery Service）や認証サービス（Authentication Service）、利用者識別子の扱いなど、アプリケーション固有の周辺インフラは別途設計を要すると整理している。[2]
背景
2者間通信では、Signalプロトコルのようなダブルラチェット方式が強い前方秘匿性と侵害後安全性を提供する。一方で、グループ通信において同様の性質を保ちながら大規模化へ対応することは難しく、単純なペアワイズ暗号化や sender key 方式では、鍵更新や侵害後回復のコストが大きくなりやすい。RFC 9420 は、こうした課題への対処として、木構造に基づく非同期なグループ鍵共有を採用している。[1]
MLSの設計的背景には、2017年に公表された Cohn-Gordon らの Asynchronous Ratcheting Trees (ART) に関する研究がある。この研究は、非同期なグループメッセージングにおいて、木構造ベースで共有鍵を効率的に更新する考え方を提示し、後のMLSの基盤となった。[3]
プロトコルの構成
MLSでは、グループの共有状態はラチェット木（Ratchet Tree）により表現される。各メンバーは葉に対応し、内部ノードに対応する秘密値からグループ共有秘密が導出される。メンバーの追加・削除・更新に応じて木の一部を更新することで、全参加者に対する再鍵配送を避けつつグループ状態を前進させる。[1]
この鍵更新機構は一般に TreeKEM と呼ばれる。MLSの標準化過程では、鍵共有だけでなく、メンバーシップ変更の認証的な取り扱いも重要論点となり、TreeSync などの研究を通じて仕様の検証と改良が進められた。2023年のWallezらの研究は、MLSのグループ管理部分に対する形式的分析を行い、標準化過程の設計改善にも寄与した。[4]
MLSでは、鍵更新の材料としてグループ内部の更新だけでなく、Pre-Shared Key（PSK）を取り込むこともできる。RFC 9420 は、外部で共有された秘密値を鍵スケジュールへ注入する機構を定義しており、これにより外部の鍵共有機構とMLSを組み合わせて運用することができる。[1]
暗号スイート
MLSでは、鍵交換、公開鍵暗号、認証付き暗号、ハッシュ関数、署名方式の組合せを暗号スイートとして定義する。RFC 9420 では複数の暗号スイートが登録されており、MLS 1.0 の必須実装は `MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519` である。これは鍵交換に X25519、AEAD に AES-128-GCM、ハッシュに SHA-256、署名に Ed25519 を用いる構成である。[1]
RFC 9420 ではこのほか、P-256、P-384、P-521 や、AES-256-GCM、ChaCha20-Poly1305 などを含む複数の暗号スイートが定義されている。MLSでは暗号スイートにより、グループ状態の管理やメッセージ保護に用いる暗号学的構成要素を統一的に指定する。[1]
メッセージ形式
MLSでは、グループ参加や初期化のために KeyPackage、GroupInfo、Welcome といったオブジェクトを用いる。KeyPackage は未参加クライアントが公開する参加用オブジェクトであり、プロトコル版、暗号スイート、初期 HPKE 公開鍵、LeafNode、拡張、署名から構成される。[1]
グループの既存メンバーが新しい参加者を追加する際には、その参加者の KeyPackage を用いて Add 提案を行い、Commit に対応する Welcome メッセージを生成する。Welcome は暗号スイート、新規参加者向けの暗号化されたグループ秘密、および暗号化された GroupInfo を含み、新規参加者はこれを用いて自らのグループ状態を初期化する。[1]
GroupInfo は、新規参加者が現在のグループ状態を把握するための情報を含むオブジェクトであり、通常は Welcome の内部で暗号化されて配送される。Welcome の処理にはラチェット木の取得も必要であり、これは Welcome 内の拡張として与えることも、配送サービスなど別経路で取得することもできる。[1]
セキュリティ特性
MLSの設計目標には、メッセージ機密性、完全性、送信者認証、グループメンバーシップ認証、非同期性、前方秘匿性、侵害後安全性、拡張性が含まれる。[1][2]
前方秘匿性とは、ある時点より後にメンバーの秘密鍵が侵害されても、過去のメッセージ機密性が保たれる性質である。侵害後安全性とは、過去に侵害が起きていても、その後に適切な鍵更新が行われれば将来の通信の安全性を回復できる性質をいう。RFC 9420 では、エポック間でメンバーが葉鍵を更新することにより、侵害後安全性が達成されると説明されている。[1]
RFC 9420 はまた、各エポックに対して epoch authenticator を導出する。これは、参加クライアントが同一のグループ状態を共有しているかを確認するための補助的な検証値として用いられ、グループの分断や状態不一致の検出に役立つ。[1]
MLSでは、グループ状態に結び付いた秘密値をアプリケーション側へ提供するため、exporter 機構も定義されている。RFC 9420 の `MLS-Exporter` は、特定エポックの状態に束縛された派生秘密を生成するものであり、アプリケーションが関連機能のために追加の鍵素材を得る用途を想定している。[1]
ただし、RFC 9750 が述べるように、実際の安全性はアプリケーション側の認証基盤、鍵配布ポリシー、配送サービスの挙動、公開鍵更新頻度などにも依存する。そのため、MLSの導入はプロトコル実装だけで完結せず、周辺システム設計と一体で検討する必要がある。[2]
資格情報と運用上の論点
MLSでは、各クライアントが署名鍵と結び付いた資格情報（credential）を用いて自らを識別する。資格情報の形式には basic credential や X.509 証明書などがあり、アプリケーション設計に応じて選択される。[1][2]
RFC 9420 は、資格情報の失効や有効期限管理がグループ運用上の重要課題になると指摘している。たとえば、期限切れの資格情報を含むグループ状態は、新規参加者による検証失敗や参加拒否の原因となりうるため、実装はグループ内で用いられる資格情報を継続的に有効な状態へ保つ必要がある。[1]
RFC 9750 はまた、単純な basic credential は利用者識別子と公開鍵との暗号学的結び付きが弱く、認証基盤の設計によっては鍵置換攻撃に弱くなりうることを説明している。そのため、MLSの安全な運用には、どの資格情報型を使うか、また識別子と鍵をどのように結び付けるかが重要となる。[2]
アーキテクチャ
RFC 9750 は、MLSを用いるメッセージング基盤の抽象サービスとして、Delivery Service（DS）とAuthentication Service（AS）を区別している。Delivery Service はメッセージの受信・配送、グループメッセージのブロードキャスト、ならびに MLS クライアントが必要とする初期公開鍵素材の保存・配送を担う。[2]
これに対し Authentication Service は、アプリケーション上の識別子と MLS における認証鍵の結び付きを証明する資格情報の発行と検証を担う。RFC 9750 は、MLSの相互運用性はプロトコル本体で規定される一方、実際の安全性は配送基盤や認証基盤の設計にも強く依存すると指摘している。[2]
配送サービスは単なる転送機構ではなく、特に Commit の線形順序を各参加者へ一貫して提示する役割を持つ。MLSのグループ状態遷移はこの順序づけに依存しており、配送サービスの設計はグループ整合性に大きな影響を与える。[2]
一方で、RFC 9750 は、配送サービスが悪意を持つ場合や不正に動作する場合には、メッセージの遅延、選択的配送拒否、参加者ごとに異なるビューの提示、グループ分断といった問題を完全には防げないと説明している。こうした状態不一致は、場合によっては `epoch authenticator` などを帯域外で比較することで検出される。[2][1]
また、配送サービスが古い KeyPackage を配布した場合、直ちにメッセージ機密性が失われるとは限らないが、侵害後安全性の回復が弱められる可能性がある。RFC 9750 はこのような stale KeyPackage の問題を、周辺基盤に由来するリスクの一例として挙げている。[2]
認証サービスが侵害された場合の影響は特に大きい。RFC 9750 は、認証サービスの侵害により、利用者識別子と資格情報の不正な結び付け、偽の資格情報の発行や署名が可能となりうると述べており、周辺インフラの信頼性はMLS全体の安全性に大きく影響する。[2]
再初期化
標準化の経緯
MLSの構想は2010年代後半に具体化し、IETFのワーキンググループで標準化が進められた。2023年3月、IETFは Messaging Layer Security を新標準として公開承認した。[5]
その後、MLSプロトコル本体は2023年7月に RFC 9420 として公開された。IETFは公表時点で、MLSがインターネット規模のグループ通信に対して、より効率的なエンドツーエンド暗号化を提供する標準であると説明している。[1][6]
さらに、利用アーキテクチャを整理する文書として RFC 9750 が2025年に公開された。これは標準本体を補完し、配送サービスや認証サービスを含む実運用上の考慮点をまとめたものである。[2]
実装と採用動向
MLSの実装としては、Rust製の OpenMLS、AWS Labs の mls-rs、C++ 製の MLS++ などが知られる。OpenMLS は RFC 9420 に準拠したオープンソース実装を掲げており、アプリケーションの構成要素として利用されることを想定している。mls-rs も RFC 9420 への適合を掲げる実装である。[7][8][9]
採用面では、IETFのRFC公開時に、Googleが相互運用可能な安全なメッセージングに向けてMLSを支持していることを表明した。のちにGoogleは、Google メッセージ向けの安全なRCSメッセージングでMLSを実装対象として扱っていることを公表している。[10][11]
また、GSMAは2025年3月に公開した RCS Universal Profile 3.0 について、エンドツーエンド暗号化の仕組みとしてMLSを取り込んだことを案内している。[12][13]
分散型メッセージングプロトコルのMatrixでも、MLSは将来のグループ暗号化の有力候補として位置づけられており、Matrix.org Foundation は2023年にMLSを「大きな前進」と評価している。[14][15]
ポスト量子暗号対応
MLSは HPKE を基盤としているため、将来的なポスト量子暗号対応も検討されている。2026年時点では、IETFにおいて ML-KEM や従来方式とのハイブリッド KEM を用いる MLS 向け暗号スイート案が議論されている。これらは、量子計算機の実用化以前に記録された通信が後年に解読される、いわゆる "harvest now, decrypt later" 型の脅威への対策を意図したものである。[16][17]
ただし、これらは標準化途中の草案であり、提案されている一部の暗号スイートはポスト量子機密性を重視する一方で、真正性の面では従来署名方式に依存するものもある。したがって、MLSのポスト量子対応は進行中の拡張領域である。[18]