Le stockage chiffré sépare les octets du fichier du pouvoir de les déchiffrer, mais destinataires, métadonnées et copies locales restent dans le modèle de menace.
Une pièce jointe chiffrée de bout en bout peut être stockée sur un serveur sans lui donner le fichier en clair. Une conception courante chiffre le fichier sur l'appareil de l'expéditeur avec une nouvelle clé de contenu, envoie les données chiffrées au serveur et transmet la clé aux destinataires prévus dans un message chiffré et authentifié.
Cette séparation est utile, mais « stockage à connaissance nulle » n'est pas une spécification complète. Il faut encore demander comment sont gérés les clés, références de fichiers, noms, contrôles d'accès et copies téléchargées.
Le cycle de vie d'une pièce jointe
- Préparer le fichier. L'expéditeur choisit une photo, une vidéo ou un document. Retirer les métadonnées ou transcoder constitue une étape distincte ; le chiffrement seul ne supprime ni les données EXIF ni les propriétés du document.
- Créer le matériel de chiffrement. Une implémentation sûre génère les clés et les nonces requis conformément au schéma choisi.
- Chiffrer avant l'envoi. Le service de stockage reçoit des octets chiffrés plutôt que le contenu original.
- Transmettre une référence authentifiée. Le message de chat chiffré transporte les informations nécessaires aux destinataires, comme l'emplacement du fichier, la clé de déchiffrement et les métadonnées d'intégrité pertinentes.
- Récupérer et vérifier. Le client destinataire récupère l'objet de données et vérifie l'authentification avant de considérer le résultat comme un contenu valide.
- Gérer les copies locales. L'affichage, l'exportation, la modification ou l'enregistrement dans une galerie peuvent créer des copies hors du périmètre initial du stockage chiffré.
La clé peut traverser l'infrastructure du même fournisseur dans une enveloppe chiffrée. Parler de transmission « hors bande » peut induire en erreur : elle est logiquement séparée du stockage de l'objet, mais pas nécessairement transmise par un canal de communication indépendant.
L'apport du chiffrement authentifié
Un schéma de chiffrement authentifié protège la confidentialité et détecte les modifications non autorisées dans son périmètre authentifié. La spécification GCM du NIST définit une telle construction et ses exigences. Une gestion correcte des clés et des nonces et la vérification du résultat d'authentification sont indispensables ; le nom d'un algorithme reconnu ne sécurise pas toutes ses implémentations.
L'application doit aussi lier le fichier au bon message et à la bonne conversation. Un objet chiffré valide ne prouve pas à lui seul qu'il appartient à ce chat précis. Identifiants de fichiers, taille attendue, ordre des blocs et métadonnées des pièces jointes exigent une conception authentifiée adaptée.
Ce que le service de stockage peut encore apprendre
| Information | Le chiffrement du contenu seul la masque-t-il ? |
|---|---|
| Octets originaux du fichier | Il est conçu pour les cacher aux parties sans clé |
| Taille chiffrée approximative | Généralement non |
| Moments d'envoi et de téléchargement | Généralement non |
| Compte demandant un fichier | Cela dépend du routage et du contrôle d'accès |
| Nom du fichier et légende | Seulement si le protocole les protège aussi |
| Copie enregistrée par un destinataire | Non ; le destinataire a déjà accès au contenu en clair |
Les contrôles d'accès restent importants même lorsque les objets sont chiffrés. Ils peuvent limiter les téléchargements indésirables, les abus et l'exposition d'identifiants. Le chiffrement ne remplace ni l'autorisation, ni les politiques de conservation, ni la disponibilité.
Les gros fichiers nécessitent plus qu'un slogan
Une conception pour les gros fichiers peut transmettre les données en flux ou les diviser en blocs authentifiés. Cela peut réduire la mémoire utilisée, mais la numérotation, la longueur finale, les nouvelles tentatives et le traitement des troncatures doivent être définis. N'inventez pas de chiffres de performance et n'affirmez pas que placer un fichier dans un message entraîne nécessairement un « gonflement de l'état du ratchet » ; ces résultats dépendent de l'implémentation.
Un test utile comprend un fichier valide, un octet modifié, un téléchargement tronqué, un bloc déplacé et une tentative de récupération non autorisée. Exécutez ces tests uniquement dans un environnement de test autorisé, avec des fichiers non sensibles. Notez si le client rejette les données invalides avant de les ouvrir.
Ce que documente Livara
La page de sécurité de Livara décrit le chiffrement avant envoi, une clé aléatoire par fichier transmise dans la session protégée, ainsi que la protection des noms et légendes dans les conversations où l'E2EE est actif, y compris les groupes privés compatibles. Les anciens groupes incompatibles sont explicitement exclus. Elle distingue les conversations protégées des canaux publics de diffusion. Ce sont des affirmations documentées du produit, pas un nouvel audit d'implémentation réalisé dans cet article.
Le modèle de menace reconnaît aussi qu'un destinataire ou un appareil compromis peut exposer un contenu lisible. Le stockage chiffré ne peut donc pas promettre qu'une image disparaîtra de tous les appareils lorsque son message est supprimé.
Questions avant de partager des fichiers sensibles
Vérifiez si le type de conversation prend en charge l'E2EE, si tous les destinataires prévus sont dignes de confiance et si le fichier contient des métadonnées identifiantes. Examinez séparément l'enregistrement automatique dans la galerie et la sauvegarde des photos dans le cloud. Pour un document, demandez-vous s'il faut retirer les commentaires, l'historique des révisions ou les propriétés intégrées avant l'envoi.
Enfin, comprenez la suppression et la récupération. Retirer un objet du serveur peut empêcher un téléchargement futur, mais ne peut rappeler la copie déjà détenue par un destinataire. Perdre la clé requise peut rendre illisible un fichier chiffré restant. Une bonne conception des pièces jointes explique clairement ces deux conséquences.
