ios - respaldo - Transmisión en vivo HTTP con encriptación

recuperar contraseña encriptado copia seguridad iphone (7)

La implementación de streaming HTTP en vivo de Apple no es compatible con DRM.

Consulte la Pregunta frecuente número 16 en http://developer.apple.com/library/ios/#documentation/networkinginternet/conceptual/streamingmediaguide/FrequentlyAskedQuestions/FrequentlyAskedQuestions.html

Estoy tratando de entender cómo el protocolo HTTP Live Streaming que Apple admite en sus dispositivos iOS y en Safari protege la clave que desbloquea el contenido.

De la manera en que lo entiendo, el archivo .m3u8 mantiene todo junto y hace referencia al contenido (en el contenedor MPEG2 TS, cifrado AES 128) y la clave del archivo TS.

Como en este ejemplo:

#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

Suponiendo una reproducción basada en navegador donde el elemento <video> se alimenta con un archivo m3u8 en el atributo "src". En este caso, incluso si la clave se entrega a través de https, ¿cómo puedo asegurarme de que el usuario simplemente no ingrese la URL https en su navegador y guarde la clave en su disco rígido? La forma en que entiendo el mecanismo, la descarga de clave se realiza mediante la etiqueta <video> mientras reproduce la fuente m3u8 utilizando la pila https del navegador: cómo se distingue el cliente legítimo dentro del navegador del usuario simplemente escribiéndolo en la barra de direcciones ? Esto debe ser realmente obvio, pero simplemente no lo veo ...

Todo lo mejor,

dansch

¿Cómo puedo asegurarme de que el usuario no ingrese simplemente la URL https en su navegador y guarde la clave en su disco rígido?

Puede tener una clave / certificado de cliente SSL en la aplicación y, por lo tanto, autenticar "la aplicación" para reproducir el contenido. Entonces evitarías filtrar tu contenido a otros dispositivos que no sean tu aplicación.

Pero eso significaría que necesitaría esconder de algún modo su contraseña / clave secreta dentro de la aplicación. Y desafortunadamente también hay problemas para que el reproductor de video en iOS use la autenticación de la clave ssl ...

La respuesta no es obvia en absoluto. En esencia, se requiere que invente su propia entrega de clave si desea que sea segura. Una opción es establecer una cookie para usuarios autorizados y verificar la cookie en el servidor de claves. Esto evitará que alguien pueda usar la url de la clave para eludir su seguridad.

Tenga en cuenta que solo se necesita un cliente legítimo para filtrar la clave para que su seguridad se invalide.

¿Cómo se distingue el cliente legítimo dentro del navegador del usuario simplemente tipeándolo en la barra de direcciones?

Interesante distinción, la sugerencia es que el navegador que el usuario está utilizando es legítimo cuando se reproduce el video incrustado en la página web, y es ilegítimo cuando se accede a través de la barra de direcciones.

Pero no hay una distinción real allí, no creo que te estés perdiendo nada.

¿Cómo le daría derechos a un navegador y no a un usuario? ¿No puede un usuario simplemente escribir su propio navegador?

Lo sé, parece poco probable que un usuario escriba un navegador, pero de todos modos este tipo de discusiones siempre tratan sobre escenarios poco probables. Un usuario poco probable podría encontrar una manera de ver el m3u8 como texto sin formato, podrían descargar las claves directamente, pueden usar esas claves para desencriptar y finalmente unir los segmentos del video.

O, algo mucho más probable: use el software de grabación de pantalla para copiar cualquier video que puedan reproducir en el navegador.

En mi opinión, si un usuario está autorizado para reproducir el video, lamentablemente también pueden copiar el video, porque no hay manera de evitar que la visualización del video se redirija a algo que ya no está encriptado, al menos en el entorno de una computadora de escritorio que está reproduciendo un video en un navegador.

De todos modos, tengo entendido que puede proteger las claves al requerir autorización para obtener las claves, pero si el usuario tiene esa autorización, entonces - bueno, pueden obtener las claves.

Eche un vistazo aquí https://tools.ietf.org/html/draft-pantos-http-live-streaming-13#section-6.3.6

la lista de reproducción tendrá que especificar una etiqueta clave para cada segmento. para que un jugador pueda identificar una clave requerida para descifrar un segmento.

Los navegadores no son compatibles con DRM de fábrica. HTML5 especifica que se puede hacer a través de EME (extensiones de medios cifrados) quien no implementó atm.

entonces tus opciones son:

usa el flash y busca las teclas a través de tu propio algoritmo
escribe tus propios complementos (extensión)
ser grande como Netflix y estar de acuerdo con los proveedores de navegadores para que apoyen la protección de contenido y la distribución de claves de DRM.

La mejor manera es usar el cifrado compatible con Apple HLS. El HLS es compatible con el cifrado AES de 128 bits y el jugador del cliente necesita decodificar la transmisión.

Algunos indicadores interesantes se pueden encontrar aquí: https://developer.apple.com/library/content/documentation/AudioVideo/Conceptual/AirPlayGuide/EncryptionandAuthentication/EncryptionandAuthentication.html

Esto requerirá un trabajo personalizado en iOS, pero también en Android y reproductores web.

Sirve claves desde un dominio HTTPS protegido . Antes de que comience la reproducción, su aplicación puede usar NSURLConnection para autenticarse, proporcionando credenciales que se mantienen ocultas.
Use cookies a través de HTTPS . Su aplicación puede establecer una conexión con un servidor HTTPS y autenticar la aplicación de una manera definida por la aplicación. Su servidor puede emitir una cookie que se aplica a las URL clave. Debe configurar la cookie para que expire mucho después de que finalice la reproducción. El servidor debe entonces requerir la presencia de una cookie de sesión válida en futuras solicitudes GET para las claves. Para una máxima confiabilidad, si la fecha de vencimiento es próxima, el servidor debe actualizar la fecha de caducidad de la cookie en su respuesta a futuras solicitudes GET.
Especifique las claves en los archivos .m3u8 utilizando un esquema de URL definido por la aplicación . La aplicación debe registrar un NSURLProtocol personalizado para gestionar las solicitudes de esas URL. El jugador vuelve a llamar a su aplicación cuando necesita cargar una URL clave; su aplicación puede obtener la clave utilizando un canal lateral seguro y puede proporcionarla al jugador.

Si solo apuntas a iOS, debes utilizar Apple Fairplay DRM, que maneja la autenticación de las claves.