Concepts du chiffrement AEAD

GoogleSQL pour BigQuery est compatible avec le chiffrement AEAD.

Cet article explique les concepts du chiffrement AEAD en langage GoogleSQL. Pour obtenir une description des différentes fonctions de chiffrement AEAD compatibles avec le langage GoogleSQL, consultez la page Fonctions de chiffrement AEAD.

Objectif du chiffrement AEAD

BigQuery protège vos données en utilisant le chiffrement au repos. BigQuery accepte également les clés de chiffrement gérées par le client (CMEK), ce qui vous permet de chiffrer des tables à l'aide de clés de chiffrement spécifiques. Toutefois, dans certains cas, le chiffrement de valeurs individuelles dans un tableau est préférable.

Par exemple, vous souhaitez conserver les données de tous vos clients dans une même table et chiffrer chacune des données de vos clients à l'aide d'une clé différente. Vous disposez de données réparties sur plusieurs tables que vous souhaitez pouvoir "crypto-supprimer". La crypto-suppression, ou "crypto-shredding" en anglais, consiste à supprimer une clé de chiffrement afin de rendre illisibles les données chiffrées à l'aide de cette clé.

Les fonctions de chiffrement AEAD vous permettent de créer des collections de clés de chiffrement et de déchiffrement, d'utiliser ces clés pour chiffrer et déchiffrer les valeurs individuelles d'une table, et d'alterner les clés d'une collection de clés.

Collections de clés

Une collection de clés est un ensemble de clés cryptographiques, dont l'une est la clé cryptographique principale et les autres, le cas échéant, sont des clés cryptographiques secondaires. Chaque clé encode un algorithme de chiffrement ou de déchiffrement, l'état de la clé (activée, désactivée ou détruite) et, dans le cas des clés non détruites, les octets de clé eux-mêmes. La clé cryptographique principale détermine comment chiffrer le texte brut d'entrée. Elle ne peut jamais être désactivée. Les clés cryptographiques secondaires ne servent qu'au déchiffrement, et peuvent être activées ou désactivées. Une collection de clés peut être utilisée pour déchiffrer toutes les données qu'elle a chiffrées.

Une collection de clés en langage GoogleSQL se présente sous la forme d'un tampon de protocole google.crypto.tink.Keyset sérialisé en BYTES.

Exemple

Voici un exemple de collection de clés AEAD comprenant trois clés et représentée par une chaîne JSON.

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

Dans l'exemple ci-dessus, la clé cryptographique principale est la première clé répertoriée dans la chaîne JSON. Son ID est 569259624. Il existe deux clés cryptographiques secondaires : l'une est activée et présente l'ID 852264701, tandis que l'autre est détruite et présente l'ID 237910588. Lorsqu'une fonction de chiffrement AEAD utilise cette collection de clés pour le chiffrement, le texte chiffré obtenu encode l'ID de la clé cryptographique principale (569259624).

Lorsqu'une fonction AEAD utilise cette collection de clés pour le déchiffrement, elle choisit la clé appropriée pour le déchiffrement en fonction de l'ID de clé encodé dans le texte chiffré. Dans l'exemple ci-dessus, une tentative de déchiffrement à l'aide des ID de clé 852264701 ou 237910588 entraînerait une erreur, car l'ID 852264701 est désactivé et l'ID 237910588 est détruit. Si l'ID de clé 852264701 était réactivé, il pourrait être déchiffré.

Le type de clé détermine le mode de chiffrement à utiliser avec cette clé.

Le chiffrement répété de texte brut à l'aide de la même collection de clés renvoie généralement différentes valeurs chiffrées en raison de différents vecteurs d'initialisation, sélectionnés à l'aide du générateur de nombres pseudo-aléatoires fourni par OpenSSL.

Remarque :Si vous essayez de transmettre des collections de clés en texte brut dans le cadre de requêtes, le texte de la requête peut être journalisé et, avec eux, la collection de clés en texte brut. Vous pouvez utiliser les requêtes paramétrées de BigQuery pour éviter de journaliser la collection de clés en texte brut.

Collections de clés encapsulées

Si vous devez gérer une collection de clés de manière sécurisée ou la transmettre via un canal non approuvé, envisagez d'utiliser une collection de clés encapsulée. Lorsque vous encapsulez une collection de clés brute, ce processus chiffre la collection de clés brute à l'aide d'une clé Cloud KMS.

Les collections de clés encapsulées peuvent chiffrer et déchiffrer des données sans les exposer. Bien qu'il existe d'autres moyens de limiter l'accès aux données au niveau des champs, les collections de clés encapsulées fournissent un mécanisme plus sécurisé de gestion des collections de clés que les collections de clés brutes.

Comme pour les collections de clés, les collections de clés encapsulées peuvent et doivent subir une rotation périodique. Les collections de clés encapsulées sont utilisées dans les fonctions de chiffrement encapsulé AEAD.

Voici quelques fonctions avec des exemples de collections de clés encapsulées:

• KEYS.NEW_WRAPPED_KEYSET : crée une collection de clés encapsulée.
• KEYS.ROTATE_WRAPPED_KEYSET : effectue une rotation de collection de clés encapsulée.
• KEYS.REWRAP_KEYSET : encapsule une collection de clés encapsulée avec de nouvelles données.
• KEYS.KEYSET_CHAIN : récupère une collection de clés Tink chiffrée avec une clé Cloud KMS.

Norme AES (Advanced Encryption Standard)

Les fonctions de chiffrement AEAD utilisent le chiffrement AES (Advanced Encryption Standard). Son entrée consiste en du texte brut et une clé de chiffrement, et elle renvoie une séquence d'octets chiffrés en sortie. Cette séquence d'octets peut ensuite être déchiffrée à l'aide de la même clé que celle qui a été utilisée pour le chiffrement. AES utilise une taille de bloc de 16 octets, ce qui signifie que le texte brut est traité comme une séquence de blocs de 16 octets. Le texte chiffré contient un préfixe spécifique à Tink indiquant la clé utilisée pour effectuer le chiffrement. Le chiffrement AES accepte plusieurs modes de chiffrement par blocs.

Modes de chiffrement par blocs

Les deux modes de chiffrement par blocs acceptés par les fonctions de chiffrement AEAD sont GCM et CBC.

GCM

Le mode GCM (Galois/Counter Mode) est un mode de chiffrement AES. La fonction numérote les blocs de manière séquentielle, puis associe le numéro de bloc à un vecteur d'initialisation (IV). Un vecteur d'initialisation est une valeur aléatoire ou pseudo-aléatoire qui constitue la base de la randomisation des données en texte brut. La fonction chiffre ensuite le numéro de bloc combiné à l'IV à l’aide de l’AES. La fonction effectue ensuite une opération logique exclusive au bit ou (XOR) sur le résultat du chiffrement et le texte brut pour produire le texte chiffré. Le mode GCM utilise une clé cryptographique de 128 ou 256 bits.

Mode CBC

Le mode CBC "enchaîne" les blocs en effectuant une opération XOR pour chaque bloc de texte brut avec le bloc de texte chiffré précédent avant le chiffrement. Le mode CBC utilise une clé cryptographique de 128, 192 ou 256 bits. Il utilise également un vecteur d'initialisation de 16 octets comme bloc initial et effectue une opération XOR pour ce bloc avec le premier bloc de texte brut.

Le mode CBC n'est pas un schéma AEAD dans le sens cryptographiques, car il ne fournit pas d'intégrité des données. En d'autres termes, les modifications malveillantes des données chiffrées ne seront pas détectées, ce qui nuit également la confidentialité des données. CBC n'est donc pas recommandé, sauf si cela est nécessaire pour d'anciennes raisons.

Données supplémentaires

Les fonctions de chiffrement AEAD acceptent l'utilisation d'un argument additional_data, également appelé données associées (AD) ou données authentifiées supplémentaires. Un texte chiffré ne peut être déchiffré que si les mêmes données supplémentaires utilisées pour le chiffrement sont également fournies. Les données supplémentaires peuvent donc être utilisées pour lier le texte chiffré à un contexte.

Par exemple, additional_data pourrait constituer la sortie de CAST(customer_id AS STRING) lors du chiffrement des données pour un client particulier. Cela garantit que les données déchiffrées ont été chiffrées à l'aide de l'identifiant customer_id attendu. La même valeur additional_data est requise pour le déchiffrement. Pour en savoir plus, consultez la RFC 5116.

Déchiffrement

La sortie de AEAD.ENCRYPT est un texte chiffré BYTES. Les fonctions AEAD.DECRYPT_STRING ou AEAD.DECRYPT_BYTES peuvent déchiffrer ce texte chiffré. Ces fonctions doivent utiliser une collection de clés contenant la clé qui a été utilisée pour le chiffrement, dont l'état doit être 'ENABLED'. Elles doivent également utiliser les mêmes données additional_data que celles utilisées pour le chiffrement.

Lorsque la collection de clés est utilisée pour le déchiffrement, la clé appropriée est choisie en fonction de l'ID de clé encodé dans le texte chiffré.

La sortie de AEAD.DECRYPT_STRING est une valeur STRING en texte brut, tandis que la sortie de AEAD.DECRYPT_BYTES est une valeur BYTES en texte brut. AEAD.DECRYPT_STRING peut déchiffrer le texte chiffré qui encode une valeur STRING. AEAD.DECRYPT_BYTES peut déchiffrer le texte chiffré qui encode une valeur BYTES. L'utilisation de l'une de ces fonctions pour déchiffrer un texte chiffré qui encode un type de données incorrect, par exemple l'utilisation de AEAD.DECRYPT_STRING pour déchiffrer un texte chiffré qui encode une valeur BYTES, perturbe son comportement et peut entraîner une erreur.

Rotation des clés

La rotation des clés de chiffrement a pour objectif principal de réduire la quantité des données chiffrées à l'aide d'une clé spécifique. Ainsi, une clé potentiellement compromise permettrait à un pirate d'accéder à une quantité de données moindre.

La rotation d'une collection de clés implique les actions suivantes :

1. Créer une nouvelle clé cryptographique principale dans chaque collection de clés
2. Déchiffrer toutes les données chiffrées et les chiffrer à nouveau

La fonction KEYS.ROTATE_KEYSET ou KEYS.ROTATE_WRAPPED_KEYSET effectue la première étape en ajoutant une nouvelle clé cryptographique principale à une collection de clés et en remplaçant l'ancienne clé cryptographique principale par une clé cryptographique secondaire.

Clés Cloud KMS

Le langage GoogleSQL accepte les fonctions de chiffrement AEAD associées aux clés Cloud KMS pour sécuriser davantage vos données. Cette couche de protection supplémentaire chiffre votre clé de chiffrement des données (DEK, Data Encryption Key) à l'aide d'une clé de chiffrement de clé (KEK, Key Encryption Key). La KEK est une collection de clés de chiffrement symétrique qui est stockée de manière sécurisée dans Cloud Key Management Service et gérée à l'aide des autorisations et rôles Cloud KMS.

Au moment de l'exécution de la requête, utilisez la fonction KEYS.KEYSET_CHAIN pour fournir le chemin d'accès à la ressource KMS de la KEK et le texte chiffré à partir de la DEK encapsulée. BigQuery appelle Cloud KMS pour désencapsuler la DEK, puis utilise cette clé pour déchiffrer les données de votre requête. La version désencapsulée de la DEK n'est stockée en mémoire que pendant la durée de la requête, puis elle est détruite.

Pour en savoir plus, consultez la page Chiffrement au niveau des colonnes SQL avec des clés Cloud KMS.