Потоковая передача 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, а также защиты контента и ключа
распределение.