Comment WhatsApp propose des résumés IA sans pouvoir lire les conversations
Quelle débauche
Dans un billet de blog publié hier soir, WhatsApp a annoncé l’arrivée des résumés pour les messages dans l’application. La fonction, qui se veut optionnelle, n’est pour l’instant disponible qu’en anglais aux États-Unis. Surtout, elle s’appuie sur une nouvelle architecture destinée à préserver la confidentialité des conversations. WhatsApp le jure, personne d’autre ne lira ces résumés.
L’annonce de WhatsApp sur les résumés est tout sauf anodine. Bien que la fonction soit un grand classique désormais des IA génératives, son arrivée dans l’application se fait au même moment où les publicités s’apprêtent à débarquer. Or, dans le cadre d’une application qui a toujours joué la sobriété – au point d’être souvent jugée austère face à des concurrents comme Telegram – tous ces changements ne passent pas inaperçus.
L’arrivée des résumés signale une intensification de l’offensive Meta AI dans WhatsApp. Mais elle soulève surtout une question évidente : qu’en est-il de la promesse de WhatsApp sur le chiffrement de bout en bout des contenus ? Si l’IA intervient, et puisqu’elle ne le fait pas localement, cela signifie-t-il que les contenus des échanges sont envoyés à des serveurs pour y être moulinés par les bons soins de Meta, qui peut donc lire les messages ?
Private Processing : de grosses ambitions
L’annonce de WhatsApp est directement liée à une architecture présentée initialement le 29 avril et qui a fait l’objet d’un livre blanc le 10 juin (PDF) : Private Processing et la notion Trusted Execution Environment (TEE). Il s’agit ni plus ni moins que de la très officielle réponse de Meta à Apple et son Private Cloud Compute, cette infrastructure conçue pour traiter les requêtes IA sans renoncer à la vie privée. Si les approches diffèrent sur plusieurs points, le constat général est le même : c’est complexe.
Pour WhatsApp, les objectifs sont clairs. L’utilisation de Meta AI, traitement privé ou non, doit être optionnelle. De plus, tout ce qui touche au traitement privé doit être transparent. Enfin, la confidentialité avancée des discussions doit aussi empêcher l’invocation de Meta AI pour traiter des messages dans les groupes. WhatsApp assure que « des chercheurs en sécurité indépendants seront en mesure de vérifier en permanence » son architecture et son intégrité.
C’est donc la réponse de Meta à la grande question : comment appliquer les traitements d’IA génératifs sur des serveurs sans compromettre la confidentialité des échanges ?
Attention les yeux
Le livre blanc de Meta identifie quatre grands piliers. Le premier est matériel et est constitué par les TEE, dans l’objectif de créer des enclaves se voulant totalement isolées des infrastructures classiques.
Du côté matériel, Meta indique se servir de processeurs EPYC d’AMD pour leur technologie SEV-SNP (Secure Encrypted Virtualization-Secure Nested Paging). Cette dernière permet le chiffrement intégral de la mémoire de la machine virtuelle où s’exécute le traitement. SEV-SNP empêche également l’hyperviseur d’inspecter ou de modifier le contenu de la machine virtuelle.
Ces CPU sont accompagnés (sans surprise) de GPU NVIDIA, plus précisément l’architecture Hopper, pour son mode Confidential Computing. Les communications entre le GPU et le pilote graphique au sein de la machine virtuelle sont ainsi chiffrées via un tunnel sécurisé utilisant le protocole SPDM. Ce mode permet également les attestations (nous allons y revenir).
Attestation et confiance
Dans son livre blanc, Meta explique que tout un mécanisme doit être mis en place pour s’assurer que les requêtes de l’utilisateur sont bien envoyées vers ces boites noires, et quelles-ci sont capables de s’identifier comme telles, afin que les traitements puissent avoir lieu.
À partir de la page 11 de son livre blanc, Meta explique ainsi se servir du protocole RA-TLS (Remote attestation over TLS). Il permet de vérifier l’authenticité et l’intégrité de la connexion d’un appareil avec l’un des TEE. Sans trop plonger dans les détails (l’architecture est particulièrement complexe), il faut retenir qu’au démarrage, le matériel calcule une empreinte cryptographique de chaque composant logiciel chargé, comme le firmware, le noyau du système d’exploitation, les conteneurs applicatifs, etc.
Quand un appareil veut se connecter à un TEE, celui-ci génère un certificat TLS spécifique à cette connexion. Il contient un rapport d’attestation signé par une clé privée et stockée dans le processeur AMD (VCEK). Ce rapport contient toutes les empreintes cryptographiques citées précédemment ainsi qu’un nonce (numéro à usage unique) fourni par le client.
Côté client, l’application WhatsApp vérifie l’authenticité du rapport. Cette étape doit répondre à trois questions : la signature du rapport provient-elle d’un processeur AMD ? Les empreintes logicielles correspondent-elles aux versions utilisées par Meta ? Toutes les politiques de sécurité sont-elles respectées ? De nombreux éléments sont contrôlés, comme la clé racine AMD, la version du firmware, etc. Tout échec sur un élément entraine celui de toute la procédure et aucune donnée n’est envoyée.
Cloudflare et Fastly entrent en piste
Pour que cette attestation fonctionne, il faut qu’une source puisse établir ce qu’est la « bonne » partie logicielle à laquelle on tente de se connecter. Meta indique ne pas pouvoir être la seule source et a donc choisi Cloudflare comme « gardien ».
Cloudflare est ainsi chargée de maintenir un journal public, en lecture seule et infalsifiable. Dans ce journal, Meta inscrit les empreintes cryptographiques de chaque composant logiciel qu’elle utilise. Quand la société ajoute par exemple une machine virtuelle, son empreinte est envoyée à Cloudflare, qui la consigne dans le journal et y ajoute sa propre signature cryptographique pour attester de la modification.
C’est ce journal qui sert de point de repère quand le client cherche à vérifier l’authenticité du TEE. L’application WhatsApp cherche ainsi dans le journal si les empreintes qu’on lui présente y figurent bien. Ce fonctionnement doit empêcher qu’une version compromise soit secrètement installée, puisque sans la signature de Cloudflare, les clients WhatsApp ne s’y connecteront pas.
Une autre entreprise participe à la machinerie. Fastly s’occupe en effet des relais tiers par lesquels les requêtes vont être acheminées vers Meta. Il n’y a pas de connexion directe, afin que Meta ne puisse pas voir les IP. Fastly voit bien l’adresse, mais pas le contenu des requêtes. Chez Meta, la passerelle voit les données, mais pas l’adresse IP du client : elle ne voit que celle de Fastly. L’ensemble se sert d’OHTTP (Oblivious HTTP).
Un autre mécanisme est utilisé pour renforcer la sécurité : ACS (Anonymous Credentials Service). Dans l’idée de pouvoir authentifier un utilisateur sans l’identifier directement, un jeton ACS lui est attribué. Ce jeton va constituer la preuve qu’il est un utilisateur légitime de WhatsApp, sans rien dire d’autre de l’identité. Il est ensuite validé par la passerelle de Meta et constitue un sésame vers le traitement.
Et ensuite ? Une session sécurisée est établie entre le client et le TEE sélectionné. La requête est envoyée sous une forme chiffrée, grâce à une clé éphémère connue uniquement du TEE, et seul ce dernier peut déchiffrer la requête. La réponse, elle, est renvoyée à l’aide d’une autre clé. Meta assure ne jamais pouvoir accéder aux informations.
Une transparence louable, mais…
Le livre blanc de Meta est doublement intéressant. D’abord parce que l’entreprise se révèle très transparente sur ses choix techniques. Nous avons résumé ici le cœur du dispositif, mais le document contient d’autres détails. On remarque d’ailleurs que jamais les documents de Meta ne sont aussi détaillés que quand ils concernent les choix techniques adoptés pour WhatsApp, comme lorsqu’il a fallu proposer une architecture de connexion aux messageries tierces, pour s’adapter au DMA.
Ensuite, parce que ces explications détaillées sont là pour convaincre que l’approche garantit l’utilisation de l’IA tout en préservant la confidentialité. Et pour montrer patte blanche, les fonctions de résumé sont pour l’instant optionnelles. Il faut se rendre en effet dans les réglages de l’application pour activer les résumés, qui ne fonctionnent pas sans Private Processing.
Mais on ne peut s’empêcher de se demander, comme dans le cas d’Apple d’ailleurs : cette débauche de moyens doit-elle déboucher sur quelque chose de tangible ? Même si dans le cas d’Apple on peut se douter que des fonctions payantes finiront bien par arriver pour rentabiliser ces investissements massifs, la question est plus prégnante pour WhatsApp.
Meta a mis en place une architecture complète pour ce qui n’est pour l’instant qu’une simple fonction de résumé. Cela signifie-t-il que d’autres capacités vont arriver par la suite ? Un bouquet payant sera-t-il proposé ? Ou au contraire, Meta choisira-t-elle d’explorer plus avant la piste des publicités ? Après tout, WhatsApp jurait ses grands dieux depuis le départ que jamais elles n’entreraient dans son application, toutes les pistes restent donc ouvertes.
Reste la question de la confiance. Le système de Meta est complexe et implique de faire confiance à l’implémentation de tous ces composants par l’entreprise. La problématique est la même que chez Apple et va au-delà de la simple image de marque. Meta, en tout cas, ne semble pas douter de son infrastructure d’attestation : « Pour contourner cette méthode d’attestation, il faudrait une collusion avec nos fournisseurs de matériel, ce qui est hors de portée ».
Le géant semble cependant assez sûr de son coup pour inviter officiellement les chercheurs indépendants à se pencher sur son infrastructure. Le programme de chasse aux bugs (bug bounty) a également été étendu à Private Processing.
Auteur : Vincent Hermann
Aller à la source
