Protección de datos en reposo en Android

Usted mismo ha respondido la pregunta. Está intentando implementar DRM para evitar que los usuarios puedan sacar el video del dispositivo. En la práctica hay poco que puedas hacer para prevenir esto. Siempre habrá formas de copiar la transmisión, incluso si se la intercepta (debe mostrarse en el dispositivo en algún momento, ¿no?).

Entonces, lo único que puedes hacer es hacerlo más difícil, pero no imposible de copiarlo. También puede incluir algunos metadatos en el video cuando se transmite o cuando se descarga para identificar al usuario que filtró el video.

Google tiene el mecanismo DRV de Widevine (solución DRM de video). Una herramienta que puede jugar con los componentes internos de Widevine (libwvcdm) se puede encontrar aquí: enlace

También existe el marco multimedia Stagefright para suministrar DRM - enlace - Josh Drake está haciendo un prezo al respecto en BlackHat US this año

ACTUALIZACIÓN: ... y aquí hay un fuzzer para meterse con Stagefright - enlace

No tienes muchas opciones para resolver esto realmente:

1. Si elimina la reproducción sin conexión, entonces puede usar HLS con cifrado, con la transmisión alojada en el servidor.
2. Permitir la reproducción sin conexión, como dijiste, tendrá que cifrar / descifrar el video de alguna manera. Siempre puede dejar la clave pública (clave de cifrado) almacenada localmente para el cifrado, pero necesita proteger la clave privada (descifrado), por lo que podría almacenarse en un servidor y recuperarse justo antes de la reproducción local. Pero en este escenario, necesitarías estar en línea para obtener la clave de descifrado. También para protegerse contra la pérdida de claves, también deberá agregar un mecanismo de protección de raíz.

Como se mencionó en otras respuestas, este problema parece muy cercano a los problemas de DRM, con la única pero notable excepción de que, según tengo entendido, no necesita que el archivo de video pueda reproducirse con ningún otro software que no sea el suyo.

Para evitar cualquier clave almacenada, me imagino que la clave real se deducirá (como un hash) de varios parámetros que definen su restricción (ID de video, ID de registro, otra información que identifica el móvil, por ejemplo, etc.), por lo tanto proporcionando una clave única por archivo, la clave real no se almacena en ninguna parte, pero se calcula al abrir el archivo.

Un poco el mismo principio que Windows al generar una clave de activación deducida del hardware de la computadora para vincular esta instalación a este hardware, la idea aquí sería generar esta clave para vincular este archivo de video a este móvil y usuario.

Por supuesto, el problema sigue siendo que algunos usuarios pueden aplicar ingeniería inversa a su aplicación, deducir el algoritmo clave de construcción y publicar una oferta especial para descifrar su video. Para contrarrestar esto, puede involucrar algunas técnicas de ofuscación, pero al igual que con el DRM, debe definir una compensación entre el esfuerzo realizado para proteger el contenido y el valor del contenido real.

Por ejemplo, dependiendo de su contenido y la popularidad de su aplicación, la mayoría de los usuarios pueden pensar que no vale la pena sacrificar la seguridad de su teléfono instalando la aplicación de descifrado de alguna tienda oscura, dado que alguien lo suficientemente competente encontró que valía la pena crear este descifrado. en primer lugar y mantenerla para que coincida con las actualizaciones de su algoritmo.