Os dados autenticados adicionais (AAD) são qualquer string que transmite ao Cloud Key Management Service como parte de um pedido de encriptação ou desencriptação. O AAD é usado como uma verificação de integridade e pode ajudar a proteger os seus dados de um ataque de representante confuso. A string AAD não pode ter mais de 64 KiB.
O Cloud KMS não desencripta o texto encriptado, a menos que o mesmo valor de AAD seja usado para a encriptação e a desencriptação.
O AAD está associado aos dados encriptados, porque não pode desencriptar o texto cifrado, a menos que conheça o AAD, mas não é armazenado como parte do texto cifrado. O AAD também não aumenta a força criptográfica do texto cifrado. Em vez disso, é uma verificação adicional do Cloud KMS para autenticar um pedido de desencriptação.
No Cloud KMS, o AAD está sempre presente quando faz uma chamada para encriptar ou desencriptar. Se não fornecer um valor para o AAD, é usada uma string vazia. Se for usada uma string vazia como o AAD para a encriptação de texto simples, apenas uma string vazia permite a desencriptação do texto cifrado.
O AAD não é registado pelos registos de auditoria do Cloud.
Quando usar o AAD
Um exemplo de utilização do AAD é quando a sua aplicação funciona como um proxy de união/separação com uma única chave e um número ilimitado de clientes, com cada cliente em limites de segurança distintos. Por exemplo, a aplicação pode ser uma aplicação de diário que permite aos utilizadores manter um diário privado. Quando um utilizador precisa de ver uma entrada de diário privada, a aplicação pode usar o nome de utilizador único como o AAD no pedido de anulação da união (desencriptação) para autenticar explicitamente o utilizador. Neste cenário, pode usar uma única chave para publicar anúncios para vários utilizadores (sem limite). Uma das principais vantagens é que não tem de manter o estado para utilizadores individuais.
Outro exemplo é se a sua aplicação precisar de usar tokens de portador que contenham algumas informações privadas, como um endereço de email. As entradas para o token de portador seriam os dados autenticados usados para um token de portador, mais o endereço de email em texto simples. Estes dados seriam encriptados para que o token de autorização trocado fosse na forma de dados autenticados encriptados adicionais (AEAD).
Exemplo de ataque de delegado confuso
Este exemplo mostra como uma aplicação pode ser enganada para desencriptar texto cifrado em nome de um utilizador malicioso. A aplicação é o delegado confuso neste exemplo porque não sabe que o atacante enganou a aplicação para usar indevidamente a sua autoridade. O resultado é que o atacante consegue ver dados desencriptados que foram originalmente encriptados para outro utilizador. Tenha em atenção que, neste ataque, o atacante não precisa de conhecer a chave de encriptação, porque depende do delegado confuso para realizar a desencriptação.
Uma aplicação de diário permite que os utilizadores mantenham um diário privado. Cada entrada do diário é encriptada e destina-se a ser desencriptada apenas pelo utilizador que criou a entrada do diário.
A Alice cria uma entrada de diário. A aplicação encripta a entrada do diário e, em seguida, armazena a entrada do diário encriptada numa localização reservada para entradas do diário que pertencem à Alice.
A Alice envia um pedido para ver a sua entrada no diário. Uma vez que a entrada do diário encriptada se encontra numa localização reservada para a Alice, a aplicação desencripta os dados e devolve-os como resposta ao pedido da Alice. Este é o comportamento pretendido da aplicação.
A Mallory copia a entrada do diário da Alice da localização reservada para a Alice para a localização reservada para a Mallory.
A Mallory envia um pedido para ver a cópia da entrada do diário da Alice da Mallory. Uma vez que a cópia da entrada do diário de Alice está numa localização reservada para Mallory, a aplicação descifra a entrada do diário e devolve o texto simples como resposta ao pedido de Mallory. Em seguida, Mallory pode ver a entrada do diário de Alice, o que não é o comportamento pretendido da aplicação.
Para se defender contra este tipo de ataque, a aplicação pode usar uma string não vazia como AAD para encriptação e desencriptação. O AAD fornece uma verificação adicional para pedidos de desencriptação. Quando a Ana envia o pedido de desencriptação para ver a cópia da Ana da entrada do diário da Alice, o pedido da Ana não é bem-sucedido, a menos que a Ana também consiga enganar a aplicação para usar o AAD correto.
Armazenar ou reproduzir AAD
Antes de encriptar com o AAD, decida se vai armazenar o AAD lado a lado com os dados encriptados ou reproduzir o AAD para desencriptação subsequente.
Um motivo para armazenar o AAD é facilitar a utilização do AAD quando precisar de desencriptar o texto cifrado. Por exemplo, uma linha da base de dados pode conter o texto cifrado e os DAA usados quando o texto simples foi encriptado. Quando é recebido um pedido de desencriptação, a aplicação pode obter o AAD e o texto cifrado da base de dados. Em seguida, a aplicação pode usar o AAD para o processo de desencriptação do texto cifrado.
Um motivo para reproduzir o AAD é validar quaisquer dados não privados, evitando também o armazenamento do AAD. Por exemplo, se quiser garantir que o caminho do ficheiro e o nome do ficheiro de um ficheiro encriptado não foram alterados, pode incluir o caminho do ficheiro e o nome do ficheiro como DAA quando encriptar o ficheiro. Em seguida, quando é enviado um pedido de desencriptação para o ficheiro, pode reproduzir os DAA examinando o caminho e o nome do ficheiro.
Armazenar AAD
O armazenamento de AAD significa que o AAD é guardado e, em seguida, fica facilmente disponível para a sua aplicação para utilização futura. Por exemplo, uma tabela de base de dados pode conter uma coluna para o texto cifrado e uma coluna para os DAA usados quando o texto cifrado foi criado. Quando chega a altura de desencriptar o texto cifrado, a aplicação obtém os DAA e usa-os para a desencriptação.
Considere uma aplicação de diário concebida para mostrar uma entrada do diário apenas ao utilizador que a criou. Quando é criada uma entrada de diário, esta é encriptada e, em seguida, guardada numa base de dados, na coluna ENCRYPTED_DIARY_ENTRY. Para cada pedido de visualização de uma entrada de diário, a aplicação autentica o utilizador e, em seguida, fornece a entrada de diário ao utilizador.
Suponhamos que não é usado nenhum DAA (além da string vazia predefinida) e, hipoteticamente, Mallory conseguiu copiar os dados ENCRYPTED_DIARY_ENTRY de Alice para os dados ENCRYPTED_DIARY_ENTRY de Mallory. Quando a Mallory envia um pedido de desencriptação dos dados de Mallory (que foram copiados dos dados de Alice), a aplicação executa a desencriptação sem se aperceber de que foi enganada.ENCRYPTED_DIARY_ENTRY
Mallory consegue ver a entrada do diário de Alice como texto simples.
Suponhamos agora que o endereço de email do utilizador é usado como o AAD quando uma entrada de diário é encriptada. Quando a Alice cria uma entrada no diário, a aplicação armazena o respetivo endereço de email não encriptado na coluna EMAIL, lado a lado com os dados ENCRYPTED_DIARY_ENTRY. Suponhamos novamente que a Joana conseguiu copiar os dados de ENCRYPTED_DIARY_ENTRY da Ana para os dados de ENCRYPTED_DIARY_ENTRY da Joana.
Quando a Mallory envia um pedido de desencriptação, a aplicação obtém o endereço de email da Mallory na coluna EMAIL para usar como AAD para o pedido de desencriptação.
O endereço de email da Joana não vai funcionar como AAD para desencriptação, pelo que a aplicação não permite que a Joana veja a entrada do diário da Ana como texto simples.
Reproduzir AAD
A reprodução de AAD significa que não é armazenado em nenhum local, mas pode reproduzir quando for altura da desencriptação.
Por exemplo, pode usar um caminho de ficheiro e um nome de ficheiro como AAD. Durante o processo de encriptação, suponhamos que o ficheiro encriptado foi guardado em MY_PATH\MY_FILE1.enc, pelo que "MY_PATH\MY_FILE1.enc" foi usado como AAD. Este AAD não é armazenado. Quando é recebido um pedido de desencriptação, a aplicação reproduz os DAA ao examinar o caminho e o nome do ficheiro a desencriptar. Se o ficheiro encriptado não tiver sido movido para outra localização, "MY_PATH\MY_FILE1.enc" é usado como o AAD durante a desencriptação, que é o mesmo que o AAD usado durante a encriptação, pelo que a desencriptação pode prosseguir.
Se o ficheiro encriptado tiver sido movido, por exemplo, para SOME_OTHER_PATH\MY_FILE1.enc, o "SOME_OTHER_PATH\MY_FILE1.enc" é usado como o AAD para desencriptação. Este valor de AAD não corresponde ao valor de AAD usado
para a encriptação, pelo que a desencriptação vai falhar.