Pour évaluer la sécurité d’un appel, ne demandez pas seulement « Est-il chiffré ? », mais où le chiffrement se termine et ce que l’enregistrement change.
Le chiffrement du chat ne prouve pas, à lui seul, que l’audio, la vidéo, le partage d’écran ou les enregistrements d’appels bénéficient de la même protection. Pour évaluer un appel, il faut demander jusqu’où les médias restent chiffrés, qui détient les clés et ce qui change lorsque des fonctions comme l’enregistrement sont activées.
Ce guide décompose les affirmations de sécurité en couches que l’on peut examiner ; le nom d’un protocole ou une icône de cadenas ne remplace pas les réponses à ces questions.
Trois circuits différents dans une même application
| Circuit | Exemples de données | Question de sécurité |
|---|---|---|
| Messages conservés | Texte, photos, fichiers et notes vocales | Qui peut lire les copies présentes sur les appareils, les serveurs et dans les sauvegardes ? |
| Médias en direct | Son du microphone, vidéo et partage d’écran | Le chiffrement se termine-t-il sur l’appareil de l’interlocuteur ou sur un serveur intermédiaire ? |
| Signalisation | Invitation à l’appel, réponse et informations de coordination de la connexion | Qui peut modifier les messages de contrôle ou l’identité du destinataire ? |
Une note vocale envoyée dans un chat est un fichier ; un appel vocal est un flux en direct. Un produit peut utiliser des clés et des mécanismes différents pour chacun. Une bonne qualité sonore ou la non-réception d’un message texte ne dit pas non plus, en soi, quoi que ce soit sur la sécurité de l’autre circuit.
Que nous indique DTLS-SRTP ?
Dans WebRTC, SRTP protège le flux de médias, tandis que DTLS-SRTP permet d’établir le matériel de clé nécessaire. RFC 5764 décrit le mécanisme DTLS-SRTP et RFC 3711, la protection des paquets de médias.
Mais « nous utilisons WebRTC » ne suffit pas à déterminer si le serveur de conférence déchiffre les médias. Les points de terminaison du chiffrement et leur authentification doivent être précisés. La connexion entre l’utilisateur et le serveur peut être chiffrée alors que le serveur accède aux contenus déchiffrés pour les traiter ou les enregistrer. Cela n’équivaut pas à un chiffrement de bout en bout (E2EE) entre les participants.
L’architecture de sécurité de WebRTC dans RFC 8827 montre aussi qu’outre la protection des médias, la confiance accordée à l’application web, le circuit de signalisation et l’identité de l’interlocuteur comptent. Des paquets chiffrés ne signifient pas que tous les composants du produit sont dignes de confiance.
Pourquoi évaluer la signalisation séparément ?
La signalisation coordonne qui appelle qui et comment la connexion s’établit. Même si une application protège ses messages de contrôle, il faut encore examiner comment cette protection est liée à l’identité réelle des participants et aux clés des médias.
Trois questions suffisent pour guider la lecture de la documentation :
- L’invitation, la réponse et les informations sur les clés sont-elles protégées contre les modifications ?
- Comment l’utilisateur sait-il que la clé appartient au contact souhaité ?
- Quel avertissement apparaît lorsqu’une clé ou un appareil change ?
Le service peut connaître les informations de routage, les horaires et les participants, même dans le cas d’un appel E2EE. Comprendre les métadonnées de messagerie explique cette distinction.
L’enregistrement d’un appel crée une nouvelle frontière de sécurité
« Appel chiffré » ne répond pas entièrement aux questions concernant la copie enregistrée. Un participant peut capturer le son ou l’image avec son propre appareil. L’enregistrement côté serveur doit aussi faire l’objet d’une documentation distincte : le serveur obtient-il accès à des médias en clair pour les enregistrer ? Qui conserve le fichier ? Quand est-il supprimé ?
Si l’activation de l’enregistrement modifie le mode de sécurité, ce changement doit être clair pour les participants. Avant une conversation sensible, vérifiez l’état de l’enregistrement et le consentement de chacun ; un indicateur d’enregistrement intégré éteint ne garantit pas que personne n’enregistre avec un autre appareil.
Comment lire la documentation actuelle de Livara ?
La page de sécurité de Livara présente les appels directs et de groupe comme étant E2EE, mais prévoit une exception pour l’enregistrement facultatif côté serveur : dans le mode REC visible, la protection de l’appel passe au chiffrement de transport. Il s’agit d’une affirmation de la documentation du produit, et non du résultat d’un test ou d’un audit indépendant réalisé dans le cadre de cet article.
La limitation de tous les appels de groupe à « 2 à 6 personnes sur Android » dans l’ancien texte ne correspond pas à la documentation actuelle et ne sert pas de base à ce guide. Pour la capacité, la plateforme et la version qui vous intéressent, consultez le guide à jour et vérifiez le comportement réel de l’application ; cet article ne fournit pas de test de capacité.
De même, citer des algorithmes du chat comme ML-KEM ne prouve pas, à lui seul, que le même algorithme est utilisé pour les médias des appels. Affirmer que les appels bénéficient d’une protection post-quantique exige des preuves propres au circuit des médias et à l’authentification. Lisez le modèle de menace de Livara en complément de la page des fonctionnalités, et non à la place d’un test indépendant.
Une courte liste de vérification avant de comparer deux services
Pour chaque « oui », notez également la version et la source :
- Les appels à deux, les appels de groupe et le partage d’écran sont-ils décrits séparément ?
- Est-il précisé si le serveur se contente de transférer les paquets ou s’il peut déchiffrer les médias ?
- Peut-on vérifier l’identité et la clé d’un participant ?
- Les changements d’appareil, l’arrivée d’un nouveau participant et l’activation de l’enregistrement sont-ils visibles ?
- Le circuit de l’appel est-il le même sur le web et dans l’application, ou existe-t-il des différences ?
- La conservation des fichiers enregistrés et des métadonnées est-elle expliquée ?
- Les éléments issus des tests ou audits concernent-ils la même version et la même fonctionnalité ?
Si la réponse ne figure pas dans la documentation, inscrivez « inconnu » ; l’absence de réponse ne prouve ni la sécurité ni une écoute.
Questions fréquentes
Un appel E2EE empêche-t-il l’interlocuteur de l’enregistrer ?
Non. Le destinataire autorisé a accès au contenu en clair et peut l’enregistrer à l’aide d’un logiciel ou d’un autre appareil.
Le chiffrement de transport est-il mauvais ?
Le chiffrement de transport offre une protection importante contre l’écoute sur le trajet de transmission. La différence est que le service qui constitue un point de terminaison peut accéder au contenu déchiffré ; cela ne doit pas être qualifié d’E2EE entre utilisateurs.
Le chiffrement post-quantique du chat rend-il aussi les appels post-quantiques ?
Non. L’affirmation doit concerner la même couche, les mêmes algorithmes et la même version de l’implémentation. Évaluez séparément le chat et les appels.
