DRM в вопросах и ответах

 Если функции и структура CAS (Conditional Access Systems-Cистем Условного Доступа) кажутся достаточно понятными, то задачи сегодняшних DRM и способы их реализации в многомногоэкранной среде с разными протоколами доставки вызывают множество вопросов. Мы попросили прояснить их руководителя отдела системной интеграции компании SmartLabs Артема Гелуна.

Чем CAS и DRM отличаются друг от друга? Какие задачи решает CAS, а какие DRM? Бывает ли необходимость использовать и то, и другое одновременно при доставке на один тип абонентских приемников?

Артем Гелун: Четкого разделения терминов CAS и DRM нет. Кто-то разделяет их по критерию «годится для спутника или нет», кто-то — «CAS – для IPTV, DRM — для мобильных устройств», кто-то еще как-то. Сформировавшегося мнения нет даже внутри нашей компании. Но я бы предложил вернуться к первоначальному определению этих аббревиатур и «плясать» от них.

CAS – «система условного доступа» (Сonditional Access System). Т.е. она проверяет условие (как правило — «оплачена ли подписка») и предоставляет или не предоставляет доступ контенту. Такой подход был свойственен и достаточен для DVB систем. Поэтому он, как правило, ассоциируется именно с ними или с их прямым наследником — «классическим», «олдскульным» IPTV.

DRM – системы управления правами (Digital Rights Management). Они получили свой старт, когда появилась возможность получать контент не только из эфира, но и с разных носителей — видеокассет, dvd дисков и т.д. Правообладатели захотели контролировать возможность копирования с кассеты на кассету, ограничивать регион потребления контента (вспомним про региональное кодирование DVD дисков и поиск DVD-приводов, в которых не ограничивалось/ломалось количество изменений региона). Т.е. изначально это были такие системы, которые более подробно описывали ваши права как покупателя контента.

Надо заметить, что и CAS, и DRM изначально были рассчитаны на использование в системах без обратного канала. И если CAS’ы под это требование подстроились благодаря применению соответствующих криптографических алгоритмов и оборудования (в частности, используемые до сих пор карточные CAS’ы для спутникового ТВ), то DRM’ы тех времён были не особенно эффективны.

Современные DRM системы, про которые в 99% случаев идет речь, объединили в себе как возможности CAS в части криптографии, безопасности и надежности закрытия контента, так и функциональность DRM по ограничению распространения приобретённого контента после его расшифровки. Например, DRM может ограничить максимальное разрешение изображения если не используется аппаратное шифрование на устройстве, запретить вывод HD контента (или вообще отображение любого контента) на аналоговые выходы, как наименее защищенные, или потребовать определенной версии HDCP для воспроизведения определенного фильма.

При этом все DRM, о которых мы говорим, требуют наличия обратного канала, т.е. возможности что-то «спросить» у сервера лицензий или отправить ему определенную информацию.

На мой взгляд, это и отличает DRM от семейства CAS. CAS могут работать без обратного канала, а реализации с обратным каналом, как правило, сохраняют совместимость с ними, что позволяет один и тот же поток передавать как по спутнику, так и по IP-сетям) Кроме того, они имеют ограниченную по сравнению с DRM функциональность.

При этом скажу, что тип контейнера ( MPEG-2 TS поток или другой) не влияет на выбор системы. Например, мы успешно внедряем решение, позволяющее использовать Widevine Modular DRM для защиты multicast-потоков, само собой, передаваемых в MPEG-2 TS). Сейчас мы также тестируем это решение для защиты контента в DVB сетях, но, само собой, при наличии обратного канала по IP.

 Чем тогда CAS отличается от DRM в части реализации?

Артем Гелун: Каждый вендор DRM или CAS сам определяет реализацию, исходя из решаемых задач – поддержки, стандартов протоколов доставки, требований к уровню безопасности , совместимости с другими DRM, и т.д.

Так же как для CAS, для DRM систем не существует какого-то одного стандарта, определяющего способы шифрования, получения ключей и т.д. И если для CAS наиболее широко применяемым стандартом стал DVB SimulCrypt, то для DRM, наверное, имеет смысл обозначить 2 основных семейства систем, которые сейчас популярны на рынке. Первое использует HLS с шифрованием AES. Это первый формат, поддерживаемый на устройствах iOS, и он де-факто стал стандартом, как минимум, до начала широкого применения DASH. Второе семейство основано на стандарте Common Encryption (CENC). Но даже тут наблюдается дробление рынка: Наиболее широко используемые DRM – Widevine и MS PlayReady поддерживают CENC с шифрованием AES-CTR, в то время как Apple выбрал для своей DRM FairPlay шифрование AES-CBC (сравнительно недавно WV начал поддерживать AES-CBC, но это касается только новых устройств). Соответственно, они несовместимы между собой.

В отличие от CAS, DRM, в большинстве случаев, выдает клиенту не только ключ, которым может быть расшифрован контент, но и набор правил использования этого ключа – срок его действия, требования к безопасности (например, поддержка HDCPv2) и другие. Всё вместе это называется “лицензией”. Алгоритмы доставки лицензии на абонентское устройство во многом определяют уникальность DRM системы и в большинстве случаев закрыты. При этом лицензия криптографически “привязывается” к устройству и не может быть использована на другом устройстве.

 Как происходит выбор DRM для “многоэкранной” доставки контента

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

Например, если вам нужно обеспечить доставку на iOS, Android, различные модели STB (в том числе, выпущенные несколько лет назад) и вы хотите использовать только аппаратную защиту на устройствах, то вам придётся хранить 3 копии контента — одну для Android (Widevine/CENC), одну для iOS (FairPlay/CENC AES-CBC) и одну для STB (какое-то решение, которое реализовано в STB аппаратно – например, от Nagra или Verimatrix).

Но количество iOS устройств с root-доступом сравнительно невелико и можно производить проверку наличия root перед запуском приложения; а STB на базе Linux, как правило, не позволяют без наличия пароля root получить доступ к исполняемым процессам никак, кроме как подключившись к шинам памяти и процессора, которые производители тоже стараются защитить. Поэтому возможно вы согласитесь с тем, что iOS и STB — ; достаточно безопасные устройства. Тогда можно на этих же устройствах использовать программную реализацию Widevine и хранить всего одну копию контента.

А как можно загрузить DRM, если она предусматривает аппаратную защиту ключей?

 Артем Гелун: В загружаемых DRM аппаратной защиты нет. Их уровень безопасности ниже, чем “нативных”, ключи которых “вшиты” в устройство и которые реализуют расшифровку лицензии и контента без доступа к общей памяти системы. Но, он как правило, вполне достаточен для того, чтобы правообладатели доверяли таким DRM для SD и, в большинстве случаев, HD контента.

Для UHD контента правообладатели всегда требуют аппаратной защиты, но, как правило, поддержка кодеков для UHD тоже делается аппаратно – найти на рынке неспециализированное устройство, поддерживающее UHD только “программно” и воспроизводящее видео без тормозов, достаточно сложно. Да и сам формат UHD обычно предполагает наличие большого экрана (какой, например, смысл смотреть 4К на iPad, или на PС с разрешением HD) а это предполагает специфику оборудования и наличие соответствующих аппаратных DRM.

Вообще, на мой взгляд, нужно понимать, что не бывает абсолютно безопасной системы. Любую систему можно взломать – вопрос только в стоимости этого взлома и времени, потраченного на него. Притом, зачастую, взломать систему проще всего не техническими методами, а используя так называемый “человеческий фактор”. Можно зашифровать контент, хранить ключи на сервере без удаленного доступа, закрытого на 10 замков и доступного только при одновременном вводе пароля, авторизации по отпечатку пальца, скану сетчатки, предоставлению паспорта и справки от психиатра. Но какой в этом смысл, если мастер-копию вы получаете в нешифрованном виде по FTP, доступному через интернет, с одним логином на всю компанию? Вспомним, например, ситуацию с утечкой “Шерлока” до его премьеры – тут никакая DRM система не поможет.

Это я к тому, что не стоит зацикливаться на “аппаратности” защиты, а нужно решать задачу комплексно.

То есть загружаемые DRM не могут удовлетворять спецификации MovieLabs?

Артем Гелун: Спецификация “MovieLabs Specification for Enhanced Content Protection” версии 1.1 требует наличие т.н. “Hardware root of trust”, что предполагает подготовку устройства для конкретной DRM системы на заводе и, что логично, предполагает аппаратную реализацию криптографии. Так что соответствовать требованиям MovieLabs программные DRM не могут.

Но подобные требования предъявляются, как правило, только к UHD контенту, оборудование для которого производится уже с учётом таких требований, или реже к так называемому “Early Window” прокату – появлению на устройствах одновременно или почти одновременно с кинотеатрами. В этом случае оператор может ограничить перечень устройств, на которых будет доступен «Early Window” контент, только “безопасными”.

 Как выглядит работа   DRM с расширением EME?

 Артем Гелун: EME — это стандарт, позволяющий (совместно с другим стандартом – MSE) браузерам использовать DRM через JavaScript. По сути, JS код делает всё кроме расшифровки и воспроизведения контента. Например, один из самых популярных плееров для DASH – Shaka Player – отвечает за реализацию протокола DASH, скачивает чанки и “отдает” эти чанки браузеру (MSE), а он, в свою очередь, использует определенное расширение (EME), соответствующее используемой DRM системе, для того, чтобы расшифровать контент и вывести его на экран/аудио выход. В частности, небезызвестный Netflix использует свой протокол доставки (не DASH и не HLS) и реализует этот протокол в браузере на JS посредством EME и MSE.

При этом EME может иметь как аппаратную реализацию (например, EME PlayReady на некоторых ноутбуках в браузерах IE и Edge; или Widevine в Chrome Browser на ряде устройств ChromeBook) так и программную, которая встречается намного чаще.

 В некоторых материалах DRM связываются не с платформой, а с «придворным» браузером- Widevine с Crome, PlayReady с Edge и FairPlay с Safari? Корректно ли это, и если да, то почему?

Артем Гелун: Нет, некорректно.“Придворный браузер” – это только часть устройств, на которых можно воспроизводить контент. Кроме PC есть еще STB, мобильные клиенты, SmartTV и т.д.

Существуют также DRM, не привязанные к определенным платформам, например от Verimatrix или Nagra. В каких случаях выбирают их?

Артем Гелун: Я бы назвал их, скорее, “коммерческими” DRM, а не DRM, не привязанными к платформе. Verimatrix и Nagra тоже имеют перечень устройств, на которых поддерживается их DRM система.

Пожалуй, они выбираются крупными операторами, которые хотят иметь гарантированный SLA, подкрепленный финансовыми обязательствами – как в части работоспособности системы (т.е. гарантии того, что пользователям будет доступен контент, когда это потребуется), так и в части гарантий безопасности этой системы (т.е. гарантий того, что система не будет взломана и контент не станет доступен злоумышленнику).

Для условно бесплатной Widevine или относительно недорогой PlayReady подобных гарантий не дается , но это не мешает им удерживать доверие правообладателей, быть лидерами рынка и работать без проблем уже много лет. Гарантии по таким DRM можно получить только от интегратора, и то в объеме, позволяющем интегратору эти гарантии выполнить. Verimatrix, Nagra и другие аналогичные поставщики имеют доступ к своему коду и могут исправить любую проблему, если она возникнет.

Кстати, я не случайно назвал Widevine УСЛОВНО бесплатной системой. Google дает возможность пользоваться ей абсолютно бесплатно, но если оператор захочет внедрить её самостоятельно, то ему потребуется пройти обучение, разобраться в технологиях, наткнуться на множество подводных камней и т.д. И это в любом случае приведет к затратам, причем весьма существенным. Verimatrix и Nagra стоят немалых денег, но сокращают время и расходы на внедрение. Они также имеют модули для работы, например, с тем же PlayReady, что облегчает развёртывание систем с использованием сторонних DRM.

В линейке продуктов SmartLabs тоже есть “зонтичное” решение – Universal DRM, объединяющий Widevine, MS PlayReady и Apple FairPlay “под одной крышей” и существенно ускоряющий и упрощающий внедрение. UDRM имеет открытый API для интеграции и, само собой, уже проинтегрирован с другими продуктами SmartLabs — SmartMEDIA в части шифрования и доставки и SmartTUBE в части авторизации клиентов.

 И вопрос не по теме – каковы критерии выбора кодека, что принимается во внимание помимо эффективности кодека?

Артем Гелун: Совместимость со всеми используемыми устройствами. Каждое устройство поддерживает своё множество кодеков и профилей (например, Android поддерживает среди прочих VP8/VP9 кодеки, STB – h262 (MPEG2), а iOS до недавнего времени поддерживала только h264(AVC) для видео и AAC для аудио), для решения выбираются те, которые поддерживаются всеми. Как правило, это h264 для видео (если речь не про UHD) и AAC для аудио. Профили и параметры кодирования подбираются индивидуально, но, опять же, поддерживаемые всеми устройствами.

Анна Бителева 

Комментарии

Оставить сообщение