it-swarm-es.com

¿Almacenar clave asimétrica privada en aplicación binaria?

Me gustaría dar acceso a un proceso de estilo demonio (es decir, sin interacción del usuario) a una clave secreta compartida para que pueda acceder a un archivo de datos compartido y cifrado. 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, OS X Keychain o Gnome Keyring, 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 contraseña específica del usuario).

El cifrado aquí se usa para proteger los datos mientras transitan redes públicas entre el servidor y el cliente. Los datos en cuestión son datos sin procesar de experimentos científicos. En su mayoría no es valioso (es decir, es poco probable que atraiga a un atacante para romper especulativamente el cifrado y explorar los datos), pero algunos de ellos son potencialmente muy valiosos y los usuarios desean mantener sus datos privados hasta que elijan compartirlo públicamente (es decir, protegerlo 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) mientras transitan el cable sin encriptar proporcionaría algunas pistas a los observadores sobre el valor de un dato.

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

Permitimos la sincronización de los datos cifrados con las estaciones de trabajo/computadoras portátiles locales de los usuarios, por lo que el cifrado de los datos en el disco es, como máximo, una molestia para un atacante determinado. Nosotros 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 demonio. 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 requeriría que cambiemos la clave, actualicemos todos los usuarios y luego volvamos a cifrar la base de datos.

¿Cuál es la mejor manera de almacenar la clave secreta compartida para el proceso del demonio? Puedo poner la clave en el disco y cifrar el archivo en el disco, pero el proceso del demonio debe tener la clave para descifrar ese archivo. Esto parece equivalente a solo tener la clave secreta compartida para los datos cifrados originales. Mi enfoque ingenuo 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?

12
Barry Wark

Esto rápidamente se convierte en un problema de "tortugas hasta el fondo". Solo tiene que decidir en qué punto deja de encriptar cosas y confía en otro método. Creo que el objetivo debería ser detener a los usuarios ocasionales, pero no a los hackers determinados, para acceder fácilmente a los datos protegidos.

Luché con un método similar en una aplicación web que necesitaba almacenar la contraseña DB y la contraseña del certificado SSL. Lo que terminé haciendo fue encriptar 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 bastante fácil darle acceso a un solo usuario al script junto con la capacidad de ejecutarlo utilizando los permisos estándar de archivos UNIX.

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

Además, hay un poco de seguridad a través de la oscuridad aquí, ya que todos los detalles de cómo funciona esto no se documentan muy bien a propósito. Tendría que rastrear cómo funciona el script de inicio, luego averiguar qué algoritmo se usa, cómo se formatea el salt + plantext, etc. Si desea obtener la contraseña de DB y llegar tan lejos, creo que probablemente ya haya tenido roto en el servidor DB directamente.

12
AngerClown

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

En términos generales, no habrá una gran solución para este problema. La clave privada se tendrá en vivo en texto sin formato en algún lugar del disco (o en texto sin formato equivalente), si desea poder iniciar el sistema sin la participación del usuario. Rápidamente golpeará "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, puede ser leída por el usuario root pero no por los usuarios comunes.

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 indicarle al módulo de seguridad de hardware que firme/descifre mensajes arbitrarios). (2) Un enfoque más sofisticado es usar un TPM y bloquear la clave privada de un software en particular. 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 del desarrollador.

7
D.W.

Barry, me gusta tu solución y tengo la idea de llevarla un paso más allá. ¿Qué hay de mantener la imagen de la máquina que usa para crear nuevas máquinas configurada automáticamente para usar 400 en el archivo de clave, luego, al arrancar, inicie el software del servidor como root, lea la clave en la memoria, elimine la clave y luego cambie el usuario que ejecuta el software del servidor? a una cuenta no root.

1
devadvocate

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

1
Barry Wark

¿No hay un llavero disponible para la cuenta del demonio?

1
Steve