Прямая трансляция HTTP с шифрованием

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

Насколько я понимаю, файл .m3u8 объединяет все вместе и ссылается на содержимое (в контейнере MPEG2 TS, зашифрованное 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 браузера — как легитимный клиент внутри браузера отличается от пользователя, просто вводящего его в адресную строку? Это должно быть очень очевидно, но я просто не вижу этого...

Всего наилучшего,

данш


ios http safari http-live-streaming live-streaming
person dansch    schedule 20.12.2010    source источник
comment
Отличный вопрос, тем более что в большинстве случаев HTTPS просто оказывается реализацией на основе доверия сервера, а не доверия клиента. Понятно, что в широкой сети это полезно, поскольку пользовательские данные передаются на серверы, а не наоборот. Таким образом, пользователи должны быть уверены, что отправляют свои данные на доверенный сайт. Однако в случае с видео контент в значительной степени раздается, и сервер должен больше доверять пользователю, чем наоборот. Однако аутентификация на стороне клиента нецелесообразна, поскольку необходимо обслуживать тысячи пользователей. В конце концов, я просто в рассол   -  person Dev Kanchen    schedule 14.03.2012

Ответы (7)


arrow_upward
3
arrow_downward

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

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

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

person janfrode    schedule 29.03.2012

arrow_upward
2
arrow_downward

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

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

person vipw    schedule 02.02.2013
comment
В качестве продолжения Apple представила безопасный механизм доставки ключей для нескольких последних устройств iOS. Они называют это потоковой передачей FairPlay. Вы можете прочитать об этом на сайте Apple: developer.apple.com/streaming/fps - person vipw; 18.08.2015

arrow_upward
2
arrow_downward

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

person Community    schedule 19.08.2016

arrow_upward
2
arrow_downward

Некоторые интересные указатели можно найти здесь: 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, который обрабатывает аутентификацию ключей.

person Pieter Coucke    schedule 19.10.2016

arrow_upward
1
arrow_downward

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

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

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

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

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

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

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

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

person Robert Dupuy    schedule 15.02.2014

arrow_upward
1
arrow_downward

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

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

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

так что ваши варианты:

  1. используйте flash и извлекайте ключи по собственному алгоритму
  2. написать свои собственные плагины (расширения)
  3. быть большим, как Netflix, и договориться с поставщиками браузеров о поддержке DRM, также известной как защита контента и распространение ключей.
person Dorin    schedule 26.05.2016

arrow_upward
1
arrow_downward

Реализация потоковой передачи HTTP в реальном времени от Apple не поддерживает DRM.

См. FAQ номер 16 на https://developer.apple.com/library/archive/documentation/NetworkingInternet/Conceptual/StreamingMediaGuide/FrequentlyAskedQuestions/FrequentlyAskedQuestions.html

person Ronan    schedule 19.01.2011
comment
В вопросе конкретно говорится о шифровании, и в FAQ № 16 говорится: медиафайлы могут быть зашифрованы, а доступ к ключу может быть ограничен путем запроса аутентификации, когда клиент извлекает ключ с вашего HTTPS-сервера. Этот ответ полностью упускает суть. - person Tom Dalling; 19.03.2014