Os dados autenticados extras (AAD, na sigla em inglês) são qualquer string que você passa para o Cloud Key Management Service como parte de uma solicitação de criptografia ou descriptografia. O AAD é usado como uma verificação de integridade e pode ajudar a proteger seus dados contra um ataque confused deputy (em inglês). A string AAD não pode ser maior que 64 KiB.
O Cloud KMS não fará a descriptografia do texto cifrado, a menos que o mesmo valor de AAD seja usado para criptografia e descriptografia.
Os AADs estão vinculados aos dados criptografados, porque não é possível decifrar o texto criptografado, a menos que você conheça os AAD, mas eles não são armazenados como parte do texto criptografado. Eles também não aumentam a capacidade criptográfica do texto criptografado. O que autentica uma solicitação de descriptografia é uma verificação extra do Cloud KMS.
No Cloud KMS, os AAD estão presentes sempre que é feita uma chamada para criptografia ou descriptografia. Se não for fornecido um valor para eles, será usada uma string vazia. Caso uma string vazia seja usada como AAD para a criptografia de texto simples, apenas uma string vazia permitirá a descriptografia do texto criptografado.
O AAD não é registrado pelo Cloud Audit Logging.
Quando usar os AAD
Um exemplo de uso dos AAD é quando seu aplicativo serve como um proxy de unir/desunir com uma única chave e um número ilimitado de clientes, cada um deles em limites de segurança distintos. Por exemplo, usuários que mantêm um diário privado com um aplicativo de diário. Quando um usuário precisa ver uma entrada de diário privada, o nome de usuário exclusivo é usado pelo aplicativo como AAD na solicitação de desunir (descriptografar), a fim de autenticar explicitamente o usuário. Nesse cenário, use uma única chave para atender a diversos (ilimitados) usuários. O principal benefício é que você não precisa manter o estado para usuários individuais.
Outro exemplo é se o aplicativo usar tokens de portadores, que contenham algumas informações privadas, como um endereço de e-mail. As entradas para o token do portador seriam os dados autenticados usados para um token do portador e o endereço de e-mail de texto simples. Essas entradas ficariam então criptografadas, para que o token do portador a ser trocado esteja na forma de dados autenticados criptografados adicionais (AEAD, na sigla em inglês).
Exemplo de ataque de confused deputy
Este exemplo mostra como um aplicativo pode ser induzido a descriptografar um texto criptografado para um usuário mal-intencionado. Neste exemplo, o aplicativo é o "confused deputy" porque não sabe que o invasor o induziu ao uso indevido da autoridade. O resultado é que o invasor consegue visualizar dados descriptografados originalmente criptografados para outro usuário. Observe que, neste ataque, o invasor não precisa conhecer a chave de criptografia porque depende do "confused deputy" para executar a descriptografia.
Os usuários mantêm um diário privado usando um aplicativo de diário. Cada entrada no diário é criptografada e só poderá ser descriptografada pelo usuário que a criou.
Alice cria uma entrada no diário. A entrada é criptografada pelo aplicativo e armazenada em um local reservado para as entradas de diário que pertencem a Alice.
Alice envia uma solicitação para ver a entrada dela no diário. Como a entrada de diário criptografado está em um local reservado para Alice, o aplicativo descriptografa os dados e os retorna como a resposta à solicitação de Alice. Esse é o comportamento esperado do aplicativo.
Mallory copia a entrada do diário de Alice do local reservado para Alice para o local reservado para Mallory.
Mallory envia uma solicitação para ver a cópia dela da entrada do diário de Alice. Como a cópia da entrada do diário de Alice está em um local reservado para Mallory, o aplicativo descriptografa a entrada do diário e retorna o texto simples como resposta à solicitação de Mallory. Em seguida, Mallory pode ver a entrada do diário de Alice, que não é o comportamento esperado do aplicativo.
Para se defender desse tipo de ataque, o aplicativo usa uma string não vazia como AAD para criptografia e descriptografia. Os AAD fornecem uma verificação adicional para solicitações de descriptografia. Quando Mallory enviar a solicitação de descriptografia para ver a cópia da entrada do diário de Alice, essa solicitação não terá êxito, a menos que ela também induza o aplicativo a usar os AAD corretos.
Como armazenar ou reproduzir os AAD
Antes de criptografar com os AAD, decida entre armazenar os AAD lado a lado com os dados criptografados ou reproduzir os AAD para a decodificação subsequente.
Uma razão para armazenar os AAD é usá-los diretamente quando for necessário descriptografar um texto criptografado. Por exemplo, uma linha de banco de dados contém o texto criptografado e os AAD usados quando o texto simples foi criptografado. Quando uma solicitação de descriptografia é recebida, os AAD e o texto criptografado do banco de dados são recuperados pelo aplicativo. Este então usa os AAD para o processo de descriptografia do texto criptografado.
Um motivo para reproduzir o AAD é verificar todos os dados não privados e, ao mesmo tempo, evitar o armazenamento do AAD. Por exemplo, se você quiser garantir que o caminho e o nome de arquivo de um arquivo criptografado não sejam alterados, inclua o caminho e o nome do arquivo como AAD ao criptografar o arquivo. Então, quando uma solicitação de descriptografia for enviada para o arquivo, reproduza os AAD, examinando o caminho e o nome de arquivo.
Como armazenar os AAD
Armazenar os AAD significa que eles estão salvos e prontamente disponíveis para uso futuro pelo seu aplicativo. Por exemplo, uma tabela de banco de dados contém uma coluna para texto criptografado e uma coluna para os AAD usados na criação do texto criptografado. Na hora de descriptografá-lo, os AAD são recuperados pelo aplicativo e utilizados para a descriptografia.
Considere um aplicativo de diário projetado para mostrar uma entrada de diário apenas para o usuário que a criou. Quando uma entrada de diário é criada, ela é criptografada e salva em um banco de dados, na coluna ENCRYPTED_DIARY_ENTRY. Para cada solicitação de visualização de uma entrada no diário, o aplicativo autentica o usuário e fornece a entrada do diário ao usuário.
Suponha que não foram usados AAD, exceto a string vazia padrão, e hipoteticamente Mallory conseguiu copiar os dados ENCRYPTED_DIARY_ENTRY de Alice para os dados ENCRYPTED_DIARY_ENTRY de Mallory. Quando Mallory envia uma solicitação de descriptografia para os dados ENCRYPTED_DIARY_ENTRY dela, copiados a partir dos dados de Alice, a descriptografia é executada pelo aplicativo sem que ele perceba que foi enganado.
Mallory consegue ver a entrada do diário de Alice como texto simples.
Agora, suponhamos que o endereço de e-mail do usuário seja usado como AAD quando uma entrada no diário for criptografada. Quando Alice cria uma entrada no diário, o endereço de e-mail dela não criptografado é armazenado pelo aplicativo na coluna EMAIL, lado a lado com os dados ENCRYPTED_DIARY_ENTRY. Suponhamos novamente que Mallory conseguiu copiar os dados ENCRYPTED_DIARY_ENTRY da Alice para os dados ENCRYPTED_DIARY_ENTRY de Mallory.
Quando Mallory envia uma solicitação de descriptografia, o aplicativo recupera o endereço de e-mail de Mallory da coluna EMAIL para usar como o AAD da solicitação de descriptografia.
O endereço de e-mail de Mallory não funcionará como o AAD para descriptografia. Portanto, o aplicativo não permite que Mallory veja a entrada do diário de Alice como texto simples.
Como reproduzir os AAD
Reproduzir os AAD significa que eles não estão armazenados em qualquer lugar, mas é possível reproduzi-los no momento da descriptografia.
Como exemplo, você pode usar um caminho de arquivo e um nome de arquivo como AAD. Durante o processo de criptografia, suponha que o arquivo criptografado foi salvo em MY_PATH\MY_FILE1.enc. Portanto, "MY_PATH\MY_FILE1.enc" foi usado como AAD. Este AAD não está armazenado. Quando uma solicitação de descriptografia é recebida, os ADD são reproduzidos pelo aplicativo, que examina o caminho e o nome do arquivo a ser descriptografado. Se o arquivo criptografado não tiver sido movido para outro local, "MY_PATH\MY_FILE1.enc" será usado como o AAD durante a descriptografia, que é o mesmo usado durante a criptografia, para que a descriptografia possa continuar.
Se o arquivo criptografado tiver sido movido, por exemplo, para SOME_OTHER_PATH\MY_FILE1.enc, "SOME_OTHER_PATH\MY_FILE1.enc" será usado como o AAD para descriptografia. Esse valor de AAD não corresponde ao usado para criptografia, por isso a descriptografia falhará.