Ce qu’un fournisseur cloud, le client de synchro et le hash de contenu voient encore après l’envoi d’un fichier non chiffré

Déposer un fichier dans un Drive n’est pas un coffre : c’est une remise

Le stockage cloud grand public se laisse facilement prendre pour le coffre-fort de la maison : le fichier est encore « à moi », donc personne d’autre ne peut l’ouvrir. Une fois le fichier déposé, ces octets ont quitté le dossier de ce disque. Ils deviennent un objet que le fournisseur stocke, synchronise, déduplique et — souvent — indexe pour l’aperçu. Une déclaration fiscale, un scan de pièce d’identité, une clé SSH privée, un dump de base et un tableau clients non masqué n’ont rien à faire en clair dans un système de stockage et de recherche tiers.

HTTPS ne couvre que l’écoute sur le chemin. Il ne décide pas comment l’autre système stocke le fichier, qui tient les clés, ce que le client de synchro met en cache sur cette machine, ni si un lien de partage rend du chiffré ou du clair reconstitué. La note précédente décrivait une remise voisine : une clé collée dans une session de modèle entre dans l’historique et la conservation. Un fichier non chiffré déposé dans un Drive appartient à la même classe d’exposition. Le destinataire n’est plus un éditeur de modèle ; c’est un hébergeur, plus ses chemins de synchro, d’aperçu et de déduplication. Avant l’envoi, la question n’est pas « ce Drive est-il malin ». C’est « cette copie contient-elle quelque chose qui ne doit pas quitter cet appareil en clair ».

Cette note s’en tient à AWS S3, Google Drive / Google Cloud et iCloud, parce que ces fournisseurs écrivent les couches dans une langue que vous pouvez relire. Un Drive grand public, un Nextcloud auto-hébergé ou un kDrive francophone écrivent rarement « qui tient les clés » dans la même phrase. Le modèle technique reste souvent le même : TLS sur le fil, chiffrement au repos avec des clés chez le fournisseur, puis miniatures, recherche plein texte ou envoi instantané par-dessus. Changez de produit, relisez la page sécurité de ce fournisseur. Ne collez pas SSE-S3 ni la « protection standard des données » sur une autre marque.

HTTPS, chiffrement au repos et connaissance nulle : trois cadenas différents

Entendre « le Drive est-il chiffré » comme une question oui/non fait tomber au moins trois couches. La première est le chiffrement en transit. Le navigateur ou le client de synchro envoie les octets en TLS. Le chemin du milieu ne voit pas le clair. Cette couche est presque toujours active, et c’est la seule chose que le cadenas de la barre d’adresse promet vraiment.

La deuxième est le chiffrement au repos — le chiffrement côté serveur. La définition AWS du chiffrement côté serveur S3 est nette : les données sont chiffrées à destination par le service qui les reçoit ; S3 chiffre à l’écriture sur les disques des centres de données AWS et déchiffre quand vous accédez à l’objet. Depuis le 5 janvier 2023, chaque nouvel envoi utilise par défaut SSE-S3 (clés gérées par Amazon S3). L’algorithme est AES-256, chaque objet a sa propre clé, AWS fait tourner la clé racine. Tant que la requête est authentifiée et autorisée, « l’accès à un objet chiffré ne diffère pas de l’accès à un objet non chiffré ». Une URL pré-signée vaut pour les deux. La liste des objets ne distingue pas non plus le chiffré du non chiffré. Autrement dit : cette couche protège un disque volé. Elle ne veut pas dire « AWS ne peut pas ouvrir votre fichier ».

La formulation publique de Google pour Drive va dans le même sens. L’aide Drive écrit : « Qu’ils soient en transit ou au repos, tous les fichiers importés dans Drive ou créés dans Docs, Sheets ou Slides sont chiffrés selon la norme AES 256 bits. » Une confidentialité supplémentaire exige le chiffrement côté client Workspace, et ce chemin demande un compte professionnel ou scolaire dont l’administrateur a activé l’option. Ce n’est qu’après ce commutateur que Google écrit « Google ne peut pas les déchiffrer ». La couche par défaut ne le dit pas. Le chiffrement au repos par défaut de Google Cloud est plus direct : « Nous possédons et gérons les clés utilisées pour le chiffrement au repos par défaut. » Si vous restez sur ce défaut, vous ne tenez pas ces clés ; le tableau officiel indique aussi que le contrôle de la rotation des clés n’est pas côté client.

Apple sépare le défaut et l’option. La présentation de la sécurité des données iCloud (mise à jour le 5 janvier 2026) écrit que la protection standard des données est le réglage par défaut du compte : les données sont chiffrées, et les clés restent dans les centres de données Apple afin qu’Apple puisse vous aider à les récupérer. Seules certaines catégories sont chiffrées de bout en bout par défaut. Le décompte d’Apple est précis : 15 catégories le sont toujours, dont Santé et le trousseau iCloud. La protection avancée des données, facultative, porte ce nombre à 25 et y ajoute la sauvegarde iCloud, Photos, Notes et iCloud Drive. Si vous la désactivez, Apple écrit : « Votre appareil téléversera les clés de chiffrement requises sur les serveurs d’Apple en toute sécurité. » Le défaut n’est pas « Apple ne peut pas non plus ouvrir les fichiers d’iCloud Drive ».

Ce qu’un fournisseur peut encore faire quand il tient les clés

Un fournisseur capable de déchiffrer n’est pas une phrase d’effroi. C’est la prémisse dont les fonctions par défaut ont besoin. L’aperçu PDF en ligne, les miniatures photo, l’OCR, la recherche plein texte et le tri « par type » exigent qu’un serveur voie le contenu, ou au moins un index en clair qui en dérive. Google écrit le coût du chiffrement côté client dans la même page d’aide : les Docs, Sheets et Slides chiffrés ne se modifient pas dans les applications mobiles, n’acceptent pas les commentaires Drive, n’ont pas de saisie vocale et perdent plusieurs modules ; les fichiers des éditeurs chiffrés plafonnent à 100 Mo ; l’historique des versions conserve au plus 100 versions. Ces limites existent pour une raison concrète : le serveur ne tient plus une clé qui ouvre le clair.

AWS écrit l’autre face avec la même clarté. Quand vous partagez un objet avec une URL pré-signée, l’accès du destinataire ressemble à celui d’un objet non chiffré. SSE-S3 ne transforme pas « la personne qui a ouvert le lien » en « chiffré seulement ». Il arrête « qui est parti avec un disque ». Un compte volé, un lien de partage fuité, un administrateur d’entreprise qui tire une copie, une réquisition légale : tout cela emprunte le chemin « accès autorisé ». Le chiffrement au repos par défaut laisse ce chemin passer.

Les Drive grand public ajoutent une couche : le client de synchro. Le fichier apparaît d’abord dans un dossier local, puis part. Même si le cloud écrit ensuite un chiffrement au repos, cet ordinateur, un autre ordinateur déjà connecté à la maison, et les caches hors ligne d’un téléphone peuvent chacun garder une copie en clair. Fermer un onglet du navigateur n’efface pas un fichier déjà tombé dans le dossier de synchro.

Dans la presse francophone, la question « qui tient les clés » se mélange souvent au CLOUD Act ou au RGPD. Cette note ne tranche pas le droit applicable. Elle s’arrête à ce que les pages sécurité des fournisseurs écrivent déjà : tant que les clés restent chez eux, un accès autorisé — administrateur, lien de partage, procédure légale — peut retrouver le clair. Changer de juridiction n’est pas la même opération que changer de dépositaire de clés.

Caches de synchro, aperçus, hash de contenu et liens de partage : d’autres copies

Entendre « envoi terminé » comme « une seule copie, dans le cloud » rate des copies des deux côtés. La première est la copie de travail du client de synchro : la file d’envoi, le cache de nouvelle tentative, les restes d’un conflit de version. La deuxième est un fichier dérivé que le serveur construit pour l’aperçu : une miniature, une vidéo transcodée, du texte OCR. Ces objets vivent souvent à part de l’original. Supprimer l’original n’emporte pas toujours le dérivé au même instant.

La troisième est un hash de contenu. Beaucoup de Drive hachent le fichier entier, ou chaque bloc, et s’en servent pour l’envoi instantané et la déduplication : le client envoie d’abord le hash ; si le serveur l’a déjà, les octets ne voyagent plus. C’est commode pour un fichier non chiffré. Cela admet aussi que « le même clair n’existe qu’une fois dans le système ». Envoyez un installeur non chiffré ou un PDF public, et le serveur peut confirmer que vous le détenez à partir du hash seul. Envoyez le même contrat interne depuis plusieurs bureaux, et la déduplication stocke encore un seul objet en clair. Chiffrez d’abord sur cet appareil : chaque passage utilise un salt et un IV neufs, le hash du chiffré ne correspond plus, l’envoi instantané rate. Ce n’est pas un bogue. C’est le résultat direct de « le fournisseur ne voit pas le contenu ».

Apple publie une version de ce mécanisme même sous la protection avancée des données. La même présentation iCloud indique que certaines métadonnées restent sous la protection standard : « les sommes de contrôle des données de fichiers et de photos sont utilisées pour aider Apple à dédupliquer et à optimiser votre stockage iCloud et au sein de votre appareil ». Pour iCloud Drive, cela inclut « les sommes de contrôle des octets bruts du contenu du fichier et le nom du fichier ». Un chiffrement de bout en bout sur le corps du fichier n’est pas la même chose que « Apple ne voit jamais une empreinte des octets ». Traitez de la même façon l’invite « déjà présent dans le cloud » de n’importe quel fournisseur : une correspondance de hash est une affirmation sur le contenu, pas seulement sur votre compte.

La quatrième copie est un lien de partage ou un espace d’équipe. Une fois le lien dehors, le modèle habituel est « quiconque tient le lien peut récupérer le fichier ». Combiné à la section précédente : le chiffrement au repos par défaut ne réécrit pas un téléchargement en « chiffré seulement ». Ce qui s’ouvre dans l’autre navigateur, c’est le clair reconstitué. Un « lien Drive » dans un groupe de chat et la pièce jointe elle-même n’ont pas la même surface. Savoir si le clair a quitté votre compte a souvent la même réponse.

Pourquoi un ZIP à mot de passe n’est souvent pas un chiffrement côté client

« Je le mets dans un ZIP avec mot de passe, puis je l’envoie » sonne comme un chiffrement côté client. Demandez d’abord quel chiffrement ZIP vous avez vraiment utilisé. Le chiffrement PKWARE classique (ZipCrypto) est un chiffrement par flot. En 1994, Eli Biham et Paul Kocher ont écrit dans A Known Plaintext Attack on the PKZIP Stream Cipher que ce chiffre est faible et ne devrait pas protéger des données de valeur : environ 13 à 40 octets de clair connu compressé, ou à peu près 30 à 200 octets au début d’un fichier non compressé, retrouvaient la représentation interne de la clé sur un ordinateur personnel de l’époque, en quelques heures. Le code moderne abaisse encore la barre. bkcrack documente une récupération à partir d’au moins 12 octets de clair connu (dont 8 consécutifs), ce qui restaure l’état interne puis ouvre le reste de l’archive — et les autres entrées chiffrées avec le même mot de passe. La longueur du mot de passe n’aide pas cette attaque. La cible est l’état du flux de clé, pas une devinette de votre phrase.

Même quand l’archiveur passe à AES, un ZIP peut encore laisser les noms de fichiers, l’arborescence et des commentaires d’entrée non chiffrés dans l’en-tête. Les listes de fichiers du Drive, la recherche et les filtres « par type » lisent ces métadonnées. Traiter « l’archive a un mot de passe » comme « le cloud ne voit que du bruit » rate à la fois l’en-tête et l’algorithme faible.

Une erreur opérationnelle plus fréquente : l’archive chiffrée et un readme.txt qui porte le mot de passe atterrissent dans le même dossier et partent ensemble en synchro. Le cadenas et la clé vont au même dépositaire. Le chiffrement au repos et le mot de passe ZIP échouent tous les deux dans ce cas.

Ce qui change quand vous chiffrez d’abord sur l’appareil

Le chiffrement côté client a un test étroit : le clair devient chiffré avant de quitter l’appareil ; la phrase secrète qui dérive la clé n’est pas envoyée à l’hébergeur ; l’hébergeur ne peut pas ouvrir le fichier en fonctionnement normal. Google décrit le chiffrement côté client Workspace comme « de bout en bout et entre les clients », et nomme « Google ne peut pas les déchiffrer ». C’est une couche supplémentaire qu’un administrateur active. Ce n’est pas le défaut d’un Drive personnel gratuit. Chiffrer vous-même, puis envoyer, marche sur la même frontière. Les clés restent dans votre phrase secrète et sur votre appareil. Vous ne dépendez pas de la présence d’un interrupteur « chiffrement côté client » chez un Drive donné.

Un chemin vérifiable dans le navigateur, c’est Web Crypto AES-GCM, pas un XOR maison. Les notes MDN sur AesGcmParams s’alignent sur NIST SP 800-38D : sous une même clé, l’IV doit être unique à chaque fois ; la spécification recommande un IV de 96 bits (12 octets) ; l’IV n’a pas besoin d’être secret et peut rester en clair à côté du chiffré. Le NIST insiste lourdement sur l’unicité : réutiliser un IV sous la même clé peut permettre une falsification, et cette exigence pèse presque autant que le secret de la clé. L’étiquette d’authentification vaut par défaut 128 bits (16 octets). Une mauvaise phrase secrète ou un chiffré altéré doit échouer fermé, pas émettre un clair cassé.

Le coffre de fichiers MakePwd implémente cette frontière : AES-256-GCM par blocs dans l’onglet courant, une phrase secrète étirée avec PBKDF2-HMAC-SHA256 et 100 000 itérations, un salt de 16 octets neuf par fichier, un IV de 12 octets neuf par bloc, et une sortie écrite IV + chiffré + étiquette de 16 octets. Un fichier peut aller jusqu’à 5 Go. Le bloc par défaut fait 1 Mo, pour ne pas lire le fichier entier en mémoire d’un coup. La sortie est .lock ou .enc, même format binaire. Le fichier et la phrase secrète ne sont pas envoyés. Tous les outils s’ouvrent sans compte, et il n’y a pas de coffre de mots de passe qui stockerait la phrase pour vous. La page répond à « ceci peut-il devenir du chiffré avant de quitter le navigateur ». Elle n’envoie pas le fichier vers un Drive à votre place.

Contrôle sur place : le canari n’entre jamais dans la file d’envoi

Un slogan « rien n’est envoyé » ne se prouve pas tout seul. Coupez le contrôle en deux. D’abord confirmer que l’étape de chiffrement n’a pas envoyé le clair comme donnée métier. Ensuite confirmer que l’objet remis au Drive est bien du chiffré.

1. Créez un fichier texte avec une phrase qui n’apparaîtra jamais dans un vrai flux, par exemple canary-cloud-20260902-only-once. Le nom de fichier peut porter le canari aussi. Utilisez une longue phrase secrète à usage unique, pas un mot de passe réutilisé.
2. Ouvrez la page de chiffrement de fichier dans le navigateur. Ouvrez les outils de développement, passez sur Network, cochez Preserve log. Choisissez le fichier, saisissez la phrase secrète, téléchargez le .lock. Collez le canari dans le filtre : il ne doit apparaître ni sur une ligne de requête, ni dans un corps, ni dans une analyse. La phrase secrète non plus.
3. Ouvrez le .lock téléchargé dans un visualiseur hexadécimal ou un éditeur. L’en-tête doit montrer une magie fixe, pas la phrase canari. Une mauvaise phrase secrète doit échouer et ne doit pas écrire un fichier clair cassé.
4. Si vous voulez encore une copie sur votre propre Drive, envoyez le .lock, pas l’original. Après la fin de l’envoi, cherchez dans l’aperçu du Drive : le corps lisible ne doit pas apparaître. Ne mettez pas la phrase secrète dans le même dossier de synchro.

La première moitié — ligne de requête, corps, analyses — est le même contrôle que Chiffrer dans le navigateur : comment vérifier que le texte en clair n’a pas quitté l’appareil. Cette note ajoute la quatrième étape : une fois l’objet hors du navigateur, la couche passe de « Web Crypto local » à « le Drive traitera-t-il ceci comme du clair ». Le canari ne doit exister que dans l’original que vous avez gardé. S’il apparaît dans un aperçu Drive ou dans une invite « déjà présent », vous avez encore envoyé une copie non chiffrée.

S’exercer sur la frontière avec un coffre qui s’ouvre sans compte

Si vous voulez « devenir du chiffré d’abord, puis décider où ça va », vous n’avez pas à vous inscrire, et vous ne remettez pas le fichier à MakePwd. Ouvrez Chiffrer un fichier, prenez un petit fichier jetable, chiffrez-le avec une longue phrase aléatoire, téléchargez le .lock, et cherchez dans Network comme ci-dessus. Quand une personne doit retenir ou recevoir la phrase secrète, tirez une chaîne aléatoire de 6 à 128 caractères dans le générateur de mot de passe (16 par défaut ; sous 8, un avertissement de force faible s’affiche), puis envisagez de l’envoyer une fois avec un lien auto-destructible plutôt que de la poser dans le même dossier Drive que le chiffré. La clé du lien auto-destructible reste dans le fragment # de l’URL. La page de lecture est publique pour le destinataire.

Chiffrer un fichier ne remplace pas l’interrupteur de chiffrement côté client d’un Drive, et ne promet pas comment l’autre produit scannera le chiffré à la recherche de maliciel ou inspectera les noms de fichiers. L’en-tête .lock porte le nom d’origine, donc le Drive peut encore voir le nom. Si le nom lui-même doit rester caché, renommez le fichier en quelque chose de sans signification avant de chiffrer. Une phrase secrète oubliée ne se récupère pas depuis le chiffré. Gardez-la quelque part que vous contrôlez.

Questions fréquentes

Si le Drive affiche « chiffré », le fournisseur peut-il encore ouvrir mes fichiers ?

Oui, en général, avec le chiffrement au repos par défaut. AWS écrit que le chiffrement côté serveur chiffre à l’écriture sur disque et déchiffre à l’accès ; une requête autorisée traite un objet chiffré comme un objet non chiffré. Google conserve les clés du chiffrement par défaut. La protection standard des données d’Apple place la plupart des clés dans ses centres de données pour pouvoir vous aider à récupérer le compte. Ce n’est pas la couche « le fournisseur ne peut pas déchiffrer ».

Un ZIP protégé par mot de passe suffit-il avant l’envoi ?

Le ZipCrypto classique, non. En 1994, Biham et Kocher ont montré qu’une douzaine d’octets de clair connu suffisent à retrouver l’état interne de la clé ; la longueur du mot de passe n’y change rien. Même un ZIP en AES peut laisser les noms de fichiers et l’arborescence en clair. Si le Drive ne doit voir que du chiffré, terminez un chiffrement authentifié sur cet appareil d’abord.

Si je chiffre d’abord, l’envoi instantané et l’aperçu fonctionnent-ils encore ?

Pas sur les octets d’origine, en général. L’envoi instantané compare un hash de contenu ; le même clair chiffré avec un salt et un IV neufs produit un autre hash. L’aperçu, les miniatures et l’OCR ont besoin du clair. C’est le coût attendu : si le fournisseur ne voit pas le contenu, il ne peut pas non plus construire un aperçu pour vous.

Puis-je laisser la phrase secrète dans le même dossier cloud que le fichier .lock ?

Non. Le chiffré et la phrase secrète dans le même compte et le même dossier de synchro remettent le cadenas et la clé au même dépositaire. Gardez la phrase dans un gestionnaire de mots de passe, ou envoyez-la une fois avec un lien auto-destructible. Une phrase oubliée ne se récupère pas depuis le fichier .lock. C’est la frontière d’une sauvegarde à connaissance nulle, pas un défaut.

Trois points à retenir avant le prochain envoi

Premier : le cadenas de la barre d’adresse et une étiquette « chiffré » couvrent le chemin et un disque volé. Ils ne couvrent ni le fournisseur, ni un administrateur, ni quiconque tient un lien de partage. Deuxième : le cache de synchro, les dérivés d’aperçu, les hash de contenu et les liens de partage peuvent chacun garder une copie ; un envoi non chiffré met du clair sur ces chemins. Troisième : si le Drive ne doit voir que des octets opaques, chiffrez sur cet appareil en AES-256-GCM vers .lock / .enc, envoyez la phrase secrète par un autre canal, puis cherchez le canari dans Network et dans l’aperçu du Drive.

Si la question suivante est de savoir si l’étape de chiffrement a envoyé le clair comme donnée métier, lisez Chiffrer dans le navigateur : comment vérifier que le texte en clair n’a pas quitté l’appareil. Quand une personne doit recevoir la phrase qui ouvre le chiffré, lisez Pourquoi le fragment après # d’une URL convient pour une clé, et quand cette protection lâche et Que reste-t-il sur le serveur après une lecture d’un lien auto-destructible. Cette note ne fait que tracer une ligne que vous pouvez écrire dans une conclusion : ce qui peut encore rester après qu’un fichier non chiffré est entré dans un Drive grand public.