java - obfuscator - proguard
Cómo almacenar de forma segura una clave privada en el código (5)
Esta pregunta ya tiene una respuesta aquí:
Estoy trabajando en un proyecto de software donde la aplicación se ejecutará en un entorno que no es de confianza. Tengo la necesidad de realizar alguna firma criptográfica auxiliar (lo que significa que este no es el medio principal para proteger los datos), pero no deseo dejar la clave a la vista como tal:
private static final String privateKey = "00AABBCC....0123456789";
¿Qué método puedo usar para asegurar razonablemente esto? Soy consciente de que nada es una prueba completa, pero esto agregará una capa adicional en el muro de seguridad.
Para aclarar: tengo lo que es esencialmente una cadena que no deseo haber extraído fácilmente en un depurador o mediante reflexión. Soy consciente de que la descompilación del archivo de clase esencialmente podría dar lugar a este debate, pero ese es un riesgo aceptable.
Obviamente, almacenar la clave fuera del sitio sería ideal, pero no puedo garantizar el acceso a Internet.
¿De quién es la clave privada? Se supone que la clave privada es privada, por lo que es incorrecto distribuirla.
¿Puedes dividir la clave privada en dos partes: almacenar una en tu programa y luego solicitar interactivamente la segunda mitad, cuando se inicia la aplicación?
En primer lugar, ¡es bueno que piense sobre este problema!
¿Es posible, en cambio, generar una clave privada, comunicarse con su Autoridad de certificación y hacer que firme la clave (y también administrar una CRL)?
Como alternativa, si esto se va a ejecutar en Windows, puede usar la API Crypto para almacenar de forma segura una clave privada marcada como no exportable. Sin embargo, cómo distribuir esa clave de forma segura puede ser otro desafío.
Es imposible asegurar una clave en un entorno no confiable. Puedes ofuscar tu código, puedes crear una clave a partir de variables arbitrarias, lo que sea. En última instancia, suponiendo que utiliza la biblioteca javax.crypto estándar, debe llamar a Mac.getInstance() , y en algún momento más tarde llamará a init() en esa instancia. Alguien que quiera tu llave lo obtendrá.
Sin embargo, creo que la solución es atar la llave al medio ambiente , no al programa. Una firma está destinada a decir que los datos se originaron a partir de una fuente conocida, y no se ha manipulado desde que la fuente lo proporcionó. Actualmente, intenta decir "garantizar que mi programa produjo los datos". En cambio, cambie su requisito de "garantizar que un usuario particular de mi programa haya producido los datos". La responsabilidad se transfiere a ese usuario para que cuide su clave.
Olvídate de oscurecerlo en el código. Solo hará que su software sea más difícil de leer, depurar y mantener. También será capturado si su software tiene que someterse a una auditoría de seguridad.
Si no puede colocar la llave en un lugar seguro (de forma segura en el disco, memoria segura o una frase de contraseña en la cabeza de alguien), no se moleste con nada más.
Si se encuentra en un entorno * nix, almacenar la clave en el disco con los permisos de root / root 400 podría ser "lo suficientemente bueno".
En Windows, puede usar el DPAPI para almacenar los datos en la memoria segura de Microsoft.
También puede usar un PBE liviano para encriptar la clave sensible y hacer que el usuario ingrese la frase de contraseña cuando se inicia la aplicación.