Clone de Snapchat: ¿Cómo aseguro las notificaciones pre-descargadas para que no puedan abrirse fuera de la aplicación?

En principio, no hay manera de resolver este problema. Snapchat es una mentira. Si Alice está motivada y bien informada, puede hacer arreglos para hacer copias persistentes de cualquier snapchats que pueda ver. Probablemente hay docenas de formas de hacer esto: hacer capturas de pantalla, aplicar ingeniería inversa a la aplicación para robar la clave de descifrado, hurgar en la memoria para encontrar los datos y hacer una copia, etc.

No hay forma de evitar que un usuario motivado e informado realice una copia permanente. Tratar de detener eso es como intentar agua no mojada .

Todo lo que puedes hacer es elevar un poco la barra, por lo que no es trivial hacer una copia permanente (es decir, hacer que sea tan difícil que los usuarios desconocidos o desmotivados no tengan éxito). Ese es un enfoque de reducción de riesgo. Pero nada será seguro en principio. Como resultado, esto no es realmente una cuestión que la criptografía pueda resolver. Es más una cuestión de seguridad. Es posible que desee intentar preguntar en Security.SE.

Estás tratando de resolver un problema sin solución. Alguien puede simplemente tomar una captura de pantalla de la imagen, hacer una grabación de la grabación de audio, tomar un video del video intercambiado.

Cualquier persona con acceso al dispositivo receptor ya tiene acceso a cualquier clave de cifrado / descifrado que pueda usar. Luego, simplemente olfatean la conexión y almacenan los medios de forma permanente.

Es una preocupación, pero no para el usuario ocasional. Puede que la aplicación solo obtenga la clave cuando se inicie la ventana de visualización y eliminarla cuando haya terminado, pero no hay manera de evitar un volcado de memoria y luego intentar extraer la clave manualmente.

No hay forma criptográfica o de programación para ahorrarse aquí. Si desea controlar la forma en que alguien puede consumir medios a los que realmente tienen acceso para consumir, está firmemente en el ámbito de DRM y es una batalla perdida.

Principio de Kerckhoffs (también llamada desiderata de Kerckhoffs, suposición de Kerckhoffs, axioma o Auguste Kerckhoffs declaró en el siglo XIX: Un criptosistema debería ser seguro, incluso si todo lo relacionado con el sistema, excepto la clave, es de conocimiento público . El principio de Kerckhoffs fue reformulado (o quizás formulado de manera independiente) por Claude Shannon como " el enemigo conoce el sistema "

  

¿Es mi enfoque sugerido criptográficamente seguro?

De hecho, un atacante observará su implementación y explotará el hecho de que está confiando en un PRF al que el atacante puede acceder. Al menos necesitarías separar el PRF del resto para estar seguro. Especialmente, ya que declara que enviaría un ID de usuario único a la PRF durante su "proceso de autorización" (llamémoslo). Si asumimos que la clave única no cambia, también estamos cambiando un poco hacia un problema de reutilización de la clave, lo que abre vectores de ataque adicionales; especialmente con su ejemplo de implementación. Pero no voy a entrar en demasiados detalles, ya que rápidamente se volvería demasiado amplio. La historia corta es: usted es correcto: su implementación descrita no es segura ... en absoluto.

  

¿Qué otros enfoques, mejores o más simples puedo tomar para resolver este problema?

Las posibles soluciones podrían encontrarse fácilmente en criptografía de clave pública . O bien, podría intentar confiar en un intercambio de datos autorizado con un servidor web utilizando una conexión HTTPS segura para que el servidor proporcione la funcionalidad PRF, pero eso es menos seguro y no estoy realmente seguro de si realmente satisfaría todas sus necesidades criptográficas .

Personalmente, recomendaría ir a public-key crypto cuando se trata de una aplicación de comunicación como la describe en su pregunta, porque es la forma habitual de manejar la situación / funcionalidad que describe. Puede sonar un poco aburrido, pero no hay necesidad de reinventar la rueda mientras haya opciones bien verificadas disponibles. Especialmente, si su conocimiento criptográfico no es (al menos) a nivel profesional. Y aún así, los profesionales tienden a ir a implementaciones criptográficas probadas en lugar de intentar crear su propia solución criptográfica. Las posibilidades de que arruines las cosas (como el PRF del que estás confiando se compartiría con los atacantes) son demasiado grandes para tomarlas ... un pequeño defecto en tu criptografía puede convertirse rápidamente en una aplicación 100% insegura.

Ahora, no mencionó ningún lenguaje de programación, así que no puedo señalarle ninguna dirección específica, pero las soluciones de clave pública (bibliotecas, etc.) están disponibles para casi cualquier lenguaje de programación. Debe ser fácil encontrar algo apropiado para sus propósitos. Y si alguna pregunta relacionada con la clave pública crypto surge en el camino, siéntase invitado a publicar otra pregunta aquí como Crypto.SE.