Open5

Using Messaging Layer Security (MLS) to Provide Keys for SFrame

抄録

Secure Frames (SFrame)は、リアルタイムメディアを暗号化するためのコンパクトなスキームを定義しています。SFrameが多くの参加者間でメディアが交換される場合(例:リアルタイム会議)に対応するためには、グループ鍵管理プロトコルで強化する必要があります。MLS(Messaging Layer Security)プロトコルは、継続的なグループ認証鍵交換を提供し、メディアセッションの参加者のグループがお互いを認証し、グループ鍵に合意することを可能にします。このドキュメントでは、MLSによって生成されたグループ鍵がどのようにSFrameで使用され、グループのリアルタイムセッションをセキュアにすることができるかを定義しています。

1. 序章

Secure Frames (SFrame)は、リアルタイムメディアを暗号化するためのコンパクトなスキームを定義しています。SFrameが多くの参加者間でメディアが交換される場合(例:リアルタイム会議)に対応するためには、グループ鍵管理プロトコルで拡張する必要があります。Messaging Layer Security (MLS)プロトコル[!I-D.ietf-mls-protocol]は、継続的なグループ認証鍵交換を提供します。MLSはいくつかの重要なセキュリティ特性を提供する[!I-D.ietf-mls-arch]。

  • グループ鍵交換。グループ鍵交換: ある時点でのグループの全メンバーは、グループ外の関係者がアクセスできない秘密鍵を知っている。
  • グループメンバーの認証。グループの各メンバーは、グループの他のメンバーを認証することができます。
  • グループの合意。グループのメンバーは、グループ内の参加者の身元について全員が同意します。
  • Forward Secrecy(前方秘匿)。イベント後にメンバーの状態が危殆化しても、イベント前に作成されたグループの秘密が安全であるようなプロトコルイベントがあります。
  • 危殆化後のセキュリティ。イベントの前にメンバーの状態が漏洩した場合、イベントの後に作成されたグループ秘密が安全であるようなプロトコルイベントがあります。

リアルタイムセッションが MLS を SFrame キーの基礎として使用する場合、これらのセキュリティ特性はリアルタイムメディアにも適用されます。このドキュメントの残りの部分では、MLS で生成された秘密を使って SFrame で必要な鍵を生成する方法を定義します。

2. SFrameキーの管理

MLS は、ある時点でグループのメンバー間で共有されている鍵の線形シーケンスを生成します。あるメンバーがグループに参加したり、グループを離れたりすると、新しい鍵が生成されますが、その鍵はグループが拡張されたり縮小されたりした場合にのみ知ることができます。グループの寿命の各ステップは「エポック」として知られており、グループの各メンバーには、グループ内にいる時間だけ一定の「インデックス」が割り当てられています。

SFrame では、エポックのグループ秘密から送信者ベースの_key 値を導出し、KID フィールドを使ってエポックと送信者インデックスを通知します。まず、MLS exporter を使用して、エポックの共有 SFrame 秘密を計算します。

sframe_epoch_secret = MLS-Exporter("SFrame 10 MLS", "", AEAD.Nk)

sender_base_key[index] = HKDF-Expand(sframe_epoch_secret, encode_big_endian(index, 4), AEAD.Nk)

オープンな問題: MLS は、あるエポック内でより良いフォワードシークレット特性を提供する独自の「シークレットツリー」を持っています(このスキームは何も提供していません)。(このスキームは何も提供していない。) 代替的なアプローチとしては、MLSの秘密木を直接またはデータ構造として再利用することであろう。]]

SFrame ヘッダーのキー ID (KID) フィールドは、MLS キースケジュールから適切なキーを生成するために必要なエポック値とインデックス値を提供します。

KID = (sender_index << E) + (epoch % (1 << E))

コンパクトにするために、エポック番号全体を送らないでください。その代わりに、低次のEビットだけを送る。グループの参加者は、ここで指定されていないネゴシエーションを通じて、与えられたセッションのEの値に同意しなければならない[MUST]。

Eは効果的に再順序付けのウィンドウを定義していることに注意してください。参加者が鍵のロールオーバーに関して同期が取れているほど、また、ネットワークによる SFrame で保護されたペイロードの並べ替えが少ないほど、必要とされるエポックのビット数は少なくなります。

受信機は、同じ E 下位ビットの新しいエポックが導入されたときに古いエポックを削除して、エポックカウンタがロールオーバーすることに備えなければならない (MUST)。

[[ OPEN ISSUE: 新規加入者への配慮があるかもしれません。自分がエポックNにいるのか、エポックN + 1 << Eにいるのかを検出するために、いくつかの試行的な復号化が必要になるかもしれません。]

SFrame スタックにエポック用の sframe_epoch_secret がプロビジョニングされると、必要な KID と sender_base_key の値を必要に応じて計算することができます。

        ...
         |
Epoch 17 +--+-- index=33 -> KID = 0x211
         |  |
         |  +-- index=51 -> KID = 0x331
         |
         |
Epoch 16 +--+-- index=2 --> KID = 0x20
         |
         |
Epoch 15 +--+-- index=3 --> KID = 0x3f
         |  |
         |  +-- index=5 --> KID = 0x5f
         |
         |
Epoch 14 +--+-- index=3 --> KID = 0x3e
         |  |
         |  +-- index=7 --> KID = 0x7e
         |  |
         |  +-- index=20 -> KID = 0x14e
         |
        ...

また、MLS は各参加者に対して認証済みの署名鍵ペアを提供します。SFrame が署名を使用する場合、これらの鍵は SFrame の署名を生成するために使用されます。

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

MLSが提供するセキュリティ特性については、[!I-D.ietf-mls-arch]と[!I-D.ietf-mls-protocol]で詳しく説明しています。このドキュメントでは、これらの保証を SFrame に拡張しています。

ここで導出された送信者ごとの鍵は送信者ごとの認証を提供しないことに注意してください。送信者ごとの鍵は、複数の非同期送信者間のnonce衝突を避けるためにのみ派生します。だからSFrameの認証の制限が残っています。署名が使用されている場合のみ、送信者ごとの認証があります。そうでなければ、SFrameはグループ内のメンバーを認証するだけで、メンバーは自由にお互いになりすますことができます。

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