Glossaire MAFATE

18+ définitions cybersécurité & conformité

Définitions courtes, sources officielles (CNIL, ANSSI, NIST, EUR-LEX, ENISA), termes liés. Le glossaire de référence pour comprendre le RGPD, HDS, DORA, le CLOUD Act et le chiffrement applicatif.

AES-256-GCM: AES-256-GCM (Advanced Encryption Standard, clé 256 bits, mode Galois/Counter Mode) est l'algorithme de chiffrement symétrique authentifié de référence en 2026. Standardisé par le NIST (FIPS 197) et recommandé par l'ANSSI au niveau "Renforcé", il combine confidentialité (chiffrement par blocs) et intégrité (tag d'authentification GCM). Accéléré par les instructions matérielles AES-NI des CPU modernes (overhead < 2%). Utilisé par MAFATE pour le chiffrement des données au repos et en transit. Ce que le mode GCM ajoute au chiffrement, et pourquoi ça compte : il produit, en plus du chiffré, un tag d'authentification qui rend toute modification détectable. Un chiffrement sans cette propriété laisse un attaquant altérer le chiffré et faire accepter le résultat comme légitime. C'est la raison pour laquelle les modes non authentifiés, longtemps courants, sont aujourd'hui écartés des référentiels. La contrainte à connaître porte sur le nonce, ce vecteur de 96 bits tiré à chaque chiffrement. Deux tirages identiques sous une même clé ne compromettent pas seulement les deux messages concernés : ils permettent de retrouver la clé d'authentification, donc de forger des messages acceptés comme authentiques. Avec des nonces aléatoires, la probabilité devient significative vers deux milliards d'opérations sous la même clé, ce qui impose de compter les usages et de changer de clé avant ce seuil. Sur le coût, l'idée reçue veut que le chiffrement ralentisse les applications. Les processeurs modernes embarquent des instructions dédiées qui ramènent le surcoût sous les deux pour cent. Ce qui coûte réellement dans une architecture chiffrée n'est jamais l'algorithme : ce sont les appels réseau au service qui détient les clés, et c'est précisément ce que le chiffrement par enveloppe réduit.
Argon2: Argon2 est la fonction de hachage de mots de passe lauréate de la Password Hashing Competition (2015), standardisée par l'IETF dans la RFC 9106. Elle décline trois variantes : Argon2d (résistance GPU), Argon2i (résistance side-channel), Argon2id (compromis recommandé), paramétrables en mémoire, temps CPU et parallélisme. L'OWASP la recommande comme algorithme par défaut pour le stockage de mots de passe (paramètres minimaux : 19 MiB / 2 itérations / 1 thread). À privilégier sur bcrypt et PBKDF2 pour tout nouveau projet.
BYOK (Bring Your Own Key): BYOK (Bring Your Own Key) est le modèle où le client génère ses propres clés cryptographiques et les importe chez son fournisseur cloud, plutôt que d'utiliser les clés générées par le fournisseur. Apporte un contrôle accru sur l'origine et la chaîne de confiance des clés, mais le fournisseur conserve l'accès opérationnel pour le déchiffrement à la demande. À distinguer de HYOK (Hold Your Own Key) où le client reste l'unique détenteur des clés. MAFATE ne propose PAS d'import de clé : les clés sont générées dans le module matériel et n'en sortent pas. Le rapprochement le plus proche est le mode enveloppe, où votre application génère la clé de données et MAFATE ne fait que l'emballer. Ce que le sigle promet, et ce qu'il faut vérifier derrière : apporter sa propre clé signifie que le client la génère chez lui, puis l'importe chez le fournisseur. La question utile n'est pas de savoir si l'import existe, mais ce que le fournisseur peut faire de la clé une fois importée. Chez la plupart des services cloud, elle est déchiffrée en mémoire pour servir, ce qui laisse au fournisseur — et à toute autorité qui le contraint — un accès théorique. Le modèle plus strict porte un autre nom, HYOK, où la clé ne quitte jamais l'infrastructure du client et où le fournisseur ne manipule que des données déjà chiffrées. La différence est décisive dans un dossier de conformité : elle décide si le fournisseur est un sous-traitant qui accède aux données ou un prestataire qui n'y accède pas. Elle a aussi un coût, l'indisponibilité du service client rendant les données inexploitables. La question qui tranche en pratique concerne la juridiction, et elle est rarement posée dans les comparatifs. Une clé importée chez un fournisseur soumis au droit américain reste atteignable par une injonction extraterritoriale, quelle que soit la localisation physique du serveur. Le BYOK déplace donc le risque sans le supprimer, ce qui suffit dans bien des cas mais ne répond pas à une exigence de souveraineté.
ChaCha20-Poly1305: ChaCha20-Poly1305 est un algorithme de chiffrement symétrique authentifié standardisé par l'IETF (RFC 8439) et le NIST (SP 800-38D-rev1 draft). Alternative à AES-256-GCM, il combine le stream cipher ChaCha20 (Daniel J. Bernstein, 2008) et le MAC Poly1305. Plus performant qu'AES sur les CPU sans accélération hardware (mobile ARM, IoT). Utilisé par TLS 1.3, WireGuard, et le chiffrement disque de Linux/Android.
Confidential Computing: Le confidential computing désigne le chiffrement des données pendant leur utilisation par le CPU, en plus de leur chiffrement au repos et en transit. Il s'appuie sur des Trusted Execution Environments (TEE) matériels : Intel SGX/TDX, AMD SEV-SNP, ARM CCA, AWS Nitro Enclaves. Promu par la Confidential Computing Consortium (Linux Foundation), il garantit qu'un attaquant disposant d'un accès root sur l'hyperviseur ou de privilèges cloud ne puisse pas inspecter la mémoire de l'application. Critique pour les workloads multi-tenant et les services tiers traitant des données réglementées.
DEK (Data Encryption Key): Une DEK (Data Encryption Key) est la clé symétrique utilisée pour chiffrer directement les données utilisateur (typiquement AES-256-GCM). Dans le modèle d'envelope encryption recommandé par le NIST, chaque blob de données reçoit sa propre DEK, elle-même chiffrée par une KEK (Key Encryption Key) de niveau supérieur. Cette séparation limite le rayon d'exposition : une DEK compromise n'expose qu'un seul fichier, sans risquer la confidentialité de l'ensemble du système. La rotation des DEK devient indépendante des KEK.
ECC (Elliptic Curve Cryptography): ECC (Cryptographie sur courbes elliptiques) regroupe les schémas asymétriques opérant sur la structure mathématique des courbes elliptiques. Standardisée par le NIST SP 800-186 (2023), elle offre une sécurité équivalente à RSA pour des clés bien plus courtes (256 bits ≈ RSA 3072 bits). Les courbes recommandées en 2026 incluent P-256, P-384, P-521 (NIST) et Curve25519 (RFC 7748). Utilisée pour TLS (ECDHE), signatures (ECDSA, Ed25519) et le chiffrement (ECIES). Comme RSA, vulnérable au quantique.
Enveloppe cryptographique (envelope encryption): L'envelope encryption est un pattern d'architecture où chaque blob de données est chiffré par une clé unique (DEK), elle-même protégée par une clé maîtresse (KEK) gérée par un HSM ou un KMS. Recommandé par NIST SP 800-57 et l'ANSSI, ce modèle découple le cycle de vie des données et celui des clés, permet une rotation des KEK sans re-chiffrer toutes les données, et limite le rayon de compromission. Mis en œuvre par AWS KMS, Google Cloud KMS, Azure Key Vault, HashiCorp Vault et MAFATE. Pourquoi ce détour plutôt qu'un chiffrement direct : une clé de données est tirée pour un usage précis, chiffre la donnée localement, puis est elle-même chiffrée par une clé maîtresse qui ne sort jamais du module qui la détient. Chiffrer un téraoctet ne demande alors qu'un appel réseau par enveloppe, et non le transfert du volume entier vers un service distant. C'est ce qui rend le chiffrement de gros volumes praticable sans sacrifier l'isolement de la clé maîtresse. Le bénéfice le moins évident est celui de la rotation. Changer la clé maîtresse n'oblige pas à déchiffrer puis rechiffrer les données : il suffit de rechiffrer les clés de données, qui sont petites et peu nombreuses au regard du volume protégé. Une rotation qui prendrait des jours sur une base entière se ramène à une opération de quelques secondes. Le point de vigilance porte sur la clé maîtresse, précisément parce qu'elle est réutilisée. En mode authentifié à nonce aléatoire, la répétition d'un nonce sous une même clé ne compromet pas seulement les deux messages concernés : elle permet de retrouver la clé d'authentification, donc de forger des messages, et cela sans le moindre signal. C'est la raison pour laquelle un compteur d'usage par clé, et une rotation déclenchée par ce compteur, ne sont pas une précaution décorative.
FPE (Format Preserving Encryption): Le chiffrement préservant le format (FPE) est une technique cryptographique standardisée par le NIST SP 800-38G qui chiffre une donnée tout en conservant son format d'origine, par exemple un numéro de carte bancaire de 16 chiffres reste un nombre de 16 chiffres. Particulièrement utile pour intégrer du chiffrement dans des systèmes legacy où la longueur ou le type des champs est rigide (cobol, ERP). Le standard définit deux modes : FF1 et FF3-1 (révisé après cryptanalyse). Recommandé pour PAN PCI-DSS, IBAN, SIREN.
HSM (Hardware Security Module): Un HSM (Hardware Security Module) est un appareil physique dédié à la génération, au stockage et à l'utilisation de clés cryptographiques dans un environnement matériel inviolable (tamper-resistant). Certifié FIPS 140-2 niveau 3 ou Common Criteria EAL4+, il assure que les clés ne quittent jamais l'enclave hardware en clair. MAFATE stocke aujourd'hui ses clés maîtresses dans un HSM logiciel PKCS#11 opéré en France ; la migration vers un HSM matériel certifié FIPS 140-2 niveau 3 est planifiée et n'est pas encore en service. À quoi sert la résistance physique, concrètement : un HSM détecte l'ouverture de son boîtier, les variations de tension et de température, et efface ses clés plutôt que de les laisser lire. Cette propriété est ce que ni un serveur chiffré ni un conteneur ne peuvent offrir, et c'est la raison pour laquelle les autorités de certification l'exigent pour les clés maîtresses. La différence entre HSM matériel et HSM logiciel : un HSM logiciel comme SoftHSM implémente la même interface standard PKCS#11 et le même cloisonnement applicatif, ce qui permet de développer et d'exploiter sans matériel dédié, mais il ne fournit aucune garantie physique. Un attaquant qui obtient les droits administrateur sur la machine hôte accède au magasin de clés, ce qu'un HSM matériel empêche. Le choix se joue donc sur le modèle de menace retenu, pas sur la qualité du chiffrement, identique dans les deux cas. Ce que la certification FIPS 140 mesure vraiment : elle porte sur le module cryptographique, pas sur le service qui l'utilise. Un fournisseur peut donc annoncer un HSM certifié niveau 3 tout en exposant une API qui, elle, n'a jamais été auditée. La question utile à poser est celle du périmètre exact de la certification, et de la date de sa dernière validation.
HYOK (Hold Your Own Key): HYOK (Hold Your Own Key) désigne le modèle dans lequel le client conserve physiquement la clé de chiffrement, jamais transmise au prestataire cloud. Contrairement à BYOK où la clé est importée chez le prestataire (qui peut techniquement y accéder), HYOK garantit que l'opérateur cloud ne puisse jamais déchiffrer les données, y compris sous injonction CLOUD Act. Implémenté typiquement via un HSM on-premises ou un service de gestion de clés tiers indépendant. Réservé aux cas usage les plus sensibles (données santé, secrets d'État, données stratégiques). La différence avec le BYOK tient en une phrase : la clé ne quitte jamais l'infrastructure du client, et le fournisseur ne manipule que des données déjà chiffrées. En apportant sa clé, on la confie à un tiers qui la déchiffre en mémoire pour s'en servir ; en la conservant, on ne lui transmet rien d'exploitable. Cette nuance décide du statut juridique du fournisseur dans un dossier de conformité, entre un sous-traitant qui accède aux données et un prestataire qui n'y accède pas. Le prix de cette garantie est réel et rarement énoncé. Le fournisseur ne peut plus indexer, rechercher ni traiter le contenu, ce qui exclut une part des fonctionnalités attendues d'un service applicatif. L'indisponibilité de l'infrastructure du client rend par ailleurs les données inexploitables, y compris pour le client lui-même. Le modèle convient donc aux données dont la confidentialité prime sur l'exploitation, et beaucoup moins à celles qu'un service doit manipuler. Une architecture sérieuse ne choisit pas un modèle unique : elle classe les données par sensibilité, et réserve le HYOK à celles dont la divulgation serait irréparable.
KEK (Key Encryption Key): Une KEK (Key Encryption Key) est la clé symétrique servant à chiffrer d'autres clés, typiquement des DEK (Data Encryption Keys) dans le modèle d'envelope encryption. Stockée dans un HSM ou un KMS, elle est par construction beaucoup moins exposée que les DEK : elle ne touche jamais directement les données et reste rarement exfiltrable. Le NIST SP 800-57 recommande KEK ≥ 256 bits, rotation tous les 1-5 ans, et stockage dans un module FIPS 140-3. La hiérarchie multi-niveaux (KEK → DEK) est le standard de fait du chiffrement at-rest moderne.
KMS (Key Management Service): Un KMS (Key Management Service) centralise la création, le stockage, la rotation, l'audit et la destruction des clés cryptographiques. Il sépare les clés des données chiffrées (envelope encryption, modèle DEK/KEK) pour minimiser le rayon d'exposition en cas de compromission. Les KMS managés (AWS KMS, Azure Key Vault, Google Cloud KMS) sont souvent soumis au CLOUD Act. MAFATE est un KMS français basé sur un HSM logiciel (PKCS#11, migration FIPS planifiée), opéré en France et non soumis aux lois extraterritoriales US. Ce qu'un KMS fait, et pourquoi ce n'est pas un coffre à mots de passe : il génère les clés, les stocke hors de portée des applications, contrôle qui peut les utiliser, les fait tourner selon un calendrier, et journalise chaque usage. La distinction essentielle est que la clé ne sort jamais : l'application envoie la donnée à chiffrer et reçoit le résultat, au lieu de récupérer la clé pour l'utiliser elle-même. Un gestionnaire de secrets, lui, restitue la valeur qu'on lui confie, ce qui suffit pour un mot de passe de base de données mais ne suffit pas pour une clé de chiffrement dont on doit prouver qu'elle n'a jamais été exposée. Le chiffrement enveloppe est le motif que tous les KMS partagent : une clé de données à usage unique chiffre la donnée, puis cette clé est elle-même chiffrée par une clé maîtresse qui, seule, réside dans le KMS. Chiffrer un téraoctet ne demande alors qu'un appel réseau par enveloppe, et non un transfert du volume entier. Le critère de choix qui compte rarement lu dans les comparatifs : la juridiction. Un KMS opéré par une société soumise au droit américain reste atteignable par le CLOUD Act, quelle que soit la localisation physique des serveurs, ce qui devient déterminant dès qu'un client final impose une garantie de souveraineté.
PKI (Public Key Infrastructure): Une PKI (infrastructure à clés publiques) est l'ensemble organisationnel et technique qui émet, distribue et révoque des certificats numériques X.509 (RFC 5280) attestant la correspondance entre une identité et une clé publique. Composée d'autorités de certification (CA), d'autorités d'enregistrement (RA), de listes de révocation (CRL/OCSP) et de magasins de confiance. Socle de TLS, S/MIME, code signing, IPsec, eIDAS. Les CAs publiques (Let's Encrypt, DigiCert) opèrent sous CA/Browser Forum ; les PKI privées suivent ETSI EN 319 411.
RSA: RSA (Rivest-Shamir-Adleman, 1977) est le système cryptographique asymétrique le plus déployé, fondé sur la difficulté de factoriser de grands entiers. Standardisé par le NIST SP 800-56B Rev. 2 pour l'établissement de clés et par FIPS 186-5 pour la signature, il requiert des modules d'au moins 3072 bits depuis 2030 selon NIST/ANSSI. Vulnérable aux ordinateurs quantiques (algorithme de Shor), il est appelé à être remplacé par les standards post-quantiques ML-KEM (chiffrement) et ML-DSA (signature).
SHA-3: SHA-3 (Secure Hash Algorithm 3) est la famille de fonctions de hachage cryptographique standardisée par le NIST dans FIPS 202 (2015), fondée sur l'algorithme Keccak. Elle inclut SHA3-224, SHA3-256, SHA3-384 et SHA3-512 ainsi que les XOF (Extendable Output Functions) SHAKE128/SHAKE256. Conçue comme alternative structurelle à SHA-2 (résistant si SHA-2 venait à être cassé), elle utilise une construction sponge offrant des marges de sécurité supérieures. Recommandée par l'ANSSI pour les nouveaux protocoles.
Signature numérique: Une signature numérique authentifie l'origine et l'intégrité d'un message via cryptographie asymétrique : l'auteur signe avec sa clé privée, n'importe qui peut vérifier avec sa clé publique. Les schémas standardisés en 2026 incluent RSA-PSS et ECDSA (FIPS 186-5), Ed25519 (RFC 8032), ML-DSA (FIPS 204, post-quantique). Distincte de la signature électronique au sens juridique eIDAS, qui ajoute des exigences de processus et d'identification. Composant fondateur de la PKI, TLS, code signing, signatures de documents.
Tokenisation: La tokenisation remplace une donnée sensible (numéro de carte bancaire, IBAN, identifiant) par un substitut aléatoire sans valeur exploitable (le "token"), la correspondance étant stockée dans un coffre-fort cryptographique séparé. Contrairement au chiffrement, le token n'est pas mathématiquement réversible : la seule façon de retrouver la donnée originale est d'interroger le coffre. Mandatée par PCI-DSS pour le PAN, recommandée par le NISTIR 8053 pour réduire la surface d'attaque des bases. Souvent combinée à FPE pour respecter les formats des systèmes legacy.

Passer à la pratique

Besoin d'aide pour appliquer ces concepts ?

MAFATE génère vos attestations de chiffrement en 1 clic : RGPD et HDS aujourd'hui, DORA et NIS2 à mesure qu'ils s'appliquent.

Demander une démo →Voir la conformité