Ways of protecting media content. Is DRM possible in Web?

Ways of protecting media content. Is DRM possible in Web?

Денис Елданди: Добрый день всем! Итак, я расскажу про то, как все плохо с DRM-технологиями, а Александр (Кистанов) – про то, как с этим жить. Давайте сначала – краткое вступление про то, что такое потоковое видео и DRM. Идея потокового видео состоит в том, чтобы проигрывать видео или аудио, которое поступает из сети без скачивания файла целиком заранее, с довольно маленькими задержками и маленьким буфферингом; это называется стриминг. Стриминг экономит время и нервы пользователя, а также – трафик. Собственно, в не-стриминге этого всего не происходит. Мы будем говорить о потоковом вещании применительно к видео-хостингу в интернете, и в этом качестве – о потоковых технологиях, таких как RSTP, RTMP и HTTP pseudo-streaming.

С приходом контента в интернет, особенно это касается контента в высоком качестве, правообладатели начинают беспокоиться по поводу защиты его от незаконного копирования. Поэтому, им предлагают защиту от копирования, которая называется – DRM. Официально расшифровывается как
Digital Rights Management, Управление цифровыми правами. Хотя многие предпочитают расшифровку
Digital Restriction Management – Управление цифровыми ограничениями.

В целом DRM – способ запретить и ограничить создание копий произведения, которые распространяются в цифровом виде. Хотя, сейчас некоторые вендоры DRM-систем говорят, что цель всего лишь в том, чтобы усложнить создание таких копий. Большинство DRM-систем используют довольно устойчивое шифрование. Для чтения зашифрованной информации нужен секретный ключ. Однако, толка от этого почти нет, потому что для легитимного чтения и информации и для просмотра фильмов, нужен тот же самый ключ что и для нелегитимного копирования, например. Собственно, DRM системы пытаются так или иначе скрыть от пользователя ключ, но так как пользовательская часть DRM-систем находится полностью в руках у юзера системы, он в состоянии вполне указанный ключ получить, с помощью так называемой trusted client problem.

Другая уязвимость, правда – менее интересная, заключается в том, что так или иначе фильм окажется в какой-то момент в аналоговом виде, пускай не в кабеле до телевизора, но на самом экране уж точно, и оттуда его всегда можно записать на диск, пусть с некоторой потерей качества. Так называемая analog hole (аналоговая брешь) – очень уязвимая. И конечно, существует очень мало достаточно полных систем DRM-систем, которые бы не предоставляли медиа-контент в открытом (цифровом) виде. Например, есть весьма распространенный метод «обхода» DRM – снятие потока с видео-буфера компьютера (если бы вы делали screencast). С другой стороны, Windows Media Player, например, использует различные техники, чтобы этого не получалось. Но разработчики тоже не спят, и обходят их так или иначе. Собственно, тут ничего нового я не сказал, все это известно, есть организация, движение, которое об этом говорит (на экране). Но поставщики DRM-систем по-прежнему утверждают, что у них все хорошо.

Примерно об этом подумали разработчики RTMP. RTMP-протокол был изначально разработан компанией Macromedia для передачи аудио и видео по интернету между Flash-приложением и CRM. Он использует Port 1235 TCP и работает по схеме запрос-ответ: клиент запрашивает URL, и сервер отдает ролик. У протокола RTMP есть разные разновидности. Например, RTMPT использует HTTP в качестве транспорта, а RTMPS использует HTTPS/SSL для шифрования.

А есть протокол RTMPE, предложенный для защиты контента, и сейчас производитель называет его protected streaming. Он должен был в идеале «убивать сразу двух зайцев» – защищать (шифровать поток), и верифицировать клиента. Идея была в том, чтобы получать ролик мог только правильный клиент, который осуществлял бы проверку на своей стороне, не показывал его «кому не надо», и нельзя было бы перехватить поток между сервером и клиентом. RTMPE не использует SSL для шифрования , разработчики решили, что это достаточно дорого со стороны сервера, т.е. дорого по производительности, и решили сделать такую самодельную «штуку», которая бы использовала временные ключи, и с помощью них шифровала бы данные. Но на самом деле, так как нет никакой проверки аутентичности сервера со стороны клиента, то можно легко устроить на этот протокол атаку Man in the middle, где «атакующий» отлично получает контент в открытом виде и сохраняет его у себя на жестком диске.

Также, их так называемая верификация клиента, основана на весьма странном алгоритме: флэш-приложение считает свой собственный хэш, берет свой собственный размер и посылает его на сервер. А сервер, знает якобы, и если приехал неправильно, он бы не отдавал ролик. Но на самом деле, ничего не стоит написать свой отдельный клиент, который бы скачивал и сохранял данные на диск. Конечно, сохранить RTMPE поток чуть более сложно, чем кликнуть правой кнопкой мыши, и сказать «сохранить как». Но на самом деле есть клиентские программы, которые скачивают по RTMPE что угодно. И если, конечно, разработчики ставили своей целью усложнить нелегальное копирование, то они, наверное, так или иначе своей цели достигли, но было бы преувеличением говорить, что их контент находится под защитой. Какие есть выходы из этой ситуации? Об этом расскажет Александр.

Александр Кистанов: Как было сказано, выходов по-настоящему нет, практически любое существующее DRM-решение не дает 100% гарантии от того, что контент будет защищен и в безопасности . Значит, что же тогда делать? На самом деле, получается, что нет никакой необходимости использовать какое-то конкретное DRM-решение. Дело в том, что все существующие DRM-решения для веб-приложений обладают недостатками. В частности, например, для некоторых это – ограниченность платформы, для других – возможность использовать эти решения только на Windows и требовательность к ресурсам; также, DRM-решения часто стоят значительное количество денег. Опять же, они достаточно сложны в освоении.

Но как мы показали, смысла их использовать особо нет. И практически того же самого можно достичь, используя какие-то более простые решения. Например, мы в своих системах обычно не используем RTMP, отдавая видеофайлы по HTTP-протоколу. Это позволяет, например, с достаточно слабого сервера отдавать гигабит трафика, и даже больше. Но как при таком подходе затруднить копирование файлов?

На самом деле, возможности для этого есть. В Adobe Flash, например, начиная с версии 10.1, появился такой функционал, который позволяет формировать видео-поток, проигрываемый плеером, прямо на лету. Это метод append_bytes(). Используя его, можно довольно легко написать простое решение, затрудняющее сохранение файлов. Видео отдаются просто через HTTP, со стороны сервера оно кодируется на лету любым потоковым шифром, а на стороне клиента оно шифруется с помощью за-хардкоженного (hard-coded) ключа. Написать такое программисту не составит труда, и это будет не сильно хуже, чем любое существующее DRM-решение. Таким образом, копирование файлов будет затрудняться.

Кстати, почему, если так легко скопировать контент, так редко возникают сервисы, которые фактически дублируют уже существующие?

Это происходит, потому, что отдача такого же количества файлов как на Youtube потребует создание такой же инфраструктуры как у них, что очень дорого и сложно. У потенциального злоумышленника возникает соблазн использовать уже лежащий на легальных серверах контент, но для своего сайта. Это возможно, если они покупают платный аккаунт, получают доступ к видео в хорошем качестве, а после этого создают свой сайт, где используют видео уже в своих целях. Однако эту проблему довольно легко обойти даже при простом решении, используя так называемую верификация урлов с помощью token , которая поддерживается в том или ином виде практически любым HTTP-сервером. Дело в том, что когда мы формируем ссылки на контент, мы генерируем token, который содержит информацию о времени жизни этой ссылки и об IP-адресе клиента, для которого она валидна. Такой подход практически исключает использование ссылок на контент для каких-то нелегальных целей.

Спасибо большое всем за внимание!

Вопросы из зала:

– Знают ли Warner Brothers, что DRM можно взломать? Почему они требуют DRM?

Денис Елданди: Warner Brothers обо всем прекрасно знают. Они требуют DRM потому, что они мало прислушиваются к советам технических специалистов. Их решения чаще принимаются неким менеджментом, который вырос из «олдскульной», старого типа модели распространения информации. Они привыкли как-то по-старинке все делать, и «закрывать в глаза» на некоторые проблемы.

– Вы могли бы рассказать про Flash Access 2.0: как можно его «открывать», и какие у него слабые места?

Денис Елданди: У него другой принцип работы – происходит проверка лицензии на сервере. Получается, что у нас контент всегда продается в зашифрованном виде, и ключ такой, как в вашем примере.

На самом деле, «атаку» Man in the middle легко можно было бы и избежать. Достаточно было бы проверить аутентичность сервера, как это делается в SSL/HTTPS. Но проблема в том, что ключ, который нужен для расшифровки контента, всегда будет у клиента, и он всегда его сможет использовать.

– К сожалению, я не большой специалист в Access. Но то, что я читал, немного информации: считается, что если контент не скачивается, а смотрится онлайн, то перед получением потока мы запрашиваем лицензию на сервере владельца контента. И этот ключ тоже имеет ограниченное «время жизни». Вроде как утверждается о том, что если я не применяю «тряпичной» копии видеосъемки, в принципе я не смогу второй раз без получения новой лицензии контент просмотреть?

Денис Елданди: А что если вам сделать «клиента», который будет пользоваться хорошим правильным ключом, но сохранять все это на диск?

– Дело не в том, как сохранить видео на диск, а как его проиграть.

Денис Елданди: Вы сохраняете байтовый, расшифрованный поток на диск. То есть, вместо того, чтобы отдавать это в видеокарту, вы сохраните его в файл. А тот, кто напишет программу, кто все это автоматизирует. В чем сложность?

– Скажите, а какова схема работы все-таки? Я хочу посмотреть кино, иду в билетную кассу и покупаю билет. Билет действует только для моего IP-адреса в течение 5 минут. Я отправляю запрос на сервер лицензий, и получаю лицензию на просмотр зашифрованного по дороге контента. Или?

Денис Елданди: Вы контент расшифровали. Но вместо того, чтобы его смотреть, вы его сохранили на диск в открытом виде. А потом его 3 раза посмотрели, и раздали контент всем своим.

– Скажите, Google Widevine победит?

Денис Елданди: А что значит победит, в бизнес смысле или в техническом? Видите ли, кто со стороны бизнеса победит – это скорее вопрос маркетинга. С технической стороны побеждать некому, потому что идея DRM изначально – странная.

– Добрый день! Я нахожусь уже давно на рынке контента, и хочу сказать, что у всех правообладателей есть квалифицированный персонал. Они все – в курсе, что можно украсть, но постепенно идут маленькими шажками по пути защиты информации, чтобы все-таки их решения как-то заработали. Все понятно, что обычный обыватель хочет бесплатно посмотреть видео, а правообладатели хотят за это деньги получить. Это – нормальная борьба, и вопрос только в том – куда она приведет. Правильно говорилось, что либо правообладатели навяжут способ, который будет более-менее у всех работать, либо же они откажутся от DRM, как это уже произошло несколько лет назад, когда Warner и Sony, и прочие основные мейджоры отказались от DRM применительно к музыке. И сказали: «ребята, мы не готовы, потому что у нас высокий процент отказов у людей, связанный с тем, что они не смогли вообще что-либо послушать, или цена слишком высокая».

Все зависит от ситуации от трекерами, когда административно закрываются все свежие раздачи. Мне кажется, что несколько отделов операторов на трекерах, которые выключают свежие раздачи – это гораздо более простая и результативная борьба, чем каждому пользователю в мозг вживлять DRM-чип, который после этого надо обновлять еще (смех в зале).

Денис Елданди: Ну как? Административные способы работают далеко не везде. Например, в Америке могут запретить, и прислать отряд полиции. Но нормальные люди уже переехали в другие страны.

– Смотрите: на сайте rutracker.ru, например, свежих раздач нет. То, что идет в кинотеатре, на сайте появиться не может, несмотря на то, что можно договориться с оператором, чтобы он снял цифровую копию фильма –потому что есть административный серверный барьер. В итоге, сильно неудобно, что на трекере нельзя получить свежий контент, а правообладателям нужно хоть какое-то время для того, чтобы продавать свой фильм до тех пор, пока все это дело по трекерам не разойдется.

Денис Елданди: Да, поэтому проще сказать: Adobe обещал, что RTMPE это надежно, поэтому все сделаем.

И все так делают, просто присутствующие: не говорите правообладателям ничего из того, что мы здесь обсуждали, и все будет хорошо. (смех в зале)

Денис Елданди: Вопросов больше нет? Всем спасибо!