Administración de claves AES / Cómo intercambiar claves de cifrado

Las claves de cifrado pueden tener un criptoperiodo después del cual esas claves no deben seguir utilizándose para el cifrado. Esto puede deberse a políticas de seguridad, debido a una persona que conoce un componente clave que abandona el negocio, debido a la sospecha de un compromiso de clave de cifrado, etc.

A menudo, una empresa utilizará una clave de cifrado (llamemos a esta clave A) para el cifrado durante X período de tiempo. Después de ese período de tiempo, se generará una nueva clave de cifrado (llamemos a esta clave B) y se utilizará para el cifrado. Los datos cifrados se almacenarán con una referencia a la clave con la que se cifró para que la aplicación sepa qué clave utilizar para el descifrado. Al utilizar nuestro nombre anterior, la clave A podría considerarse inválida para el cifrado de nuevos datos, pero podría usarse para el descifrado de datos cifrados utilizando esa clave. KeyB actualmente puede ser válido para cifrar y descifrar datos.

Como sus datos probablemente se almacenan de acuerdo con los períodos de retención de datos definidos, una vez que se eliminan los datos heredados, también se pueden eliminar las claves más antiguas, ya que ya no son necesarias para el descifrado de datos.

Según su publicación, descifrar y volver a cifrar grandes volúmenes de datos puede llevar mucho tiempo y ser un proceso costoso.

¿Por qué no realiza el cifrado de descifrado a petición?

No estoy seguro si eso funciona para tu caso, pero aquí están mis pensamientos. Los datos vienen originalmente a su aplicación web como datos simples, ¿no? Luego usted encripta los datos y los almacena. Asumamos el siguiente escenario

1. Hoy subí el archivo "My_Data1.txt" a su servidor, usted lo cifra utilizando una clave AES llamada "X1"
2. "X1" caducará después de 90 días a partir de hoy, y se establecerá dentro de 80 días como el tiempo de reciclaje de "X1"
3. Después de 20 días, cargué un nuevo archivo "My_Data2.txt", de nuevo lo cifras usando "X1"
4. Después de 80 días quería acceder a "My_Data1.txt", lo descifras usando "X1"
5. Hice algunos cambios en "My_Data1.txt" cuando solicito almacenar el archivo nuevamente en su servidor, usted cifrará "My_Data1.txt" usando una nueva clave "X2"
6. "X2" caducará 90 después de que "X1" caduque.
7. Cualquier acceso de usuario a los datos encriptados después del punto de reciclaje de la clave de encriptación actual desencadena su descifrado con la clave actual y encripta con la nueva clave.

Esto evitará la necesidad de ejecutar un enorme proceso de cifrado / descifrado para todos los datos almacenados al mismo tiempo.

otras opciones

1. Dedique otro servidor para realizar el trabajo de cifrado / descifrado, o
2. Realice el cifrado en el lado del cliente (requiere un diseño con mucha precaución)

Finalmente , ¿cuál es el requisito de seguridad detrás de esta solicitud? Es posible que podamos sugerir una mejor solución para evitar el descifrado / cifrado intensivo

Pasarías por la tarea relativamente ardua de descifrar y volver a cifrar los datos por una sola razón: crees que la clave de cifrado se ha comprometido, pero los datos no, o lo contrario.

Si tanto los datos como la clave estaban comprometidos. estas tostada Ninguna cantidad de cambio de clave te salvará.

Si una de las claves o los datos estuvieran comprometidos, podría tener sentido cambiar la clave y volver a cifrar los datos en caso de que un atacante pudiera obtener la otra mitad del rompecabezas de alguna manera. Sin embargo, esto huele a "cambiar su contraseña cada 30 días, solo en el caso.

Mencionó un riesgo de descifrado y recifrado, es decir, una falla en la mitad del proceso. Usted mitiga ese riesgo al cifrar los nuevos medios. Pero, por supuesto, los medios antiguos permanecen, encriptados con la clave antigua. Debes destruir los datos antiguos y la clave antigua con ácido, fuego e imanes fuertes cuando el proceso se complete, o de lo contrario no habrás mitigado ningún riesgo. Si este es un sistema en línea, habrá un tiempo de inactividad o un período de solo lectura durante el proceso de recifrado. Puede haber otros riesgos.

Si de alguna manera gira las claves criptográficas para que en cualquier momento alguna parte de los datos se cifre con una clave más antigua y otras con una clave más nueva, como se sugiere en otra respuesta, entonces algunos de los datos se exponen en el caso de compromiso.

Como Gilles ya ha escrito, esto huele a teatro de seguridad. Quien sea responsable de la política debe describir los riesgos que se mitigarán a través de su implementación. Luego puede examinar los costos y los nuevos riesgos introducidos y tomar una decisión informada.