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.