動画配信の DRM（Webvine）について調べてみた

2025/12/28

はじめに

HLS を暗号化で配布する場合、.m3u8 ファイルの EXT-X-KEY に共通鍵の URL を記載することでクライアントサイドで復号することができる。 URL アクセスを cookie や JWT の認証にすることで、会員のみのアクセスといったことを実現できる。もしくは、.m3u8 ファイルへのアクセスを cookie や JWT 認証にするならば、共通鍵の URL を署名付き URL することで、アクセス時間の問題短いキー共有を実現できる。

#EXT-X-KEY:METHOD=AES-128,URI="https://example.com/key"

しかし、復号と再生はユーザランドで行われるため、ブラウザに限らず .m3u8 と共通鍵を取得さえできれば、動画をローカルに保存し、再配布（不正コピー）できてしまう。DRM はより安全に実現できる仕組みである。

以下、Webvine + android、すなわち L1 を説明する。全体的に複雑であるため、間違っている箇所があるかもしれない。

DRM の全体像

ハードウェアの仕組みを使用して、復号キーへのアクセスや、復号した動画へのアクセスを特定のハードウェアに制限し、例え OS でも動画へのアクセスができないようにすることで実現する。

Android の例

[Browser / App]
  └─ CDM（Normal World）
        ↓（License Request）
      DRM Server
        ↓（License Response）
  └─ CDM
        ↓（Secure IPC）
      TEE / TA（Secure World）
        ├─ Content Key 復号・保持
        ├─ 再生可否判断
        └─ Secure HW レジスタ設定
              ↓
      Memory Controller / Decoder / GPU / Display
        （Secure モード化）

[CDN]
  ↓ (encrypted media)
[Browser / App]
  ↓
[OS / Kernel / Driver]
  ↓
[Secure Video Decoder]
  ↓
[Secure Video Buffer]
  ↓
[GPU / Display]

復号までの流れ

0. .m3u8 ファイルにアクセス

EXT-X-KEY において METHOD=SAMPLE-AES が指定されており、鍵を直接取得する形式ではないため、DRM フロー（CDM とライセンスサーバーの通信）が必要であると判断される。

#EXT-X-KEY:METHOD=SAMPLE-AES,URI="https://license-proxy.example.com"

ブラウザが GraphicBuffer/MediaCodec 等で dmabuf/ION 等の共有 DMA バッファを確保し、暗号化されたデータを保持する
- バッファに対する handle が返される
- 後続の Secure Video Decoder は、この handle を用いて DMA 経由で暗号化されたデータへアクセスする。

1. CDM とライセンスサーバーの通信

CDM（Content Decryption Module）というユーザランドのモジュールが、ライセンスサーバーと通信を行う。
CDM は、公開鍵を含む証明書チェーンをライセンスサーバーに送信する。
あわせて、Cookie や JWT 認証などのアプリケーションレベルの認証も行われる。
ライセンスサーバーは以下を実行する。
- セッションキーを作成する。
- 動画を暗号化するためのコンテンツ暗号化キー（コンテンツキー）を返却する。
  - ライセンス要求では、エフェメラルな鍵共有（ECDH）を用いて共有秘密が生成され、KDF によりセッションキーが導出される。
    - ライセンス要求に含まれる ECDH 公開鍵などのパラメータは、TEE 内の長期秘密鍵で署名され、その正当性が保証される。
  - コンテンツキーは、このセッションキーで暗号化されて返却される。
公開鍵に対応する秘密鍵は、TEE（Trusted Execution Environment）の Secure World 内で管理されており、Trusted App（TA）のみがアクセス可能である。
- 例：
  - Widevine においては、Widevine Trusted App が Secure World 側に存在する。
  - Widevine CDM はユーザーランド側の実装である。
CDM は、受け取ったライセンスレスポンスを TEE の Trusted App に渡すことで、この後の復号および再生処理が可能となる。

2. TEE 内での鍵復号処理

TA は Secure World 内で、TEE が管理する秘密鍵を用いてセッションキーを復号する。
復号したセッションキーを使用して、コンテンツキーを復号する。
復号されたコンテンツキーは Secure World 内で保持され、Normal World からは参照できない。

3. Secure 再生経路の確立（ハードウェア設定）

TA は Video Decoder のハードウェアレジスタを設定し、Secure mode（Secure Video Decoder）を有効化する。
あわせて、GPU や Display Controller に対しても Secure mode に関する制約を設定する。
TA は復号後のデータを保持するための Secure Video Buffer を確保する。
- メモリは通常の DRAM 上に確保されるが、Secure 属性が付与される。
- Secure Video Decoder、GPU、Display Controller など、保護されたハードウェア経路のみがアクセス可能となるようセキュリティポリシーが設定される。
TA はコンテンツキーに対するアクセスポリシーを設定し、Secure Video Decoder がキーを参照して復号処理を行うことを許可する。

4. メディアデータの復号およびデコード

Secure Video Decoder は、暗号化されたメディアデータを復号しながら、対応するコーデックのデコード処理を行う。
デコードされた映像フレームは Secure Video Buffer に格納される。
復号後の平文フレームが通常のメモリや CPU から参照可能な領域に出ることはない。

5. 表示とキャプチャ制限

Secure Video Buffer に格納されたデータは、TA によって設定された制約のもとで GPU や Display Controller に渡される。
Secure mode では、GPU や Display Controller のキャプチャ機能がハードウェア的に制限または無効化される。
その結果、画面キャプチャや画面録画を行っても、キャプチャアプリケーションは制限されたデータにアクセスできない。
- キャプチャ結果として取得される映像は黒い画面、または無効なフレームとなる。

Windows + Chrome はどうなるか

Windows には当然 Webvine の TA は TEE に存在しないので L3 となる。一方で、Windows において Secure Boot HVCI、ドライバー署名強制が有効な環境では、ユーザーが任意に改変した GPU ドライバーやカーネルドライバーを導入することは困難であり、OS や GPU ドライバーは DRM の脅威モデルにおいて「完全に信頼できないが、容易には破れない実行環境」として扱われる。復号したフレーム等は、GPU や Display Controller の機能を使い、API 　経由でのキャプチャを不可能とすることで、L1 に比べると弱いものの比較的安全に DRM を実現できる。