¿Cómo almacenar con seguridad datos confidenciales como un número de seguridad social?

Lo que estás buscando es un cifrado determinista: que el mismo valor cifrado dos veces da el mismo resultado. Dado el cifrado determinista con una clave K, un atacante necesitaría la clave para determinar qué SSN se asigna a qué valor cifrado. Aún puede realizar búsquedas en los datos cifrados de manera determinista, pero solo comparaciones de equivalencia (==,! =).

Ejemplos de criptografía determinista que funcionarían:

• Bloque los cifrados en el modo ECB , si los datos están < 1 bloque de largo
• Bloquea los cifrados en CBC , con una estática IV .
• Bloquea los cifrados en CBC con un modo IV derivado del texto simple. (Tenga en cuenta que no desea almacenar el IV en ese momento, por lo tanto, el descifrado sin el texto simple es imposible, por lo que esta es una opción de solo búsqueda).

Lo que no funcionará:

• Modo CTR con un IV estático (un atacante puede usar varios cifrados para recuperarse la secuencia de teclas & plaintexts)
• Modo CBC con un IV aleatorio (no se puede buscar)
• Cualquier cifrado de flujo (igual que el modo CTR)

Tenga en cuenta que, en todos los casos, está renunciando a la indistinguibilidad del texto cifrado, pero ese es un requisito fundamental para poder buscar en los textos cifrados.

Necesita un mecanismo para compartir la clave con otros sistemas que necesitan acceso al texto sin formato, pero un atacante que obtiene acceso a una copia de seguridad de la base de datos, inyección de SQL o cualquier otro ataque que otorgue acceso solo a la base de datos no lo hará. ser capaz de discernir las plaintexts.

PKI no es útil aquí, como señala, por tener la clave pública permite enumerar los valores y recuperarlos, si está utilizando un criptosistema PKI determinista (simple, sin relleno, RSA , por ejemplo). El uso de una PKI no determinista (RSA rellenada) no le permitirá buscar en los textos cifrados.

Revisaría si realmente necesita encriptar plaintexts forzados pequeños, fácilmente brutos. ¿Cuál es tu modelo de amenaza? ¿Puede protegerse contra estas amenazas de otras maneras?

Tenga en cuenta que hay dos partes separadas para proteger estos datos, cuando está en reposo y cuando está en tránsito.

No debe almacenar (datos en reposo) ningún tipo de datos confidenciales directamente en texto claro, punto. Cosas como contraseñas y seguridad social, y los números de las tarjetas de crédito deben estar encriptados antes de ser almacenados en el disco. Estoy de acuerdo con lorenzog en cuanto a desacoplar su solución, pero sugiero una configuración ligeramente diferente:

1. Servidor de base de datos. Este servidor almacena campos cifrados confidenciales en una base de datos (SQL / MySQL / Oracle), pero nunca tiene los datos de texto claro. Se cifrará antes de almacenarse en la tabla / campo de la base de datos. Tampoco tiene la clave privada para descifrar los datos, solo los blobs cifrados.

2. Servidor de aplicaciones criptográficas. Este servidor almacena la clave privada utilizada para cifrar y descifrar los campos de un usuario autorizado y autenticado. Este es el único lugar donde los datos almacenados en el servidor de la base de datos se pueden cifrar y descifrar. Obviamente, este será un objetivo alto para los activos, y debe fortalecerse y controlarse mediante políticas. Trate de manera similar a un controlador de dominio, por ejemplo, y audite todos los accesos y consultas al mismo.

3. Servidor web. Cargar las solicitudes de balance del usuario y la comunicación segura entre servidores y servicios. Sirve como punto final para la comunicación con usuarios externos.

La comunicación (datos en tránsito) con el cliente y sus equipos asociados también es muy importante aquí, no se debe pasar por alto eso. Asegúrese de estar usando SSL y en los niveles más altos de cifrado y cifrado posibles.

No será fácil de configurar (más difícil que nada de seguridad básica, pero no imposible de ninguna manera) y si no cumple con la confianza de sus clientes, estará en una forma mucho peor que el tiempo necesario para obtener la seguridad. Derecho de datos personales. :)

¡Buena suerte!

En realidad, tienes TRES problemas que has implicado en tu pregunta.

• El título habla de datos en reposo.
• En la pregunta, también habla sobre el control de acceso.
• Además, también tiene una pregunta sobre los datos en tránsito.

La pregunta puede tener una respuesta diferente si ya está utilizando un sistema DB y está introduciendo el cifrado en un sistema existente. Muchos de los sistemas DB ahora admiten dichas funciones de seguridad (ver más abajo).

Control de acceso y datos en tránsito

La mayoría de los sistemas de base de datos admiten el control de acceso desde el primer día (es casi un requisito mínimo). Sin embargo, cuando dice que tal o cual sistema necesita poder leerlo, es realmente una pregunta de control de acceso.

Del mismo modo, los datos en tránsito también son una cuestión de los protocolos utilizados, muchos de los cuales son compatibles con los sistemas de base de datos existentes. Por ejemplo, SQL Server admite SSL para las conexiones, al igual que MySQL . (Busque a otros, también podrían apoyarlo).

Cifrado en reposo

El tercero es el cifrado en reposo, que resuelve el problema de si una persona o sistema no autorizado obtuviera el archivo de base de datos real, qué es lo que ven. También viene un problema relacionado con la administración de claves, es decir, ¿por qué la persona que recibió su archivo DB no puede obtener las claves?

Durante el diseño, sería prudente suponer que un día las claves podrían ser comprometidas o robadas o, puramente desde el punto de vista de la agilidad criptográfica, tendrá que cambiar el algoritmo y las claves (por ejemplo, quien las haya usado). DES tuvo que mudarse eventualmente a AES). Aunque no puede ser 0 costo, tiene que haber un camino esp. Si su base de datos será distribuida, cambie el algoritmo o la clave.

Muchos DB ahora proporcionan cifrado en reposo junto con algunas soluciones de administración de claves. Por ejemplo, SQL Server ha admitido el cifrado desde 2008 . Además, el servidor SQL ha publicado una historia clave de la gestión del ciclo de vida también con aparentemente soporta claves simétricas y asimétricas (a través de certificados). Creo que SQL también admite el cifrado completo de la base de datos frente a los campos seleccionados a través de consultas (como en su caso para SSN).

Igualmente, MySQL también admite cifrado mediante funciones de consulta , que puede utilizar para su escenario SSN. También puede utilizar otros sistemas de bases de datos que ya puedan admitir el cifrado y usarlos.

Si utiliza un sistema que admite el cifrado incorporado, es probable que evite muchas de las dificultades asociadas a hacerlo por su cuenta, así como obtener un sistema compatible.

Base de datos de investigación

CryptDB es un sistema de base de datos desarrollado en el MIT que cifra los datos en reposo y también admite la ejecución de consultas sobre los datos cifrados. Si observa la página del sistema, enumera las organizaciones que realmente lo están utilizando.

Escribiendo su propia lógica de cifrado

Es probable que esto sea más lento y más desafiante para hacerlo bien, pero según su pregunta, parece que está considerando esto como un problema. Si estuviera en una situación similar, definitivamente lo evitaría e iría con uno de los sistemas de base de datos existentes.

Hay muchos problemas. Por ejemplo, cuando encripta los datos, la salida es algo aleatoria, por lo que al cifrar los mismos datos con la misma clave generalmente no se obtendrá el mismo texto cifrado. Puede ser un poco difícil y es posible que tenga que disminuir la entropía (por ejemplo, mediante el uso de los mismos IV o sales), lo que podría afectar la seguridad de su sistema. Y con algo tan simple como almacenar hashes (o incluso HMAC con una sola clave), si alguien obtiene los archivos de la base de datos, puede ejecutar la fuerza bruta para recuperar los datos en cuestión de semanas, si no de días. Esto es especialmente cierto en campos como el SSN, a menos que pasara tiempo y siempre requiera múltiples campos para una consulta (por ejemplo, SSN y DOB y las primeras tres letras del apellido, o tales combinaciones), y solo almacene esos como hash pero ninguno de ellos. estos por separado Esto aumentará la entropía y dificultará que alguien encuentre los valores reales donde obtendría su archivo DB.

Aparte de eso, uno tiene que resolver los problemas clave de la gestión del ciclo de vida.

EDITAR: En realidad es un problema común y, una vez que evalué los datos de encriptación, cuando escribí la respuesta inicial, no lo incluí aquí. Desde entonces, he actualizado mi respuesta para incluir eso, así como para aclarar los problemas de control de acceso, conexión segura y datos en reposo.

How to safely store sensitive data like a social security number?
...
Must be able to search (i.e. to look up an existing piece of data) but not view
...

El cifrado homomórfico permitirá clasificar y buscar datos cifrados. Tanto Microsoft como IBM tienen sistemas. Pero no los he visto en la producción general (todavía). Consulte, por ejemplo, Cifrado totalmente homomorfo eficiente de (LWE estándar) . También cumple con sus otros dos requisitos: reversibilidad y rendimiento.

Si no necesita la noción de seguridad PRP, use un cifrado de bloque. Es posible que incluso pueda utilizar un esquema de cifrado de preservación de formato (FPE). Consulte, por ejemplo, Se revisa el cifrado de preservación de pedidos - Análisis de seguridad mejorado y soluciones alternativas e incluso A Sinopsis de Format Preserving Encryption para algunas ideas.

No estoy seguro de qué hacer con "Otros sistemas deben poder recuperar el valor real" (aparte de la reversibilidad). ¿Puedes explicar el flujo de datos? Ingenuo, diría que realice la selección en los datos encriptados, descifre los datos, encripte los datos con la clave pública del sistema remoto y luego envíe los datos encriptados al sistema remoto.

  

Sin embargo, creo que un atacante podría usar el proceso de cifrado como un oráculo y recuperar los datos debido a su baja entropía.

Va a filtrar información si carece de la noción de seguridad de PRP; no debido a los datos de baja entropía como los SSN. Por ejemplo, RSA / OAEP puede enmascarar efectivamente un SSN. El malo no tiene más ventaja que adivinar (con un poco de renuncia).

También necesitará una estrategia para almacenar la clave privada. Tal vez un HSM o KMIP. Guttman tiene algunos pensamientos interesantes sobre HSM y otros dispositivos de almacenamiento (como el hardware que respalda el protocolo KMIP) en su libro Seguridad de Ingeniería .

No estoy seguro de lo que está tratando de hacer (¿es un servicio web? ¿Una aplicación móvil? ¿Una aplicación de escritorio?), pero dadas sus necesidades, podría considerar la posibilidad de desacoplar el sistema en dos componentes separados:

• Uno tendría un hash (seguro) del SSN que actúa como una base de datos de "solo lectura". Una búsqueda de un número de seguro social determinado haría un hash de la consulta y la compararía con la base de datos. Si el hash existe, devuelve una coincidencia. Obviamente, debe considerar las consultas que limitan la velocidad para evitar los ataques de fuerza bruta.

• Otro sistema (VM o físicamente separado, depende de usted) mantendría los datos "en claro" con un proceso similar a PCI (es decir, para almacenar datos financieros confidenciales). El acceso a este sistema sería más estricto y usted podría auditar más de cerca las autenticaciones exitosas (y fallidas).

La introducción de un nuevo número de seguro social en el último sistema provocaría una actualización de las entradas en el primero. De esta manera, podría replicar la base de datos de "solo lectura" mediante el equilibrio de carga o técnicas similares para garantizar el rendimiento.