Multi-appareil de bout en bout

Un utilisateur s’attend à pouvoir utiliser son profil depuis tous ses appareils. Il veut pouvoir commencer une discussion depuis un appareil, puis la continuer naturellement depuis un autre. Du point de vue de ses contacts, cette opération doit être transparente. En particulier, il ne faut pas que l’ajout d’un appareil par un utilisateur nécessite une opération manuelle de la part de ses contacts.

La liste des appareils : un enjeu de sécurité

Sans chiffrement de bout en bout, la solution technique peut être triviale :

• Les utilisateurs enregistrent chacun de leurs appareils auprès du serveur (typiquement en s’authentifiant via un login et un mot de passe depuis chaque appareil).
• Lorsqu’un contact envoie un message, le serveur distribue ce message à tous les appareils enregistrés.

Dans le cas de l’utilisation d’une messagerie chiffrée de bout en bout, c’est une autre paire de manches. Chaque appareil de chaque utilisateur doit établir un canal de communication sécurisé avec chaque appareil de chaque destinataire. Lorsqu’un utilisateur envoie un message à l’un de ses contacts, le message est en réalité chiffré à destination de chacun des appareils du destinataire. Le moyen utilisé pour chiffrer vers plusieurs appareils varie d’une messagerie à l’autre, mais dans tous les cas, l’idée est de ne chiffrer qu’une fois le contenu des messages et de fournir à chaque appareil destinataire le moyen de le déchiffrer. Mais comment l’application connaît-elle la liste exacte des appareils ?

Une approche naïve serait de procéder de façon similaire à la solution triviale ci-dessus, en s’appuyant totalement sur le serveur de la solution pour indiquer à nos contacts la liste de nos appareils et les clés de chiffrement à utiliser pour chacun d’entre eux. Cette approche présente un risque majeur : le serveur pourrait ajouter malicieusement un appareil fictif à la liste des appareils d’un utilisateur A, en diffusant une clé de chiffrement qu’il maîtrise de façon à pouvoir déchiffrer toutes les communications reçues par cet appareil. L’attaque est parfaitement silencieuse : les contacts de l’utilisateur A chiffrent consciencieusement une copie de chaque message vers cet appareil fictif, comme vers n’importe quel appareil légitime, et rien ne leur permet de s’apercevoir de quoi que ce soit. On reconnaît l’attaque par substitution de clé décrite dans la page sur la substitution d’identité, transposée cette fois à la liste des appareils.

Rattacher les appareils à l’identité, pas au serveur

Dans une approche de bout en bout, on s’interdit naturellement de faire une quelconque confiance au serveur, ce qui disqualifie l’approche naïve. Il faut que l’application reconnaisse d’elle-même les appareils d’un contact. Mais cette exigence en croise une autre, de praticité : on ne peut pas demander à l’utilisateur de valider manuellement chaque appareil de chacun de ses contacts, ni exiger de ses contacts une quelconque opération à chaque fois qu’il ajoute un appareil. Les solutions qui concilient ces deux exigences ont un point commun, elles rattachent les appareils d’un utilisateur à son identité cryptographique, celle que ses contacts ont déjà authentifiée, plutôt qu’à une liste tenue par le serveur. Ainsi, la confiance accordée une fois à l’identité s’étend à ses appareils, sans que le serveur ait son mot à dire. Les moyens d’y parvenir varient :

• Olvid : tous les appareils d’un utilisateur partagent la même paire de clés long terme (celle qui constitue son identité). Un contact qui a authentifié cette identité peut faire confiance à l’ensemble de ses appareils sans qu’il soit nécessaire de vérifier quoi que ce soit de plus ; en interne, un canal sécurisé est établi entre chaque paire d’appareils à partir de cette clé commune.
• Signal et WhatsApp : chaque appareil possède sa propre clé, mais un appareil « principal » signe celles des autres avec sa clé long terme. Le contact fait confiance à cet appareil principal, l’identité qu’il connaît, et cette signature suffit alors à son application pour accepter les autres appareils.
• Matrix : le protocole prévoit un mécanisme appelé cross-signing, où l’utilisateur dispose d’une clé de certification unique qui signe l’ensemble de ses appareils ; un contact peut ainsi tous les valider en vérifiant cette seule clé. Mais ce mécanisme n’est pas imposé : selon le client Matrix et sa configuration, la vérification peut ne pas être activée, et le serveur (le « homeserver ») redevient alors, de fait, l’autorité qui déclare quels appareils appartiennent à l’utilisateur. La garantie n’est donc pas systématique.

Le cas de l’accès par navigateur

La question du multi-appareil de bout en bout se pose aussi pour les messageries proposant un accès depuis un navigateur : chaque navigateur, sur chaque ordinateur, est en fait un nouvel appareil et nécessite lui aussi des canaux sécurisés. Si l’utilisateur peut accéder à ses discussions depuis un navigateur, en s’authentifiant uniquement auprès du serveur (par un login et un mot de passe, par exemple), c’est que le chiffrement de bout en bout n’est pas au rendez-vous : pour qu’un navigateur dans lequel aucune clé n’existe encore puisse afficher les messages, il faut bien que le serveur soit en mesure de fournir de quoi les déchiffrer. Un accès web n’est pas nécessairement incompatible avec le chiffrement de bout en bout, mais il exige alors qu’un appareil déjà légitime autorise ce nouvel accès, exactement comme pour n’importe quel appareil.

Il existe une autre approche, plus limitée : celle de l’appareil « miroir ». Le client de Threema pour ordinateur (application de bureau ou client web), par exemple, n’est pas un appareil autonome, mais une fenêtre sur le téléphone : l’appairage exige un scan de QR code depuis l’application mobile, le téléphone doit rester connecté pendant toute la session, et les messages synchronisés sont effacés de l’ordinateur dès la session terminée^archivé. Cette approche ne fait (du point de vue des clés de chiffrement) aucune confiance au serveur : c’est bien un appareil légitime qui autorise l’accès. L’approche de SimpleX est similaire : son application de bureau est une télécommande de l’application mobile, à laquelle elle se lie directement, sans qu’un serveur intervienne, les deux appareils devant pour cela se trouver sur le même réseau local. Dans les deux cas, il y a un coût en termes de praticité : l’ordinateur ne détient aucune identité propre et dépend entièrement du téléphone, il ne s’agit donc pas d’un vrai multi-appareil.

Un accès par navigateur posera toujours un problème supplémentaire, même s’il est bien conçu : le code du client web est rechargé depuis le serveur à chaque session, si bien que l’opérateur (ou quiconque compromettant son serveur web) peut en servir une version modifiée, potentiellement malveillante, à un utilisateur ciblé, sans que quoi que ce soit ne puisse être détecté facilement. Une application installée ne souffre pas de ce problème, si bien que le modèle miroir, décliné en application de bureau, y échappe, alors que sa version « client web » y reste exposée.

Le Web 2.0 et les applications en mode SaaS ont fait entrer dans les mœurs l’usage du navigateur en remplacement des « clients lourds », mais ce modèle part du principe que l’on fait confiance au serveur qui héberge à la fois les données et l’application. Dans un modèle où l’on cherche de la sécurité de bout en bout et où l’on ne souhaite pas faire confiance au serveur, cela ne tient plus. L’utilisation d’une application dédiée pour ordinateur permet d’atteindre un niveau de sécurité qu’un accès par navigateur ne permet pas.

L’ajout d’un appareil : une opération critique

Dans toutes les approches décrites ci-dessus, c’est un appareil déjà légitime qui autorise le nouvel appareil. Toute la sécurité du multi-appareil repose donc sur cette procédure d’ajout : si un attaquant parvient à faire enregistrer son propre appareil sur le compte de sa victime, il obtient l’équivalent d’une copie de toutes ses conversations futures. Ce n’est pas un risque théorique, puisque des campagnes de phishing ont exploité^archivé la procédure d’ajout d’appareil de Signal, en amenant des utilisateurs à scanner un code QR qui liait en réalité l’appareil de l’attaquant à leur compte. Une note du CERT-FR^archivé a même été publiée en mars 2026 à ce sujet.

Ce risque impose une exigence contre-intuitive : la procédure d’ajout d’un appareil ne doit pas être trop simple. L’utilisateur ne doit pas pouvoir la déclencher, ni surtout la mener à son terme, sans comprendre ce qu’il est en train de faire. Une bonne procédure d’ajout est une expérience inhabituelle, qui sort l’utilisateur de ses automatismes et l’oblige à réfléchir avant de valider. On ajoute un appareil un petit nombre de fois dans une vie de compte (typiquement à l’achat d’un nouveau téléphone). Rien ne justifie donc que l’opération soit rapide. À l’inverse, un simple enchaînement d’écrans de confirmation ne protège de rien, quel que soit le nombre d’avertissements affichés : l’utilisateur les validera machinalement pour en sortir au plus vite. Et cette procédure ne doit surtout pas pouvoir être déclenchée de l’extérieur, par un lien ou le scan d’un code QR reçu d’un tiers, ce qu’ont précisément exploité les attaques contre Signal.

Application de ce critère

✅Bon si un vrai multi-appareil existe (chaque appareil est autonome, pas un miroir du téléphone) et que l’appartenance d’un appareil à un utilisateur est garantie par son identité cryptographique.