Cómo proteger la clave de desencriptación de la descompilación?

Soy un programador principiante de Java. Estoy trabajando en una aplicación que descifra algunos datos. La clave de descifrado está codificada en el software y, por lo tanto, puede verse analizando el bytecode.Cómo proteger la clave de desencriptación de la descompilación?

Sé que la ingeniería inversa no puede evitarse por completo, por lo que estoy tratando de hacer el proceso lo más difícil posible.

Mi idea no es introducir directamente la clave en mi código, sino hacer que experimente algún tipo de transformación. Por ejemplo, podría escribir -

private static final byte[] HC256A = Hex 
      .decode("8589075b0df3f6d82fc0c5425179b6a6" 
        + "3465f053f2891f808b24744e18480b72" 
        + "ec2792cdbf4dcfeb7769bf8dfa14aee4" 
        + "7b4c50e8eaf3a9c8f506016c81697e32");

De esta manera alguien que busca en el código de bytes no puede leer inmediatamente. Pero tendrá que seguir la lógica y aplicarle transformaciones, lo que no será mucho más fácil a nivel de byte.

¿Qué piensan? ¿Esto es útil? ¿Cuál podría ser la mejor transformación que no sea la decodificación hexadecimal? ¿Hay algún otro método disponible para proteger las claves de descifrado codificadas?

Gracias por todas sus sugerencias.

Fuente

2011-05-20 Monika Michael

Puede escuchar la conexión de un depurador (funciona en C++, no está seguro de cómo hacerlo en Java) y, de ser así, elimine el valor de la memoria. –

¿Cuál es la sensibilidad de los datos que se decodifican? Esto ayudará a servir de guía en cuanto a la cantidad de esfuerzo para proteger esos datos. Cualquier forma de ocultar la clave en el bytecode es relativamente fácil de vencer. Además, esto requeriría que cada usuario del software tenga la misma clave y se requiere una nueva recopilación para cambiar a la clave. –

La información es bastante sensible. Es una impresión de medios digitales que, si se filtrara, causaría graves problemas a la empresa. –

La forma correcta de atacar tal ofuscación (especialmente en los lenguajes de bytecode) es conectar el depurador al lugar donde se pasa la clave (si la depuración no es posible, comience a analizar el código desde ese lugar). De esta forma, el atacante no necesita buscar la clave en absoluto y no le importa cuán ofuscada está la clave. Entonces necesitas repensar tu diseño.

Si solo quiere protegerse de los acechadores amateurs, entonces dividir la llave y XORing sus partes (posiblemente con diferentes llaves), sería suficiente. Un truco más: obtenga la clave de las constantes de texto ya presentes en el código (como el nombre de la aplicación). Esto hace que la clave sea menos obvia que la división o XORing.

Fuente

2011-05-20 09:37:22

+1 para 'derivar la clave' – sehe

+1 para responder ** ambos ** por qué no debes hacerlo ** y ** cómo hacerlo ;-) –

@Joachim en realidad las dos partes cubren diferentes tipos de atacantes :) –

Enfrentado con un problema similar (en c) fui con almohadillas XOR de un solo uso. Esto es bueno porque parece una basura ... si se vuelve realmente inteligente, puede husmear esa tecla (incorrecta) en uso. Evitaría cualquier cosa que inyecte cadenas legibles por humanos, ya que invariablemente llamarán la atención sobre ese fragmento de código.

Fuente

2011-05-20 09:34:11 Yaur

Las almohadillas XOR con algunos cambios de bit aplicados son probablemente tan buenas como pueden: no es realmente * buena * prevención, pero frustra a aquellos que simplemente llaman a 'javah' y esperan obtener un volcado directo de la clave. –

No codifique la clave en el código fuente en absoluto. Guárdelo por separado, envíelo por separado, p. en un almacén de claves de Java, y solo a los clientes/sitios/clientes en los que confía, y ponga algunos términos legales en la licencia que les impone la carga si pierden el almacén de claves.

Fuente

2011-05-20 09:53:57 EJP

¿Y cómo almacena la clave del almacén de claves en su código? – raymi

Cómo proteger la clave de desencriptación de la descompilación?

Respuesta

Cuestiones relacionadas