Los datos autenticados adicionales (AAD) son cualquier string que pasas a Cloud Key Management Service como parte de una solicitud de encriptación o desencriptación. AAD se usa como una comprobación de integridad y pueden ayudar a proteger los datos de un ataque de engaño de aplicación delegada. La string de AAD no debe superar los 64 KiB.
Cloud KMS no desencriptará el cifrado, a menos que el mismo valor de AAD se use en la encriptación y la desencriptación.
Los AAD están vinculados a los datos encriptados, ya que no puedes desencriptar el cifrado a menos que conozcas los AAD, pero no se almacenan como parte del cifrado. Estos datos tampoco incrementan la fortaleza criptográfica del cifrado. En su lugar, son una comprobación adicional de Cloud KMS para autenticar una solicitud de desencriptación.
En Cloud KMS, los AAD siempre están presentes cuando haces una llamada para encriptar o desencriptar, es decir, si no proporcionas un valor para los AAD, se deberá usar una string vacía. Si se usa una string vacía como los AAD para realizar la encriptación del texto sin formato, quiere decir que solo una string vacía permitirá desencriptar el cifrado.
Los registros de auditoría de Cloud no registran los AAD.
Cuándo se deben utilizar los AAD
Un ejemplo sobre cómo usar los AAD es cuando tu aplicación sirve como un proxy de unión/separación con una clave única y un número de clientes sin vínculo, con cada cliente en diferentes límites de seguridad. Por ejemplo, la aplicación puede ser una aplicación de diario que le permite a los usuarios mantener un diario privado. Cuando un usuario necesita ver una entrada del diario privado, la aplicación puede usar el nombre único de usuario como el valor AAD en la solicitud de separación (desencriptación) para autenticar al usuario de forma explícita. En esta situación, puedes usar una clave única que sirva para varios usuarios (sin vínculo). Uno de los principales beneficios es que no es necesario que mantengas un estado para los usuarios individuales.
Otro ejemplo es si tu aplicación necesita usar tokens del portador que contienen información privada, como una dirección de correo electrónico. Las entradas al token del portador serían los datos autenticados usados en un token del portador, además de la dirección de correo electrónico sin formato. Estas entradas se encriptarán posteriormente, de manera que el token del portador que se intercambia se encuentra en la forma de datos autenticados encriptados adicionales (AEAD).
Ejemplo de ataque de engaño de aplicación delegada
En este ejemplo, se muestra cómo se puede engañar a una aplicación para que desencripte cifrado en nombre de un usuario malicioso. La aplicación es el delegado del engaño en este ejemplo, ya que la aplicación no tiene conocimiento de que el atacante engañó a la aplicación para que usara su autoridad de forma inadecuada. El resultado es que el atacante puede ver los datos desencriptados que originalmente se encriptaron para otro usuario. Ten en cuenta que en este ataque, el atacante no necesita saber la clave de encriptación, porque depende de la aplicación delegada para desencriptar los datos.
Una aplicación de diario permite a los usuarios mantener un diario privado. Cada entrada en el diario se encripta y se espera que se desencripte solo por el usuario que creó tal entrada.
Alice crea una entrada en el diario. La aplicación encripta la entrada y la almacena en una ubicación reservada para las entradas de diario que pertenecen a Alice.
Alice envía una solicitud para ver su entrada de diario. Debido a que la entrada del diario encriptado se encuentra en una ubicación reservada para Alice, la aplicación desencripta los datos y los muestra como respuesta a la solicitud de Alice. Este es el comportamiento deseado de la aplicación.
Mallory copia la entrada de diario de Alice desde la ubicación reservada para Alice a la reservada para ella.
Mallory envía una solicitud para ver la copia de Mallory de la entrada de diario de Alice. Debido a que la copia de la entrada de diario de Alice se encuentra en la ubicación reservada para Mallory, la aplicación desencripta la entrada de diario y muestra el texto sin formato como respuesta a la solicitud de Mallory. Así, Mallory puede ver la entrada de diario de Alice, que no es el comportamiento deseado de la aplicación.
A fin de protegerse de este tipo de ataque, la aplicación puede usar una string que no esté vacía como el valor AAD para la encriptación y desencriptación. Los AAD proporcionan un comprobación adicional para las solicitudes de desencriptación. Cuando Mallory envíe la solicitud de desencriptación para ver su copia de la entrada de diario de Alice, la solicitud no tendrá éxito, a menos que Mallory también pueda engañar a la aplicación para que use el valor AAD correcto.
Almacena o reproduce los AAD
Antes de realizar la encriptación con AAD, debes decidir si almacenarás los AAD junto con los datos encriptados, o los reproducirás para su desencriptación posterior.
Un motivo para almacenar los AAD es que hacerlo facilita su uso cuando necesitas desencriptar cifrado. Por ejemplo, una fila de una base de datos podría contener el cifrado y los AAD que se usaron cuando se encriptó el texto sin formato. Cuando se recibe una solicitud de desencriptación, la aplicación puede recuperar los AAD y el cifrado de la base de datos. Así, la aplicación puede usar los AAD en el proceso de desencriptación del cifrado.
Un motivo para reproducir los AAD es que se verifican todos los datos no privados y, al mismo tiempo, se evita el almacenamiento de los AAD. Por ejemplo, si deseas asegurarte de que la ruta y el nombre de un archivo encriptado no hayan cambiado, puedes incluir la ruta de acceso y el nombre de archivo como AAD cuando encriptes el archivo. Así, cuando se envía una solicitud de desencriptación para el archivo, puedes reproducir los AAD con solo examinar la ruta y el nombre de archivo.
Almacena los AAD
Almacenar los AAD se refiere a que estos se guardan y, posteriormente, tu aplicación dispone de ellos fácilmente para usarlos en el futuro. Por ejemplo, una tabla de una base de datos podría contener una columna para el cifrado y una columna para los AAD que se usaron cuando se creó el cifrado. Cuando llegue el momento de desencriptar el cifrado, la aplicación recupera los AAD y los usa para la desencriptación.
Considera una aplicación de diario diseñada para mostrar una entrada de diario solo al usuario que la creó. Cuando se crea una entrada en el diario, esta se encripta y, luego, se guarda en una base de datos, en la columna ENCRYPTED_DIARY_ENTRY. Para cada solicitud a fin de ver una entrada de diario, la aplicación autentica al usuario y, luego, le proporciona la entrada.
Supongamos que no se usaron AAD (distintos de la string vacía predeterminada) y que, de manera hipotética, Mallory pudo copiar los datos de ENCRYPTED_DIARY_ENTRY de Alice en sus datos de ENCRYPTED_DIARY_ENTRY. Cuando Mallory envía una solicitud de desencriptación a sus datos ENCRYPTED_DIARY_ENTRY (que se copiaron de los datos de Alice), la aplicación lleva a cabo la desencriptación sin darse cuenta de que se la engañó.
Así, Mallory puede ver la entrada de diario de Alice como texto sin formato.
Ahora, supongamos que la dirección de correo electrónico del usuario se usa como AAD cuando se encripta una entrada de diario. Cuando Alice crea una entrada de diario, la aplicación almacena su dirección de correo electrónico en la columna EMAIL, junto con los datos de ENCRYPTED_DIARY_ENTRY. Supongamos de nuevo que Mallory pudo copiar los datos de ENCRYPTED_DIARY_ENTRY de Alice en sus datos de ENCRYPTED_DIARY_ENTRY.
Cuando Mallory envía una solicitud de desencriptación, la aplicación recupera la dirección de correo electrónico de Mallory desde la columna EMAIL para usarla como el valor AAD en esa solicitud de desencriptación.
La dirección de correo electrónico de Mallory no tendrá éxito como AAD para la desencriptación, por lo que la aplicación no permitirá que Mallory vea la entrada de diario de Alice como texto sin formato.
Reproduce los AAD
Reproducir los AAD se refiere a que no se almacenan en ninguna parte, pero puedes reproducirlos cuando llega el momento de la desencriptación.
Por ejemplo, puedes usar una ruta de acceso de archivo y un nombre de archivo como AAD. Durante el proceso de encriptación, supongamos que el archivo encriptado se guardó en MY_PATH\MY_FILE1.enc, por lo que "MY_PATH\MY_FILE1.enc" se usó como AAD. No se almacena este AAD. Cuando se recibe una solicitud de desencriptación, la aplicación reproduce los AAD mediante la revisión de la ruta y el nombre del archivo que se desencriptará. Si el archivo encriptado no se ha movido a otra ubicación, "MY_PATH\MY_FILE1.enc" se usará como AAD durante la desencriptación, que es el mismo que el AAD que se usa durante la encriptación, para que la desencriptación pueda continuar.
Si se movió el archivo encriptado, por ejemplo, a SOME_OTHER_PATH\MY_FILE1.enc, se usará "SOME_OTHER_PATH\MY_FILE1.enc" como AAD para la desencriptación. Este valor de AAD no coincide con el valor que se usó en la encriptación, de manera que la desencriptación fallará.