Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Directives pour le client de chiffrement C3R

Le client de chiffrement C3R est un outil qui permet aux entreprises de rassembler des données sensibles afin de tirer de nouvelles informations de l'analyse des données. L'outil limite cryptographiquement ce qui peut être appris par n'importe quelle partie et AWS au cours du processus. Bien que cela soit d'une importance vitale, le processus de sécurisation cryptographique des données peut entraîner une surcharge importante en termes de ressources de calcul et de stockage. Il est donc important de comprendre les inconvénients liés à l'utilisation de chaque paramètre et de savoir comment optimiser les paramètres tout en maintenant les garanties cryptographiques souhaitées. Cette rubrique se concentre sur les implications en termes de performances des différents paramètres du client et des schémas de chiffrement C3R.

Tous les paramètres de chiffrement du client de chiffrement C3R fournissent des garanties cryptographiques différentes. Les paramètres de collaboration sont les plus sécurisés par défaut. L'activation de fonctionnalités supplémentaires lors de la création d'une collaboration affaiblit les garanties de confidentialité, ce qui permet d'effectuer des activités telles que l'analyse des fréquences sur le texte chiffré. Pour plus d'informations sur la manière dont ces paramètres sont utilisés et sur leurs implications, consultezInformatique cryptographique pour Clean Rooms.

Implications sur les performances pour les types de colonnes

C3R utilise trois types de colonnes : cleartextfingerprint, etsealed. Chacun de ces types de colonnes fournit des garanties cryptographiques différentes et a des utilisations prévues différentes. Dans les sections suivantes, les implications du type de colonne sur les performances sont abordées ainsi que l'impact de chaque paramètre sur les performances.

Cleartextcolonnes

Cleartextles colonnes ne sont pas modifiées par rapport à leur format d'origine et ne sont en aucun cas traitées cryptographiquement. Ce type de colonne ne peut pas être configuré et n'a aucune incidence sur les performances de stockage ou de calcul.

Fingerprintcolonnes

Fingerprintles colonnes sont destinées à être utilisées pour joindre des données sur plusieurs tables. À cette fin, la taille du texte chiffré obtenu doit toujours être la même. Toutefois, ces colonnes sont affectées par les paramètres de collaboration. Fingerprintles colonnes peuvent avoir différents degrés d'impact sur la taille du fichier de sortie en fonction du cleartext contenu de l'entrée.

Frais généraux de base pour les fingerprint colonnes

Il existe un surcoût de base pour les fingerprint colonnes. Cette surcharge est constante et remplace la taille des cleartext octets.

Les données des fingerprint colonnes sont traitées cryptographiquement par le biais d'une fonction HMAC (Hash Based Message Authentication Code), qui transforme les données en un code d'authentification de message (MAC) de 32 octets. Ces données sont ensuite traitées via un encodeur base64, ce qui ajoute environ 33 % à la taille des octets. Il est précédé d'une désignation C3R à 8 octets pour désigner le type de colonne à laquelle appartiennent les données et la version du client qui les a produites. Le résultat final est de 52 octets. Ce résultat est ensuite multiplié par le nombre de lignes pour obtenir le surcoût total de base (utilisez le nombre total de null valeurs non égales s'il preserveNulls est défini sur true).

L'image suivante montre comment BASE_OVERHEAD = C3R_DESIGNATION + (MAC * 1.33)

Le texte chiffré de sortie dans les fingerprint colonnes sera toujours de 52 octets. Cela peut entraîner une diminution significative de la capacité de stockage si les cleartext données d'entrée dépassent en moyenne plus de 52 octets (par exemple, les adresses postales complètes). Cela peut représenter une augmentation significative du stockage si les cleartext données d'entrée sont en moyenne inférieures à 52 octets (par exemple, l'âge du client).

Paramètres de collaboration pour les fingerprint colonnes

Paramètre preserveNulls

Lorsque le paramètre au niveau de la collaboration preserveNulls est false (par défaut), chaque null valeur est remplacée par 32 octets uniques et aléatoires et traitée comme si ce n'était pas le cas. null Le résultat est que chaque null valeur est désormais de 52 octets. Cela peut ajouter des exigences de stockage importantes pour les tables contenant très peu de données par rapport à ce paramètre true et à ce que null les valeurs sont transmises sous forme null de.

Si vous n'avez pas besoin des garanties de confidentialité de ce paramètre et que vous préférez conserver null les valeurs de vos ensembles de données, activez le preserveNulls paramètre au moment de la création de la collaboration. Le preserveNulls paramètre ne peut pas être modifié une fois la collaboration créée.

Exemple de données pour une fingerprint colonne

Voici un exemple de jeu de données d'entrée et de sortie pour une fingerprint colonne avec des paramètres à reproduire. D'autres paramètres de collaboration n'ont allowDuplicates pas d'impact sur les résultats et peuvent être définis au fur true et à mesure que allowCleartext false vous essayez de reproduire localement.

Exemple de secret partagé : wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Exemple d'identifiant de collaboration : a1b2c3d4-5678-90ab-cdef-EXAMPLE11111

allowJoinsOnColumnsWithDifferentNames: True ce paramètre n'a aucune incidence sur les performances ou les exigences de stockage. Toutefois, ce paramètre rend le choix du nom de colonne non pertinent lors de la reproduction des valeurs indiquées dans les tableaux suivants.

fingerprintColonnes de dépannage

Pourquoi le texte chiffré de mes fingerprint colonnes est-il plusieurs fois supérieur à la taille du texte cleartext qui y est inscrit ?

Le texte chiffré d'une fingerprint colonne a toujours une longueur de 52 octets. Si vos données d'entrée étaient petites (par exemple, l'âge des clients), elles indiqueront une augmentation significative de leur taille. Cela peut également se produire si le preserveNulls paramètre est réglé surfalse.

Pourquoi le texte chiffré de mes fingerprint colonnes est-il plusieurs fois plus petit que la taille du texte cleartext qui y figure ?

Le texte chiffré d'une fingerprint colonne a toujours une longueur de 52 octets. Si vos données d'entrée sont volumineuses (par exemple, les adresses complètes des clients), leur taille diminuera considérablement.

Comment savoir si j'ai besoin des garanties cryptographiques fournies par preserveNulls ?

Malheureusement, la réponse est que cela dépend. Au minimum, Paramètres de calcul cryptographique il convient de vérifier la manière dont le preserveNulls paramètre protège vos données. Cependant, nous vous recommandons de faire référence aux exigences de traitement des données de votre organisation et à tout contrat applicable à la collaboration correspondante.

Pourquoi dois-je supporter la surcharge de base64 ?

Pour garantir la compatibilité avec les formats de fichiers tabulaires tels que CSV, le codage base64 est nécessaire. Bien que certains formats de fichier Parquet puissent prendre en charge les représentations binaires des données, il est important que tous les participants à une collaboration représentent les données de la même manière afin de garantir des résultats de requête corrects.

Sealedcolonnes

Sealedles colonnes sont destinées à être utilisées pour transférer des données entre les membres d'une collaboration. Le texte chiffré de ces colonnes n'est pas déterministe et a un impact significatif sur les performances et le stockage en fonction de la configuration des colonnes. Ces colonnes peuvent être configurées individuellement et ont souvent le plus grand impact sur les performances du client de chiffrement C3R et sur la taille du fichier de sortie qui en résulte.

Frais généraux de base pour les sealed colonnes

Il existe un surcoût de base pour les sealed colonnes. Cette surcharge est constante et s'ajoute à la taille des octets cleartext et de remplissage (le cas échéant).

Avant tout chiffrement, les données des sealed colonnes sont précédées d'un caractère de 1 octet désignant le type de données contenues. Si le rembourrage est sélectionné, les données sont ensuite complétées et ajoutées avec 2 octets indiquant la taille du pad. Une fois ces octets ajoutés, les données sont traitées cryptographiquement à l'aide d'AES-GCM et stockées avec les IV (12 octets), nonce (32 octets) et Auth Tag (16 octets). Ces données sont ensuite traitées via un encodeur base64, ce qui ajoute environ 33 % à la taille des octets. Les données sont précédées d'une désignation C3R à 7 octets pour indiquer le type de colonne auquel elles appartiennent et la version du client utilisée pour les produire. Le résultat est un surdébit de base final de 91 octets. Ce résultat peut ensuite être multiplié par le nombre de lignes pour obtenir le surcoût total de base (utilisez le nombre total de valeurs non nulles s'il preserveNulls est défini sur true).

L'image suivante montre comment BASE_OVERHEAD = C3R_DESIGNATION + ((NONCE + IV + DATA_TYPE + PAD_SIZE + AUTH_TAG) * 1.33)

Paramètres de collaboration pour les sealed colonnes

Paramètre preserveNulls

Lorsque le paramètre au niveau de la collaboration preserveNulls est false (par défaut), chaque null valeur est unique, aléatoire de 32 octets et traitée comme si ce n'était pas le cas. null Le résultat est que chaque null valeur est désormais de 91 octets (plus si elle est complétée). Cela peut ajouter des exigences de stockage importantes pour les tables contenant très peu de données par rapport à ce paramètre true et à ce que null les valeurs sont transmises sous forme null de.

Si vous n'avez pas besoin des garanties de confidentialité de ce paramètre et que vous préférez conserver null les valeurs de vos ensembles de données, activez le preserveNulls paramètre au moment de la création de la collaboration. Le preserveNulls paramètre ne peut pas être modifié une fois la collaboration créée.

sealedColonnes des paramètres du schéma : types de rembourrage

Type de pad none

La sélection d'un type de pad none n'ajoute aucun rembourrage à la surcharge de base décrite précédemment cleartext et n'ajoute aucune surcharge supplémentaire à la surcharge de base décrite précédemment. L'absence de rembourrage permet d'obtenir la taille de sortie la plus économe en espace. Cependant, il n'offre pas les mêmes garanties de confidentialité que les types de rembourrage fixed et de max rembourrage. Cela est dû au fait que la taille du sous-jacent cleartext est perceptible à partir de la taille du texte chiffré.

Type de pad fixed

La sélection d'un type de pad fixed est une mesure de protection de la vie privée qui permet de masquer la longueur des données contenues dans une colonne. Cela se fait en complétant le tout dans le champ cleartext fourni pad_length avant qu'il ne soit crypté. Toute donnée dépassant cette taille entraîne l'échec du client de chiffrement C3R.

Étant donné que le remplissage est ajouté cleartext avant d'être chiffré, AES-GCM dispose d'un mappage 1 à 1 entre les octets du texte chiffré. cleartext Le codage base64 ajoutera 33 %. La surcharge de stockage supplémentaire du rembourrage peut être calculée en soustrayant la longueur moyenne du de la valeur cleartext du pad_length et en la multipliant par 1,33. Le résultat est le surcoût moyen de remplissage par enregistrement. Ce résultat peut ensuite être multiplié par le nombre de lignes pour obtenir la surcharge de remplissage totale (utilisez le nombre total de null valeurs non égales si la valeur preserveNulls est définie surtrue).

PADDING_OVERHEAD = (PAD_LENGTH - AVG_CLEARTEXT_LENGTH) * 1.33 * ROW_COUNT

Nous vous recommandons de sélectionner le minimum pad_length qui englobe la plus grande valeur d'une colonne. Par exemple, si la valeur la plus élevée est de 50 octets, une valeur pad_length de 50 est suffisante. Une valeur supérieure à cette valeur ne fera qu'augmenter la charge de stockage.

Le rembourrage fixe n'entraîne aucune surcharge de calcul significative.

Type de pad max

La sélection d'un type de pad max est une mesure de protection de la vie privée qui permet de masquer la longueur des données contenues dans une colonne. Cela se fait en ajoutant le tout cleartext à la plus grande valeur de la colonne, plus le montant supplémentaire, pad_length avant qu'il ne soit chiffré. En général, max le remplissage fournit les mêmes garanties que le remplissage fixed d'un seul ensemble de données, tout en permettant de ne pas connaître la plus grande cleartext valeur de la colonne. Cependant, le max remplissage peut ne pas fournir les mêmes garanties de confidentialité que le fixed remplissage entre les mises à jour, car la valeur la plus élevée des ensembles de données individuels peut être différente.

Nous vous recommandons de sélectionner une valeur supplémentaire pad_length de 0 lorsque vous utilisez le max rembourrage. Cette longueur permet à toutes les valeurs d'avoir la même taille que la plus grande valeur de la colonne. Une valeur supérieure à cette valeur ne fera qu'augmenter la charge de stockage.

Si la cleartext valeur la plus élevée est connue pour une colonne donnée, nous vous recommandons d'utiliser plutôt le type fixed pad. L'utilisation fixed du rembourrage assure la cohérence entre les ensembles de données mis à jour. L'maxutilisation du remplissage permet de compléter chaque sous-ensemble de données à la valeur la plus élevée figurant dans le sous-ensemble.

Exemple de données pour une sealed colonne

Voici un exemple de jeu de données d'entrée et de sortie pour une sealed colonne avec des paramètres à reproduire. D'autres paramètres de collaboration tels que allowCleartextallowJoinsOnColumnsWithDifferentNames, et allowDuplicates n'ont pas d'impact sur les résultats et peuvent être définis au fur true et à mesure que false vous essayez de reproduire localement. Bien qu'il s'agisse des paramètres de base à reproduire, la sealed colonne n'est pas déterministe et les valeurs changent à chaque fois. L'objectif est d'afficher les octets entrants par rapport aux octets sortants. Les pad_length valeurs d'exemple ont été choisies intentionnellement. Ils montrent que le fixed rembourrage donne les mêmes valeurs que le max rembourrage avec les pad_length paramètres minimaux recommandés ou lorsqu'un rembourrage supplémentaire est souhaité.

Exemple de secret partagé : wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

Exemple d'identifiant de collaboration : a1b2c3d4-5678-90ab-cdef-EXAMPLE11111

Type de pad none

Type de tampon fixed (exemple 1)

Dans cet exemple, pad_length c'est 62 et la plus grande entrée est 62 octets.

Type de tampon fixed (exemple 2)

Dans cet exemple, pad_length c'est 162 et la plus grande entrée est 62 octets.

Type de tampon max (exemple 1)

Dans cet exemple, la valeur pad_length est 0 et la plus grande entrée est de 62 octets.

Type de tampon max (exemple 2)

Dans cet exemple, pad_length c'est 100 et la plus grande entrée est 62 octets.

sealedColonnes de dépannage

Pourquoi le texte chiffré de mes sealed colonnes est-il plusieurs fois supérieur à la taille du texte cleartext qui y est inscrit ?

Cela dépend de plusieurs facteurs. D'une part, le texte chiffré d'une Cleartext colonne a toujours une longueur d'au moins 91 octets. Si vos données d'entrée étaient petites (par exemple, l'âge des clients), elles indiqueront une augmentation significative de leur taille. Ensuite, si vous avez preserveNulls défini ce paramètre sur false et que vos données d'entrée contenaient un grand nombre de null valeurs, chacune de ces null valeurs aura été transformée en 91 octets de texte chiffré. Enfin, si vous utilisez le rembourrage, par définition, des octets sont ajoutés aux cleartext données avant qu'elles ne soient chiffrées.

La plupart de mes données dans une sealed colonne sont très petites et je dois utiliser le rembourrage. Puis-je simplement supprimer les grandes valeurs et les traiter séparément pour économiser de l'espace ?

Nous vous déconseillons de supprimer des valeurs importantes et de les traiter séparément. Cela modifie les garanties de confidentialité fournies par le client de chiffrement C3R. En tant que modèle de menace, supposons qu'un observateur puisse voir les deux ensembles de données chiffrés. Si l'observateur constate qu'une colonne d'un sous-ensemble de données est plus ou moins remplie qu'un autre sous-ensemble, il peut tirer des conclusions sur la taille des données de chaque sous-ensemble. Supposons, par exemple, qu'une fullName colonne soit complétée à un total de 40 octets dans un fichier et à 800 octets dans un autre fichier. Un observateur peut supposer qu'un ensemble de données contient le nom le plus long du monde (747 octets).

Dois-je fournir un rembourrage supplémentaire lorsque j'utilise ce type de max rembourrage ?

Non. Lorsque vous utilisez le max rembourrage, nous recommandons que lepad_length, également connu sous le nom de rembourrage supplémentaire au-delà de la plus grande valeur de la colonne, soit défini sur 0.

Puis-je simplement en choisir une grande pad_length lorsque j'utilise un fixed rembourrage pour ne pas me demander si la plus grande valeur convient ?

Oui, mais la grande longueur du pad est inefficace et utilise plus d'espace de stockage que nécessaire. Nous vous recommandons de vérifier la taille de la plus grande valeur et de la pad_length définir sur cette valeur.

Comment savoir si j'ai besoin des garanties cryptographiques fournies par preserveNulls ?

Malheureusement, la réponse est que cela dépend. Au minimum, Informatique cryptographique pour Clean Rooms il convient de vérifier la manière dont le preserveNulls paramètre protège vos données. Cependant, nous vous recommandons de faire référence aux exigences de traitement des données de votre organisation et à tout contrat applicable à la collaboration correspondante.

Pourquoi dois-je supporter la surcharge de base64 ?

Pour garantir la compatibilité avec les formats de fichiers tabulaires tels que CSV, le codage base64 est nécessaire. Bien que certains formats de fichier Parquet puissent prendre en charge les représentations binaires des données, il est important que tous les participants à une collaboration représentent les données de la même manière afin de garantir des résultats de requête corrects.

Résolution des problèmes liés aux augmentations imprévues de la taille du texte chiffré

Supposons que vous ayez chiffré vos données et que la taille des données obtenues soit étonnamment importante. Les étapes suivantes peuvent vous aider à identifier l'endroit où l'augmentation de taille s'est produite et les mesures que vous pouvez prendre, le cas échéant.

Identification de l'endroit où l'augmentation de taille s'est produite

Avant de pouvoir déterminer pourquoi vos données chiffrées sont nettement plus volumineuses que vos cleartext données, vous devez d'abord identifier l'origine de l'augmentation de taille. Cleartextles colonnes peuvent être ignorées en toute sécurité car elles sont inchangées. Examinez le reste fingerprint des sealed colonnes et choisissez-en une qui semble significative.

Identifier la raison pour laquelle l'augmentation de taille s'est produite

Une fingerprint colonne ou une sealed colonne peut contribuer à l'augmentation de la taille.

L'augmentation de taille provient-elle d'une fingerprint colonne ?

Si la colonne qui contribue le plus à l'augmentation du stockage est une fingerprint colonne, cela est probablement dû au fait que les cleartext données sont petites (par exemple, l'âge du client). Chaque fingerprint texte chiffré obtenu a une longueur de 52 octets. Malheureusement, rien ne peut être fait à ce sujet sur une column-by-column base solide. Pour plus d'informations, voir Frais généraux de base pour les fingerprint colonnes les détails de cette colonne, notamment son impact sur les exigences de stockage.

L'autre cause possible de l'augmentation de la taille d'une fingerprint colonne est le paramètre de collaboration,preserveNulls. Si le paramètre de collaboration pour preserveNulls est désactivé (paramètre par défaut), toutes les null valeurs des fingerprint colonnes seront devenues 52 octets de texte chiffré. Rien ne peut être fait pour cela dans le cadre de la collaboration actuelle. Le preserveNulls paramètre est défini au moment de la création d'une collaboration et tous les collaborateurs doivent utiliser le même paramètre pour garantir des résultats de requête corrects. Pour plus d'informations sur ce preserveNulls paramètre et sur l'impact de son activation sur les garanties de confidentialité de vos données, consultezInformatique cryptographique pour Clean Rooms.

L'augmentation de taille provient-elle d'une sealed colonne ?

Si la colonne qui contribue le plus à l'augmentation du stockage est une sealed colonne, certains détails peuvent contribuer à l'augmentation de la taille.

Si les cleartext données sont petites (par exemple, l'âge du client), chaque sealed texte chiffré obtenu a une longueur d'au moins 91 octets. Malheureusement, rien ne peut être fait à ce sujet. Pour plus d'informations, voir Frais généraux de base pour les sealed colonnes les détails de cette colonne, notamment son impact sur les exigences de stockage.

La deuxième cause principale de l'augmentation du stockage dans les sealed colonnes est le rembourrage. Le remplissage ajoute des octets supplémentaires cleartext avant le chiffrement afin de masquer la taille des valeurs individuelles d'un ensemble de données. Nous vous recommandons de définir le rembourrage à la valeur minimale possible pour votre ensemble de données. Au minimum, le pad_length fixed remplissage doit être défini de manière à inclure la plus grande valeur possible dans la colonne. Tout paramètre supérieur n'ajoute aucune garantie de confidentialité supplémentaire. Par exemple, si vous savez que la plus grande valeur possible d'une colonne peut être de 50 octets, nous vous recommandons de la pad_length définir sur 50 octets. Toutefois, si la sealed colonne utilise un max remplissage, nous vous recommandons de définir la pad_length valeur sur 0 octet. Cela est dû au fait que le max rembourrage fait référence au rembourrage supplémentaire au-delà de la plus grande valeur de la colonne.

La dernière cause possible de l'augmentation de la taille d'une sealed colonne est le paramètre de collaboration,preserveNulls. Si le paramètre de collaboration pour preserveNulls est désactivé (paramètre par défaut), toutes les null valeurs des sealed colonnes seront devenues 91 octets de texte chiffré. Rien ne peut être fait pour cela dans le cadre de la collaboration actuelle. Le preserveNulls paramètre est défini au moment de la création d'une collaboration, et tous les collaborateurs doivent utiliser le même paramètre pour garantir des résultats de requête corrects. Pour plus d'informations sur ce paramètre et sur l'impact de son activation sur les garanties de confidentialité de vos données, consultezInformatique cryptographique pour Clean Rooms.