Qu'est-ce que le chiffrement de bout en bout ? Comment il protège vos photos
Le chiffrement de bout en bout tient le contenu lisible des photos et les clés de contenu en clair hors de portée du fournisseur de stockage.
Le chiffrement de bout en bout (E2EE) est un modèle de sécurité dans lequel le texte en clair est chiffré sur un point de terminaison autorisé et déchiffré sur un autre. Le fournisseur de stockage ou de transport ne détient pas la clé de contenu en clair. Cette limite protège le contenu de la lecture directe côté serveur, mais elle ne masque pas chaque élément de métadonnées ni ne protège un point de terminaison compromis, un identifiant de récupération, un destinataire partagé ou une mise à jour client malveillante.
Pour le stockage de photos, le chiffrement de bout en bout signifie que votre téléphone chiffre le contenu des photos avant l'envoi et que le cloud stocke le texte chiffré plutôt que les images lisibles. Le déchiffrement nécessite une clé disponible via un appareil autorisé ou un chemin de récupération. La taille du fichier, la durée, les données du compte, les relations de partage et d'autres métadonnées peuvent rester visibles. Ce guide explique les limites et compare les modèles de services courants.
Comment fonctionne le chiffrement de bout en bout
Le mécanisme central implique trois étapes : génération de clé, chiffrement et déchiffrement.
Génération de clé
L'appareil de l'utilisateur génère une clé cryptographique. Dans le chiffrement symétrique (comme AES-256), la même clé chiffre et déchiffre. Dans le chiffrement asymétrique (comme RSA), une clé publique chiffre et une clé privée déchiffre. De nombreux systèmes E2E combinent les deux : le chiffrement asymétrique échange une clé de session symétrique, qui gère ensuite le chiffrement en masse.
Les applications de coffre-fort de photos utilisent plusieurs conceptions de gestion de clés. Certaines dérivent une clé de fichier directement d'un mot de passe ; des conceptions en couches plus solides utilisent une clé de déverrouillage dérivée de l'identifiant pour encapsuler une clé de fichier aléatoire. Vaultaire utilise PBKDF2-HMAC-SHA512 pour dériver une clé de coffre de 256 bits à partir d'un motif 5x5 et d'un sel commun à tout l'appareil. Cette clé de coffre authentifie l'index chiffré et désencapsule une clé principale aléatoire distincte utilisée pour le chiffrement des fichiers.
Chiffrement
Le texte clair (votre photo) est transformé en texte chiffré à l'aide de la clé de chiffrement et d'un algorithme de chiffrement. AES-256-GCM est le chiffre symétrique le plus utilisé à cette fin. GCM (Galois/Counter Mode) fournit un chiffrement authentifié — il chiffre à la fois les données et produit un tag d'authentification qui détecte toute altération. Chaque fichier reçoit un vecteur d'initialisation (IV) unique, assurant que des fichiers identiques produisent des textes chiffrés différents.
Déchiffrement
L'appareil du destinataire utilise la même clé (symétrique) ou la clé privée correspondante (asymétrique) pour inverser la transformation. Sans la clé correcte, le texte chiffré est indiscernable de données aléatoires. Il n'y a pas de raccourci mathématique. AES-256 a 2^256 clés possibles — plus que le nombre estimé d'atomes dans l'univers observable.
Chiffrement de bout en bout vs autres modèles de chiffrement
Tout chiffrement n'est pas de bout en bout. Les différences déterminent qui peut accéder à vos données.
Chiffrement en transit (TLS/SSL)
Les données sont chiffrées entre votre appareil et le serveur. Le serveur les déchiffre à réception. Cela protège contre les écoutes pendant la transmission mais laisse les données lisibles sur le serveur. Chaque grand service cloud utilise le chiffrement en transit. C'est la base, pas le standard.
Chiffrement au repos (côté serveur)
Le serveur chiffre les données stockées en utilisant des clés qu'il gère. Cela protège contre le vol physique du matériel serveur mais pas contre le fournisseur de services, ses employés ou les demandes juridiques dirigées contre le fournisseur. iCloud, Google Drive et Dropbox utilisent tous le chiffrement côté serveur au repos. Le fournisseur détient les clés.
Chiffrement de bout en bout
Les données sont chiffrées sur un point de terminaison autorisé avant que le fournisseur de stockage ne les reçoive. Une conception solide maintient la clé du contenu en clair hors de la garde habituelle du fournisseur côté serveur, de sorte qu'une compromission du seul stockage ou une demande légale visant le contenu stocké ne livre que du texte chiffré plutôt que des photos lisibles. Le fournisseur peut toujours fournir du texte chiffré et des métadonnées, distribuer des logiciels clients ou exploiter des systèmes de récupération et de partage qui doivent être inclus dans le modèle de menace.
| Modèle de chiffrement | Qui détient les clés | Le fournisseur peut lire les données ? | Protège contre le fournisseur ? |
|---|---|---|---|
| En transit uniquement (TLS) | Serveur | Oui | Non |
| Au repos (côté serveur) | Serveur | Oui | Non |
| De bout en bout | Points de terminaison autorisés ou détenteurs de récupération | Pas uniquement à partir du texte chiffré stocké | Protège le contenu des clés de stockage détenues par le fournisseur |
| Chiffrement côté client aveugle au fournisseur | Client et chemins de récupération documentés | Aucun accès au contenu en clair, par conception | Protège le contenu ; les métadonnées et la confiance des clients demeurent |
Comment les services de stockage de photos gèrent le chiffrement
Le modèle de chiffrement varie considérablement entre les services de stockage de photos. Certains annoncent le « chiffrement » sans préciser le modèle, ce qui peut induire les utilisateurs en erreur en leur faisant croire que leurs photos sont chiffrées E2E alors qu'elles ne le sont pas.
Photos iCloud
Apple utilise le chiffrement en transit et au repos. Apple détient les clés de chiffrement par défaut. Avec une demande juridique valide, Apple peut fournir les données de Photos iCloud. Exception : La Protection avancée des données (PAD) d'Apple, disponible depuis décembre 2022, ajoute le chiffrement de bout en bout aux Photos iCloud. La PAD doit être explicitement activée dans les Réglages. Lorsqu'elle est activée, Apple ne peut pas accéder aux données des Photos iCloud. La plupart des utilisateurs n'ont pas activé la PAD.
Google Photos
Google utilise le chiffrement en transit et au repos avec des clés côté serveur. Google détient les clés de chiffrement pour toutes les données de Google Photos, y compris le contenu du Dossier verrouillé. Google peut se conformer aux demandes légales de données. Google ne propose pas d'option de chiffrement de bout en bout pour Google Photos.
Dropbox
Chiffrement en transit (TLS 1.2+) et au repos (AES-256 avec clés gérées par Dropbox). Dropbox détient les clés et peut accéder à vos fichiers. Dropbox a subi des violations de données (2012, 68 millions de comptes). Dropbox Vault (une fonctionnalité payante) ajoute une protection PIN mais pas le chiffrement de bout en bout.
OneDrive
Microsoft utilise le chiffrement en transit et au repos avec des clés gérées par Microsoft. Microsoft détient les clés. Le Coffre personnel OneDrive ajoute une vérification d'identité (2FA) mais pas le chiffrement de bout en bout — Microsoft peut toujours accéder aux données. Pour les clients entreprise, les clés gérées par le client sont disponibles.
Vaultaire
Chiffrement côté client, sans clés détenues par le fournisseur. Vaultaire chiffre les photos et les métadonnées sur l'appareil avec AES-256-GCM avant tout envoi vers le cloud. Une clé principale aléatoire chiffre les données du coffre. Une clé de coffre locale dérivée du motif de l'utilisateur et d'un sel d'appareil encapsule cette clé principale, tandis qu'une clé de sauvegarde distincte dérivée d'un motif protège les enregistrements de sauvegarde CloudKit privés. Vaultaire n'exploite pas de serveur de contenu et ne reçoit pas ces clés. Il ne peut donc pas remettre en clair un enregistrement CloudKit depuis un serveur. L'application, iOS et un appareil déverrouillé restent à l'intérieur de la limite de confiance, et une demande légale peut toujours obtenir des métadonnées de compte ou de service détenues par le fournisseur concerné.
| Service | Chiffrement en transit | Chiffrement au repos | Chiffrement de bout en bout | Le fournisseur peut accéder |
|---|---|---|---|---|
| Photos iCloud (défaut) | Oui | Oui (clés Apple) | Non | Oui |
| Photos iCloud (PAD activée) | Oui | Oui | Oui | Non |
| Google Photos | Oui | Oui (clés Google) | Non | Oui |
| Dropbox | Oui | Oui (clés Dropbox) | Non | Oui |
| OneDrive | Oui | Oui (clés Microsoft) | Non | Oui |
| Vaultaire | Oui | Oui | Sauvegarde chiffrée côté client, activée par défaut | Aucune clé de contenu en clair ; les métadonnées CloudKit restent |
Pourquoi le chiffrement de bout en bout est important pour les photos
Les photos sont des données particulièrement sensibles. Elles contiennent des visages, des localisations (métadonnées GPS), des horodatages et des enregistrements visuels de moments privés. Une violation de votre bibliothèque photos expose plus d'informations personnelles que presque tout autre type de données.
Violations de données
Lorsqu'un fournisseur de services stocke des photos avec des clés côté serveur, une compromission du stockage et de son chemin de gestion des clés peut exposer un contenu lisible. Avec un E2EE solide, une fuite limitée au stockage ne livre que du texte chiffré et toutes les métadonnées conservées par le service. La compromission des points de terminaison, les informations d'identification de récupération volées, les logiciels clients malveillants et les failles des services de clés restent des voies distinctes vers le texte en clair.
Accès juridique et gouvernemental
Les prestataires de services peuvent être tenus de fournir les dossiers qu’ils possèdent. Avec E2EE, cela peut inclure du texte chiffré, des informations de compte, des journaux d'accès, la taille des enregistrements et des métadonnées de synchronisation et de partage, plutôt qu'un contenu photo lisible. La question de savoir si une demande peut atteindre un appareil, une méthode de récupération, un destinataire ou le comportement futur du client est une autre question juridique et technique.
Accès interne
Les employés ou les attaquants ayant accès aux clés de stockage gérées par le fournisseur peuvent être en mesure d'accéder au contenu chiffré côté serveur. E2EE supprime ce chemin direct de clé de stockage lorsque le fournisseur ne dispose pas de clés de contenu en clair. Cela ne rend pas les abus internes catégoriquement impossibles, car les fournisseurs peuvent contrôler la distribution des clients, l'état du compte, les métadonnées, le partage ou les composants de récupération.
Protection des métadonnées
Certaines implémentations E2EE chiffrent uniquement le contenu des fichiers, laissant les métadonnées telles que les noms de fichiers et les dates non protégées. Vaultaire protège les en-têtes de fichiers, types MIME, index, vignettes et autres métadonnées du coffre avec chiffrement authentifié AES-256-GCM. Les longueurs de texte chiffré stockées et le nombre de fichiers d'index chiffrés peuvent toujours exposer des informations structurelles à une personne ayant accès au conteneur d'application.
Idées reçues courantes sur le chiffrement E2E
« Mon stockage cloud est chiffré, donc mes photos sont sûres. » Le chiffrement côté serveur protège contre les violations externes du matériel serveur. Il ne protège pas contre le fournisseur lui-même, les demandes juridiques ou les menaces internes. Le fournisseur détient les clés.
« HTTPS signifie que mes photos sont chiffrées de bout en bout. » HTTPS (TLS) chiffre les données en transit entre votre appareil et le serveur. Une fois que les données arrivent au serveur, elles sont déchiffrées. HTTPS est le chiffrement du tuyau, pas le chiffrement des données.
« Le chiffrement de bout en bout signifie que personne ne peut jamais voir mes photos. » Le chiffrement E2E signifie que personne sans la clé ne peut voir vos photos. Si quelqu'un a votre mot de passe ou clé, il peut déchiffrer les données. La gestion des clés et les mots de passe robustes restent essentiels.
« Apple/Google ne peuvent pas voir mes photos. » Par défaut, les deux entreprises détiennent les clés de chiffrement pour vos photos stockées dans le cloud. Apple propose la Protection avancée des données en tant qu'option opt-in. Google ne propose pas du tout d'option E2E pour Google Photos.
Comment Vaultaire implémente le chiffrement de bout en bout
Vaultaire utilise une approche E2E en couches :
- AES-256-GCM chiffre tout le contenu des fichiers. Chaque fichier reçoit un vecteur d'initialisation unique. Le chiffrement authentifié détecte les altérations.
- PBKDF2 avec HMAC-SHA512 dérive une clé de coffre locale à partir du motif dessiné par l'utilisateur et du sel de l'appareil. Le facteur de travail augmente le coût de chaque supposition hors ligne sans ajouter d’entropie au motif. Cette clé de coffre authentifie l'index chiffré et désencapsule la clé principale aléatoire qui chiffre les données des fichiers.
- AES-256-GCM pour les métadonnées protège les noms de fichiers, les dates, les dimensions, les index et les vignettes sous chiffrement authentifié.
- Le Keychain iOS et la protection des données protègent le sel de l'appareil et la base de données de récupération chiffrée. Les opérations AES-GCM et les clés symétriques actives restent dans le processus de l'application pendant qu'un coffre est ouvert.
- La séparation des clés du fournisseur signifie que Wraxle ne reçoit aucune clé de coffre, principale, de sauvegarde ou de récupération en clair. CloudKit (sauvegarde activée par défaut) stocke les enregistrements de texte chiffré et les enveloppes de clés chiffrées, tandis qu'Apple peut toujours observer les métadonnées du service. Vaultaire ne nécessite pas de compte d'identité Vaultaire.
Vaultaire conserve les informations de récupération, y compris le motif, dans une base de données chiffrée par AES-GCM stockée dans le Keychain iOS. Elles ne sont ni écrites dans des fichiers en clair ni envoyées à un service de compte Vaultaire. S'il ne reste ni motif utilisable, ni phrase de récupération, ni appareil déjà déverrouillé, Vaultaire ne détient pas de clé de récupération de fournisseur permettant de restaurer l'accès.
Questions fréquentes
Le chiffrement de bout en bout est-il légal ?
Le traitement juridique du chiffrement, de l'accès forcé et des services chiffrés varie selon les juridictions et peut changer. Ce guide décrit le modèle technique et non des conseils juridiques. Vérifiez la législation locale en vigueur si votre utilisation implique des fouilles aux frontières, des ordonnances judiciaires, des dossiers réglementés ou un autre contexte à haut risque.
Les forces de l'ordre peuvent-elles casser le chiffrement de bout en bout ?
Les attaques passent rarement par une recherche exhaustive dans l'espace de clés AES-256. Un examinateur peut cibler un mot de passe ou un motif faible, un point de terminaison déverrouillé, une mémoire, une phrase de récupération, un destinataire, une sauvegarde ou un défaut d'implémentation. Un AES-256-GCM correctement mis en œuvre avec une clé aléatoire à haute entropie est conçu pour résister à la recherche directe de clé, mais ce n'est qu'une partie du système.
Quelle est la différence entre le chiffrement E2E et le chiffrement zéro-connaissance ?
L'E2EE décrit où ont lieu le chiffrement et le déchiffrement du texte en clair et qui détient les clés de contenu utilisables. La « connaissance zéro » est souvent utilisée dans le marketing produit pour le chiffrement aveugle du fournisseur, mais elle ne doit pas être lue littéralement : un service peut ne pas disposer des clés en clair tout en continuant à voir le texte chiffré, les données de compte, les tailles, le timing, les relations de partage et d'autres métadonnées. Évaluez les chemins de clés et de récupération documentés plutôt que l’étiquette.
Le chiffrement de bout en bout ralentit-il mon téléphone ?
Les appareils modernes gèrent AES-256 efficacement grâce à l'accélération matérielle exposée via les bibliothèques cryptographiques du système. Sur iPhone, Vaultaire exécute AES-GCM dans le processus de l'application via CryptoKit. Les API publiques de la Secure Enclave d'Apple ne constituent pas un moteur AES-GCM arbitraire de chiffrement de fichiers. La surcharge de chiffrement et de déchiffrement dépend de la taille du fichier et de l'appareil, mais elle est conçue pour passer inaperçue en utilisation normale.
Que se passe-t-il si je perds ma clé de chiffrement ?
La perte de tous les chemins de déchiffrement et de récupération utilisables rend les données chiffrées irrécupérables. De nombreux systèmes E2EE utilisent donc des phrases de récupération, des appareils de confiance, des contacts de récupération, des kits d'urgence ou des enveloppes de clés chiffrées. Ces mécanismes préservent l’accès, mais chacun devient également partie intégrante du modèle de sécurité.
Conclusion
Le chiffrement de bout en bout peut supprimer le chemin de clé en texte brut du fournisseur de stockage lorsque le chiffrement a lieu sur un point de terminaison autorisé avant l'envoi. Il s’agit d’une protection significative, et non d’une garantie pour l’ensemble du système. Vérifiez la conservation des clés de contenu, la récupération, les métadonnées, les mises à jour du client, la sécurité des terminaux et le partage avant de confier des photos privées à un service.
Vaultaire implémente le chiffrement côté client pour iOS. Vos photos et métadonnées du coffre sont chiffrées sur l'appareil avec AES-256-GCM avant la sauvegarde (activée par défaut) ou la synchronisation facultative. Vaultaire ne reçoit pas les clés de déchiffrement et n'exploite pas de serveur capable de transformer ces enregistrements chiffrés en vos photos. Cette limite côté fournisseur ne rend pas digne de confiance un iPhone compromis ou déverrouillé.