Chiffrer un fichier avant l’envoi

Chiffrez un fichier avec AES-256-GCM dans le chiffreur AES-256-GCM. La clé ne quitte jamais votre navigateur et le fichier est traité localement.

Ce que couvre le chiffrement cloud, et ce qu’il ne couvre pas

Les fournisseurs cloud chiffrent les données au repos. Cela protège le disque physique et la couche de stockage, mais dans la plupart des produits grand public, le fournisseur détient les clés et peut lire le texte en clair lorsqu’il sert un fichier à votre compte.

Les risques qui subsistent sont concrets : un compte détourné, un cookie de session volé, un client de synchronisation qui copie un dossier dont vous aviez oublié qu’il était partagé, ou un outil d’assistance capable d’accéder à vos données. Chiffrer avant l’envoi déplace la frontière de confiance : le cloud stocke des octets qu’il ne peut pas lire.

Cela ne protège pas un appareil déjà compromis, un mot de passe faible qui verrouille le fichier chiffré, ni une clé rangée à côté du texte chiffré. Le chiffrement est une couche, pas un programme de sécurité complet.

Remarque: Chiffrer un fichier ne cache ni sa taille, ni l’heure de l’envoi, ni le fait que vous avez envoyé quelque chose. Cela cache le contenu, pas les métadonnées.

Utiliser un chiffrement authentifié

AES-256-GCM est un choix par défaut raisonnable pour chiffrer des fichiers. Il combine confidentialité et intégrité : si un seul octet du texte chiffré est modifié, le déchiffrement échoue au lieu de renvoyer un texte corrompu.

GCM exige un nonce unique pour chaque chiffrement avec la même clé. Un nonce aléatoire de 96 bits est la norme. Ne réutilisez jamais un nonce avec la même clé ; avec des nonces aléatoires, la probabilité de collision reste négligeable pour un nombre normal de fichiers.

La clé doit provenir d’un mot de passe fort via une fonction de dérivation lente comme PBKDF2, ou d’un fichier de clé aléatoire. AES-CBC sans MAC séparé, les schémas XOR bricolés et les algorithmes dissimulés dans un tableur ne remplacent pas cela. Le guide du chiffrement AES en production détaille le choix du mode et de la clé.

Algorithme : AES-256-GCM avec un nonce aléatoire de 96 bits.
Intégrité : l’étiquette d’authentification doit être vérifiée avant d’utiliser le texte en clair.
Dérivation de clé : PBKDF2 avec un grand nombre d’itérations, ou une clé aléatoire de 256 bits.
Stockage du nonce : avec le texte chiffré ; il n’est pas secret, mais doit être unique.

Chiffrer avant que le fichier ne quitte votre appareil

Ouvrez le chiffreur AES-256-GCM et choisissez le mode fichier.
Sélectionnez le fichier. Il est lu localement et jamais envoyé.
Utilisez une phrase de passe solide, ou générez-en une et rangez-la dans un gestionnaire de mots de passe.
Chiffrez et téléchargez le fichier chiffré. L’original reste intact.
Exportez le fichier de clé si l’outil le propose, et stockez-le ailleurs que le texte chiffré.
N’envoyez que le fichier chiffré vers le stockage cloud.
Téléchargez-le une fois et déchiffrez-le pour confirmer que la sauvegarde fonctionne avant de supprimer l’original local.

Avertissement: Si vous perdez la phrase de passe et le fichier de clé, les données sont perdues. Aucun service de récupération n’existe pour un fichier chiffré localement.

La gestion des clés est la partie difficile

Le chiffrement est généralement l’étape facile. Le point de défaillance, c’est la gestion des clés : une clé enregistrée dans le même dossier cloud, une phrase de passe réutilisée d’un autre compte, ou une copie unique sur un ordinateur portable qui rend l’âme. Pour les secrets stockés dans un dépôt, chiffrer les fichiers .env avant commit applique la même règle.

Gardez au moins deux copies de la clé à des endroits distincts, par exemple un gestionnaire de mots de passe et une sauvegarde hors ligne. N’envoyez pas la clé chez le même fournisseur que le texte chiffré. Si le compte cloud est compromis, l’attaquant ne récupère qu’un fichier qu’il ne peut pas ouvrir.

En équipe, décidez qui peut déchiffrer et comment les clés sont renouvelées avant le premier envoi. Renouveler une clé suppose de déchiffrer puis de rechiffrer chaque fichier qui l’utilisait ; prévoyez ce coût.

Ne rangez jamais la clé dans le même compartiment ou dossier que le fichier chiffré.
Utilisez une phrase de passe unique ; ne réutilisez pas un mot de passe de compte.
Conservez une copie hors ligne du fichier de clé.
Notez quelle clé correspond à quel fichier si vous renouvelez les clés.
Testez le déchiffrement sur un second appareil avant de compter sur la sauvegarde.

Noms de fichiers et synchronisation : ce qui fuit aussi

Un fichier nommé scan-passeport.pdf indique au fournisseur et à quiconque y a accès ce que contient le bloc chiffré. Renommez-le de façon neutre avant l’envoi et gardez la correspondance dans vos propres notes.

Les clients de synchronisation peuvent envoyer automatiquement un fichier dès qu’il arrive dans un dossier surveillé. Si vous utilisez Google Drive, Dropbox ou iCloud Drive, chiffrez le fichier avant de le déplacer dans ce dossier. Pour les photos, désactivez l’envoi automatique des albums sensibles, ou chiffrez d’abord et envoyez le résultat.

Remarque: L’historique des versions et les vignettes du cloud peuvent conserver des copies antérieures. Si un fichier a été envoyé en clair une fois, le supprimer aujourd’hui n’efface peut-être pas toutes les versions.

Où cette méthode s’arrête

Un navigateur chiffre en mémoire : les fichiers très volumineux sont limités par la RAM de l’appareil. Compressez d’abord un dossier dans une archive, ou découpez-le en archives plus petites, puis chiffrez chaque archive.

Un fichier chiffré ne peut être ni recherché, ni prévisualisé, ni modifié à plusieurs dans le cloud. Si une équipe doit travailler sur le document, chiffrez-le uniquement pour le stockage et déchiffrez-le dans un environnement local maîtrisé pour l’édition.

Le chiffrement ne dispense pas non plus de sauvegardes. Sauvegardez le fichier chiffré et la clé séparément, et testez le chemin de restauration.

FAQ

Q.Le chiffrement côté fournisseur ne suffit-il pas ?

A.Il protège l’infrastructure de stockage, mais dans la plupart des produits grand public, le fournisseur détient les clés et peut accéder au texte en clair. Chiffrer avant l’envoi signifie que le fournisseur ne voit jamais que du texte chiffré. En contrepartie, la clé devient votre responsabilité.

Q.Que se passe-t-il si je perds la clé ?

A.Le fichier ne peut plus être déchiffré. Il n’existe aucun recours lorsque vous chiffrez localement et gardez la clé vous-même. Stockez au moins deux copies à des endroits distincts et testez l’une d’elles avant d’en avoir besoin.

Q.Puis-je chiffrer des photos avant iCloud ou Google Photos ?

A.Oui, mais le fichier chiffré ne s’affichera pas comme une photo, et l’envoi automatique peut le copier avant que vous ayez terminé. Chiffrez d’abord, envoyez le fichier chiffré et gardez la clé hors de la photothèque. Pour les albums sensibles, désactivez l’envoi automatique.

Q.Renommer le fichier chiffré le casse-t-il ?

A.Non. Le texte chiffré contient ce qu’il faut pour le déchiffrer, à condition de conserver la clé et les métadonnées du nonce. Le nom de fichier ne fait pas partie de la charge cryptographique, mais il peut encore divulguer une information : choisissez un nom neutre.

Références

NIST SP 800-38D - Recommandation sur les modes opératoires des chiffrements par blocs : mode Galois/Counter (GCM) : https://csrc.nist.gov/pubs/sp/800/38/d/final
OWASP - Aide-mémoire sur le stockage cryptographique : https://cheatsheetseries.owasp.org/cheatsheets/Cryptographic_Storage_Cheat_Sheet.html
W3C - API Web Cryptography : https://www.w3.org/TR/WebCryptoAPI/
RFC 8018 - PKCS #5 : spécification de la cryptographie basée sur mot de passe, version 2.1 : https://www.rfc-editor.org/rfc/rfc8018