Conceitos de criptografia AEAD

O GoogleSQL para BigQuery é compatível com a criptografia AEAD.

Neste tópico, explicamos os conceitos que norteiam a criptografia AEAD no GoogleSQL. Para receber uma descrição das diferentes funções de criptografia AEAD compatíveis com o GoogleSQL, consulte Funções de criptografia AEAD.

Finalidade da criptografia AEAD

O BigQuery mantém seus dados seguros usando a criptografia em repouso. O BigQuery também oferece suporte a chaves de criptografia gerenciadas pelo cliente (CMEKs) que permitem criptografar tabelas usando chaves de criptografia específicas. Em alguns casos, no entanto, talvez você queira criptografar valores individuais em uma tabela.

Por exemplo, você quer manter os dados de todos os seus clientes em uma tabela comum e criptografar os dados de cada cliente usando uma chave diferente. Seus dados estão espalhados por várias tabelas que você quer poder "excluir criptograficamente". Exclusão ou trituração criptográfica é o processo de excluir uma chave de criptografia para tornar ilegíveis quaisquer dados criptografados por essa chave.

É possível criar conjuntos de chaves com chaves para criptografia e descriptografia por meio das funções de criptografia AEAD, usar essas chaves para criptografar e descriptografar valores individuais em uma tabela e girar as chaves dentro de um conjunto de chaves.

Conjunto de chaves

Um conjunto de chaves é uma coleção de chaves criptográficas. Uma delas é a chave criptográfica primária e o restante, se houver, são chaves criptográficas secundárias. Cada chave codifica um algoritmo para criptografia ou descriptografia, o estado da chave (ativada, desativada ou destruída) e, no caso de chaves não destruídas, os próprios bytes de chave. A chave criptográfica primária determina como criptografar o texto simples de entrada. A chave criptográfica primária nunca pode estar desativada. As chaves criptográficas secundárias servem apenas para descriptografia e podem estar no estado ativada ou desativada. Um conjunto de chaves pode ser usado para descriptografar todos os dados que foram usados para criptografar.

A representação de um conjunto de chaves no GoogleSQL é como um buffer de protocolo google.crypto.tink.Keyset serializado em BYTES.

Exemplo

Veja a seguir um exemplo de conjunto de chaves AEAD, representado como uma string JSON com três chaves.

{
  "primaryKeyId": 569259624,
  "key": [
    {
      "keyData": {
        "typeUrl": "type.googleapis.com/google.crypto.tink.AesGcmKey",
        "value": "GiDPhTp5gIhfnDb6jfKOT4SmNoriIJc7ah8uRvrCpdNihA==",
        "keyMaterialType": "SYMMETRIC"
      },
      "status": "ENABLED",
      "keyId": 569259624,
      "outputPrefixType": "TINK"
    },
    {
      "keyData": {
        "typeUrl": "type.googleapis.com/google.crypto.tink.AesGcmKey",
        "value": "GiBp6aU2cFbVfTh9dTQ1F0fqM+sGHXc56RDPryjAnzTe2A==",
        "keyMaterialType": "SYMMETRIC"
      },
      "status": "DISABLED",
      "keyId": 852264701,
      "outputPrefixType": "TINK"
    },
    {
      "status": "DESTROYED",
      "keyId": 237910588,
      "outputPrefixType": "TINK"
    }
  ]
}

No exemplo acima, a chave criptográfica primária, com o código 569259624, é a primeira que aparece na string JSON. Há duas chaves criptográficas secundárias: uma com o ID 852264701 no estado desativada e outra com o ID 237910588 no estado destruída. Quando uma função de criptografia AEAD usa esse conjunto de chaves para criptografia, o texto criptografado resultante codifica o ID da chave criptográfica primária, 569259624.

Quando uma função AEAD usa esse conjunto de chaves para descriptografia, ela escolhe a chave apropriada com base no código de chave codificado no texto criptografado. No exemplo acima, a tentativa de descriptografar usando o código de chave 852264701 ou 237910588 geraria um erro, porque o código de chave 852264701 está desativado e o código 237910588 está destruído. Restaurar o ID de chave 852264701 para o estado ativado o tornaria utilizável para descriptografia.

O tipo de chave determina o modo de criptografia a ser usado com essa chave.

Criptografar texto simples mais de uma vez usando o mesmo conjunto de chaves costuma retornar diferentes valores de texto criptografado devido a diferentes vetores de inicialização (IVs, na sigla em inglês), que são escolhidos por meio do gerador de número pseudo-aleatório fornecido pelo OpenSSL.

Observação: se você tentar passar conjuntos de chaves em texto simples como parte de consultas, o texto da consulta poderá ser registrado e, com eles, o conjunto de chaves em texto simples. Use as consultas parametrizadas do BigQuery para evitar o registro do conjunto de chaves em texto simples.

Conjunto de chaves encapsuladas

Se você precisar gerenciar com segurança um conjunto de chaves ou transmiti-lo em um canal não confiável, use um conjunto encapsulado. Quando você encapsula um conjunto de chaves bruto, esse processo criptografa o conjunto usando uma chave do Cloud KMS.

Os conjuntos de chaves encapsulados podem criptografar e descriptografar dados sem expor os dados deles. Embora possa haver outras maneiras de restringir o acesso a dados no nível do campo, os conjuntos de chaves encapsulados fornecem um mecanismo mais seguro para o gerenciamento de conjuntos em comparação com os brutos.

Assim como os conjuntos de chaves, os conjuntos de chaves encapsulados podem e devem ser rotacionados periodicamente. Os conjuntos de chaves encapsulados são usados nas funções de criptografia de envelope AEAD.

Veja algumas funções com exemplos de conjunto de chaves encapsulados:

• KEYS.NEW_WRAPPED_KEYSET: criar um novo conjunto de chaves encapsulado.
• KEYS.ROTATE_WRAPPED_KEYSET: rotacionar um conjunto de chaves encapsulado.
• KEYS.REWRAP_KEYSET: reencapsular um conjunto de chaves encapsuladas com novos dados.
• KEYS.KEYSET_CHAIN: receba um conjunto de chaves Tink criptografado com uma chave do Cloud KMS.

Padrão de criptografia avançada (AES)

As funções de criptografia AEAD usam o padrão de criptografia avançada (AES, na sigla em inglês). A criptografia AES usa texto simples como entrada junto com uma chave criptográfica e retorna uma sequência criptografada de bytes como saída. É possível descriptografar essa sequência de bytes posteriormente usando a mesma chave usada para criptografá-la. O AES usa um tamanho de bloco de 16 bytes, isto é, o texto simples é tratado como uma sequência de blocos de 16 bytes. O texto criptografado conterá um prefixo específico do Tink indicando a chave usada para realizar a criptografia. A criptografia AES é compatível com vários modos de criptografia em blocos.

Modos de criptografia em blocos

Dois modos de criptografia em blocos compatíveis com as funções de criptografia AEAD são GCM e CBC.

GCM

O Galois/Counter Mode (GCM) é um modo de criptografia AES. A função numera os blocos sequencialmente e, em seguida, combina o número do bloco com um vetor de inicialização (IV, na sigla em inglês). Um vetor de inicialização é um valor aleatório ou pseudo-aleatório que forma a base da ordem aleatória dos dados em texto simples. Em seguida, a função criptografa a combinação de número do bloco e IV usando AES. A função executa uma operação OR lógica exclusiva (XOR, na sigla em inglês) bit a bit no resultado da criptografia e o texto simples para produzir o texto criptografado. O modo GCM usa uma chave criptográfica de 128 ou 256 bits de comprimento.

Modo CBC

O CBC “encadeia” blocos fazendo XOR de cada bloco de texto simples com o bloco anterior de texto criptografado antes de criptografá-lo. O modo CBC usa uma chave criptográfica de 128, 192 ou 256 bits de comprimento. O CBC usa um vetor de inicialização de 16 bytes como bloco inicial e faz XOR desse bloco com o primeiro bloco de texto simples.

O modo CBC não é um esquema AEAD no sentido criptográfico porque não fornece integridade de dados. Em outras palavras, modificações mal-intencionadas nos dados criptografados não serão detectadas, o que também compromete a confidencialidade dos dados. Portanto, o CBC não é recomendado, a menos que seja necessário por motivos legados.

Dados extras

As funções de criptografia AEAD aceitam o uso de um argumento additional_data, também conhecido como dados associados (AD, na sigla em inglês) ou dados autenticados extras. Um texto criptografado só poderá ser descriptografado se houver os mesmos dados adicionais usados para descriptografia. Portanto, os dados adicionais podem ser usados para vincular o texto criptografado a um contexto.

Por exemplo, additional_data pode ser a saída de CAST(customer_id AS STRING) quando se criptografa dados para um cliente específico. Isso garante que, quando os dados forem descriptografados, terão sido criptografados previamente usando o customer_id esperado. O mesmo valor additional_data é necessário para descriptografia. Para mais informações, consulte a RFC 46485 (em inglês).

Descriptografia

A saída de AEAD.ENCRYPT é o texto criptografado BYTES. As funções AEAD.DECRYPT_STRING ou AEAD.DECRYPT_BYTES podem descriptografar este texto cifrado. Essas funções precisam usar um conjunto de chaves que tenha a chave usada para criptografia. Essa chave precisa estar no estado 'ENABLED'. Elas também precisam usar os mesmos additional_data usados na criptografia.

Quando o conjunto de chaves é usado para descriptografia, a chave apropriada é escolhida para descriptografia com base no código de chave codificado no texto criptografado.

A saída de AEAD.DECRYPT_STRING é uma STRING de texto simples, enquanto a saída de AEAD.DECRYPT_BYTES é de texto simples BYTES. AEAD.DECRYPT_STRING pode descriptografar o texto criptografado que codifica um valor de STRING. AEAD.DECRYPT_BYTES pode descriptografar o texto criptografado que codifica um valor de BYTES. Usar uma dessas funções para descriptografar um texto criptografado que codifica o tipo de dados incorreto, como usar AEAD.DECRYPT_STRING para descriptografar o texto criptografado que codifica um valor de BYTES, causa comportamento indefinido e pode gerar erro.

Troca de chaves

A principal finalidade do revezamento de chaves de criptografia é reduzir a quantidade de dados criptografados com qualquer chave específica, para que uma chave possivelmente comprometida limite o acesso de um invasor aos dados.

O revezamento do conjunto de chaves envolve:

1. Criação de uma nova chave criptográfica primária dentro de cada conjunto de chaves.
2. Descriptografia e nova criptografia de todos os dados criptografados.

A primeira etapa é executada pela função KEYS.ROTATE_KEYSET ou KEYS.ROTATE_WRAPPED_KEYSET com a adição de uma nova chave criptográfica primária a um conjunto de chaves e a transformação da antiga chave criptográfica primária em secundária.

Chaves do Cloud KMS

O GoogleSQL oferece suporte a funções de criptografia AEAD com chaves do Cloud KMS para proteger ainda mais seus dados. Essa camada extra de proteção criptografa sua chave de criptografia de dados (DEK, na sigla em inglês) com uma chave de criptografia de chaves (KEK, na sigla em inglês). A KEK é um conjunto de chaves de criptografia simétrica armazenada com segurança no Cloud Key Management Service e gerenciada usando permissões e papéis do Cloud KMS.

No tempo de execução da consulta, use a função KEYS.KEYSET_CHAIN para fornecer o caminho do recurso KMS da KEK e o texto criptografado da DEK encapsulada. O BigQuery chama o Cloud KMS para desencapsular a DEK e, em seguida, usa essa chave para descriptografar os dados na consulta. A versão desencapsulada da DEK é armazenada apenas na memória durante a consulta e, em seguida, destruída.

Para mais informações, consulte Criptografia na coluna SQL com chaves do Cloud KMS.