Dados autenticados extras

O termo "dados autenticados extras" (AAD, na sigla em inglês) refere-se a qualquer string transmitida para o Cloud Key Management Service como parte de uma solicitação de criptografia ou descriptografia. Esses dados são usados como verificação de integridade e protegem os dados contra ataques de confused deputy. A string de AAD é codificada em base64 e não pode ultrapassar 64 KiB.

O Cloud KMS não fará a descriptografia do texto criptografado, 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.

  1. 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.

  2. 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.

  3. Alice envia uma solicitação para ver a entrada dela no diário. Como a entrada do diário criptografada está em um local reservado para ela, os dados são descriptografados pelo aplicativo e retornados como resposta à solicitação. Este é o comportamento esperado para o aplicativo.

  4. Mallory copia a entrada do diário de Alice do local reservado para Alice para o local reservado para Mallory.

  5. 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, a entrada é descriptografada pelo aplicativo e o texto simples é retornado como resposta à solicitação dela, que então vê a entrada do diário de Alice. Esse não é o comportamento esperado para o 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.

Uma razão para reproduzir os AAD é verificar qualquer dado não privado, ao mesmo tempo que evita o armazenamento dos AAD. Por exemplo, para garantir que o caminho e o nome de arquivo de um arquivo criptografado permaneçam inalterados, inclua-os como AAD no momento de criptografá-lo. 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. A cada solicitação para ver a entrada de um diário, o usuário é autenticado pelo aplicativo e recebe a entrada do diá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 endereço de e-mail dela é recuperado pelo aplicativo da coluna EMAIL para usar como AAD nessa solicitação. O endereço de e-mail de Mallory não terá êxito como AAD para descriptografia, e o aplicativo não permite que ela 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, use um caminho e nome de arquivo como AAD. Durante o processo de criptografia, suponha que o arquivo criptografado foi salvo em MY_PATH\MY_FILE1.enc, então "MY_PATH\MY_FILE1.enc" foi usado como AAD. Eles não estão armazenados. 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. Caso o arquivo criptografado não tenha sido movido para outro local, o "MY_PATH\MY_FILE1.enc" será usado como AAD durante a descriptografia. Esses são os mesmos AAD usados durante a criptografia, dando continuidade ao processo.

Por exemplo, caso o arquivo criptografado tenha sido movido para SOME_OTHER_PATH\MY_FILE1.enc, o "SOME_OTHER_PATH\MY_FILE1.enc" será usado como AAD para descriptografia. Esse valor de AAD não corresponde ao usado para criptografia, por isso a descriptografia falhará.

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…