Потоковая передача HTTP с использованием шифрования

Я пытаюсь понять, как протокол HTTP Live Streaming, поддерживаемый Apple на своих устройствах iOS, а также Safari защищает ключ, который разблокирует контент.

Как я понимаю, файл .m3u8 объединяет все это и ссылается на содержимое (в контейнере TS MPEG2, зашифрованном AES 128) и ключ к TS файлу.

Как в этом примере:

   #EXTM3U
   #EXT-X-MEDIA-SEQUENCE:7794
   #EXT-X-TARGETDURATION:15

   #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=52"

   #EXTINF:15,
   http://media.example.com/fileSequence52-1.ts
   #EXTINF:15,
   http://media.example.com/fileSequence52-2.ts
   #EXTINF:15,
   http://media.example.com/fileSequence52-3.ts

   #EXT-X-KEY:METHOD=AES-128,URI="https://priv.example.com/key.php?r=53"

   #EXTINF:15,
   http://media.example.com/fileSequence53-1.ts

Предполагая, что воспроизведение на основе браузера, где элемент <video> будет загружать файл m3u8 в атрибут "src". В этом случае, даже если ключ доставляется через https, как я могу убедиться, что пользователь не просто вводит URL-адрес https в своем браузере и сохраняет ключ на своем жестком диске? Как я понимаю механизм, загрузка ключа выполняется тегом <video>, поскольку он воспроизводит источник m3u8, используя стек https браузера - как законный клиент внутри браузера отличается от пользователя, просто введя его в адресную строку? Это должно быть действительно очевидно, но я просто не вижу его...

Все самое лучшее,

dansch

Ответы

Ответ 1

как я могу убедиться, что пользователь не просто вводит URL-адрес https в своем браузера и сохраняет ключ на своем жестком диске?

В приложении вы можете иметь ключ/сертификат клиента SSL и тем самым аутентифицировать "приложение" для воспроизведения содержимого. Затем вы избежите утечки контента на другие устройства, чем ваше приложение.

Но это означало бы, что вам нужно как-то скрыть свой ssl-key/passphrase внутри приложения. И, к сожалению, есть проблемы с тем, что видеопроигрыватель iOS использует аутентификацию ключа ssl...

Ответ 2

Ответ не очевиден. По сути, вам необходимо придумать свою собственную поставку ключей, если вы хотите, чтобы она была безопасной. Один из вариантов - установить cookie для авторизованных пользователей и проверить файл cookie на ключевом сервере. Это не позволит кому-либо использовать ключевой URL-адрес для защиты вашей безопасности.

Имейте в виду, что по-прежнему требуется только один законный клиент для утечки ключа для обеспечения безопасности.

Ответ 3

Лучший способ - использовать поддерживаемое Apple HLS шифрование. HLS поддерживает 128-битное AES-шифрование, а клиентскому проигрывателю необходимо декодировать поток.

Ответ 4

Некоторые интересные указатели можно найти здесь: https://developer.apple.com/library/content/documentation/AudioVideo/Conceptual/AirPlayGuide/EncryptionandAuthentication/EncryptionandAuthentication.html

Это потребует пользовательской работы в iOS, но также и для Android и веб-игроков.

Служить ключами из защищенного домена HTTPS. Перед началом воспроизведения ваше приложение может использовать NSURLConnection для аутентификации, предоставляя учетные данные, которые скрыты.
Использовать файлы cookie через HTTPS. Ваше приложение может подключиться к HTTPS-серверу и аутентифицировать приложение определенным образом. Затем ваш сервер может выпустить файл cookie, который применяется к ключевым URL-адресам. Вы должны установить, что cookie истекает долго после завершения воспроизведения. Затем сервер должен требовать наличия допустимого файла cookie сеанса в будущих запросах GET для ключей. Для максимальной надежности, если срок действия находится в ближайшем будущем, сервер должен обновить дату истечения срока действия cookie в своем ответе на будущие запросы GET.
Укажите ключи в файлах .m3u8 с помощью схемы URL, определенной приложением. Приложение должно зарегистрировать пользовательский NSURLProtocol для обработки запросов на эти URL-адреса. Затем плеер возвращается в ваше приложение, когда ему нужно загрузить ключевой URL; ваше приложение может затем получить ключ с использованием защищенного бокового канала и может предоставить его игроку.

Если вы ориентируетесь только на iOS, вам следует использовать Apple Fairplay DRM, который обрабатывает аутентификацию ключей.

Ответ 5

Реализация потокового вещания HTTP в Apple не поддерживает DRM.

См. Раздел часто задаваемых вопросов № 16 на странице https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/FrequentlyAskedQuestions/FrequentlyAskedQuestions.html

Ответ 6

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

Интересное различие, предложение - браузер, который использует пользователь, является законным при воспроизведении видео, встроенного в веб-страницу, и неправомерным при доступе через адресную строку.

Но там никакого реального различия нет, я не думаю, что вы что-то пропустили.

Как вы дадите права на браузер, а не на пользователя? Не можете ли пользователь просто написать свой собственный браузер?

Я знаю, маловероятно, что пользователь будет писать браузер, но в любом случае эти типы обсуждений всегда связаны с маловероятными сценариями. Маловероятный пользователь может найти способ просмотра m3u8 в виде обычного текста, он может напрямую загрузить ключи, они могут использовать эти ключи для незашифрования и возможного фрагмента вместе с сегментами видео.

Или, что гораздо более вероятно, используйте программное обеспечение для записи экрана для копирования любого видео, которое они могут воспроизводить в браузере.

На мой взгляд, если пользователю разрешено воспроизводить видео, они могут, к сожалению, также скопировать видео, потому что нет способа предотвратить отображение видео, которое будет перенаправлено на то, что больше не зашифровано - по крайней мере, в среда настольного компьютера, которая воспроизводит видео в браузере.

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

Ответ 7

Посмотрите здесь https://tools.ietf.org/html/draft-pantos-http-live-streaming-13#section-6.3.6

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

Браузеры не поддерживают DRM из коробки. В HTML5 указывается, что это можно сделать через EME (зашифрованные медиа-расширения), кто бы не реализовал atm.

поэтому ваши варианты:

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