Pourquoi le chiffrement au repos ne protège pas vos fichiers
Par Simon Themiot - consultant cybersécurité freelance. Publié le 19 mai 2026.
En résumé
- Le chiffrement au repos protège les supports, sauvegardes et snapshots contre certains accès directs. Il ne crée pas de barrière contre le fournisseur lorsqu'il gère aussi les clés, ni contre une compromission qui atteint l'application et le service de clés.
- Quand un service dit "vos fichiers sont chiffrés", il faut demander : qui détient la clé ? Si c'est le fournisseur, il peut lire vos fichiers.
- Le chiffrement de bout en bout (E2E) ajoute une séparation essentielle : le serveur stocke le contenu chiffré sans recevoir la clé nécessaire pour le lire.
Sommaire
1. Les 3 niveaux de chiffrement des services cloud
Quand un service de partage de fichiers annonce que vos données sont "chiffrées", cela peut désigner trois choses très différentes :
Niveau 1 : Chiffrement en transit (TLS)
Vos fichiers sont protégés pendant le trajet entre votre navigateur et le serveur (HTTPS/TLS). C'est le socle attendu de tout service web sérieux. Cela ne protège pas les fichiers une fois arrivés sur le serveur. Analogie : un fourgon blindé qui livre votre colis, mais le dépose dans un entrepôt dont l'exploitant peut ouvrir la porte.
Niveau 2 : Chiffrement au repos (server-side)
Le serveur chiffre vos fichiers une fois reçus, avec des clés qu'il gère. Cette couche protège notamment les disques, sauvegardes et snapshots contre certains accès directs. Elle ne protège pas à elle seule contre : un accès applicatif autorisé, un administrateur disposant des droits, une réquisition valide ou une compromission conjointe de l'application et des clés. Analogie : votre colis est dans un coffre, mais l'exploitant en a la clé.
Niveau 3 : Chiffrement de bout en bout (E2E / zero-knowledge)
Votre navigateur chiffre le fichier avant tout envoi. La clé est transmise au destinataire sans passer par le serveur, par exemple dans le fragment du lien. Le serveur ne reçoit qu'un blob chiffré. Cette séparation protège les contenus déjà stockés si le stockage serveur est compromis seul ; elle ne protège pas un terminal compromis ni un JavaScript malveillant servi lors d'un futur transfert.
2. Ce que le chiffrement au repos ne protège pas
Le chiffrement au repos est proposé par la plupart des services grand public, notamment WeTransfer, Dropbox, Google Drive, OneDrive et SwissTransfer. Lorsque le fournisseur gère les clés, cette couche ne couvre pas certains scénarios importants :
- Employé malveillant ou négligent : Un administrateur suffisamment privilégié peut parfois passer par l'application ou le service de clés.
- Réquisition légale : Un fournisseur soumis à une demande valide peut remettre le contenu s'il est techniquement capable de le déchiffrer. La juridiction et les garanties applicables doivent être analysées au cas par cas.
- Compromission de l'infrastructure : Si un pirate prend le contrôle du serveur (via une faille applicative, un accès SSH compromis, une supply chain attack), il a accès aux clés et donc aux fichiers déchiffrés.
- Erreur de configuration : Un bucket S3 mal configuré, un backup non chiffré, un log qui expose des clés - autant de vecteurs documentés qui contournent le chiffrement au repos.
- Accès de sous-traitants : Les fournisseurs cloud utilisent des sous-traitants (CDN, supervision, sauvegarde) dont les droits et les flux doivent être documentés.
La question fondamentale
Quand un service vous dit "vos fichiers sont chiffrés AES-256", posez une question structurante : "Qui peut utiliser la clé de déchiffrement ?" Si c'est le fournisseur, le chiffrement au repos reste utile, mais il ne l'empêche pas techniquement d'accéder au contenu.
3. Scénarios de fuite malgré le chiffrement au repos
Le chiffrement au repos peut être contourné sans casser AES. Quelques scénarios typiques :
- Identifiants applicatifs volés : l'attaquant utilise l'API légitime, qui déchiffre les objets avec les droits du service.
- Rôle cloud trop permissif : un compte compromis obtient à la fois les objets et l'autorisation d'utiliser la clé KMS.
- Bucket ou lien mal configuré : le stockage chiffre bien les octets, mais les restitue automatiquement à toute identité autorisée par erreur.
- Sauvegarde ou export secondaire : une copie peut échapper à la politique de chiffrement, de clés ou de rétention du stockage principal.
Le point commun : l'attaquant contourne le chiffrement en empruntant un chemin auquel le service fait déjà confiance. La robustesse d'AES n'est pas en cause ; la frontière de confiance l'est.
4. La difference fondamentale du chiffrement de bout en bout
Le chiffrement de bout en bout (E2E) change la frontière de confiance : la clé utile au contenu reste chez les clients autorisés. Le serveur de partage ne la reçoit pas et ne doit pas pouvoir la reconstituer.
Concrètement, sur un service E2E comme PrivCloud :
- Votre navigateur génère une clé AES-256-GCM aléatoire de 256 bits.
- Le fichier est chiffré localement dans le navigateur avec cette clé via la
Web Crypto API. - Seul le blob chiffré (illisible) est envoyé au serveur.
- La clé est placée dans le fragment d'URL (après
#), qui n'est jamais transmis au serveur par conception HTTP. - Le destinataire ouvre le lien : son navigateur extrait la clé du fragment et déchiffre le fichier localement.
Résultat : une compromission du stockage seul expose des blobs AES-256-GCM sans leur clé aléatoire de 256 bits, dont la recherche exhaustive est impraticable. Le modèle ne couvre cependant pas un poste client compromis ni un JavaScript malveillant servi au moment du transfert.
5. Comment vérifier qu'un service est vraiment E2E
Voici les indicateurs concrets pour vérifier si un service de transfert de fichiers offre un chiffrement de bout en bout réel :
- Pour un partage par lien, la clé peut être dans le fragment d'URL : une longue chaîne après
#est un bon indice, sans constituer une preuve suffisante à elle seule. - Le code source est ouvert : Vous pouvez vérifier dans le code que le chiffrement se fait bien côté client. Avec un code propriétaire, vous devez faire confiance sur parole.
- L'onglet "Network" du navigateur apporte un indice : le fichier envoyé doit être un blob chiffré, sans contenu en clair reconnaissable.
- La documentation technique l'explique : Un service sérieux publie un modèle de menace et décrit son implémentation cryptographique.
6. FAQ
Le chiffrement au repos est-il complètement inutile ?
Non. Il protège les supports, sauvegardes et snapshots contre plusieurs formes d'accès direct et constitue une bonne pratique de base. C'est une couche de défense parmi d'autres. Pour les partages sensibles, le chiffrement E2E ajoute une séparation de clé que le chiffrement au repos ne fournit pas.
Google Drive, Dropbox, OneDrive sont-ils tous dans le même cas ?
Leur offre par défaut repose généralement sur des clés gérées par le fournisseur, mais certaines options changent le périmètre, par exemple la protection avancée des données d'Apple. Il faut vérifier le produit, le plan, les fonctions activées et les procédures de récupération plutôt que raisonner uniquement par marque.
Le chiffrement E2E a-t-il des inconvénients ?
Pour un partage par lien, perdre le fragment peut rendre le contenu irrécupérable. Le chiffrement ajoute aussi du travail CPU, des copies mémoire et des contraintes de reprise. Le traitement en flux et les Web Workers limitent ces coûts, sans permettre de promettre un impact nul sur tous les navigateurs et tous les appareils.
À lire aussi
Passez au chiffrement E2E
PrivCloud propose un chiffrement E2E optionnel AES-256-GCM côté navigateur, un code source ouvert et un hébergement temporaire en France. Jusqu'à 2 Go sans compte.
Dernière mise à jour : 14 juillet 2026.