¿Guardar una clave asimétrica privada en el binario de la aplicación?

12

Me gustaría otorgar acceso a una clave secreta compartida a un proceso de tipo demonio (es decir, sin interacción del usuario) para que pueda acceder a un archivo de datos encriptado compartido. Las aplicaciones de usuario que acceden a los mismos datos cifrados almacenan la clave secreta compartida en el llavero del sistema operativo del usuario (por ejemplo, el llavero OS X o el llavero de Gnome, etc.). El llavero del sistema operativo, a su vez, protege la clave secreta con la contraseña de inicio de sesión del usuario (u otra específica del usuario).

El cifrado aquí se utiliza para proteger los datos mientras transita las redes públicas entre el servidor y el cliente. Los datos en cuestión son datos en bruto de experimentos científicos. Principalmente no valioso (es decir, es poco probable que atraiga a un atacante para romper especulativamente el cifrado y navegar por los datos), pero algunos de ellos son potencialmente muy valiosos y los usuarios desean mantener sus detalles privados hasta que decidan compartirlos públicamente (es decir, protegerlos). de observadores casuales en la red). El valor de los datos es difícil de determinar sin un análisis científico, por lo que observar la actividad de los usuarios (incluidas las consultas) a medida que transitan el cable sin cifrar proporcionaría algunas pistas a los observadores sobre el valor de un dato.

El proceso daemon es un servidor de consultas para el sistema. Lee los datos compartidos, procesa una consulta y devuelve los identificadores de un conjunto de resultados al cliente, quien luego extrae los datos identificados del almacén compartido.

Permitimos la sincronización de los datos cifrados a las estaciones de trabajo / computadoras portátiles locales de los usuarios, por lo que el cifrado de los datos en el disco es a lo sumo una molestia para un atacante determinado. También permitimos a los usuarios ejecutar el servidor de consultas localmente (aún iniciado por init.d / launchd), por lo que quiero hacer todo lo posible para proteger la clave secreta almacenada con el daemon. El mayor riesgo es que un determinado usuario malintencionado pueda descubrir la clave secreta del demonio en su sistema. La exposición de esa clave nos obligaría a cambiar la clave, actualizar todos los usuarios y luego volver a cifrar la base de datos.

¿Cuál es la mejor manera de almacenar la clave secreta compartida para el proceso del daemon? Puedo poner la clave en el disco y cifrar el archivo en el disco, pero el proceso del daemon debe tener la clave para descifrar ese archivo. Esto parece equivalente a solo tener la clave secreta compartida para los datos cifrados originales. Mi ingenuo enfoque sería almacenar la clave en el binario de la aplicación, pero no puedo imaginar que sea la mejor opción. ¿Algún consejo?

    
pregunta Barry Wark 18.01.2011 - 19:12
fuente

5 respuestas

12

Esto se convierte rápidamente en un problema de 'tortugas hasta el fondo'. Solo tienes que decidir en qué punto dejar de cifrar las cosas y confiar en otro método. Creo que el objetivo debería ser detener a los usuarios ocasionales, pero no a los piratas informáticos, para obtener fácilmente los datos protegidos.

Luché con un método similar en una aplicación web que necesitaba almacenar la contraseña de DB y la contraseña de certificado SSL. Lo que terminé haciendo fue cifrar esas contraseñas en un archivo de configuración para la aplicación usando una contraseña maestra diferente . La contraseña maestra se almacenó como una variable de entorno establecida por el script de inicio de la aplicación. Dado que la contraseña maestra se configuró solo en el script de inicio, fue lo suficientemente fácil como para que un solo usuario acceda al script junto con la capacidad de ejecutarlo con los permisos de archivo UNIX estándar.

Mi idea era que para obtener acceso a este script, de lo contrario, ya debías ser root, en ese momento, realmente no importa. Si no puede confiar en la raíz (o el servidor ha sido pirateado) probablemente tenga otros problemas.

También, hay un poco de seguridad en la oscuridad aquí en que todos los detalles de cómo funciona esto no se documentan muy bien a propósito. Tendría que hacer un seguimiento de cómo funciona la secuencia de comandos de inicio, luego averiguar qué algoritmo se usa, cómo se formatea el texto sal + plan, etc. Si desea obtener la contraseña de base de datos y llegar tan lejos, me imagino que probablemente ya tenga roto en el servidor DB directamente.

    
respondido por el AngerClown 18.01.2011 - 22:12
fuente
7

Como de costumbre, el mejor lugar para comenzar es preguntarse: ¿Cuál es su modelo de amenaza? ¿Qué estás tratando de proteger? ¿Contra quién estás tratando de protegerlo? ¿Por qué usas crypto en primer lugar? Ninguno de estos está claro de la pregunta. (Crypto no es polvo mágico de duendes). Y sin respuestas a esas preguntas, no podemos ofrecerle una solución: la solución correcta dependerá de lo que esté tratando de lograr.

En general, no habrá una gran solución para este problema. La clave privada tendrá que vivir en texto claro en algún lugar del disco (o en texto claro equivalente), si desea poder iniciar el sistema sin la participación del usuario. Rápidamente golpearás "tortugas hasta el fondo", como han sugerido otros.

Un paso que puede tomar es asegurarse de que la clave privada esté protegida por los controles de acceso al sistema de archivos: por ejemplo, es legible por la raíz pero no por los usuarios normales.

Nota al pie: Existen enfoques sofisticados, pero probablemente no sean adecuados para su entorno de bajo costo. (1) Un enfoque más seguro es almacenar la clave privada en un módulo de seguridad de hardware conectado al servidor. Si el servidor se ve comprometido, el software no puede robar la clave privada (pero aún puede dar instrucciones al módulo de seguridad de hardware para que firme / descifre mensajes arbitrarios). (2) Un enfoque más sofisticado es usar un TPM y bloquear la clave privada a una pieza particular de software. Desafortunadamente, los sistemas operativos actuales no brindan un buen soporte para esto, por lo que sería muy difícil hacerlo usted mismo como administrador de sistemas: requeriría un soporte significativo para desarrolladores.

    
respondido por el D.W. 19.01.2011 - 08:16
fuente
1

¿No hay un llavero disponible para la cuenta para el daemon?

    
respondido por el Steve 18.01.2011 - 19:23
fuente
1

Para completar, la solución que elegimos fue una combinación de las respuestas de @SteveSyfuhs y @ AngerClown. En OS X, estamos haciendo uso del llavero del sistema ( /Library/Keychains/System.keychain ). En Linux, almacenamos la clave de cifrado en un archivo con los bits de permisos 400 (es decir, solo de lectura por propietario), propiedad de root.

    
respondido por el Barry Wark 23.01.2011 - 04:32
fuente
1

Barry, me gusta tu solución y tengo una idea para ir un paso más allá. ¿Qué le parece mantener la imagen de la máquina que usa para crear nuevas máquinas configuradas automáticamente para usar 400 en el archivo de clave, luego al iniciar el software del servidor como root, leer la clave en la memoria, eliminar la clave y luego cambiar al usuario que ejecuta el software del servidor a una cuenta no root.

    
respondido por el devadvocate 29.09.2011 - 06:00
fuente

Lea otras preguntas en las etiquetas