Conceptos de encriptación AEAD

GoogleSQL para BigQuery es compatible con la encriptación AEAD.

Este tema explica los conceptos en los que se basa la encriptación AEAD en GoogleSQL. Para obtener una descripción de las diferentes funciones de encriptación AEAD compatibles con GoogleSQL, consulta las funciones de encriptación AEAD.

Propósito de la encriptación AEAD

BigQuery mantiene tus datos seguros mediante la encriptación en reposo. BigQuery también brinda asistencia para las claves de encriptación administradas por el cliente (CMEK), lo cual te permite encriptar tablas con claves de encriptación específicas. Sin embargo, en algunos casos, es posible que desees encriptar valores individuales en una tabla.

Por ejemplo, deseas mantener los datos de todos tus clientes propios en una tabla común y encriptar los datos de cada uno de tus clientes con una clave diferente. Tienes datos distribuidos en varias tablas que deseas poder "borrar de forma criptográfica". La eliminación criptográfica, o crypto-shedding, es el proceso de eliminar una clave de encriptación para hacer que cualquier dato encriptado con una clave sea ilegible.

Las funciones de cifrado AEAD te permiten crear conjuntos de claves que contienen claves para la encriptación y desencriptación, usar estas claves a fin de encriptar y desencriptar valores individuales en una tabla y rotar claves dentro de un conjunto de claves.

Conjuntos de claves

Un conjunto de claves es una colección de claves criptográficas, una de las cuales es la principal y el resto, si las hay, son claves criptográficas secundarias. Cada clave codifica un algoritmo de encriptación o desencriptación; si la clave está habilitada, inhabilitada o destruida; y, para las claves no destruidas, los bytes de clave en sí mismos. La clave criptográfica principal determina cómo se encripta el texto sin formato de entrada. La clave criptográfica principal nunca puede estar en estado inhabilitado. Las claves criptográficas secundarias solo se utilizan para desencriptación y pueden estar habilitadas o inhabilitadas. Se puede utilizar un conjunto de claves a fin de desencriptar cualquier dato que se utilizó para encriptar.

La representación de un conjunto de claves en GoogleSQL es como un búfer de protocolo google.crypto.tink.Keyset serializado en BYTES.

Ejemplo

El siguiente es un ejemplo de un conjunto de claves AEAD, representado como una string JSON, con tres claves.

{
  "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"
    }
  ]
}

En el ejemplo anterior, la clave criptográfica principal tiene un ID de 569259624 y es la primera clave que aparece en la string JSON. Hay dos claves criptográficas secundarias, una con ID 852264701 en estado inhabilitado y otra con ID 237910588 en estado destruido. Cuando una función de encriptación AEAD usa este conjunto de claves para la encriptación, el texto cifrado resultante codifica el ID de la clave criptográfica principal 569259624.

Cuando una función AEAD utiliza este conjunto de claves para la desencriptación, la función elige la clave apropiada para desencriptar en función del ID de la clave codificada en el texto cifrado; en el ejemplo anterior, intentar desencriptar con los ID de clave 852264701 o 237910588 produciría un error, porque el ID de clave 852264701 está inhabilitado y el ID 237910588 destruido. Restablecer el ID de la clave 852264701 a un estado habilitado lo volvería utilizable para la desencriptación.

El tipo de clave determina el modo de encriptación que se usará con esa clave.

Encriptar texto simple más de una vez con el mismo conjunto de claves generalmente mostrará diferentes valores de texto cifrado debido a diferentes vectores de inicialización (IV), que se eligen mediante el generador de números seudoaleatorio proporcionado por OpenSSL.

Nota: Si intentas pasar conjuntos de claves en texto simple como parte de las consultas, es posible que el texto de la consulta se registre, en conjunto con el conjunto de claves en texto simple. Puedes usar las consultas con parámetros de BigQuery para evitar registrar el conjunto de claves en texto simple.

Conjuntos de claves unidos

Si necesitas administrar un conjunto de claves de forma segura o transmitirlo a través de un canal no confiable, considera usar un conjunto de claves unido. Cuando unes un conjunto de claves sin procesar, el proceso se encripta mediante una clave de Cloud KMS.

Los conjuntos de claves unidos pueden encriptar y desencriptar datos sin exponer los datos del conjunto de claves. Si bien puede haber otras formas de restringir el acceso a los datos a nivel de campo, los conjuntos de claves unidos proporcionan un mecanismo más seguro para la administración de conjuntos de claves en comparación con los conjuntos de claves sin procesar.

Al igual que con los conjuntos de claves, los conjuntos de claves unidos pueden y deben rotar de forma periódica. Los conjuntos de claves unidos se usan en las funciones de encriptación de sobre AEAD.

Estas son algunas funciones con ejemplos de conjuntos de claves unidos:

• KEYS.NEW_WRAPPED_KEYSET: Crea un nuevo conjunto de claves unidos.
• KEYS.ROTATE_WRAPPED_KEYSET: Rota un conjunto de claves unido.
• KEYS.REWRAP_KEYSET: Vuelve a unir un conjunto de claves unido con datos nuevos.
• KEYS.KEYSET_CHAIN: Obtén un conjunto de claves Tink que está encriptado con una clave de Cloud KMS.

Estándar de encriptación avanzada (AES)

Las funciones de encriptación AEAD usan el Estándar de encriptación avanzada (AES ). La encriptación AES toma el texto simple como entrada, junto con una clave criptográfica, y muestra una secuencia encriptada de bytes como resultado. Esta secuencia de bytes se puede desencriptar posteriormente mediante la misma clave que se utilizó para encriptarla. AES utiliza un tamaño de bloque de 16 bytes, lo que significa que el texto simple se trata como una secuencia de bloques de 16 bytes. El texto cifrado contendrá un prefijo específico de Tink que indica la clave utilizada para realizar la encriptación. La encriptación AES admite varios modos de cifrado de bloque.

Modos de cifrado en bloque

Los dos modos de cifrado en bloque admitidos por las funciones de encriptación AEAD son GCM y CBC.

GCM

El modo Galois / Counter (GCM) es un modo para la encriptación AES. La función numera los bloques secuencialmente y combina este número de bloque con un vector de inicialización (IV). Un vector de inicialización es un valor aleatorio o seudoaleatorio que forma la base de la aleatorización de los datos de texto simple. Luego, la función encripta el número de bloque combinado y el IV mediante AES. A continuación, la función realiza una operación lógica de disyunción exclusiva (XOR, exclusive OR) a nivel de los bits en el resultado de la encriptación y el texto simple para producir el texto cifrado. El modo GCM utiliza una clave criptográfica de 128 o 256 bits de longitud.

Modo CBC

CBC "encadena" los bloques mediante el método XOR de cada bloque de texto simple con el bloque anterior de texto cifrado antes de encriptarlo. El modo CBC utiliza una clave criptográfica de 128, 192 o 256 bits de longitud. CBC utiliza un vector de inicialización de 16 bytes como bloque inicial y realiza una XOR en este bloque con el primer bloque de texto simple.

El modo CBC no es un esquema AEAD en el sentido criptográfico, ya que no proporciona integridad de datos. En otras palabras, las modificaciones maliciosas en los datos encriptados no se detectarán, lo que también compromete la confidencialidad de los datos. Por lo tanto, no se recomienda CBC, a menos que sea necesario por motivos de compatibilidad heredada.

Datos adicionales

Las funciones de encriptación AEAD son compatibles con el uso de un argumento additional_data, también conocido como datos asociados (AD) o datos autenticados adicionales. Un cifrado solo se puede desencriptar si los mismos datos adicionales que se usaron para la encriptación también se proporcionan a fin de desencriptarlos. Por lo tanto, los datos adicionales se pueden usar para vincular el cifrado a un contexto.

Por ejemplo, additional_data podría ser el resultado de CAST(customer_id AS STRING) cuando se encriptan datos para un cliente en particular. Esto garantiza que, cuando se desencripten los datos, antes se hayan encriptado con el customer_id esperado. Se requiere el mismo valor additional_data para la desencriptación. Para obtener más información, consulta RFC 5116.

Desencriptación

El resultado de AEAD.ENCRYPT es el texto cifrado BYTES. Las funciones AEAD.DECRYPT_STRING o AEAD.DECRYPT_BYTES pueden desencriptar este texto cifrado. Estas funciones deben usar un conjunto de claves que contenga la clave que se usó para la encriptación. Esa clave debe tener un estado 'ENABLED'. También deben usar los mismos additional_data que se usaron en la encriptación.

Cuando el conjunto de claves se utiliza para la desencriptación, se elige la clave apropiada para esto en función del ID de la clave codificada en el texto cifrado.

El resultado de AEAD.DECRYPT_STRING es una STRING de texto simple, mientras que el resultado de AEAD.DECRYPT_BYTES es BYTES de texto simple. AEAD.DECRYPT_STRING puede desencriptar el texto cifrado que codifica un valor de STRING; AEAD.DECRYPT_BYTES puede desencriptar un texto cifrado que codifica un valor de BYTES. Usar una de estas funciones con el fin desencriptar un texto cifrado que codifica un tipo de datos incorrecto, como usar AEAD.DECRYPT_STRING para desencriptar un texto cifrado que codifica un valor de BYTES, causa un comportamiento indefinido y puede provocar un error.

Rotación de claves

El propósito principal de rotar las claves de encriptación es reducir la cantidad de datos encriptados con cualquier clave en particular, de modo que una clave potencialmente comprometida le permitiría acceder a menos datos a un atacante.

La rotación del conjunto de claves implica lo siguiente:

1. Crear una nueva clave criptográfica primaria dentro de cada conjunto de claves
2. Desencriptar y volver a encriptar todos los datos encriptados

La función KEYS.ROTATE_KEYSET o KEYS.ROTATE_WRAPPED_KEYSET realiza el primer paso, ya que agrega una nueva clave criptográfica principal a un conjunto de claves y cambia la clave criptográfica primaria anterior por una secundaria.

Claves de Cloud KMS

GoogleSQL admite las funciones de encriptación AEAD con claves de Cloud KMS para proteger aún más los datos. Esta capa adicional de protección encripta tu clave de encriptación de datos (DEK) con una clave de encriptación de claves (KEK). La KEK es un conjunto de claves de encriptación simétrica que se almacena de forma segura en Cloud Key Management Service y se administra mediante permisos y roles de Cloud KMS.

En el momento de la ejecución de la consulta, usa la función KEYS.KEYSET_CHAIN para proporcionar la ruta de acceso del recurso de KMS de la KEK y el texto cifrado de la DEK unida. BigQuery llama a Cloud KMS para separar la DEK y, luego, usa esa clave a fin de desencriptar los datos en tu consulta. La versión separada de la DEK solo se almacena en la memoria durante la consulta y, luego, se destruye.

Para obtener más información, consulta Encriptación a nivel de columnas de SQL con las claves de Cloud KMS.