Защита контента на iOS устройствах

This post is also available in: Английский

iphone-video

Разработка профессиональных видео приложений для iOS устройств (iPhone/iPad) очень часто связана с необходимостью реализации надежных средств защиты контента. Без этого видео приложение может остаться без профессионального видео контента от правообладелей. В этой статье мы расскажем про технические особенности реализации DRM решений для видео сервисов работающих на iOS устройствах.

Основы DRM систем
Большинство DRM решений построены по единой архитектуре. Защищаемый контент предварительно шифруется DRM модулем шифрации (как правило, применяется AES-128), а модуль управления лицензиями выдает ключи пользователям на просмотр контента (как правило создается на базе Java сервера приложений). Такая реализация позволяет эффективно разделить этапы обработки контента, доставки контента и управления разрешениями на использование. На рисунке ниже изображена типовая архитектура DRM решений.

Typical DRM Architecture

Такую архитектуру имеют решения Adobe Flash Access (Java Tomcat + Flash Player / AIR), Microsoft PlayReady (IIS + Silverlight), Widevine DRM. В случае Adobe Flash Access серверная часть построена на базе Apache Tomcat сервера Java приложений.

В случае iOS системы защиты контента видео плеер Apple берет на себя лишь дешифрацию видео данных получаемых по HTTP Live Streaming протоколу при помощи заранее указанного ключа дешифрации. В качестве алгоритма используется стандартный AES-128. В этом случае разработчику видео сервиса для iOS устройств нужно реализовать на серверной части механизм сохранения ключей шифрации и очень аккуратной их выдачи, а на клиентской части обеспечить качественный прием этих ключей с минимальным риском для перехвата (например, обеспечить jailbreak detection в приложении). Схема реализации защиты контента на iOS устройствах приведена ниже.

iOS DRM Architecture
Рассмотрим более подробно реализацию систем защиты контента в iOS устройствах.

HTTP Live Streaming
Прежде всего стоит рассмотрть принципы работы доставки видео контента при помощи HTTP Live Streaming. Архитектурно HTTP Live Streaming (HLS) состоит из трех частей: серверная видео часть, система доставки контента, клиентское ПО.

  • Серверная видео часть отвечает за прием видео контента и его энкодинг (или транскодирование), упаковку видео в подходящий формат для дальнейшей доставки, подготовку видео для дальнейшего распространения.
  • Система доставки контента для HTTP Live Streaming состоит из стандартных веб серверов (кеширующие HTTP Proxy).
  • Клиентское ПО отвечает за запрос нужного мультимедийного контента, загрузку сопутствующих ресурсов и вывод их на отображение пользователю. Клиентское ПО включено в iOS начиная с версии 3.0, а также компьютеры с Safari начианая с 4ой версии.

В типовой конфигурации аппаратный энкодер принимает аудио и видео на входе, сжимает видео H.264 кодеком и аудио AAC кодеком, и выдает результат в потоке MPEG-2 Transport Stream. Этот поток далее при помощи программного сегментатора потоков разбивается на последовательность маленьких файлов (чанков). Также сегментатор создает индексный файл со списком чанков. Все эти файлы помещаются на web сервер. Клиентское ПО считывает индексный файл, а затем в нужной последовательности запрашивает чанки для непрерывного отображения.

Защита контента в iOS браузере
Технология доставки
Плеер (клиентское ПО) сначала загружает индексный файл по URL идентифицирующему мультимедиа поток. Индексный файл в свою очередь определяет местоположение доступных мультимедиа материалов, ключей дешифрации и альтернативных потоков. Для выбранного потока плеер загружает каждый доступный медиа файл последовательно (внутри них расположены соответствующие сегменты видео). Как только загружен достаточное количество мультимедиа данных плеер начинает воспроизведение объединенного мультимедиа потока.

Плеер отвечает за предварительную загрузку ключей дешифрации, аутентификацию или предоставление графического интерфейса аутентификации и дешифрацию мультимедиа контента при необходимости.

Этот процесс продолжается до тех пор пока не встречается тег #EXT-X-ENDLIST в индексном файле. Если такого тега там нет #EXT-X-ENDLIST, то индексный файл является частью запущенной онлайн трансляции. В ходе онлайн трансляций плеер периодически подгружает обновленные версии индексного файла, проверяет новые мультимедиа файлы и ключи дешифрации, добавляет их в очередь воспроизведения.

Обеспечение защиты
Мультимедиа файлы с сегментами потока могут быть зашифрованы по отдельности. В случае применения шифрации ссылки на соответствующие ключи дешифрации появляются в индексном файле, чтобы клиент мог получить их для дешифрации контента.
На данный момент HTTP Live Streaming поддерживает AES-128 шифрацию при помощи 16-байтных ключей.
Серверный сегментер от Apple — media stream segmenter поддерживает три режима шифрации.

  • В первом случае для шифрации потока используется ключ предварительно сохраненный на локальном диске (все медиа файлы потока шифруются единым ключом). Именно этот режим реализован в Adobe Flash Media Server.
  • Во втором режиме сегментер предварительно генерирует случайным образом ключ и сохраняет его на диске. Далее этот ключ используется аналогично первому режиму.
  • В третьем случае сегментер генерирует случайные ключи каждые n сегментов, сохраняет их на диске и прописывает ссылки в индексном файле. Данный режим часто упоминается как ротация ключей дешифрации.

Работа с ключами
При доставке ключей в видео плеер браузера для защиты ключей Apple предлагает использовать HTTPS. При этом остается риск перехвата ключа, в тех случаях если произвели взлом устройства (Jailbreak) или каким-то образом сэмулировали на PC данное устройство. Существенно снизить этот риск, можно лишь при написании своего приложения, реализовав дополнительные проверки. Об этом пойдет речь далее.

Защита контента в iOS приложении
Для пунктов Технология доставки и Обеспечение защиты все идентично защите контента в плеере браузера, а вот в реализации механизмов работы с ключами дешифрации есть особенности и дополнительные возможности.

Работа с ключами
В дополнение к доставке ключа по HTTPS, при написании собственного приложения можно предусмотреть установку своего сертификата, таким образом гарантируя доставку контента только в свое приложение. При инсталяции приложения можно осуществлять проверку устройства на Jailbreak. Как правило, именно этот подход требуют правообладатели. Также они обычно легко соглашаются на использование реализаций видео плееров от Authentec / SecureMedia / Discretix / Irdeto (механизмы защиты этих плееров одобрены), хотя никто не мешает реализовать эти механизмы самостоятельно.

Материалы
При подготовке материалов использовалось: официальная документация Apple, новый релиз Adobe Flash Media Server 4.5 с поддержкой HTTP Live Streaming и документация по нему (в своих проектах мы чаще используем FMS 4.5 для стриминга на iOS устройства, хотя иногда настраивали альтернативные конфигурации, и NGINX в качестве edge — кеширующего прокси).

В ближайшее время мы напишем серию статей про разработку видео плееров для iOS устройств, где более подробно рассмотрим особенности добавления видео материалов в приложения и на iOS веб страницы. Кроме того, наши iOS разработчики всегда ждут Ваших вопросов 🙂

Побольше просмотров Вашему видео сервису!