Consulta de base de datos cifrada

Question

Acabo de encontrar información sobre Stack Overflow y solo estoy comprobando si hay ideas para una restricción que tengo con algunos amigos en un proyecto, aunque esta es una pregunta más teórica a la que he estado tratando de encontrar una respuesta por algún tiempo.

No estoy muy dedicado a la criptografía, pero si no estoy lo suficientemente claro, intentaré editar / comentar para aclarar cualquier pregunta.

Tratando de ser breve, el entorno es algo así:

• Una aplicación donde el front-end como acceso para cifrar / descifrar claves y el back-end solo se utiliza para el almacenamiento y las consultas.

• Al tener una base de datos a la que no puede acceder por un par de campos, por ejemplo, digamos " dirección " que es text / varchar como de costumbre.

• No tiene acceso a la clave para descifrar la información y toda la información llega a la base de datos ya cifrada.

El problema principal es algo como esto: cómo hacer consultas de manera consistente en la base de datos, es imposible hacer cosas como " donde direcciones como '% F§YU / ´ ~ # JKSks23%' " (Si hay alguien con una respuesta para esto, siéntase libre de dispararle).

Pero ¿está bien hacer donde address = '±! NNsj3 ~ ^ º-:' ? ¿O también se comería completamente la base de datos?

Otra limitación que podría aplicarse es que el extremo frontal no tiene mucha capacidad de procesamiento disponible, por lo que la información de encriptación / descifrado ya comienza a llevarla a sus límites. (Decir esto solo para evitar respuestas como " Exportar una combinación de tablas al inicio y consultarlas allí ")

¿Podría alguien apuntarme en una dirección para seguir pensando en ello?

---

Bueno, gracias por las respuestas tan rápidas a las 4 AM, por primera vez, me siento realmente impresionado con esta comunidad. (O tal vez estoy solo por la zona horaria diferente)

Solo estoy suministrando información:

El problema principal es la concordancia parcial. Como requisito obligatorio en la mayoría de las bases de datos es permitir coincidencias parciales. La principal restricción es en realidad al propietario de la base de datos no se le permitiría buscar información en la base de datos . Durante los últimos 10 minutos he encontrado una posible solución que se extiende nuevamente a los posibles problemas de la base de datos, a los que agregaré aquí:

Posible solución para permitir la coincidencia semi parcial:

• La contraseña + un par de campos públicos del usuario son en realidad la clave para el cifrado. Para la autenticación, la idea es cifrar un valor estático y compararlo dentro de la base de datos.
• Creando un nuevo conjunto de tablas donde la información se almacena de forma analizada, lo que significa algo como: " 4th Street " se convertirían en 2 filas cifradas (una para '4ta' otra para 'Calle'). Esto ya permitiría una comparación semi-parcial, ya que una búsqueda ya se podría realizar en las tablas separadas.

Nueva pregunta:

• ¿Probablemente esto volverá a comerse el servidor de la base de datos, o alguien cree que es una solución viable para el problema de coincidencia parcial?

Post Scriptum: no he aceptado la respuesta de Cade Roux solo para permitir una mayor discusión y, especialmente, una posible respuesta a la nueva pregunta.

Answer 1

Puede hacerlo de la manera que lo describe: puede consultar el hash de forma efectiva, por ejemplo, pero no hay muchos sistemas con ese requisito, porque en ese punto los requisitos de seguridad están interfiriendo con otros requisitos para que el sistema sea utilizable, es decir, no parcial. coincide, ya que las normas de cifrado que fuera. Es el mismo problema con la compresión. Hace años, en un entorno muy pequeño, tuve que comprimir los datos antes de ponerlos en el formato de datos. Por supuesto, esos campos no se pueden buscar fácilmente.

En una aplicación más típica, en última instancia, las claves estarán disponibles para alguien de la cadena, probablemente el servidor web.

Para el tráfico de usuarios finales, SSL protege esa canalización. Algunos conmutadores de red pueden protegerlo entre el servidor web y la base de datos, y el almacenamiento de datos cifrados en la base de datos está bien, pero no va a consultar datos cifrados de esa manera.

Y una vez que se muestran los datos, están disponibles en la máquina, por lo que cualquier dispositivo informático de propósito general puede ser eludido en ese momento, y tiene defensas perimetrales fuera de su aplicación que realmente entran en juego.

Answer 2

¿por qué no cifrar el disco que contiene las tablas de la base de datos, cifrar las conexiones de la base de datos y dejar que la base de datos funcione normalmente?

[realmente no entiendo el contexto / las restricciones que requieren este nivel de paranoia]

EDITAR: " restricciones de ley " eh Espero que no estés involucrado en nada ilegal, odiaría ser un accesorio inadvertido ... ;-)

Si las restricciones legales (ejem, las restricciones legales) fuerzan esta solución, entonces eso es todo lo que hay que hacer: no hay coincidencias de LIKE y una respuesta lenta si las máquinas cliente no pueden manejarlo.

Answer 3

Hace unos meses encontré el mismo problema: toda la base de datos (excepto los índices) está encriptada y el problema en las coincidencias parciales surgió.

Busqué en Internet buscando una solución, pero parece que no hay mucho que hacer al respecto, sino una "solución".

La solución que finalmente adopté es:

1. Cree una tabla temporal con los datos del campo en el que se realiza, descifra la consulta y otro campo que es la clave principal de la tabla (obviamente, este campo no tiene que ser descifrado como está texto sin formato).

2. Vuelve a realizar la coincidencia parcial en esa tabla temporal y recupera los identificadores.

3. Consulte la tabla real para esos identificadores y devuelva el resultado.

4. Suelte la tabla temporal.

Soy consciente de que esto supone una sobrecarga no trivial, pero no he encontrado otra forma de realizar esta tarea cuando es obligatorio que la base de datos esté completamente encriptada.

Dependiendo de cada caso en particular, es posible que pueda filtrar el número de líneas que se insertan en la tabla temporal sin perder datos para el resultado (solo tenga en cuenta las filas que pertenecen al usuario que realiza la consulta, etc. ..).

Answer 4

Quieres usar hash md5. Básicamente, toma su cadena y la convierte en un hash que no se puede reproducir. Luego puedes usarlo para validar contra cosas más tarde. Por ejemplo:

$salt = "123-=asd";
$address = "3412 g ave";

$sql = "INSERT INTO addresses (address) VALUES ('" . md5($salt . $address) . "')";
mysql_query($sql);

Luego, para validar una dirección en el futuro:

$salt = "123-=asd";
$address = "3412 g ave";

$sql = "SELECT address FROM addresses WHERE address = '" . md5($salt . $address) . "'";
$res = mysql_query($sql);
if (mysql_fetch_row($res))
    // exists
else
    // does not

Ahora está encriptado en el lado de la base de datos para que nadie pueda averiguarlo, incluso si buscaron en su código fuente. Sin embargo, encontrar la sal les ayudará a descifrarla.

http://en.wikipedia.org/wiki/MD5

Answer 5

Si necesita almacenar datos confidenciales que desea consultar más tarde, le recomiendo que los almacene en texto sin formato, restringiendo el acceso a esas tablas tanto como pueda.

Si no puede hacer eso y no desea una sobrecarga en el extremo frontal, puede crear un componente en el extremo posterior, que se ejecuta en un servidor, que procesa los datos cifrados.

¿Haciendo consultas a datos encriptados? Si está utilizando un buen algoritmo de encriptación, no puedo imaginarme cómo hacerlo.