Sí, pero no lo hagas.
Si está preguntando si es posible encontrar un esquema propietario para cifrar datos que solo su aplicación "sepa", la respuesta es sí, hasta que alguien descubra cómo realizar una ingeniería inversa (lo que generalmente es más fácil que te das cuenta). Este tipo de práctica se conoce como security by obscurity y es altamente desaconsejado .
En su lugar, su aplicación debe utilizar un esquema de cifrado que sea de dominio público (y, por lo tanto, probado y probado). Para proporcionar la especificidad de la aplicación, use una clave criptográfica que solo la aplicación "conoce . " Un pirata informático que intenta realizar una ingeniería inversa de la clave puede tener cierto éxito, pero los parámetros que gobiernan ese éxito (por ejemplo, cuánto tiempo tomará y la potencia de cálculo requerida) son bien conocidos y entendidos, y puede diseñar una estrategia de riesgo general adecuada para el nivel de la seguridad requerida por su caso de negocio (por ejemplo, puede usar claves más largas o cambiarlas más a menudo).
El cifrado es solo una parte del problema
No estoy seguro de qué vectores de ataque está intentando mitigar, pero supongo que desea una aplicación de "visor de imágenes" que sea el único medio para ver una imagen, y además está trabajando con el supuesto de que la aplicación puede caer en manos de un hacker. Si esto es correcto, se enfrenta a un problema muy difícil (punto final de cliente comprometido).
Por lo general, si hay un punto final de cliente comprometido, los profesionales de seguridad de EE. UU. se dan por vencidos. Una solución totalmente a prueba de balas es casi imposible. Pero se han hecho intentos, y estos caen bajo el léxico de Digital Rights Management (DRM) . Estos son algunos de los problemas que deberá resolver:
- Necesita una ruta de medios protegida .
Incluso si toda la seguridad en su aplicación funciona, aún necesita mostrar la imagen, y la forma en que O / S muestra una imagen está utilizando un controlador de video. Bueno, cualquiera puede escribir su propio controlador de video, y no hay nada que impida que un controlador de video grabe y almacene una imagen para uso involuntario. La forma típica de lidiar con esto es exigir que las bibliotecas del controlador de video estén firmadas digitalmente y que el O / S verifique la firma antes de permitir que la salida vaya al controlador.
- Necesitas proteger la memoria de tu aplicación
No importa lo inteligente que sea su aplicación, un pirata informático puede encontrar una manera de acceder a su memoria si tiene acceso físico a la máquina. Una mitigación mínima para esto es ejecutar un pequeño código para verificar si hay algún depurador actualmente en ejecución en el sistema, y detener la salida si la hay. No es probable que esto detenga a un pirata informático determinado que tiene formas de enmascarar esas cosas.
- Debes proteger el contenido y la clave
Las soluciones que he visto implican almacenar los medios en formato cifrado (usando una clave simétrica: una clave pública / privada es demasiado lenta). Cuando se ejecuta el visor, solicita una clave de un servidor, utilizando un documento firmado que indica que tiene derecho a solicitar la clave. La clave se almacena en la memoria y el contenido se descifra, luego la clave se sobrescribe en la memoria con datos aleatorios y se descarta.
- Debe evitar que el pirata informático tome una fotografía del monitor de video
Problema bastante difícil de resolver. Incluso si haces todas estas cosas de seguridad, nada en el mundo impedirá que alguien saque su cámara y tome una foto de la pantalla. Esto sería una pérdida, por supuesto, pero con un buen monitor y una buena cámara aún puede obtener una gran imagen.
La única mitigación para esto que puedo imaginar es incluir una marca de agua sensible al contraste en la imagen en sí. Esto puede o no ser aceptable para usted.