WhatsApp — dossier individuel d’investigation (13 octobre 2026)¶
Registre de preuves — Phase 2
Ce dossier est une pièce de recherche datée. La conclusion canonique est celle du rapport final 1.0. Les synthèses antérieures et renvois à la Phase 3 restent historiques. UNKNOWN reste UNKNOWN.
Périmètre. WhatsApp Messenger grand public: contenu personnel et appels annoncés E2EE sur le Signal Protocol, mais client/service Meta centralisés et fermés. Business Platform, interactions avec bots/IA, interopérabilité DMA et sauvegardes dépendent de réglages/chemins distincts et ne doivent pas être agrégés sans qualification.
| Catégorie | FACT | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN |
|---|---|---|---|---|---|
| 1 Architecture | Service centralisé Meta, identification historique par téléphone; serveur distribue ciphertext, identité et metadata; app mobile et appareils liés. | Meta dit que le chiffrement s’applique aux conversations personnelles; politique décrit infrastructure et sous-traitants Meta. | Meta engineering explique l’interopérabilité E2EE appuyée sur Signal Protocol dans l’UE; backend/client complets non ouverts. | La centralité donne à Meta comptes, réseau de delivery, contact-graph signalétique et surfaces de sauvegarde/business même sans message clair. | Cartographie backend actuelle, segmentation par régions, différences exactes interop/bots/Business. |
| 2 Protocole cryptographique | Signal Protocol dérivé, X3DH/PQXDH selon implémentation/version puis Double Ratchet; Sender Keys pour groupes, E2EE media/calls. | WhatsApp affirme E2EE par défaut pour messages et appels personnels, hors frontières produit explicites. | Étude 2026 modélise WhatsApp Web et observe conformité aux modèles symboliques des exécutions capturées; vérifie authentification/confidentialité au niveau modélisé, trouve des différences non documentées au fork libsignal. | Propriété du protocole Signal n’est pas preuve d’équivalence complète à Signal app ni de sécurité de toutes features. | Version précise et algorithmes actifs pour chaque client/device/business/interoperability; audit de backend; détails des differences post-publication. |
| 3 Création d’identité | Numéro de téléphone requis dans flux compte classique; nom/profil facultatif; mécanisme de username pourrait réduire l’exposition à l’échange de numéro dans les nouveaux flux, sans supprimer l’identité du compte. | Politique dit numéro nécessaire pour fournir service et trouver les utilisateurs. | Play listing et help center/Meta policies; pas de test enrollment courant fait. | Une SIM réelle permet corrélation opérateur–compte et numéro facilite enumeration. | Déploiement global des usernames, exigences par nouveau type compte / parent-managed accounts / linked devices. |
| 4 Contact discovery | App propose retrouver contacts via répertoire et phone matching; autorisation OS facultative côté accès local, mais flux précis dépend mode et réglages. | WhatsApp dit utiliser les numéros de contacts pour fournir la fonction et ne pas partager sa liste avec Meta « pour ses propres fins ». | NDSS 2021 paper a crawlé 10% de numéros US; NDSS 2026 a rapporté enumeration de milliards de comptes puis indique issue de rate-limiting corrigée en collaboration. Deux dates distinctes, anciennes mesures ne prouvent pas vulnérabilité courante. | Téléphone requis et availability checks créent une surface OSINT; du hachage seul n’empêche pas lookup des numéros à faible entropie. | Release/endpoint actuel, rate-limit et champs répondus; test contrôlé post-fix, nouveaux usernames et privacy settings. |
| 5 Métadonnées serveur | Compte, téléphone, contacts upload/lookup, appareil, groupe, heure de connexion et données routage; WhatsApp dit ne pas garder un registre complet de qui parle à qui en routine. | Politique: aucune conservation normale des messages remis et des journaux de transaction; les logs targeted peuvent être collectés sur ordre PRTT valide. | Government guide en français détaille les informations de base et collecte prospective; Meta transparency fournit demandes par région/catégorie, pas trace complète des données livrées dans chaque cas. | E2EE ne chiffre pas identité, destinataire, horaires, group membership, IP de connexion ou logs légalement ciblés. | Journaux internes actuels, logs de routage/rétention par feature, volumes et audience analytics. |
| 6 IP utilisateur | Service voit connexions/IP; une PRTT peut déclencher collecte targeted d’IP/timestamps/type/sens de communication d’un compte. | Guide LE indique ces données pour un ordre valable; politique générale décrit traitements IP/diagnostics. | U.S. affidavit 2025 associe les PRTT records WhatsApp d’un compte à groupe/senders/volume/communications; underlying response not public. | VPN déplace observation IP vers VPN; numéro/compte reste un pivot. | Historique IP passif retenu et durée; relation entre service logs ordinaires et collecte prospective. |
| 7 IP au correspondant | Appel 1:1 peut utiliser P2P; “Protect IP address in calls” impose relais; appels groupe sont relayés d’après Meta. | Meta dit que le relais cache l’adresse IP au pair tandis que média reste chiffré E2EE. | Meta Engineering annonce déploiement du réglage et architecture; aucune capture faite ici. | En mode direct le pair peut obtenir l’IP, en relayé l’opérateur du relay voit les IP/temps. | Candidats ICE effectifs, exceptions et état par défaut selon versions/regions; comportement lors d’appel link/interop. |
| 8 Messages | Messages personnels 1:1 E2EE par défaut; service détient ciphertext pour remise temporaire, supprime quand livré selon LE guide; messages non remis supprimés après 30 jours. | WhatsApp/Meta disent ne pouvoir lire les messages privés E2EE. | Model-monitoring paper 2026 fournit une preuve indépendante partielle sur WhatsApp Web protocol execution, pas une inspection de backend ou binaire store-wide. | Un participant, endpoint, backup non chiffré, report par receveur ou notification peut exposer texte malgré E2EE réseau. | Les messages interactifs/IA, business, report flags, endpoints de backup/interoperability et exceptions spécifiques. |
| 9 Groupes | Group messages E2EE; serveur gère delivery et group membership. | Meta dit que groupes privés restent chiffrés; metadata de qui participe ou quand peut être nécessaire au service. | Research on Sender Keys and formal-model study; PRTT case records establish messages/group metadata available under law. | Participants peuvent exfiltrer/capturer et group key update/compromise changes trust. | Exact group sender-key implementation/version and membership metadata retention/server log fields. |
| 10 Appels | E2EE audio/video; WebRTC network can be direct or relay; group defaults relay. | Meta claims E2EE calls; Protect IP setting for 1:1. | Protocol design & help docs; no independent live packet capture/current call audit in this phase. | Media secrecy against server does not hide IP/timing/network endpoints. | Call signaling logs, selective recording/transcription, interoperable and business call paths. |
| 11 Fichiers | Attachments sent in encrypted message; client encrypts media before server delivery; business/cloud integrations can introduce other endpoints. | Help center says photos, docs, voice notes and location are E2EE between personal senders/recipients. | Signal-derived design public; no app binary/traffic test of all attachment formats. | Metadata such as sizes/time and media local preview/caches survive; recipient can save. | Thumbnail/index/key handling, AI scan boundaries, CDN retention, link/interop exceptions. |
| 12 Multi-device | Linked devices including web/desktop and companion devices; independent session keys/device synchronization. | WhatsApp says linked devices E2EE and account’s primary phone not required continuously. | 2026 academic monitor targeted WhatsApp Web specifically, finding model-compatible observed executions and differences from upstream libsignal. | Every linked device is an added endpoint/key and compromise surface; account management metadata exposes device set. | Cross-device history sync details, credential rotation, app version floor and sync artifact protections. |
| 13 Push | Mobile push via OS provider; push may signal new message and app fetches ciphertext; exact payload may vary. | Vendor says notifications do not reveal private content unless user preview settings expose locally. | No live APNs/FCM payload capture in this phase; current SDKs not inspected. | Apple/Google see token, app/device/time and network signals; lock-screen preview is user-controlled risk. | Push payload keys, token linkage/retention, SDK versions and regional behavior. |
| 14 Stockage local | App keeps database, encrypted message/attachment data or decrypted presentation/cache as needed; client/OS keys and linked devices matter. | WhatsApp relies on OS/device security; E2EE is transport/session guarantee. | Public forensic literature covers legacy Android/iOS builds; no contemporary commercial-tool test (versioned) established here. | Unlocked device/app process can access plaintext; disk encryption/device passcode governs seized locked case. | Current database schema/keychain/Keystore behavior and media cache by platform/version. |
| 15 Sauvegardes | Optional E2EE cloud backup exists; enable with password/key/passkey-style recovery as product supports; ordinary iCloud/Google backup historically has different trust. | WhatsApp says E2EE backup prevents WhatsApp/Apple/Google from accessing the backup if feature properly enabled. | Help/Meta engineering docs; not independently tested by restoring current builds. | Backup ciphertext protection does not repair plaintext already held by an unlocked endpoint; weak password permits offline guessing if format allows. | Default state per user/platform, passkey rollout details, metadata retained by cloud provider and recovery workflow. |
| 16 Analytics / SDK tiers | Meta apps integrate analytics/diagnostic/product and business services; store labels list categories. | Meta says private messages/contacts are not shared with Meta for its own purposes while some metadata/device/business service info is shared within Meta companies. | Apple App Privacy / Google Play Data Safety are developer-submitted disclosures; Google explains labels depend developer disclosure and have scope exceptions. No current binary SDK/runtime measurement made. | Labels, policy and code manifest can differ; neither store label alone establishes no collection. | Exact embedded SDK inventory, crash logs, attribution signals, data-flow per feature and actual Play vs App Store behavior. |
| 17 Code source | WhatsApp client app/backend closed source; upstream Signal libsignal is public but WhatsApp uses a fork. |
Meta describes Signal Protocol implementation and certain open-source dependencies. | 2026 paper reports previously undocumented differences between WhatsApp fork and libsignal; no source of client fork available for public review. | “Uses Signal Protocol” does not imply client parity; auditor/runtime evidence increases confidence only on studied Web execution. | Current precise fork version, proprietary verification code and code review scope. |
| 18 Builds reproductibles | No official public reproducible client build process for WhatsApp established. | Store publisher does not claim public exact-match reproducible builds in sources reviewed. | Closed app plus platform signatures means independent source-to-binary comparison unavailable in this evidence set. | Store attestation/signing identifies publisher/channel, not source semantics. | Internal build provenance, SBOM, in-toto/SLSA attestations, independent reproducibility program. |
| 19 Supply chain | Meta maintains closed clients/backend; Android/iOS app stores and FCM/APNs are dependencies; libsignal-derived implementation not equivalent to public libsignal. | Meta bug bounty/advisories demonstrate external report path. | 2026 CVEs listed below show recent patched client issues; academic 2026 found fork differences. | Signed update from legitimate vendor can still change implementation; store policy and dependency operations matter. | Full SBOM, active maintainers, signed release/tag, dependency pinning, patch latency by platform. |
| 20 Infrastructure OSINT | Central global Meta infrastructure, CDN/object/region services and push; no per-domain DNS/ASN snapshot captured. | Meta says globally distributed infrastructure / service providers. | Public infrastructure docs and transparency only; this investigation did not query passive DNS or ASN history. | Anycast/CDN/region routing cannot be inferred from brand; WhatsApp server may be separate by feature. | Exact current hostnames, ASN, regions, transit/cloud vendors, routing, retention and backup copies. |
| 21 Juridiction | WhatsApp LLC serves much of world; WhatsApp Ireland Limited handles EEA/UK region per corporate policies; data transfers subject to applicable law. | Policy and LE guide identify entity/address and processing; Meta global companies support service. | Court files show US PRTT process; official policies are first party. | Entity and physical storage do not alone dictate which legal process applies. | Case-specific data controller, cross-border transfer route, US/Irish objection and retention orders. |
| 22 Demandes policières | LE guide distinguishes preservation/basic account/subscriber/PRTT/emergency and says messages normally not retained once delivered; legal targeted collection may begin prospectively. | Meta says it reviews and responds to valid legal processes, may challenge overbroad requests. | Official guide includes examples of available data; official transparency report counts requests and compliance. | Authorities can obtain metadata even where they cannot request server-held E2EE plaintext; endpoint and cloud backup are separate routes. | Per-case actual fields, preservation details, emergency edge cases, content from report messages. |
| 23 Affaires judiciaires connues | U.S. v. [case 2:25-mj-30673-DUTY / 25-CR-?] 2025 amended complaint cites court-authorized PRTT records for account, group, senders and ~125 communications, range/timestamps and media types. | — | DOJ complaint is a primary affidavit but underlying company return is not attached. It demonstrates actual use of WhatsApp-returned records at least for communication metadata/group activity; some content wording's provenance cannot be independently separated from other investigative sources. | Count/media-type and participant/timing data were available from records; do not claim WhatsApp gave plaintext body based only on this affidavit. | Exact fields provided by WhatsApp, prospective vs retrospective interval and whether every excerpted message body came from handset/recipient/other source. |
| 24 Audits | No publicly established end-to-end independent audit of all current messenger app/backend/crypto found. Trail of Bits’ 2025 report covers Private Processing for AI, not ordinary WhatsApp conversations: 28 findings, 16 resolved, 4 partial, 8 open in that review’s final fix-status table. | Meta commissioned the scoped review; report also records its own point-in-time positive observations about enclave processing and post-processing retention. | Full ToB report with fix review; independent runtime/model research is separate and scoped. | Findings about Private Processing cannot be translated into a weakness or assurance for the main WhatsApp chat protocol; they do document insider/TEE, logs, metadata, supply-chain and transparency risks in the AI feature. | Current rollout/version, whether open findings were fixed after Aug 2025, and audit coverage of ordinary messaging/backend. |
| 25 Vulnérabilités | Meta advisories 2026: CVE-2026-23866 (AI rich-response arbitrary URL/custom scheme handling; iOS <=2.26.15.72 / Android <=2.26.7.10 listed range) and CVE-2026-23863 Windows attachment filename NUL spoofing before 2.3000.1032164386.258709. | Meta says no evidence of in-the-wild exploitation for these advisories. | Advisory primary source; current deployed versions/rollout not independently checked. | CVSS severity should be combined with prereqs/surface/patch status, not read as observed exploitation. | All current advisories and exact OS/app version mapping outside 2026 list; uptake on installed devices. |
| 26 Recherche académique | Contact-discovery abuse, Sender Keys, runtime monitoring of Signal/WhatsApp Web, and targeted prekey depletion research. | — | NDSS 2026 paper reports past number enumeration and says rate-limiting issue was resolved collaboratively; WOOT 2025 Prekey Pogo found targeted depletion risk affecting PFS/availability in tested builds; 2026 runtime paper verifies scoped model. | Research findings are scoped/time-specific; no proof of ongoing exploit after fix or E2EE general break. | Current prevalence/remediation, production code mapping, device/app versions on current channel. |
| 27 Incidents historiques | Number/contact enumeration, 2021 Facebook phone-number scrape, legal PRTT data and software CVEs are documented; these are distinct incident classes. | Meta says PRTT and platform protections evolve. | Peer-reviewed/publication and court/advisory evidence. | Historical phone exposure may enable social engineering even if account protections later change. | Breach notification details and whether current contact discovery has additional undisclosed issues. |
| 28 Gouvernance / société / financement | Owned by Meta Platforms, publicly traded parent with advertising business; WhatsApp operating entities under Meta. | Meta says WhatsApp retains boundaries on private messages while shares service/security/business-related data. | Meta privacy policy, SEC/court/regulator filings and EU regulatory actions provide external records; no internal governance audit here. | Commercial incentives and integration are relevant to non-message data; they do not by themselves prove E2EE deception. | Internal access controls, employee review policy, cross-company joins and product roadmap. |
| 29 Résistance à la censure | Central domains, app stores, SIM/SMS enrollment, Meta infra and push are blocking points; no federation. | Meta does not position WhatsApp as a circumvention tool. | No systematic country/ISP blocking study in this phase. | VPN can route around some IP blocks but not registration dependency, store removal or targeted lawful block. | Country-by-country service availability, registration bypass, protocol obfuscation. |
| 30 Maintenance actuelle | Official security advisories/releases continue through 2026; multiple client/platform channels. | Meta states supported versions and security patches via app stores. | 2026 advisory dates and app stores establish active maintenance; no installed-device patch survey. | Users on old versions remain exposed until store rollout/adoption. | Release cadence, percent patched, Android sideload/business versions and post-patch test. |
WhatsApp — audits et recherche approfondis¶
| Organisme / date / version / commit | Durée | Scope / méthodologie / exclusions | Findings / sévérité / recommandations / correction / retest |
|---|---|---|---|
| Moustafa Said, Aurora Naska, Kevin Morio, Robert Künnemann, From Specs to Apps: Verifying and Monitoring Models of Signal and WhatsApp, preprint 10 sept. 2026 / révision 12 sept.; WhatsApp Web, commit/build de production exact non publié dans abstract. | 3 person-weeks pour modèle WhatsApp Web, instrumentation, fuzzing/expériences selon le papier. | Instrumentation du runtime réseau/cryptographic components; modèles Tamarin compatibles; validation observée vs modèle symbolique, abstraction dépend d’extraction fidèle des événements. Pas audit du serveur, de toutes plateformes, du binaire mobile ou preuve mathématique du déploiement global. | Observed traces conform to model under stated abstraction; vérifie auth/secrecy des components core; découvre différences précédemment non documentées entre libsignal upstream et fork WhatsApp. Ce n’est pas une vulnérabilité démontrée ni une rupture E2EE. Publication arXiv 2609.11882; corrections/roadmap non identifiées dans le preprint résumé; retest inconnu. |
| Trail of Bits, Meta WhatsApp Private Processing Security Assessment with Fix Review, rapport final daté 26 août 2025 (PDF canonique; l’index ToB le classe août 2025, 12 engineer-weeks). Six consultants; travail 3–28 févr. 2025 : 2 engineer-weeks design/threat model, 6 infra, 4 code; fix reviews 23–25 avr. et 22–23 mai (5 engineer-days au total), confirmation partielle additionnelle le 12 août. | Le PDF ne donne pas de commit/SHA client pour les cibles; il couvre clients iOS/Android, libs C++, TEE server libs/infrastructure, transparency. Les identifiants de correction D… sont des références internes de changement Meta, pas des Git commit publics. |
Revue design + infra déployée dans le réseau interne Meta + code; accès sources, docs, hôtes/guests confidential-computing déployés. Révision manuelle, statique/dynamique, fuzzing interfaces host/TEE, vérification dépendances/CVE. Exclusions : canaux physiques/attaques de tampering non testés; extensions proposées non implémentées; Fastly OHTTP relay, Cloudflare transparency monitor, firmwares/drivers AMD/NVIDIA, analyse complète stack Llama exclus. C’est Private Processing/IA, pas un audit de WhatsApp Messenger ou Signal Protocol dans son ensemble. | Résumé et inventaire finding par finding ci-dessous. Le rapport dit avoir validé, pour l’implémentation observée, le traitement dans les enclaves et l’absence d’indication de conservation post-traitement; cela reste un résultat temporel/scopé, avec résiduels et exclusions explicités. PDF ToB, article ToB sur l’audit. |
| Meta Bug Bounty, CVE-2026-23866 et CVE-2026-23863, avis 2026. | Non publié. | Triage incident et correctif par éditeur, pas audit indépendant; versions affectées indiquées par plateforme. | iOS/Android AI rich responses pouvaient traiter une URL arbitraire et custom URL scheme; Windows NUL byte attachment extension mismatch pouvait afficher un type mais exécuter un fichier. Meta dit ne pas voir exploitation in the wild. Corrections: after listed version thresholds; aucune vérification indépendante du retest/rollout. Advisories 2026. |
Trail of Bits — inventaire des 28 findings Private Processing¶
Sévérités et états repris des tableaux de synthèse et de fix review du PDF. Les D… sont les identifiants de changements Meta rapportés par ToB, pas des hashes de commit vérifiables publiquement. « Résolu » désigne la conclusion du fix review, sans démontrer la version déployée en octobre 2026.
| ID / finding | Sévérité | Recommandation ou mitigation indiquée | Fix review / statut rapporté |
|---|---|---|---|
| WAPI-1 ACS key rotation peut dé-anonymiser | Medium | Rendre la configuration ACS cohérente entre clients (clé racine embarquée, dérivation à attributs, ou cache Fastly); signer et vérifier les preuves; éviter une rotation qui réduit l’anonymat. | Résolu : configuration/keys via Fastly et clé publique Meta codée côté client (D71515247, D71773542). |
| WAPI-2 ACS peut fournir des tokens aveuglés invalides | Medium | Fournir une preuve d’équivalence discrete-log et la vérifier au client. | Résolu : preuves servies et vérifiées iOS/Android (D69822878, D69829118, D70011790). |
| WAPI-3 rotation OHTTP peut dé-anonymiser | Medium | Configurer les clés HPKE de manière cohérente et authentifiée; utiliser un cache de configuration fiable. | Résolu selon rapport : clé/config via Fastly et signature Meta (D71515247, D71773542). |
| WAPI-4 ciblage géographique des clients | Informational | Séparer privilèges de changements clients/logs des privilèges de routage PoP→datacenter; randomiser durées/réutilisation des tokens pour réduire la corrélation. | Non résolu dans le tableau final; Meta dit évaluer les mitigations à l’échelle/steady-state. |
| WAPI-5 données sensibles d’inférence loguées côté client | Low | Détecter les formes de tokens et réponses sensibles dans les logs; alerter équipe produit et sécurité; contrôles dans hooks/CI. | Non résolu; Meta répond par principes généraux de code review/minimisation, sans correctif spécifique vérifié. |
| WAPI-6 attributs suivis permettant ciblage | Informational | Minimiser collecte/rétention d’attributs identifiants de temps, lieu, latence et usage; expliciter le risque dans le threat model interne. | Non résolu; Meta dit ne pas avoir observé de preuve que ces logs brisent la non-targetability. |
| WAPI-7 attestation sans fraîcheur | High | Lier l’attestation à un nonce client/TLS par session. | Résolu : client_random inclus et comparé (D74603096). |
| WAPI-8 TCB SEV-SNP non vérifié contre certificat VCEK | High | Vérifier les niveaux bootloader/TEE/SNP/microcode signés dans les extensions X.509 VCEK, pas uniquement les champs reportés par firmware. | Résolu : validation des champs VCEK étendue (D69724419). |
| WAPI-9 politiques Guest SEV-SNP non toutes appliquées | Informational | Imposer flags de politique guest stricts (debug, migration, SMT et protections disponibles). | Partiel : SMT désactivé au niveau hôte, contrôles client MIGRATE_MA/DEBUG; les autres flags n’étaient pas supportés par le kernel/KVM testé. Confirmation partielle datée du 12 août 2025. |
| WAPI-10 attestation non liée aux machines Meta | High | Restreindre l’attestation aux hôtes réellement contrôlés par Meta, par CA/provisionnement ou allowlist hardware ID vérifiée. | Partiel : enrollment trust-on-first-use et publication de digest VCEK; ToB dit que provenance/intégrité hardware ne sont pas entièrement garanties (D73932854, D73827419). |
| WAPI-11 TLS 1.2 et suites permissives | Informational | Passer à TLS 1.3; planifier le post-quantique pour résister au SNDL. | Résolu pour TLS : clients RA-TLS n’utilisent que TLS 1.3 (D69931378, D70004593); PQ traité séparément en WAPI-12. |
| WAPI-12 vulnérabilité SNDL post-quantique | Informational | Plan public de transition vers TLS et primitives PQ-hardened. | Non résolu au rapport final; Meta dit travailler à la transition et juge l’attaque moins probable avec ses protections d’anonymat. |
| WAPI-13 injection de variables d’environnement dans CVM | High | Parser/allowlister les variables et valider/quoting stricts, plutôt qu’accepter un fichier arbitraire. | Résolu : allowlist fixe et valeurs validées (longueur max 50, charset borné) (D72583676, D72805813). |
| WAPI-14 usage rsync non sûr | Informational | Éviter dereference symlink; --safe-links; séparateurs de fichiers NUL; éviter glob imprévisible. |
Résolu : copie temporaire sans -L, fichiers séparés par NUL et glob supprimé (D69858604, D71784233). |
| WAPI-15 modèles chargés comme pickle | Informational | Utiliser un format sérialisé moins dangereux / chargement poids seuls, ou retirer le chargement pickle de production. | Résolu : migration de la pile vers vLLM, les torch.load concernés ne sont plus exécutés en production (D70305933). |
| WAPI-16 taille de sortie LLM non masquée | Low | Padding de réponses (p. ex. Padmé) et plafond de longueur pour réduire fuite par taille chiffrée. | Non résolu; Meta reconnaît l’impact faible mais conserve un travail d’endurcissement. |
| WAPI-17 hyperviseur injecte des ACPI SSDT | High | Lier les tables ACPI à la mesure de boot et vérifier leur digest dans CVM. | Résolu : bootloader Stage0 custom, SSDT incluse dans measurement/digest attendu (D73804542, D73937575). ToB recommande de rendre QEMU command/artifacts publics. |
| WAPI-18 absence de reproductibilité des images CVM | High | Construire artefacts depuis sources versionnées, contrôler binaires mis en cache et publier provenance/digests reproductibles. | Partiel : dépendances contrôlées/manifests et sources plus ouvertes, mais images pas encore pleinement reproductibles; audit tiers depuis source seule impossible. |
| WAPI-19 digests artifacts privés ne préservent pas l’arborescence | Low | Hacher un paquet qui préserve structure/noms/metadata (ex. tar) et ajouter un namespace de domaine. | Non résolu dans le rapport final. |
| WAPI-20 namespace de transparence non imposé | High | Épingler namespaces attendus dans client et orchestrateur; lier le type TEE au certificat. | Résolu sur la protection principale par restriction de namespaces (D70708182); ToB recommande encore de distinguer explicitement le type TEE via SAN. |
| WAPI-21 artifacts de transparence sans expiration | Informational | Version minimale côté client et durée de preuve limitée. | Résolu : expiration selon type; image CVM expirait après 3 semaines (D70813884). |
| WAPI-22 ports I/O inutiles accessibles à hyperviseur malveillant | Medium | Allowlist explicite des ports; ne pas exposer le chargement firmware/blobs non mesurés. | Résolu : allowlist noyau pour ports, hors mode debug (D72410416). |
| WAPI-23 échec vérification transparency peut être silencieux | Low | Faire dépendre le démarrage CVM de la vérification et tester chemin négatif. | Résolu : dépendance systemd; startup échoue si preuve invalide (D70925617). |
| WAPI-24 versions Mbed TLS/OpenSSL avec CVE | Informational | Mettre à jour les dépendances et suivre les divulgations, notamment side-channel local. | Partiel : Mbed TLS 3.6.0 sur composants concernés; OpenSSL restait non corrigé à la revue (Meta invoquait coût perf/absence d’exploit concret). |
| WAPI-25 protections Spectre absentes | Informational | Ajouter les flags noyau recommandés et désactiver SMT lorsque requis. | Résolu selon rapport : options mitigations ajoutées au kernel CVM (D70646271). |
| WAPI-26 fuite tokenizer LLM via cache side-channel | Informational | Réduire SMT; tokenizer avec accès mémoire moins dépendants du secret/hash rerandomisé, ou tokenisation côté client; étude dédiée. | Non résolu; aucun side-channel n’a été exécuté pendant l’audit; risque et capacité réelle restent à mesurer. |
| WAPI-27 transparency dépend d’une partie centrale honnête | Informational | Lier cryptographiquement les epochs et utiliser un journal append-only/Merkle vérifiable. | Non résolu; Meta envisage une vérification cryptographique dans une itération future. |
| WAPI-28 LLM GPU sans vérification attestation NVIDIA | High | Vérifier preuves GPU/attestation avant chargement du service. | Résolu : utilitaire NVIDIA nvtrust vérifie rapports avant lancement (D70814218); RIM encore embarqués dans build, provisioning/révocation runtime futurs. |
Résultat agrégé ToB au 26 août 2025 : 16 résolus, 4 partiellement résolus, 8 non résolus. Aucun des statuts n’atteste l’état déployé aujourd’hui. Les quatre « partiels » sont WAPI-9, -10, -18, -24. Les huit ouverts sont -4, -5, -6, -12, -16, -19, -26, -27. Cet audit ne doit pas servir à caractériser le chiffrement des chats ordinaires : il concerne une fonctionnalité distincte de traitement IA sous TEE.
Recherche vulnérabilité protocol-level. Prekey Pogo (USENIX WOOT 2025) décrit une attaque ciblée d’épuisement des one-time prekeys d’un appareil WhatsApp pouvant dégrader PFS pour certains messages et disponibilité/confidentialité sous conditions; cela n’équivaut pas à déchiffrer toutes conversations. Papier WOOT [accès à vérifier]. Hey There! You Are Using WhatsApp (NDSS 2026) a énuméré >100 M numéros/heure dans un test avant correction, réutilisation/prekeys multi-comptes observées; version mise à jour déclare que les auteurs ont collaboré et rate-limit sous-jacent corrigé. NDSS 2026. Ne pas présenter ces anciens états comme vulnérabilité active le 13-10-2026.
Mobile/privacy labels. Apple listing et Google Play Data Safety sont les déclarations éditeur. Le Help Center répond à l’étiquette Apple et affirme que contact list n’est pas partagée avec Meta pour ses propres fins; Apple regroupe certaines catégories sous “linked to you”; Google documente que les développeurs soumettent les catégories et certaines collectes transitoires/non stockées sont hors-scope. Ce n’est pas une analyse binaire. Manifestes, permissions actuelles, Firebase/APNs/SDK list, camera/mic/location/photos permissions, diagnostics, contact discovery payload et crash runtime n’ont pas été mesurés dans cette phase. Sources: WhatsApp privacy label explainer, Google Data Safety methodology, Apple developer privacy disclosure.
Repos/builds/infrastructure. Main client binaries, server and official apps are proprietary; protocol lineage is documented but no source-to-store deterministic build is provided. signalapp/libsignal is not WhatsApp’s complete fork. Full dependency inventory, SBOM, signature verification and active maintainer count of private repositories unavailable. Meta global infrastructure and partner disclosures are public at high level; exact WhatsApp domain DNS/ASN/CDN/regions were not passively snapshotted here. Store labels and policy cannot establish exact FCM/APNs payload or analytics SDK behavior.
Forensics and legal evidence. No reproducible literature result in this dossier names Cellebrite UFED/PA, GrayKey or Magnet + exact OS version + WhatsApp build + extraction date and proves present capability. Public forensic papers mostly concern older builds/OS; must be treated as historical, not current. The 2025 U.S. affidavit/court-file excerpt for 2:25-mj-30673-DUTY reports court-authorized PRTT records associated with an account, group, participants, approximate 125 communications and transmission date/type data. The actual underlying company return is not public; the complaint’s message excerpts could derive from other sources. The government guide confirms prospective metadata collection, while saying normal operations do not retain messages after delivery or transaction logs; this is not contradictory if the PRTT order triggers targeted collection. It does not establish that WhatsApp handed over E2EE plaintext in that matter. WhatsApp LE guide FR, DOJ case record.
WhatsApp — matrice des métadonnées¶
| Métadonnée | Fournisseur Meta / WhatsApp | Contact | ISP | Apple / Google | Autorités |
|---|---|---|---|---|---|
| IP | CONFIRMÉ service sees; PRTT can collect prospective targeted IP/time | POSSIBLE direct 1:1 call | CONFIRMÉ network sees | POSSIBLE store/push/IP account separate | CONFIRMÉ where valid PRTT/record exists; exact log interval unknown |
| Téléphone | CONFIRMÉ in legacy account; usernames may alter contact presentation | CONFIRMÉ or POSSIBLE by privacy/new username feature | CONFIRMÉ carrier knows subscriber/SIM, not app chat | POSSIBLE by store account separate | POSSIBLE/CONFIRMÉ as subscriber info if request |
| POSSIBLE account/support/backup/business | POSSIBLE profile | NON ACCESSIBLE PAR DESIGN | CONFIRMÉ store identity if supplied | POSSIBLE if retained/account-linked | |
| Identifiant | CONFIRMÉ account/device IDs and phone | CONFIRMÉ profile/name/number as shown | POSSIBLE traffic correlation | CONFIRMÉ app install/device/account signals | CONFIRMÉ basic subscriber records and device info when available |
| Graphe social | PROBABLE contacts/delivery/groups; WhatsApp says not routinely logging who everyone messages | CONFIRMÉ conversation participants | POSSIBLE traffic correlation | NON ACCESSIBLE PAR DESIGN except app-store usage | CONFIRMÉ in documented PRTT case for a group/participants |
| Timestamps | PROBABLE delivery/session metadata; targeted PRTT confirms time | CONFIRMÉ message/call time | CONFIRMÉ IP session/time | POSSIBLE push/install events | CONFIRMÉ targeted PRTT time; normal history retention varies |
| Volumes | POSSIBLE/PROBABLE store/metadata; exact fields unknown | CONFIRMÉ message counts/media size | CONFIRMÉ bytes | POSSIBLE app diagnostics | PROBABLE from record types; underlying disclosure not fully public |
| Groupes | CONFIRMÉ membership/routing data may be returned; policy/account info can include groups | CONFIRMÉ group members | POSSIBLE only traffic patterns | NON ACCESSIBLE PAR DESIGN by store | CONFIRMÉ group data referenced in 2025 PRTT affidavit |
| Appareils | CONFIRMÉ linked devices / device type | POSSIBLE linked sessions/status | POSSIBLE fingerprint | CONFIRMÉ store device association | POSSIBLE device/basic account fields under process |
| Push tokens | PROBABLE APNs/FCM and Meta delivery backend | NON ACCESSIBLE PAR DESIGN to peer | NON ACCESSIBLE PAR DESIGN | CONFIRMÉ token holder provider, exact token retention unknown | POSSIBLE via Meta/provider process |