---
title: "Discordの音声E2EEプロトコルDAVEをSwiftで受信・復号する"
description: "Discordがボイスチャンネル向けに導入したE2EEプロトコルDAVEについて、ボットとしてMLSグループに参加し、他参加者の音声をRTP受信からOpusデコードまでSwiftネイティブで復号する検証をしました。公式ドキュメントだけでは埋まらない、受信側実装だけで見える3つの落とし穴を扱います。"
category: "Apple"
tags: ["Swift","Discord","MLS"]
publishedAt: "2026-08-12"
lastmod: "2026-08-12"
---

Discordがボイスチャンネル向けに導入したE2EEプロトコルDAVEについて、ボットとしてMLSグループへの参加を成立させ、他参加者の音声をRTP受信からOpusデコードまでSwiftネイティブで復号する検証をしました。公式ドキュメントには明記されていない、rtpsize拡張ヘッダの暗号化範囲・PrepareEpochによるグループ再初期化・IP Discoveryのバイト順という、受信側の実装でしか見えない3つの落とし穴を扱います。

## DAVEとMLS

Discordは2024年9月に、音声・映像通話のエンドツーエンド暗号化プロトコル「[DAVE](https://discord.com/blog/meet-dave-e2ee-for-audio-video)」を発表しました。DAVEの[プロトコル白書](https://daveprotocol.com/)自体は「MLSプロトコル自体の説明はしない、それは[RFC 9420](https://www.rfc-editor.org/rfc/rfc9420)が担う範囲」と明記しているとおり、鍵合意の仕様は [MLS (Messaging Layer Security)](https://www.rfc-editor.org/rfc/rfc9420) 側にあります。DAVEはこのMLSのグループ鍵から、通話参加者だけが持つ送信者ごとのラチェット鍵を導出して、メディアフレームを暗号化します。[公式ドキュメント](https://docs.discord.com/developers/topics/voice-connections)は、ダイレクトメッセージ・グループDM・ボイスチャンネル・Go Liveストリームを含むすべての音声・映像通話について、2026年3月1日以降はE2EEのみをサポートすると明記しています。

DiscordはプロトコルのC++実装 [libdave](https://github.com/discord/libdave) をMITライセンスで公開しています。今回はこれをSwiftから直接呼び出し、ボイスチャンネルにボットとして参加してDAVEのグループ参加を成立させたうえで、他参加者の音声をRTPで受信し、トランスポート復号、DAVE復号、Opusデコードを経て話者ごとのWAVファイルに書き出すところまでを実装しました。送信(自分から音声を流す側)は対象外で、受信だけに絞ったPoCです。

この記事で扱う3つの落とし穴が、この経路のどこに現れるかを先に示しておきます。

![接続の確立はGateway、Voice Gateway、UDP IP Discovery、DAVE/MLSと進み、その後の受信はRTP受信、トランスポート復号、DAVE復号、Opusデコード、話者ごとのWAV書き出しと続く。rtpsizeのAAD範囲はトランスポート復号の位置に、PrepareEpochによるグループ再初期化はDAVE/MLSの位置に、IP Discoveryのバイト順はUDP IP Discoveryの位置に現れる](/images/posts/discord-dave-voice-decrypt-swift/receive-pipeline.svg)

## libdaveのC APIをSwiftから直接叩く

libdaveをSwiftから呼べること自体は、前回の記事で骨格だけを確認しています。セッションの作成・初期化・破棄が通ることまでを見た段階で、実サーバーへの接続やMLSの実データのやり取りは手つかずでした。今回はその続きにあたります。

::card[/posts/discord-dave-swift-libdave-c-interop]

libdaveはフラットなC APIとして公開されているので、SwiftPMの `systemLibrary` でモジュールマップを書けば、実験的なC++相互運用を使わずに通常のC interopで呼び出せます。py-cordやdiscord.jsのようなランタイムは介さず、暗号処理はCryptoKitとlibdaveだけで完結します。ラッパーの骨格は次のようになります(簡略化しています)。

```swift
final class DaveSession {
  let handle: DAVESessionHandle

  init?(authSessionId: String) {
    guard let handle = daveSessionCreate(nil, authSessionId, failureCallback, userData) else {
      return nil
    }
    self.handle = handle
  }

  func processCommit(_ commit: [UInt8]) -> CommitOutcome? {
    // MLSのCommitメッセージを処理し、ロスター更新を返す
  }
}
```

トランスポート層の暗号方式には `aead_aes256_gcm_rtpsize` を選びました。[Discordのドキュメント](https://docs.discord.com/developers/topics/voice-connections)は音声ゲートウェイが対応するモードとして `aead_xchacha20_poly1305_rtpsize` を必須と説明する一方、`aead_aes256_gcm_rtpsize` は利用可能なら優先すべきモードと位置づけています。CryptoKitはAES-GCMをネイティブでサポートしているため、こちらを選ぶとハンドシェイクだけでなく受信メディアの復号でも同じ実装を使い回せます。

## rtpsizeの拡張ヘッダ、暗号化されているのは値の部分だけ

最初につまずいたのがここです。受信したRTPパケットには拡張ヘッダ(先頭バイトが `0x90` でXビットが立っている)が付いていて、AEADの認証対象データ(AAD)がどこまでかを正しく決めないと復号に失敗します。

Discordのドキュメントは、rtpsizeモードの「暗号化されていないヘッダ」の範囲をSRTPの考え方に沿って説明し、RTP基本ヘッダ(CSRCを含む)と拡張プリアンブルまでを平文のまま認証されるAADとして扱うとしています。ただし、拡張ヘッダの値そのものが暗号化されているかどうかまでは明記していません。実際には、拡張ヘッダのうちAADに含まれるのはプリアンブル4バイトだけで、値の部分は暗号文に含まれています。復号後、暗号文の先頭からこの拡張値を取り除く処理が必要で、送信専用のライブラリでは扱わない部分のため、Pythonの [discord-ext-voice-recv](https://github.com/imayhaveborkedit/discord-ext-voice-recv) のような受信側の実装を読んで初めて、仕様の全体像が見えてきます。

![rtpsizeモードのRTPパケット構造。RTP基本ヘッダと拡張プリアンブルがAADとして平文のまま認証され、拡張値とDAVE/Opusフレームと認証タグが暗号化され、末尾4バイトのnonceはAAD対象外の平文](/images/posts/discord-dave-voice-decrypt-swift/rtpsize-aad.svg)

## PrepareEpochによるグループ再初期化

2つ目の落とし穴は退出処理です。DAVEのプロトコル仕様には、グループの参加者が1人まで減ったときの挙動が定義されています。

> When only a single member remains in an established group, the voice gateway sends a `dave_protocol_prepare_epoch` opcode (24) with the initial group epoch `epoch = 1` to the sole remaining member.

[プロトコル仕様](https://github.com/discord/dave-protocol/blob/main/protocol.md)によれば、これはMemberを取り除く通常のRemove proposalではなく、epoch=1の `PrepareEpoch` によるグループの作り直しです。受信した側は新しいキーパッケージを生成して送り直す必要があります。

![確立済みのグループから参加者が1人に減るとVoice GatewayがPrepareEpochをepoch=1で送り、クライアントは状態をリセットして新しいKeyPackageを送る。別の参加者が加わると再びグループが確立し、同じサイクルが繰り返される](/images/posts/discord-dave-voice-decrypt-swift/prepare-epoch-cycle.svg)

仕様には「この作り直しが発生する」ことは書かれていますが、実装側が「DAVEの初期化処理を一度きりのガードにしてはいけない」ところまでは書かれていません。最後の1人になって全員が抜け、また別の参加者が入ってくるたびにこのサイクルが繰り返されるため、初期化処理を再入可能にしておかないと、2回目のグループ参加に失敗します。

## IP Discoveryのバイト順

3つ目は、UDP接続確立時のIP Discoveryレスポンスです。Discordのドキュメントは「numericな値はすべてbig-endian」と明記していて、ここ自体は仕様上は明確です。それでも実装時には見落としやすいポイントです。手元でリトルエンディアンとして読み違えて試したところ、ポート番号自体は誤った値になるだけで、サーバー側が実際の送信元アドレスでルーティングするため接続自体は成立しました。エラーで気づけるとは限らないという意味で見落としやすく、正しく受信するにはここをドキュメントどおりbig-endianとして読む必要があります。

## 受信専用のPoCとして持つ範囲

今回のPoCは受信専用です。ボット側から音声を送り返す実装、48kHzから16kHzへのリサンプリング、libdaveやlibopusといったネイティブ依存をCI上でビルドする仕組みは、スコープの外に置いています。Discordの音声受信は公式にドキュメント化されていない領域で、これは自分が管理するサーバーに対して行った技術検証です。実際の通話を録音することは、参加者の同意や法的な扱いが関わる場合があるため、実運用に持ち込む前にそこは別に整理する必要があります。