Un secreto compartido por más de dos personas ya no es un secreto.
Encriptar los datos con una clave simétrica K , y luego encriptar K con la clave asimétrica (RSA) de cada destinatario, significa dar acceso al destinatario a todos los datos encriptados con K ; "todos los datos" incluyen lo que estará encriptado con K . Este método de cifrado es la situación normal para los correos electrónicos seguros (por ejemplo, con OpenPGP ), pero un punto crucial es que un correo electrónico es " one shot "y cada correo electrónico está encriptado con su propia, específica, aleatoria K .
Con una base de datos , las cosas son más complicadas, porque una base de datos es un conjunto de datos que evoluciona con el tiempo. Al dar K a cada usuario, potencialmente les permite leer los contenidos de la base de datos no solo ahora, sino también los contenidos futuros que se agregarán más adelante. Esto no es necesariamente un problema: mientras un usuario determinado tenga acceso a una base de datos, puede (al menos en teoría) volcar todos los datos en un archivo propio, y no hay manera de hacer que "olvide" los datos. . Sin embargo, a la larga, esto requiere actualizaciones clave.
Por ejemplo, supongamos que, en algún momento, desea otorgar acceso a la base de datos a un nuevo usuario. Esto es simple: simplemente encripte K con la clave RSA de ese nuevo usuario. La operación dual de eliminar a un usuario es más compleja. Como no puede obligar a los usuarios a olvidar datos, lo mejor que puede lograr es negar el acceso a datos nuevos (datos que se agregan después de la eliminación del usuario), y esto implica elegir un nuevo K ' distinto de K (y K ' no debe ser computable desde K , por lo que estamos hablando de seleccionar un nuevo elemento aleatorio K ' desde cero). Así que hay dos opciones:
-
Establezca el formato de su base de datos para que cada registro pueda etiquetarse con un identificador para la clave K que se usa para ese registro. Cada actualización clave implica crear un nuevo K con un nuevo identificador, y usar ese nuevo identificador en cada registro recién agregado o modificado. Se mantiene un repositorio para todo el K cifrado (indexado por identificador y por usuario). Tras el uso, cada usuario accede al repositorio utilizando la etiqueta en el registro de destino, para obtener la clave K que se utilizará para descifrar el registro.
-
Cuando se actualiza la clave, todos los datos de la base de datos se descifran con el antiguo K y se vuelven a cifrar con el nuevo K . Se mantiene un repositorio para la versión encriptada de cada K (indexado por usuario).
El segundo método hace que el almacenamiento sea más sencillo, y tiene el agradable beneficio de "expulsar" a los usuarios eliminados (en el modelo de ataque, asumimos que un usuario eliminado se encargó de copiar todos los datos que pudo, pero si no lo hizo , luego expulsarlo explícitamente cis agradable). Sin embargo, las actualizaciones clave con el segundo método pueden ser bastante caras, dependiendo de su frecuencia y el tamaño de la base de datos. El primer método es más genérico y permite un control de acceso detallado (por ejemplo, hacer que los datos sean accesibles para algunos subconjuntos de usuarios).
Microsoft SQL Server tiene muchas funciones de soporte (como el nivel de lenguaje SQL) para implementar tales cosas (sin embargo, tenga en cuenta que la documentación de Microsoft sobre elementos criptográficos tiene una tendencia molesta a redefinir la terminología, a veces de forma abrupta en medio de la propia documentación).