Chiffrement au repos vs en transit : les deux comptent

Le chiffrement en transit protège les données en déplacement entre deux points — votre navigateur et un serveur, par exemple — en utilisant TLS 1.3 avec AES-256-GCM ou ChaCha20-Poly1305. Le chiffrement au repos protège les données stockées sur disque, généralement avec AES-256-XTS pour le chiffrement de disque complet ou AES-256-GCM par fichier. Ni l'un ni l'autre ne suffit seul. TLS protège contre l'espionnage réseau mais se déchiffre au serveur ; le chiffrement au repos protège les données stockées mais est inutile si les clés se trouvent à côté du texte chiffré. La vraie sécurité vient de la superposition des deux, idéalement avec un chiffrement côté client (de bout en bout) pour que le serveur ne voie jamais le texte en clair.

Deux menaces distinctes, deux contrôles distincts

Les menaces diffèrent selon l'endroit où vos données se trouvent :

En transit (chemin réseau) : un attaquant dans un café avec un analyseur de paquets, un routeur FAI compromis, un État interceptant des câbles sous-marins. Les documents Snowden de 2013 ont révélé le programme MUSCULAR de la NSA interceptant les liens fibre internes de Google. Défense : TLS 1.3, de préférence avec épinglage de certificat pour les applications.

Au repos (stockage) : un ordinateur portable volé, une bande de sauvegarde perdue, un bucket S3 mal configuré, un employé malhonnête du centre de données avec accès aux disques. La violation Equifax de 2017 a exposé 147 millions de dossiers en partie parce que des données étaient stockées sans chiffrement. Défense : LUKS, BitLocker, FileVault pour les disques ; AES-256-GCM ou AES-256-XTS par fichier ou par bloc.

L'erreur consiste à traiter l'un comme substitut de l'autre. TLS ne protège pas un dump de base de données. Le chiffrement de disque n'arrête pas une attaque man-in-the-middle.

Comment TLS 1.3 protège les données en transit

TLS 1.3, standardisé dans la RFC 8446 (2018), est la valeur par défaut moderne. Il utilise :

• La confidentialité persistante par défaut via l'échange de clés ECDHE éphémère. Même si la clé à long terme d'un serveur fuite, les sessions passées restent protégées.
• Des chiffrements AEAD uniquement — AES-128-GCM, AES-256-GCM ou ChaCha20-Poly1305. Les anciens modes CBC et RC4 ont disparu.
• Une poignée de main en un aller-retour (1-RTT), ou zéro aller-retour (0-RTT) pour la reprise.
• Une poignée de main chiffrée pour que les observateurs passifs ne voient pas la chaîne de certificats.

Chaque service de transfert de fichiers réputé — WeTransfer, SwissTransfer, Tresorit, Proton Drive, HexaTransfer — utilise TLS 1.3 avec des en-têtes HSTS imposant HTTPS pendant au moins 12 mois. Vous pouvez vérifier avec l'outil testssl de SSL Labs ; tout score inférieur à A- présente des problèmes de configuration.

Comment fonctionne le chiffrement au repos côté serveur

Une fois les fichiers arrivés et TLS terminé, le chiffrement au repos prend le relais. Il existe plusieurs couches :

• Au niveau des blocs (disque complet) : AES-256-XTS sur LUKS (Linux), BitLocker (Windows), FileVault (macOS), ou équivalents fournisseur cloud comme le chiffrement AWS EBS. Protège contre les disques volés.
• Au niveau du système de fichiers : eCryptfs, Fscrypt sur ext4/F2FS. Les fichiers de chaque utilisateur sont chiffrés avec des clés séparées.
• Au niveau du stockage d'objets : AWS S3 SSE-KMS, Azure Blob avec Storage Service Encryption, Google Cloud Storage avec des clés gérées par le client. Chaque objet est chiffré avec AES-256-GCM.
• Au niveau applicatif : le service chiffre chaque fichier dans son propre code avant de l'écrire dans le stockage, avec des clés détenues dans un KMS ou un HSM.

Le niveau applicatif est le plus solide car le chiffrement se produit avant que tout système de stockage ne voie les données. AWS KMS facture 1 $/clé/mois plus 0,03 $ par 10 000 requêtes — assez peu coûteux pour que les services sérieux l'utilisent par fichier.

Le piège des "clés à côté du texte chiffré"

C'est là où le chiffrement au repos échoue couramment. Si les clés sont stockées sur le même serveur que le texte chiffré, un attaquant qui viole le serveur obtient les deux. Le fournisseur peut techniquement cocher la case "chiffré au repos" pour la conformité tout en offrant une protection réelle nulle contre la compromission du serveur.

Les bonnes architectures séparent les responsabilités :

• Texte chiffré sur S3 ou un stockage d'objets similaire.
• Clés de chiffrement dans AWS KMS, Google Cloud KMS, Azure Key Vault, ou un HSM dédié.
• Accès aux clés conditionné par des identifiants IAM à courte durée de vie et des journaux d'audit.

Les excellentes architectures vont plus loin : les clés n'existent jamais sur le serveur. Le chiffrement côté client (E2EE) signifie que le navigateur de l'utilisateur génère la clé, chiffre le fichier et conserve la clé. Le serveur stocke le texte chiffré et n'a rien à divulguer.

Où apparaissent les lacunes de chiffrement

Même avec les deux contrôles en place, les données sont brièvement en clair à plusieurs endroits :

• En mémoire serveur lors du traitement de l'envoi, de l'analyse antivirus ou de la génération de vignettes. Un dump mémoire pendant cette fenêtre révèle le texte en clair.
• Dans les journaux d'accès si les noms de fichiers ou des extraits de contenu sont journalisés pour le débogage.
• Sur les bandes de sauvegarde si les sauvegardes n'héritent pas du même chiffrement.
• Pendant la compression ou le transcodage où le service traite le contenu des fichiers.
• Dans le cache du navigateur après le téléchargement si l'utilisateur ne le vide pas.

Ces lacunes expliquent pourquoi le chiffrement zéro connaissance (côté client) est important. Quand les fichiers sont chiffrés dans le navigateur avant l'envoi, les lacunes côté serveur deviennent sans importance — le serveur ne voit jamais que du texte chiffré.

Ce que font réellement les grands services

Une classification approximative basée sur la documentation publique :

• Google Drive, Dropbox, OneDrive : TLS 1.3 en transit, AES-256 au repos avec des clés détenues par le fournisseur. Non zéro connaissance — le fournisseur peut lire vos fichiers.
• WeTransfer (niveau gratuit) : TLS 1.3, AES-256 au repos sur AWS S3. Le fournisseur détient les clés.
• Box Enterprise : TLS 1.3, AES-256-GCM au repos, clés gérées par le client optionnelles (Box KeySafe).
• Tresorit, Proton Drive, SwissTransfer niveau E2EE, HexaTransfer : TLS 1.3 en transit, AES-256-GCM au repos, mais les clés par fichier sont générées côté client et n'atteignent jamais le serveur. Effectivement zéro connaissance.

Pour les données sensibles, seule la dernière catégorie offre une protection significative contre les menaces internes et les demandes légales valides.

La conformité et l'exigence de "défense en profondeur"

Les régulateurs exigent explicitement les deux :

• L'article 32 du RGPD impose la "pseudonymisation et le chiffrement des données à caractère personnel" sans restriction sur l'état des données.
• La règle de sécurité HIPAA 45 CFR § 164.312(a)(2)(iv) et (e)(2)(ii) exige le chiffrement des ePHI à la fois en transit et au repos.
• La norme PCI DSS 4.0 Exigences 3 et 4 distingue "protéger les données de titulaires de carte stockées" (au repos) de "protéger les données de titulaires de carte avec une cryptographie forte pendant la transmission" (en transit).
• La validation FIPS 140-3 s'applique aux modules cryptographiques utilisés dans les deux contextes.

N'en fournir qu'un constitue un échec de conformité avant même de devenir un échec de sécurité.

Comment vérifier que les deux sont actifs

Cinq vérifications rapides pour tout service de transfert de fichiers :

1. Exécutez testssl.sh https://fournisseur.com pour confirmer TLS 1.3 avec des chiffrements forts uniquement.
2. Vérifiez les en-têtes HSTS avec un max-age d'au moins 31 536 000 (un an).
3. Lisez le livre blanc de sécurité pour mention explicite d'AES-256-GCM ou AES-256-XTS au repos.
4. Confirmez que les clés sont détenues dans un KMS ou HSM, pas dans la base de données applicative.
5. Cherchez une certification SOC 2 Type II ou ISO 27001 — les deux exigent des contrôles documentés au repos et en transit.

En bonus : vérifiez si le chiffrement côté client est disponible comme option. Si oui, activez-le pour tout ce qui est sensible.

Les superposer correctement

Le modèle qui fonctionne vraiment :

1. Le navigateur chiffre le fichier avec une clé AES-256-GCM aléatoire (côté client).
2. Le texte chiffré voyage sur TLS 1.3 vers le serveur (en transit).
3. Le serveur stocke le texte chiffré sur un stockage chiffré AES-256 (au repos).
4. La clé de déchiffrement vit uniquement dans le fragment d'URL du lien de partage, jamais envoyée au serveur.

Trois couches indépendantes. Brisez-en une, les autres tiennent. C'est la conception qu'utilise HexaTransfer, ainsi que Tresorit Send, les liens de partage Proton Drive et le mode E2EE de SwissTransfer.

Essayez sur hexatransfer.com — gratuit, sans compte, jusqu'à 10 Go.