ウォーターマークの挿入方法を知る

前回のポストでは、海賊行為事業者が海賊行為を行う理由と、海賊行為への対策としてDRMとウォーターマークの2つを紹介しました。特にウォーターマークは法的措置を執るに当たって重要なテクノロジーであることも述べました。

海賊行為への対抗策として有用なウォーターマークですが、映像データに挿入する方法としては大きく分けて3種類の方法があります。

（1）サーバー側で動的に挿入する

配信事業者側のコントロール下にある配信サーバーやCDN側で映像データにウォーターマークを動的に挿入するという方法です。ウォーターマーク挿入処理を海賊行為事業者の手の届かないサーバー側で行う方法であるため、ウォーターマーク自体の堅牢度は非常に高い方法です。

サーバー側で動的にウォーターマークを載せる例。出典 https://www.friendmts.com/wp-content/uploads/2018/03/FMTS_Application_Note_8pp_AW_web.pdf

しかしながら、2点ほど課題があり、あまり採用が進んでいない状態です。

まず、サーバー側での動的なID埋め込み処理に対応したハードウェアやソフトウェアなどのインフラが必要であると言うこと。ただし、最近ではAmazon AWSがNAGRAのNexGuardをCloudFrontに統合したということもありインフラを用意する敷居は多少下がってきました。

しかし、この手法の根本的な課題として、サーバー側で映像データを一旦デコードするなどし、動的なID埋め込み処理が行えるような状態に準備する処理が必要という点があげられます。ハードウェアの支援はあれども映像のデコードや前処理のための計算処理はそれなりに時間がかかるため、ライブ配信では利用することができなかったり、VODでも配信インフラをウォーターマークを考慮したものに設計し直す必要があるため、導入のためのハードルは高めになっています。

（2）2種類のウォーターマークの切り替えパターンで加入者IDを表現する

サーバー側でIDを埋め込む方法の効率の悪さをカバーする方法として、2種類のウォーターマークの切り替えパターンで加入者IDを表現するという方法があります。
AとBという2種類のウォーターマークを用意しておき、契約者（1）に対してはAABBAA、契約者（2）に対してはABABBAとみせて、パターンの違いで識別するという方法です。

切り替えパターンでIDを表現する。出典 https://www.friendmts.com/wp-content/uploads/2018/03/FMTS_Application_Note_8pp_AW_web.pdf

この方法であれば、1つの映像素材に対して2種類のウォーターマークを載せたデータを用意しておくだけで良いため、サーバー側に要求される負荷は比較的低くなります（ただし、エンコーディング費用とCDNのストレージコストは2倍になります）。

この方法の欠点としては、まず、加入者IDを特定するまでの時間の長さがあげられます。2種類のデータの切り替えパターンを使うため、20回の切り替えを行ったとしてようやく104万通りのIDを表現することができます。1回の切り替えを6秒で行った場合、20回の切り替えには120秒かかります。

次に、クライアント側をある程度堅固にしておかないと、海賊事業者に切り替えパターン自体を操作されてしまい加入者IDが特定出来なくなるということがあげられます。
切り替えパターンは、クライアント側に渡ってくるマニフェスト（どの順番でどのファイルを再生するかが書かれたファイル）上に記載されています。クライアントが脆弱だとマニフェストファイルを書き換えることで、A/Bそれぞれの切り替えパターン自体を操作されてしまい、結果契約者IDが特定出来なくなってしまいます。

（3）クライアント側でウォーターマークをオーバーレイする

ウォーターマークでは一番よく使われている方法です。クライアント（≒プレイヤー）側でウォーターマークを映像信号にオーバーレイして画面上に描画するという方法です。

クライアント側でウォーターマークをオーバーレイする。出典 https://www.friendmts.com/wp-content/uploads/2018/03/FMTS_Application_Note_8pp_AW_web.pdf

前述の2つの方法と比べたとき、既存の配信インフラに手を加える必要がないというところが大きなメリットです。また、ライブ配信のような即時性を求められる配信に対してもウォーターマークを差し込むことができます。更に、映像データの上に何らかの画像データを乗算するというのは比較的軽い処理であるため、CPUやメモリーリソースが限られている小型のハードウェア上でも実行可能です。

欠点としては、ウォーターマークが入っていない映像信号がクライアント側まで来ているため、クライアントの作りを堅固にしていないと生信号をそのまま取られてしまいかねないということがあげられます。
しかしながら、サーバー側での動的挿入も、A/Bパターンの切り替えも、クライアント側が脆弱であればこれらのウォーターマークを破る突破口を与えてしまうという点ではあまり変わりないため、クライアント側オーバーレイ固有の欠点というわけではありません。