2009-02-11 36 views
16

Estoy trabajando en proyectos que deben proteger los archivos de datos (revelar el código no es el problema principal). Estamos usando Java + Netbeans. ¿Hay alguna instalación que creará jar en formato encriptado? También estamos usando sqlite para la base de datos, por lo que poner archivos de texto en formato encriptado tampoco es una opción adecuada para nosotros.¿Cómo crear un archivo jar encriptado?

+4

Su diseño es defectuoso; enviar datos confidenciales junto con el código no es una idea inteligente. – Rob

+0

Es una aplicación de escritorio. Java se usa para compatibilidad multiplataforma. –

+3

Si necesita proteger los datos, considere SqlCipher. Puede enviar el archivo DB ya encriptado si lo desea. –

Respuesta

20

No es posible crear JAR cifrados, ya que la ejecución de JavaVM debe poder leer de alguna manera los datos que desea ejecutar. Y, al igual que en una VM, cualquier persona con las herramientas y los conocimientos técnicos adecuados podría extraer todos los datos del JAR.

Si fuera posible encriptar el JAR, también debería proporcionar alguna clave de descifrado o facilidad al cliente que desea ejecutar el JAR que anula el propósito del cifrado.

Lo mejor que puedes obtener es ofuscación, pero eso no es una seguridad real ni un obstáculo para el atacante ambicioso.

2

Otra opción sería crear una JVM personalizada que descifre el JAR sobre la marcha. Pero el mismo problema persiste: en algún momento, las clases JAR Java deben descifrarse para que la JVM las ejecute, y en ese punto pueden capturarse y descompilarse.

Sin mencionar que tener una JVM personalizada requeriría que todos sus usuarios descargaran esa JVM también.

1

Puede usar CipherOutputStream y CipherInputStream para serializar objetos Java en un disco en formato cifrado. Esto puede ser una opción abierta para guardar datos.

7

Kosi2801 está más o menos en lo cierto. Lo único que puedo pensar que podrías hacer es lo siguiente, pero es feo.

  1. Envíe un archivo JAR estándar pequeño y un archivo de datos cifrados.
  2. Cuando se ejecuta el JAR, descifra (algunos) del archivo de datos cifrados en la memoria (como el directorio donde están los datos en el JAR, básicamente un sistema de archivos en memoria simple de pares de puntero/longitud)
  3. Conjunto su propio cargador de clases que, cuando se le llama, obtiene los bytes cifrados derecha de la jarra (utilizando la tabla de pseudo-FS se describe en el # 2), lo descifra, y luego carga los datos de la clase de allí

Esto haría dejate cargar las clases Podría hacer lo mismo (sin el cargador de clases) para cargar otros recursos.

Aunque sea divertido para poner en práctica (para los que como un desafío) hay algunos problemas con esto:

  1. que había necesidad de ser capaz de descifrar la materia, por lo que el usuario tendrá que o bien introducir una contraseña cada vez o algo similar. Si el JAR sabe lo suficiente como para descifrarlo, cualquiera puede verlo y descubrir cómo descifrar las cosas. Esto podría mitigarse poniéndose en contacto con un servidor conocido por Internet para solicitar la clave de descifrado (siempre que asegure ese proceso). Por supuesto, esto requiere una conexión de red activa cada vez que alguien quiera ejecutar el programa.
  2. Todo termina en la memoria. Sin una JVM personalizada que maneje bits diminutos de código de bytes cifrados (como mencionó Cameron McKay), las clases terminarán descifradas en algún momento en la memoria principal. A menos que confíe en el sistema operativo para evitar que otras personas lean ese recuerdo, ya habrá perdido la batalla contra cualquiera con un poco de tiempo en sus manos.El mismo problema para los recursos (como imágenes/fuentes/etc.) que intenta leer de alguna tienda cifrada.

Para que pueda darle la vuelta a la gente y hacer las cosas más difíciles, pero en la situación que ha dado todo lo que puede hacer es intentar que no valga la pena el tiempo que la otra persona tendrá que invertir.

La protección del software es difícil, especialmente en algo como Java que puede descompilarse fácilmente y no puede alterar su propio código como C/Assembly. Existe una razón por la que algunos de los programas más costosos requieren dongles de hardware o están bloqueados en una CPU u otro hardware determinado.

+0

ahora entiendo cuando utilicé Ericsson TEMS por qué tenía que usar un dispositivo usb todo el tiempo para ejecutarlo, sorprendentemente usb no tenía datos pero no funcionaría sin él – Johnydep

3

En general, no hay forma de hacerlo de forma segura, si desea que la aplicación y sus datos sean independientes. Sin embargo, ciertamente puede encriptar los archivos y definirlos con una clave enterrada en el código. Un hacker determinado puede obtenerlo, pero si eso no es lo que le preocupa, entonces está bien. Si hace esto, recuerde que los datos cifrados no se pueden comprimir, por lo tanto, comprima primero y luego encripte.

Si realmente necesita que los datos sean seguros (por ejemplo, datos confidenciales), tendrá que encriptar los datos con una clave y suministrar esa clave a la aplicación por algún medio externo, como ponerlo en una unidad flash y haciéndolo llegar al usuario por medio de un servicio de mensajería seguro.

Otra posibilidad es que los datos (o la clave) estén disponibles a través de SSL, y utilice un buen método de autenticación para verificar quién es su usuario.

En general, no es posible que un sistema sea perfectamente seguro, pero tampoco es necesario. Un sistema solo necesita ser lo suficientemente seguro como para desalentar a los atacantes que crees que tratarán de descifrar.

9

Estoy de acuerdo con Kosi2801. El cifrado de archivos de clase es solo una imitación de la seguridad (ver http://www.excelsior-usa.com/articles/java-obfuscators.html) El uso de ClassLoader personalizado puede romper la aplicación, p. en Servidores de aplicaciones.

Existe la mejor manera: use el cifrado de las constantes de cadena en los archivos de una clase. La mayoría de los ofuscadores comerciales tienen esta función, por ejemplo Allatori, Stringer Java Obfuscation Toolkit, Zelix KlassMaster, Smokescreen, DashO (súper caro). El Stringer Java Obfuscator tiene call context check y funciones de control de integridad lo que hace que la protección sea realmente difícil de hackear.

La manera más segura es almacenar y ejecutar partes de bytecode en un dispositivo externo como JavaCard.

N.B. Soy CEO en Licel LLC. Desarrollador de Stringer Java Obfuscator.

Cuestiones relacionadas