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 ?
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)
1 « J'aime »
@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…
@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)
Dommage que cet article mélange chiffrer et crypter (qui d’ailleurs n’existe pas)…
Décrypter oui, sans la clé de chiffrement.
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 »…
1 « J'aime »
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.
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.
1 « J'aime »
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).
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.
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).
Les nouvelles règles européennes obligeront-elles les différents services de messagerie à proposer une interopérabilité ET un chiffrement des messages ?
Car le plus simple me semble-t-il serait pour WhatsApp, Signal, Telegram et compagnie de proposer l’envoi en clair vers d’autres services, et avertir l’utilisateur/trice que si il/elle veut bénéficier de plus de sécurité et de confidentialité, il/elle a tout intérêt à inciter ses correspondant(e)s à migrer vers leur solution.
En lisant ta première phrase, je pensais que tu n’avais pas compris le protocole DH, mais ta deuxième phrase prouve que si.
Le protocole DH est justement fait contre le MITM. Il faut cependant que chaque intervenant ait une clé privée et une clé publique, la clé publique servant à définir le message intermédiaire qui est échangé (contenant la clé secrète et temporaire de la session qui ne peut être décodée qu’avec la clé privée des intervenants).
Si les intervenants utilisent une clé qui n’est pas privée (par exemple, celle de Whatsapp ou Signal ou du FBI ou de la NSA), alors oui, il n’y a pas de secret possible. C’est un peu la base ici.
Le protocole que Signal utilise est assez sécure sur ce point, vu que la clé privée ne quitte jamais ton téléphone. Seule la clé publique est associée à ton numéro et stockée dans la base d’utilisateur Signal. Si tu changes de téléphone, en général, ta clé privée & publique sont régénérées et Signal va avertir tous tes contacts que tu as changé.
Bref, il n’est pas nécessaire que Signal ou Whatsapp ou Apple connaissent ta clé privée pour communiquer entre eux vu que DH n’utilise pour l’établissement de la communication que la clé publique. Il faut par contre s’assurer que l’algorithme utilisé pour le chiffrement soit le même (on ne peut pas utiliser une clé ECDSA avec un RSA par exemple), de même pour le hashage, le padding des messages etc… Et ça, c’est exactement ce que TLS négocie.
Il n’y a donc rien à ré-inventer ici, juste appliquer TLS, et fournir des points/API pour l’établissement des communications (genre « Zézette appelle X », « J’ai besoin de la clé publique de X », etc…). C’est pas franchement compliqué.
Et pour ce qui est de la « surveillance gouvernementale », les gouvernements ont suffisamment d’information dans les métadonnées (« Zézette a appelé X le 4 avril à 12h33 » soit 2h avant la découverte du corps dans la baignoire), ils se foutent royalement du contenu, ça se devine que trop bien après coup.