Chiffrement côté client : guide développeur

Ce que signifie le chiffrement côté client

Le chiffrement côté client signifie que le texte clair ne quitte jamais l'appareil sur lequel il a été créé. Le chiffrement et le déchiffrement se déroulent dans le navigateur, l'application mobile ou la machine de l'utilisateur – pas sur un serveur.

En pratique, un système web côté client ressemble à ceci : l'utilisateur saisit des données, le navigateur dérive ou importe une clé de chiffrement, chiffre localement avec Web Crypto, et seul le texte chiffré est transmis, stocké ou partagé.

Le résultat est une architecture zéro connaissance : le fournisseur de services ne peut pas lire les données, même si sa base de données est volée, si ses journaux font l'objet d'une assignation ou si son infrastructure est compromise.

C'est différent de TLS. TLS protège les données en transit entre le navigateur et le serveur, mais le serveur voit le texte clair. Le chiffrement côté client protège les données au repos et contre le serveur lui-même.

Le modèle de menace : ce qu'il protège, ce qu'il ne protège pas

• Protège : les données au repos sur un serveur auquel vous ne faites pas confiance – stockage cloud, backends de synchronisation, documents partagés
• Protège : les données en transit qui seraient autrement lisibles par des intermédiaires ayant accès au transport
• Protège : les violations de bases de données, les employés malveillants, les assignations contre le fournisseur
• Ne protège PAS : un navigateur compromis, les extensions de navigateur malveillantes, les keyloggers ou les enregistreurs d'écran sur l'appareil de l'utilisateur
• Ne protège PAS : le terminal lui-même – si un logiciel malveillant s'exécute en tant qu'utilisateur, il peut lire les données avant chiffrement ou après déchiffrement
• Ne protège PAS : les phrases de passe faibles ou les clés mal gérées – la cryptographie ne vaut que ce que vaut l'hygiène des clés

API Web Crypto : les primitives dont vous avez besoin

L'API Web Crypto (crypto.subtle) fournit des opérations cryptographiques standard et auditées dans tous les navigateurs modernes. Elle s'exécute dans le même processus que la page, mais les opérations elles-mêmes sont implémentées et examinées par l'éditeur du navigateur.

Utilisez-la plutôt que les bibliothèques JavaScript de cryptographie : les implémentations natives sont plus rapides et moins susceptibles de contenir des bugs subtils, et elles prennent en charge le stockage de clés adossé au matériel quand il est disponible.

Les primitives qui comptent pour le chiffrement côté client :

• AES-256-GCM – chiffrement authentifié des payloads, le choix par défaut pour le chiffrement de texte et de fichiers
• PBKDF2 – dérive une clé d'une phrase de passe avec un coût configurable
• HKDF – dérive plusieurs clés d'une seule entrée à forte entropie
• RSA-OAEP – chiffrement asymétrique quand vous devez chiffrer vers une clé publique sans secret partagé
• ECDH – accord de clé pour dériver un secret partagé entre deux parties
• crypto.getRandomValues – aléa cryptographiquement sécurisé pour sels, IV et nonces

Comment fonctionne un système basé sur phrase de passe

// Encrypt with Web Crypto (WebCrypto is available in all modern browsers)
const enc = new TextEncoder();
const salt = crypto.getRandomValues(new Uint8Array(16));
const iv = crypto.getRandomValues(new Uint8Array(12));
const keyMaterial = await crypto.subtle.importKey(
  'raw', enc.encode('passphrase'), 'PBKDF2', false, ['deriveKey']
);
const key = await crypto.subtle.deriveKey(
  { name: 'PBKDF2', salt, iterations: 600000, hash: 'SHA-256' },
  keyMaterial, { name: 'AES-GCM', length: 256 }, false, ['encrypt', 'decrypt']
);
const ciphertext = await crypto.subtle.encrypt(
  { name: 'AES-GCM', iv }, key, enc.encode('plaintext')
);
// Store salt + iv + ciphertext together

1. Générez un sel aléatoire et un IV aléatoire de 12 octets pour chaque opération de chiffrement.
2. Dérivez une clé de 256 bits de la phrase de passe avec PBKDF2 et un nombre d'itérations élevé (600 000+ pour SHA-256 selon les orientations OWASP).
3. Chiffrez le texte clair avec AES-256-GCM en utilisant la clé dérivée et l'IV.
4. Concaténez et stockez : sel, IV et texte chiffré (avec le tag d'authentification GCM).
5. Pour déchiffrer, redérivez la clé de la phrase de passe et du sel stocké, puis déchiffrez – le tag GCM échoue si le texte chiffré ou la phrase de passe est incorrect.

La gestion des clés est la partie difficile

L'algorithme est normalisé ; c'est la gestion des clés que les systèmes échouent. Une clé stockée à côté du texte chiffré, une phrase de passe écrite dans le code source ou une clé réutilisée entre documents compromettent toutes le chiffrement.

Directives qui s'appliquent à toute conception côté client :

Un IV ou nonce aléatoire frais pour chaque chiffrement – ne réutilisez jamais un IV avec la même clé

Un sel aléatoire unique par dérivation de clé, pour que des phrases de passe identiques ne produisent pas des clés identiques

Des itérations PBKDF2 élevées ou un KDF à dureté mémoire comme scrypt ou Argon2 pour les clés dérivées de phrases de passe

Ne stockez jamais les phrases de passe ou clés dérivées dans le source, localStorage ou les paramètres d'URL

Prévoyez un scénario de récupération : si la clé est perdue, les données sont irrécupérables – communiquez-le clairement aux utilisateurs

Soutenez la rotation des clés par conception : versionnez le matériau de clé et rechiffrez lors d'un changement de clé

Quand le chiffrement côté client est le mauvais outil

• Un traitement côté serveur est requis – recherche, statistiques, rapports rendus par le serveur
• Vous ne pouvez pas garantir l'environnement client (webviews embarquées, appareils non fiables)
• Les données doivent être récupérables quand les utilisateurs perdent leurs clés, et vous n'avez aucun scénario de dépôt de clé acceptable
• La menace est une compromission du terminal – le chiffrement ajoute peu si un logiciel malveillant s'exécute sur la même machine
• La conformité exige l'auditabilité du traitement du texte clair par le fournisseur

Liste de vérification pour l'implémentation en production

• Utilisez AES-256-GCM (ou ChaCha20-Poly1305) pour les payloads symétriques – jamais ECB, jamais CBC non authentifié
• Générez les IV/nonces avec crypto.getRandomValues, 12 octets pour GCM, jamais réutilisés
• Dérivez les clés de phrases de passe avec PBKDF2 (600 000+ itérations SHA-256) ou Argon2id/scrypt quand disponible
• Authentifiez les données associées (AAD) qui ne doivent pas être chiffrées mais doivent être inviolables, comme les numéros de version
• Stockez sel, IV et texte chiffré ensemble dans un format de conteneur documenté et versionné
• Échouez fermé : toute défaillance d'intégrité au déchiffrement interrompt l'opération
• Ne journalisez jamais le texte clair, les clés ou les phrases de passe – y compris dans les messages d'erreur
• Testez la rotation des clés, la récupération après perte de clé et les cas limites d'entrée vide
• Définissez une CSP stricte pour que la page elle-même ne puisse pas être modifiée par des scripts injectés
• Auditez le code et conservez un modèle de menace écrit à ses côtés

FAQ

Références

• API W3C Web Cryptography : https://www.w3.org/TR/WebCryptoAPI/
• NIST SP 800-38D – Galois/Counter Mode (GCM) : https://csrc.nist.gov/pubs/sp/800/38/d/final
• NIST SP 800-132 – Dérivation de clé par mot de passe (PBKDF2) : https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-132.pdf
• RFC 5116 – Chiffrement authentifié : https://www.rfc-editor.org/rfc/rfc5116
• Aide-mémoire OWASP sur le stockage des mots de passe : https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html