Une clé propre à un fichier ne signifie ni vue unique ni récupération de la copie du destinataire.
Pour protéger une pièce jointe, une messagerie peut chiffrer le fichier sur l’appareil de l’expéditeur avec une clé aléatoire, téléverser la copie chiffrée et transmettre la clé du fichier au destinataire dans un message chiffré de bout en bout. Ce schéma est parfois appelé chiffrement par enveloppe : le fichier volumineux et les quelques informations nécessaires à son ouverture suivent des chemins différents, mais liés.
Cette explication concerne les pièces jointes d’une conversation avec E2EE ; l’envoi d’un fichier dans n’importe quelle application ou type de canal n’offre pas nécessairement la même protection.
Le parcours d’une photo privée, de l’appareil au destinataire
- L’appareil de l’expéditeur génère une clé de contenu pour le fichier.
- Le fichier est chiffré avec un chiffrement authentifié ; le destinataire doit pouvoir détecter les modifications non autorisées des données.
- La copie chiffrée est déposée sur un service de stockage de fichiers.
- L’adresse ou l’identifiant du fichier et la clé nécessaire sont envoyés au destinataire dans un message protégé.
- L’appareil destinataire télécharge le fichier, le valide, puis l’ouvre.
La documentation de sécurité de Livara décrit, pour les pièces jointes, une clé aléatoire propre au fichier et sa transmission au sein de la session de messagerie. Cet article explique cette architecture déclarée, et non le résultat d’un audit de l’implémentation.
Une « clé propre au fichier » ne signifie pas « fichier ouvrable une seule fois »
Une clé générée pour un fichier peut être nécessaire pour lire plusieurs fois ce même fichier. Une clé dédiée n’implique ni son abandon immédiat après la première consultation, ni la suppression automatique du fichier, ni l’impossibilité pour le destinataire de l’enregistrer.
De même, une clé de message à usage unique et l’utilisation d’une clé de contenu pour une pièce jointe sont deux notions distinctes. Des fonctions comme la vue unique ou les messages éphémères ne doivent pas être déduites du seul nom de l’algorithme.
Pourquoi la clé et le nonce comptent-ils tous les deux ?
AES-GCM assure, outre la confidentialité, une vérification de l’authenticité des données ; son utilisation correcte reste toutefois essentielle. La norme NIST SP 800-38D explique les règles de GCM. Réutiliser une combinaison clé-nonce pour des données différentes peut compromettre la sécurité.
Pour l’utilisateur, la conséquence pratique est la suivante : la mention « AES-256 » ne suffit pas à elle seule. Il faut aussi examiner les spécifications de gestion des clés, de génération aléatoire, de validation des fichiers et de traitement des erreurs. La modification d’un octet devrait entraîner le rejet du fichier invalide, et non l’affichage d’un contenu altéré comme s’il s’agissait d’un fichier intact.
Que voient le destinataire, le serveur et l’application de galerie ?
| Emplacement | Question de sécurité |
|---|---|
| Service de stockage de fichiers | Ne détient-il que des octets chiffrés, ou a-t-il aussi accès à la clé ? |
| Message contenant la clé | La clé, le nom du fichier et sa description sont-ils protégés dans la conversation E2EE ? |
| Appareil destinataire | Après ouverture, où le fichier reste-t-il : mémoire, cache ou galerie ? |
| Sauvegarde cloud | La copie enregistrée rejoint-elle la sauvegarde des photos, et quelle protection cette sauvegarde possède-t-elle ? |
Le chiffrement pendant la transmission ne contrôle pas la copie que le destinataire enregistre dans sa galerie. Avant d’envoyer un document sensible, vérifiez aussi les parties inutiles de l’image, les écrits en arrière-plan et les informations de localisation du fichier.
Qu’est-ce qui change pour un fichier dans un groupe privé ?
Le nombre de personnes autorisées à détenir la clé augmente. Livara décrit la prise en charge des pièces jointes de groupes privés compatibles en mode E2EE dans LGS1 ; cette affirmation ne doit pas être étendue aux canaux publics. Tout membre ayant reçu le fichier peut en conserver une copie. Retirer un membre ou renouveler les clés futures ne récupère pas sa copie antérieure.
Liste de vérification avant l’envoi d’un fichier sensible
- Vérifiez à nouveau l’espace de conversation et ses destinataires.
- Si l’identité du contact importe, vérifiez l’empreinte de la clé par une voie de confiance.
- N’envoyez que les informations nécessaires ; une photo complète d’un document n’est pas toujours indispensable.
- Convenez avec le destinataire des règles d’enregistrement dans la galerie, de téléchargement automatique et de sauvegarde cloud.
- Ne laissez pas le fichier déchiffré sur un appareil partagé ou non verrouillé.
Questions fréquentes
Une clé propre au fichier garantit-elle un envoi sécurisé ?
Non. Il faut aussi des appareils sains, l’authentification du destinataire et une implémentation correcte. Lisez le modèle de menace de Livara en complément des spécifications de chiffrement.
Une image dans un canal public bénéficie-t-elle de la même protection ?
Selon la limite déclarée par Livara, les canaux sont publics et lisibles ; la confidentialité des pièces jointes privées n’y est pas promise.
Un lien vers le fichier suffit-il à lui seul ?
Cela dépend de la conception du service. Examinez séparément le lien, la clé et l’autorisation d’accès ; une URL longue ou aléatoire ne constitue pas une preuve d’E2EE.
