HTTP прямой эфир с шифрованием - PullRequest
15 голосов
/ 20 декабря 2010

Я пытаюсь понять, как протокол 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 в браузере - чем отличается законный клиент в браузере от пользователя, который просто вводит его в адресную строку ? Это должно быть действительно очевидно, но я просто не вижу этого ...

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

dansch

Ответы [ 7 ]

3 голосов
/ 29 марта 2012

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

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

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

2 голосов
/ 19 октября 2016

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

Для этого потребуется пользовательская работа в iOS, а также в Android и веб-плеерах.

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

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

2 голосов
/ 19 августа 2016

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

2 голосов
/ 02 февраля 2013

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

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

1 голос
/ 27 мая 2016

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

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

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

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

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

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

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

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

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

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

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

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

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

1 голос
/ 20 января 2011

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

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

...