Cryptographie côté client : bonnes pratiques

La violation de données qui a tout changé

En 2019, un gestionnaire de mots de passe populaire a été piraté. Des millions de coffres d'utilisateurs ont été volés. Mais voici le rebondissement : les pirates n'ont rien obtenu d'utile. Chaque coffre était chiffré avec AES-256 et l'entreprise n'a jamais détenu les clés de déchiffrement.

C'est la puissance de la cryptographie côté client. Même lorsque les serveurs sont compromis, vos données restent sécurisées car elles ont été chiffrées avant de quitter votre appareil.

La plupart des services en ligne fonctionnent à l'inverse. Vous envoyez vos données à leurs serveurs, ils les traitent, les stockent et, espérons-le, les protègent. Quand ils sont piratés, vos données sont exposées. La cryptographie côté client inverse ce modèle.

Qu'est-ce que la cryptographie côté client ?

La cryptographie côté client signifie que tout le chiffrement et le déchiffrement se déroulent dans votre navigateur ou votre appareil, avant que les données ne soient envoyées à un serveur.

Pensez-y comme à une enveloppe scellée. Vous écrivez une lettre, la scellez dans une enveloppe, puis la confiez à un coursier. Le coursier peut la livrer mais pas la lire. Le serveur est le coursier – il gère vos données chiffrées mais ne peut pas les déchiffrer.

C'est fondamentalement différent du chiffrement côté serveur, où vous envoyez du texte clair à un serveur et lui faites confiance pour le chiffrer. Avec le chiffrement côté client, vous n'avez jamais à confier vos données non chiffrées au serveur.

Pourquoi la cryptographie côté client compte

Les bénéfices de la cryptographie côté client vont au-delà de la seule sécurité :

• Vraie confidentialité des données – Le fournisseur de services ne peut pas lire vos données, point final. Ni pour la publicité, ni pour les statistiques, ni parce qu'un employé est curieux.
• Protection contre les violations – Si les serveurs sont piratés, les attaquants obtiennent des blobs chiffrés calculatoirement irréalisables à casser.
• Protection juridique – Le fournisseur ne pouvant pas déchiffrer vos données, il ne peut pas être contraint de les remettre lors de procédures judiciaires.
• Conformité réglementaire – Aide à respecter le RGPD, le CCPA et d'autres réglementations sur la confidentialité par conception.
• Contrôle de l'utilisateur – Vous détenez les clés. Vous décidez qui peut accéder à vos données.

Comment fonctionne le chiffrement côté client

Le processus est d'une simplicité élégante :

1. Vous saisissez des données dans votre navigateur – texte, fichiers, mots de passe, n'importe quoi.
2. Le navigateur génère une clé de chiffrement à partir de votre mot de passe avec une fonction de dérivation de clé comme PBKDF2 ou Argon2.
3. Les données sont chiffrées avec AES-256-GCM ou un autre algorithme robuste, entièrement dans votre navigateur.
4. Seules les données chiffrées sont envoyées au serveur. Le serveur les stocke mais ne peut pas les déchiffrer.
5. Lorsque vous souhaitez accéder à vos données, le blob chiffré est renvoyé à votre navigateur.
6. Votre navigateur les déchiffre localement avec votre mot de passe. Le texte clair ne quitte jamais votre appareil.

La technologie derrière : l'API Web Crypto

Les navigateurs modernes intègrent des capacités cryptographiques natives appelées Web Crypto API. Ce n'est pas une bibliothèque à télécharger – c'est une partie du navigateur lui-même, écrite en code natif hautement optimisé.

L'API Web Crypto fournit les mêmes algorithmes que ceux utilisés par les gouvernements et les banques : AES-256, RSA, SHA-256 et plus. Elle est plus rapide et plus sûre que les bibliothèques JavaScript de cryptographie car elle s'exécute au niveau natif et est protégée contre les attaques temporelles.

Et surtout, elle fonctionne entièrement hors ligne. Une fois la page chargée, vous pouvez chiffrer et déchiffrer sans aucune connexion réseau. Vos données ne quittent jamais votre appareil, sauf si vous choisissez d'envoyer la version chiffrée.

Implémenter le chiffrement côté client

Voici un exemple complet de chiffrement côté client avec l'API Web Crypto :

// Client-side encryption using Web Crypto API
class ClientCrypto {
  async deriveKey(password, salt) {
    const encoder = new TextEncoder();
    const keyMaterial = await crypto.subtle.importKey(
      'raw', encoder.encode(password), 'PBKDF2', false, ['deriveKey']
    );
    return crypto.subtle.deriveKey(
      { name: 'PBKDF2', salt, iterations: 100000, hash: 'SHA-256' },
      keyMaterial, { name: 'AES-GCM', length: 256 }, false, ['encrypt', 'decrypt']
    );
  }
  async encrypt(plaintext, password) {
    const salt = crypto.getRandomValues(new Uint8Array(16));
    const iv = crypto.getRandomValues(new Uint8Array(12));
    const key = await this.deriveKey(password, salt);
    const encoder = new TextEncoder();
    const ciphertext = await crypto.subtle.encrypt(
      { name: 'AES-GCM', iv }, key, encoder.encode(plaintext)
    );
    return { ciphertext, iv, salt };
  }
  async decrypt(encryptedData, password) {
    const { ciphertext, iv, salt } = encryptedData;
    const key = await this.deriveKey(password, salt);
    const decrypted = await crypto.subtle.decrypt(
      { name: 'AES-GCM', iv }, key, ciphertext
    );
    return new TextDecoder().decode(decrypted);
  }
}
// Usage
const crypto = new ClientCrypto();
const encrypted = await crypto.encrypt('Secret data', 'password123');
// Send encrypted data to server...
const decrypted = await crypto.decrypt(encrypted, 'password123');

// Open DevTools (F12) and run this before encryption:
console.log('Starting encryption test...');
const startTime = performance.now();
// Perform encryption
const encrypted = await encryptData('test data', 'password');
const endTime = performance.now();
console.log(`Encryption took ${endTime - startTime}ms`);
console.log('Check Network tab - no requests should appear');
// Verify in Network tab (F12 → Network)
// If no new requests appear, your data stayed local!

Bonnes pratiques pour le chiffrement côté client

Pour tirer le maximum de sécurité de la cryptographie côté client :

• Utilisez des mots de passe forts – Le chiffrement côté client ne vaut que ce que vaut votre mot de passe. Utilisez une phrase de passe de 5 mots aléatoires ou plus, ou 16+ caractères mélangés.
• Ne perdez jamais votre mot de passe – Il n'y a pas de réinitialisation. Si vous l'oubliez, vos données sont perdues pour toujours. Utilisez un gestionnaire de mots de passe.
• Vérifiez le code – Pour les applications critiques, examinez le JavaScript ou utilisez des extensions de navigateur qui vérifient que le code n'a pas changé.
• Vérifiez le HTTPS – Assurez-vous toujours que le site utilise HTTPS pour empêcher les attaques de l'homme du milieu sur le code lui-même.
• Conservez des sauvegardes – Les données chiffrées sont sûres mais peuvent être perdues. Gardez des sauvegardes des données chiffrées et du mot de passe (séparément).

Limites et considérations

La cryptographie côté client est puissante mais ce n'est pas une solution magique. Voici ce qu'elle ne peut pas faire :

• Pas de récupération de mot de passe – Si vous oubliez votre mot de passe, personne ne peut vous aider. C'est voulu, mais cela exige de la discipline.
• Dépendance au navigateur – Vous avez besoin d'un navigateur moderne avec JavaScript activé. Certains environnements d'entreprise bloquent cela.
• Limites de performance – Les gros fichiers (Go et plus) peuvent faire planter les navigateurs à cause des limites de mémoire. Utilisez des applications de bureau pour les très gros fichiers.
• Fiez-vous au chargement initial – Vous devez faire confiance au fait que le code JavaScript chargé initialement n'est pas malveillant. C'est pourquoi HTTPS et la signature de code comptent.
• Ne protège pas contre les logiciels malveillants – Si votre appareil a un keylogger, il peut capturer votre mot de passe quand vous le tapez.

Préparation post-quantique en 2026

La plus grande menace à long terme pour la cryptographie actuelle est un futur ordinateur quantique à grande échelle. En août 2024, le NIST a finalisé trois normes post-quantiques : ML-KEM (FIPS 203) pour l'encapsulation de clés, ML-DSA (FIPS 204) et SLH-DSA (FIPS 205) pour les signatures.

L'adoption est déjà en cours : les principaux navigateurs et bibliothèques TLS ont déployé ou déploient l'échange de clés hybride (X25519Kyber768), protégeant ainsi les connexions contre les attaques classiques et quantiques sans rien changer pour vous.

Pour des outils comme celui-ci, la recommandation pratique pour 2026 est simple : continuez à utiliser des algorithmes éprouvés (AES-256-GCM, SHA-256/512, HMAC et RSA-2048/4096 pour l'échange de clés actuel), suivez les mises à jour de prise en charge post-quantique et n'implémentez jamais votre propre cryptographie. Le projet de transition post-quantique du NIST est la référence à suivre. Vous pouvez examiner les tailles et formats de clés dans notre générateur de clés RSA pour voir ce qu'impliquerait une migration.

Questions fréquentes

Références

• API W3C Web Cryptography : https://www.w3.org/TR/WebCryptoAPI/
• NIST SP 800-57 – Recommandation pour la gestion des clés : https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final