Envoyer un message de Whatsapp vers iMessage : le casse-tête de l'interopérabilité

Publié le 31 mars 2022 à 11h00

La nouvelle législation européenne sur les marchés numériques va demander aux grandes applications de messagerie instantanées qu'elles interopèrent avec les plus petites. Est-ce possible, et quels sont les risques pour les utilisateurs ?

Une des conséquences cette nouvelle régulation sera l'opérabilité inter-plateforme. À terme, les usagers de Whatsapp ou de Messenger pourraient donc envoyer un message directement à un utilisateur de Signal ou tout autre application de messagerie.

Réguler la compétition

La nouvelle régulation européenne sur les marchés numériques insiste sur l'interopérabilité, notamment, pour des question de libre concurrence. Avec plus de 4 milliards d'utilisateurs, Facebook agit actuellement comme « contrôleur d'accès » au marché de la messagerie numérique. L'impossibilité de communiquer depuis les plus petites plateformes vers les grandes forcent en effet les utilisateurs à basculer vers les messageries du géant que sont Whatsapp ou Messenger.

Les nouvelles règles européennes stipulent donc que l'interopérabilité devra être mise en place à la demande des plateformes. La loi ne sera évidemment pas fonctionnelle immédiatement, et les détails techniques ne sont toujours pas rendus publics. On sait toutefois qu'une entreprise sera tenue de permettre l'envoi de messages inter-plateforme trois mois après la demande ; la perméabilité des appels pourra quant à elle prendre jusqu'à quatre ans.

Des risques pour les données cryptées

Le problème majeur qui se pose est celui du chiffrage des données contenues dans les messages échangés. L'avantage principal des plateformes comme Whatsapp sur les SMS est la garantie de confidentialité grâce au cryptage de bout en bout. Si les applications se mettent à opérer entre elles, ce chiffrage pourrait être compromis.

Aujourd'hui, chaque application de messagerie instantanée utilise un code de chiffrage différent. Ainsi, le cryptage des messages pourrait être perdu lors du transit d'une plateforme à l'autre. Pour éviter le problème, deux solutions existent : l'utilisation d'un pont entre les deux plateformes ou l'adoption d'un code de cryptage universel.

Or, le pont décrypterait le message avant de le transférer, posant des problèmes majeurs de confidentialité. L'adoption d'un cryptage universel serait peut-être plus réaliste, d'autant plus que des protocoles de ce type, comme le protocole « Matrix », existent déjà.

Source: Wired

Par Louise Jean

Actualités High-Tech

Vous êtes un utilisateur de Google Actualités ou de WhatsApp ?
Suivez-nous pour ne rien rater de l'actu tech !

Commentaires (0)

Rejoignez la communauté Clubic

Rejoignez la communauté des passionnés de nouvelles technologies. Venez partager votre passion et débattre de l’actualité avec nos membres qui s’entraident et partagent leur expertise quotidiennement.

Commentaires (10)

sirifa

Point de détail pour Louise Requin.
Je milite pour l’utilisation de chiffrement et pas cryptage.
On transforme en chiffre les données pour les rendre non lisible sans déchiffrement.
Si on crypte c’est pour que ça devienne mort ? (ironie)

ThE_oNe

@Sirifa : tout à fait d’accord, j’allais faire le même commentaire
On chiffre avec une clé de chiffrement.
On déchiffre avec une clé de chiffrement.
On décrypte sans la clé de chiffrement.
Impossible de crypter un message, ça n’a aucun sens…

ovancantfort

@sirifa
Le français est une langue vivante. Il est normal que de nouveaux termes apparaissent, soient incorporés, ou changent de sens.
Pour le verbe « crypter », c’est du combat d’arrière-garde. Il est devenu tellement courant qu’il est déjà dans le dictionnaire : crypter - Définitions, synonymes, conjugaison, exemples | Dico en ligne Le Robert
Vouloir figer le français, c’est pour que ça devienne une langue morte ? (ironie)

Blm79

Dommage que cet article mélange chiffrer et crypter (qui d’ailleurs n’existe pas)…
Décrypter oui, sans la clé de chiffrement.

HAL1

Il est tout à fait normal qu’une langue vivante évolue et change, mais dans l’exemple présent, pourquoi vouloir absolument utiliser un terme qui n’existe pas en français, alors qu’il y en a un qui fait déjà l’affaire ?

Dans un de mes précédents emplois, on avait pour habitude de plaisanter en disant :

Est-ce que tu pourrais me printer la database des suppliers ?

Alors on peut trouver ça merveilleux, mais personnellement je trouve préférable que ça reste de l’humour et dire dans un cadre normal :

Est-ce que tu pourrais m’imprimer la base de données des fournisseurs ?

D’autant plus qu’une grande partie des personnes qui abusent des anglicismes le font pour se donner un genre et apparaître « sachant »…

TofVW

Il y a 2 ans environ, je suis passé d’un travail de « terrain » à un travail de bureau, à mon premier briefing je me serais cru dans le sketch « Les publicitaires » des Inconnus.

C’était ignoble.

xryl

C’est pas comme si il existait déjà un protocole ouvert pour l’échange de clé temporaire, d’algorithme de chiffrement, de fonction de hashage etc… Pour ceux qui l’ignoreraient encore, vous l’utilisez en ce moment même en lisant cette page: TLS (utilisé sur le protocole HTTP ce qui donne HTTPS).

Dire qu’il y a des difficultés d’interopérabilité, c’est se mettre la tête dans le sable en faisant semblant d’ignorer ce qui existe depuis des décennies, histoire de faire sa pleureuse (ouh les vilains parlementaires européens qui comprennent rien à la technologie).

Sûr, ça veut dire qu’il va falloir ajouter une option de négociation des protocoles dans Signal (que Whatsapp exploite déjà) et iMessage du genre: « Si le destinataire n’est pas chez moi, alors commencer une négo via TLS d’un Diffie Helman pour une clé secrête et tel ou tel algorithme ». Pas franchement de quoi fouetter un chat.

sirifa

C’est plus compliqué que cela. Le serveur qui envoi n’a pas le message en clair (du moins pas forcement), donc la clef de chiffrement il ne la connais pas. Il ne peux donc pas transmettre cette clef aux autres serveurs.

Signal c’est le terminal de l’utilisateur qui fait le déchiffrement/chiffrement (si j’ai bien compris), le reste les serveurs ne voient pas les messages en clair, et n’ont pas la possibilité de les déchiffrés.

Ce problème est déjà connu et résolu depuis un certain temps, c’est des clefs de chiffrement publique/privé avec une publication de la clef publique.

Les destinataires recherchent dans un annuaire publique où on lie identifiant + application et clef publique, Ils chiffrent le message avec cette clef, ils l’envoient au serveur qui transmet le message à l’autre serveur de l’autre application qui délivre le message. Le récepteur déchiffre le message avec sa clef privée.

C’est facile, mais ca demande potentiellement à certaine application de sécurisé vraiment les messages et donc fermer les portes dérobées pour les agences gouvernementales…
Elle peuvent toujours feinté le système, en déchiffrant elle même les messages reçu en conservant les clef privés sur leur serveur et re-chiffré par la suite pour envoyé au récepteur (une sorte de man in the middle).

Le Diffie Helman c’est un superbe algorithme mais pas applicable pour la résolution de ce problème (enfin je ne pense pas).

xryl

Non, tu te trompes. C’est bien aux clients de négocier le protocole de chiffrement. En gros, lorsque tu envoies un message (via Whatsapp) à un utilisateur Signal, Whatsapp se rend compte qu’il n’a pas le destinataire dans sa base. Le client commence alors un échange DH pour une clé de session. Les échanges de négociation se passent par le serveur Whatsapp qui contacte Signal (en clair ou pas, on s’en fout). Si le deuxième client (celui de Signal) est trouvé, il continue l’échange de clé. Signal renvoi, via Whatsapp, le 3eme message au client initial.

Les 2 clients ont alors une clé privée et peuvent l’utiliser pour chiffrer leurs messages qui sont « proxyfiés » par Whatsapp/Signal sur une liaison en clair.

C’est un protocole classique en 3 étapes, les intermédiaires (Whatsapp, Signal) ne peuvent pas déduire la clé de session, ils ne sont que des transporteurs. C’est la base de toute authentification par clé publique/privée. Ni Signal ni Whatsapp ne connaissent la clé publique de l’autre client (vu que ce n’est pas nécessaire pour un DH que les clés publiques soient connues). Ils servent juste de transporteur de message. À la limite, ils peuvent authentifier les clients (empêcher que Bob croit parler à Alice mais en réalité parle à Eve) en interne en signant les message d’authentification, mais dans la pratique ce n’est pas requis.

sirifa

Une précision, le Diffie Helman ne protège pas de l’attaque man in the middle donc si c’est proxyfié alors cette attaque est très simple à faire, et donc le chiffrement du message n’est
plus une sécurité.

Si les clients font du point à point le Diffie Helman marche, mais ni les applications de messageries le permettrons, ni les agences gouvernemental un peu trop attachées à l’accès en claire des messages.

Pour moi la solution c’est les clefs de chiffrement asymétrique qui doit être mise en place, avec un annuaire publique des clefs publique. Mais les agences gouvernemental un peu trop attachées à l’accès en claire des messages seront contre ce genre de chose qui leur rend la tâche plus compliquée (mais pas impossible).