Comment ça marche
Le trajet réel d’un champ chiffré : ce qui se passe chez vous, ce qui voyage jusqu’à MAFATE, et la hiérarchie de clés qui tient l’ensemble.
Principe fondamental
MAFATE est un service de clés, pas un service de stockage, et pas davantage un service par lequel vos données transitent. Votre application chiffre le champ chez elle, avec une clé de données qu’elle tire elle-même. MAFATE reçoit cette clé de données, l’emballe, et la rend emballée. Le champ en clair et le champ chiffré restent chez vous.
Ce que MAFATE reçoit, exactement : 32 octets de clé
Ni le champ, ni le chiffré, ni sa taille. C’est ce qui rend une compromission de MAFATE seule sans effet sur vos données : il faudrait aussi compromettre votre base. C’est aussi ce qui rend l’affirmation vérifiable, plutôt que promise : les deux seuls appels réseau de la séquence sont wrap et unwrap.
Ce mode, dit « enveloppe », est actif par défaut sur tout compte créé depuis le 11/08/2026. Le mode serveur, où le clair transite pour être chiffré, existe toujours et s’ouvre sur demande : il est décrit plus bas.
Le trajet d’un champ
Une écriture puis une lecture, de bout en bout. Les deux opérations de chiffrement se font dans votre processus ; les deux flèches vers MAFATE ne portent que de la clé.
Votre application MAFATE API Votre base
│ │ │
│ [tirage d'une cle de donnees, 32 o.] │ │
│ [chiffrement AES-256-GCM DU CHAMP] │ │
│ ← le clair ne sort pas d'ici │ │
│ │ │
│ POST /v1/keys/{id}/wrap │ │
│ { dek: "<32 octets, base64>" } │ │
│ ──────────────────────────────────────>│ │
│ │ [emballage par la │
│ │ cle du locataire] │
│ { wrapped_key, key_version } │ │
│ <──────────────────────────────────────│ │
│ │ │
│ INSERT INTO users (first_name = l'enveloppe a SIX champs) │
│ ───────────────────────────────────────────────────────────────>│
│ │ │
│ SELECT first_name FROM users │ │
│ <───────────────────────────────────────────────────────────────│
│ │ │
│ POST /v1/keys/{id}/unwrap │ │
│ { wrapped_key } │ │
│ ──────────────────────────────────────>│ │
│ │ [desemballage + │
│ │ ecriture d'audit] │
│ { dek } │ │
│ <──────────────────────────────────────│ │
│ │ │
│ [dechiffrement AES-256-GCM DU CHAMP] │ │
│ [remise a zero de la cle de donnees] │ │
Ce que MAFATE a vu de cette sequence : deux fois 32 octets de cle.
Ni le champ, ni le chiffre, ni sa taille.La hiérarchie de clés
Le chiffrement par enveloppe est la technique employée par AWS KMS, GCP KMS et Azure Key Vault. Chez MAFATE elle compte trois niveaux, et non deux : la clé de données que vous tirez est emballée par la clé de votre locataire, elle-même emballée par la clé racine du module de sécurité.
Hierarchie des cles : trois niveaux
────────────────────────────────────
┌─────────────────────────────────────────────────────────────────┐
│ 1. KEK RACINE │
│ Vit dans le module de securite, ne sort jamais. │
│ Emballe le materiel de cle des locataires, en AES-KWP │
│ (CKM_AES_KEY_WRAP_PAD). │
└───────────────────────────┬─────────────────────────────────────┘
│ emballe
▼
┌─────────────────────────────────────────────────────────────────┐
│ 2. CLE DU LOCATAIRE (une par cle que vous creez, versionnee) │
│ Desemballee a chaque operation, effacee juste apres. │
│ Sert de cle d'emballage pour vos cles de donnees. │
└───────────────────────────┬─────────────────────────────────────┘
│ emballe, en AES-256-GCM, avec le
│ locataire + la cle + la version en
│ donnees associees (AAD)
▼
┌─────────────────────────────────────────────────────────────────┐
│ 3. CLE DE DONNEES (DEK) │
│ Tiree CHEZ VOUS, 32 octets, une par operation. │
│ C'est elle, et elle seule, qui voyage jusqu'a MAFATE. │
│ Emballee, elle devient le champ wrapped_key. │
└───────────────────────────┬─────────────────────────────────────┘
│ chiffre, chez vous
▼
┌─────────────────────────────────────────────────────────────────┐
│ VOTRE CHAMP, chiffre, dans VOTRE base. │
│ Stocke sous forme d'enveloppe a SIX champs : │
│ ciphertext, wrapped_key, iv, key_id, key_version, │
│ envelope_version │
└─────────────────────────────────────────────────────────────────┘
⚠️ L'AAD du niveau 3 est ce qui fait echouer un wrapped_key presente a une
autre cle ou par un autre locataire : GCM refuse de l'authentifier. Ce n'est
pas un controle applicatif que l'on pourrait contourner.Algorithmes
| Algorithme | Paramètres | Où |
|---|---|---|
| AES-256-GCM | clé 256 bits, IV 96 bits, tag 128 bits | Chiffrement de votre champ, dans votre processus |
| AES-256-GCM | AAD = locataire + clé + version | Emballage de la clé de données par la clé du locataire |
| AES-KWP | CKM_AES_KEY_WRAP_PAD, NIST SP 800-38F | Emballage de la clé du locataire par la clé racine, dans le module |
| CSPRNG | crypto/rand, crypto.randomBytes, os.urandom | Tirage de la clé de données et de l’IV, chez vous |
Le module de sécurité est aujourd’hui logiciel, conforme PKCS#11. Un module matériel est prévu, il n’est pas en place : c’est une différence qui compte dans un dossier de conformité, et l’écrire autrement vous exposerait.
Le mode serveur, et pourquoi il existe
Un service qui ne peut pas exécuter de cryptographie côté client existe : un environnement contraint, un langage sans bibliothèque disponible, une équipe qui intègre en quelques heures. Pour ces cas, MAFATE peut chiffrer lui-même, sur demande auprès du support.
Ce mode a un coût, et il n’est pas cosmétique : le champ en clair transite par notre API. Il n’y est ni stocké ni journalisé, mais il y passe, et votre analyse d’impact comme votre dossier HDS doivent le refléter. C’est la raison pour laquelle il n’est plus le mode par défaut.
MODE SERVEUR : refuse par defaut, ouvert sur demande
Votre application MAFATE API Votre base
│ │ │
│ POST /v1/encrypt │ │
│ { plaintext: "Jean Dupont" } │ │
│ ─────────────────────────────>│ ⚠️ le clair transite ici │
│ │ [chiffrement AES-256-GCM] │
│ { ciphertext, wrapped_key, │ [le clair est oublie] │
│ iv, key_id, key_version } │ │
│ <─────────────────────────────│ │
│ │ │
│ INSERT INTO users │ │
│ ──────────────────────────────────────────────────────────────>
Le clair n'est ni stocke ni journalise, mais il TRANSITE. C'est cette
difference que votre dossier de conformite doit refleter.Ce que le chiffrement ne change pas
Le mode enveloppe empêche votre clair d’atteindre nos serveurs. C’est beaucoup, et c’est tout ce qu’il fait : le sur-vendre serait vous exposer devant un auditeur.
- •Il n'apporte aucune certification. ANSSI, SecNumCloud, HDS et ISO 27001 portent sur une organisation et des audits, pas sur le trajet d'une donnée.
- •Il ne change rien au module de sécurité, qui reste logiciel.
- •Il ne vous sort pas du RGPD : vous restez responsable de traitement, avec vos registres et vos analyses d'impact.
- •Il ne protège pas un stockage négligent de votre côté. Chiffré et clé emballée dans le même dépôt sans contrôle d'accès, le risque est reconstitué.
- •Il ne protège pas d'une compromission de votre application : un attaquant qui exécute du code chez vous voit le clair avant chiffrement.
- •Il ne couvre pas /v1/hash, qui reçoit le clair du champ que vous rendez cherchable, dans les deux modes.