Wire — dossier de preuves individuel (référence : 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.

Registre de preuves en 30 catégories¶

Chaque ligne sépare le fait documentaire du discours éditeur et de l’inférence. « Inconnu » signifie que les sources consultées ne permettent pas de conclure, non que la donnée n’existe pas.

# / catégorie	FACT	VENDOR CLAIM	INDEPENDENT EVIDENCE	INFERENCE	UNKNOWN
1. Architecture	Wire Cloud est un service centralisé avec backends, bases, DNS, relais d’appel et files de remise; le serveur est publié sous licence open source. Wire documente aussi l’auto-hébergement et la fédération entre backends. Architecture, serveur	Wire présente son cloud comme hébergé en Europe et offre du cloud privé / on-prem à des clients entreprise. Options	La documentation de déploiement exige plusieurs services (API, asset store, webapp, comptes; optionnels SFT/fédération); ce n’est pas un réseau pair-à-pair. DNS/deploiement	Le mode personnel public concentre le pouvoir opérationnel chez Wire; un backend privé déplace la confiance vers l’administrateur client.	Architecture physique exacte du Wire Cloud courant, concentration réelle par compte, mécanisme de consensus/indépendance des fédérations, topologie de secours.
2. Protocole cryptographique	Documentation de sécurité distingue Proteus et MLS. Proteus combine Double Ratchet, préclés/X3DH, X25519, ChaCha20, HMAC-SHA256, HKDF et Ed25519. MLS est l’autre protocole E2EE documenté; la mise à jour standard vers MLS est annoncée le 24 mars 2026. Whitepaper, migration MLS, RFC 9420	Wire annonce E2EE, forward secrecy et post-compromise recovery selon protocole/configuration.	La thèse ETH 2023 a trouvé des attaques de sécurité dans l’intégration Proteus de l’époque et des problèmes de conception de l’intégration MLS alors en développement; elle ne teste pas le produit de 2026. Thèse [accès à vérifier]	La présence d’un standard MLS ne prouve pas que tous les clients, conversations, appels et versions utilisent partout un même profil; une transition coexistante Proteus/MLS reste documentée.	Build courant et sélection du protocole par plateforme/type de conversation; paramètres MLS, ciphersuites réellement négociées après retrait de Kyber, garanties d’authentification/PCS par mode.
3. Création d’identité	Pour le compte Messenger, la politique exige username, email et mot de passe; inscription par double opt-in; Wire peut conserver horodatages de création/vérification et IP d’inscription. Les comptes entreprise peuvent employer SAML/SSO. Politique, whitepaper sécurité	Wire dit qu’email et mot de passe sont utilisés pour assurer le compte et que des informations de profil supplémentaires sont facultatives.	L’affaire espagnole de 2024 montre qu’une adresse email d’inscription a effectivement été remise en réponse à une demande légale. TechCrunch, citant des pièces judiciaires [accès à vérifier]	Un pseudonyme de profil n’isole pas d’une adresse email réutilisée ou corrélable; compte Wire personnel n’est pas anonyme par défaut.	Possibilité actuelle d’inscription sans email avec tous clients; seuils anti-abus, CAPTCHA, attributs conservés après suppression, possibilités de paiement anonyme entreprise.
4. Contact discovery	La recherche Wire permet la découverte par nom ou username; le résultat peut inclure nom d’affichage, username et photo. L’équipe peut restreindre la découverte à un username exact. Privacy Whitepaper	Le livre blanc décrit le carnet d’adresses comme optionnel et affirme que les numéros hachés sont traités pour recherche sans téléverser le carnet complet.	Aucun protocole PSI/TEE ni mesure de requête réseau actuelle n’a été trouvé; le hachage simple, s’il est employé, ne rend pas un espace de numéros faible non devinable.	Recherche nominative centralisée crée une surface d’énumération et de corrélation; la confidentialité dépend des paramètres et de la version.	Algorithme actuel de découverte, sel/OPRF/PSI éventuel, limitation de débit, données exactes vues lors d’une recherche et rétention.
5. Métadonnées serveur	La politique actuelle (mise à jour oct. 2025) dit que logs techniques sont collectés à chaque accès, conservés max. 90 jours; profil conserve username, display name et email pendant la vie du compte. Le backend connaît auteur, date UTC, participants et leurs appareils, nom et rôles des groupes; ces métadonnées ne sont que chiffrées en transport. Politique, privacy paper	Wire dit minimiser les données et ne pas accéder au contenu des conversations.	Le whitepaper précise aussi noms de dossiers et associations conversation/dossier en clair sur le backend; l’architecture de remise requiert identifiants appareils et état de file.	Wire Cloud détient suffisamment de métadonnées pour relier comptes, groupes, appareils et opérations serveur, sans déchiffrer le contenu E2EE.	Schémas et rétentions courants par microservice; logs API complets; requêtes d’accès interne; durée réelle des logs et des événements de remise.
6. IP utilisateur	Politique dit que l’IP d’inscription peut être enregistrée et que logs de service durent jusqu’à 90 jours; le site public a une politique séparée avec IP des visiteurs de site jusqu’à 30 jours.	Wire ne vend pas les données et ne fait pas de publicité ciblée; cette déclaration n’équivaut pas à absence de collecte IP.	Les docs réseau listent des API, assets, TURN et SFT centralisés. Domaines/ports	Un opérateur de service reçoit nécessairement une IP source lors de connexion directe au cloud; un VPN déplace la confiance vers l’opérateur VPN et ne supprime pas les corrélations temporelles.	Quelle IP parvient à chaque composant, conservation des logs API hors catégorie annoncée, adresses des utilisateurs derrière proxy/VPN, conditions légales de remise par cas.
7. IP exposée au correspondant	Wire documente appels WebRTC directs quand possible, TURN/Co-TURN si connexion directe impossible et SFT pour conférences; TURN/SFT changent le chemin réseau. Support réseau	Le whitepaper affirme que TURN masque l’adresse peer quand l’appel est relayé et que ses relais sont séparés du backend utilisateur.	Les rapports 2017–18 n’ont pas audité ICE/WebRTC dans son ensemble ni l’analyse de trafic; ils ne valident donc pas chaque chemin 2026. Audit Web/Calling	En appel direct, le pair peut obtenir l’adresse réseau candidate via ICE; un relais peut la masquer au pair mais connaît lui-même l’IP source.	Comportement réel par client, option « masquer IP », IPv6, appel 1:1/groupe et stratégie de sélection ICE sur chaque version actuelle.
8. Messages	Wire affirme que texte, voix, vidéo et documents partagés dans les conversations sont E2EE; messages chiffrés mis en file hors ligne puis supprimés après livraison. Politique	Wire déclare ne posséder aucune clé de déchiffrement et ne pas avoir de backdoor.	Privacy paper décrit une file de messages par utilisateur/appareil et métadonnées associées, avec rétention de queue de quatre semaines dans une autre section; c’est une différence de périmètre à résoudre avec la formulation « immédiatement supprimé après livraison ».	Le contenu ciphertext doit rester accessible au serveur avant livraison; après livraison, il peut subsister une copie locale ou autre appareil/capture.	Distinction actuelle exacte entre message payload, notification queue, états/cursors et backups; vérification expérimentale de purge réelle après livraison.
9. Groupes	Backend stocke participants et appareils, créateur, timestamp, nom et rôles. Wire annonce migration des conversations vers MLS; MLS permet l’état de groupe cryptographique, mais ne cache pas la liste au backend dans cette architecture. Whitepaper privacy, MLS	Les messages de groupe sont E2EE et les administrateurs contrôlent membres/guests selon options entreprise.	Thèse ETH 2023 a étudié redirection de groupe / confidentialité sous serveur malveillant dans des versions antérieures; non retesté ici sur integration actuelle.	L’ajout d’un appareil ou participant et les métadonnées du groupe sont des surfaces critiques distinctes de la confidentialité des messages.	Assurance d’ajout/suppression et gestion des groupes mixtes Proteus/MLS; audit MLS en production, guests anonymes, limites de taille et logs admin.
10. Appels	Clients utilisent WebRTC, SRTP et mécanismes Wire de signalisation/établissement de clés; 1:1 peut être direct ou TURN; conférences passent par SFT puis éventuellement TURN.	Wire présente voix/vidéo comme chiffrées de bout en bout; le fournisseur décrit SFT comme relais de paquets chiffrés.	L’audit X41/Kudelski 2018 s’est limité à la signalisation et à certains aspects de protocole; codecs, WebRTC complet, ICE, traffic analysis et dépendances tierces étaient exclus.	Chiffrement du média n’empêche pas le relais de voir IP, horaires, participants routés, volumes et durée.	Vérification du chemin, suites cryptographiques et réduction de visibilité par type d’appel/plateforme actuelle; audits indépendants récents de SFT.
11. Fichiers	Pièces jointes conversationnelles sont incluses dans la déclaration E2EE; Wire Drive distingue stockage documentaire chiffré au repos/en transit mais pas E2EE. Politique, Support	Wire annonce partage de fichiers E2EE dans les conversations.	La documentation de déploiement distingue service d’assets; cette URL/infra traite les blobs, tandis que chiffrement E2EE dépend du type de fonctionnalité utilisé.	Confondre pièce jointe dans un chat et Wire Drive crée une erreur de périmètre; nom de fichier/metadata peuvent être séparés du contenu crypté.	Parité des clients, thumbnails, EXIF, liens prévisualisés et détails actuels du protocole Wire Drive/retention.
12. Multi-device	Chaque client a une clé d’identité publique et peut avoir des sessions/chiffres propres; backend conserve l’inventaire participant-appareil. Le store Android annonce jusqu’à 8 appareils. Sécurité, Google Play	Wire dit que les appareils sont vérifiés et que l’état MLS peut être attesté via certificats X.509 pour backend d’entreprise/on-prem.	Whitepaper décrit fingerprint manuel par appareil sous Proteus, vérification MLS conditionnée à la confiance dans le backend CA; ajout appareil fait passer une conversation en état « dégradé » tant que non vérifié.	Appareil secondaire est une nouvelle frontière cryptographique et peut donner accès à l’historique futur; ajout silencieux serait important mais non prouvé ici.	Flux exact actuel d’ajout/suppression, synchronisation de vérification entre appareils, mécanismes de recovery et portée des clés/certificats sur Wire Cloud.
13. Push	Android utilise FCM, iOS APNs; push contiendrait UUID associé et signal de réveil, puis client récupère la queue; F-Droid contourne FCM via websocket permanent. Privacy Whitepaper	Wire dit que les push ne contiennent pas de contenu et offre F-Droid sans FCM.	Apple/Google peuvent voir existence app, token d’installation, IP et horaires d’échanges push par conception des services OS; contenu exact dépend du payload réellement transmis.	Push réduit certains coûts mais introduit observateur OS-tier; WebSocket évite FCM côté Android mais garde IP/horaires visibles à Wire/ISP et augmente consommation.	Payload réseau actuel Apple/Google, token lifecycle, notifications de groupe, mode iOS alternatif, nombre de réveils et éventuelle corrélation identifiant↔compte côté OS.
14. Stockage local	Clients ont bases locales, éléments chiffrés/déchiffrés, clés et caches pour fonctionnement multi-device; l’audit Android a examiné stockage, partages et WebViews en 2017.	Wire dit que messages restent sous contrôle utilisateur et peuvent être supprimés localement.	Anciens audits ont trouvé risques de path traversal, intents et caches; cela documente surfaces/version de 2017, pas comportement de l’app actuelle.	Un appareil déverrouillé ou session active expose le plaintext, indépendamment d’E2EE; partage de logs par l’utilisateur est une voie d’exfiltration volontaire.	Schéma/algorithme exact de chiffrement de DB actuelle, clés Android Keystore/iOS Keychain, caches supprimés, état notification/clipboard, protections OS et retention locale.
15. Sauvegardes	La documentation consultée ne décrit pas une sauvegarde consumer de messages E2EE équivalente à iCloud/Drive; l’admin peut exporter des données d’équipe selon outils.	Wire dit qu’une suppression de compte supprime les données associées côté service.	Aucune publication indépendante n’a vérifié les fichiers de sauvegarde système actuels, clés d’app ou restauration sur iOS/Android.	L’absence de fonctionnalité « backup » identifiée ne signifie pas absence de copies OS, exports, cache ou copies de destinataire.	Inclusion/exclusion des données Wire dans iCloud/iTunes/Android backup, chiffrement et restauration; durée des éléments chez correspondants et appareils désinstallés.
16. Analytics / SDK tiers	Politique actuelle indique Countly avec consentement, auto-hébergé par Wire en UE, events/crash/usage; pseudonyme, version, modèle/OS et IP traitée mais non conservée selon la politique; données max 365 jours. APNs/FCM et Zendesk sont mentionnés; stores peuvent recevoir crash reports opt-in OS. Politique, whitepaper	Wire affirme que Countly n’est pas lié au compte et n’est pas partagé avec Countly Ltd; F-Droid et backend custom n’envoient pas ces métriques selon le whitepaper.	Google Play et App Store privacy labels sont auto-déclarés; ils ne certifient pas les flux. SDK/manifests de binaires exacts non extraits pour cette enquête.	Version Play, F-Droid, iOS, web et build entreprise peuvent différer nettement; l’analytics du site (HubSpot/Google Analytics) n’est pas l’analytics du Messenger.	Liste complète des SDK embarqués en 2026, endpoint réel, opt-in effectif, rapports OS, crash uploads et consentement entreprise par déploiement.
17. Code source	Dépôts publics existent pour serveur, Android, iOS, webapp, signalling et composants cryptographiques; serveur est sous licence AGPL (clients selon repo GPLv3). Org Wire	Wire affirme que le code publié permet une inspection et propose des déploiements autonomes.	Android README décrit variante F-Droid sans clés/API Play et lib AVS ouverte; binaire Play contient améliorations AVS propriétaires. iOS README décrit amélioration AVS propriétaire dans Store, absente du source ouvert. Android, iOS	« Open source » ne signifie pas identité source↔binaire officielle, ni service cloud identique au dépôt.	Inventaire précis des composants fermés actuels (AVS, SDK), écarts de config et licences pour chaque store/build.
18. Reproductibilité	Releases Android récentes ont des tags/commits GitHub « Verified »; F-Droid compile une version source publiée. iOS source compile mais APNs dépend de signature/configuration du développeur. Release Android, F-Droid	Éditeur affirme une certaine transparence et publie source/build docs.	Aucun binaire App Store/Play courant n’a été reproduit ni comparé bit à bit dans cette enquête; parties AVS propriétaires empêchent une reproduction exacte à partir du seul source public.	Tag signé vérifie attribution/intégrité Git, pas reproductibilité ni conformité du binaire distribué.	Attestations SLSA, provenance store, reproduction actuelle indépendante, hashes comparatifs, reproducible release pour iOS et Play.
19. Supply chain	Dépôts GitHub publics exposent commits, CI et dépendances; politique de sécurité demande rapport privé, dernière version supportée et traitement annoncé. SECURITY.md	Wire décrit une coordination responsable avec délais et divulgation publique après correction.	Advisory iOS CVE-2026-35049 est public; releases Android récentes signées; les audits historiques ont couvert des dépendances ciblées seulement.	Clés de signature store, pipeline propriétaire, dépendances binaires AVS et mise à jour restent des points de concentration.	Couverture CI/secret scanning actuelle par repo, provenance officielle des stores, nombre de mainteneurs, attestations/build isolation et retests de fix.
20. Infrastructure	Wire publie les domaines client, TURN et SFT; ses IP de load balancer sont dynamiques. Support	Livre blanc dit données clients stockées en Europe; déploiement Wire peut utiliser AWS, Azure, StackIT, autre cloud ou on-prem. Options	Snapshot DNS/BGP du 14 oct. 2026 : les pools `prod-nginz-https`, `prod-nginz-ssl`, `sft.calling-prod-v01` et trois des quatre cibles TURN observées routaient par AS16509 (Amazon). Une cible TURN (`18.184.5.76`) n’a pas de préfixe RIPEstat vérifié dans cette passe.	Cela établit un routage réseau observé pour les adresses répondues, pas que Wire détient les serveurs, où les données sont stockées, ni que tous les appels/utilisateurs utilisent ces cibles.	Région et propriétaire de chaque instance, origin/CDN, backends, trafic réel, rétention/logs, autres points d’accès et changements de pool.
21. Juridiction	Wire Swiss GmbH, Zug, Suisse; droit suisse de protection des données; Wire Germany GmbH est représentant UE RGPD. Politique légale	Wire indique que les demandes étrangères passent par les autorités suisses/entraide selon son rapport historique.	Cas 2024 confirme requête espagnole transmise par voie suisse et réponse de Wire par email d’inscription. Dossier presse/court records [accès à vérifier]	La juridiction ne neutralise pas une donnée existante; l’email de compte a été techniquement récupérable et communiqué.	Propriétaire ultime/gouvernance actuelle, lois d’interception et obligations applicables précisément à la forme Wire Cloud; changement depuis ancien rapport de transparence.
22. Demandes policières	Transparency report officiel historique publie 2018: 1 requête valide/8 comptes impactés (+2 rejetées); 2019: 192 requêtes/142 comptes (+7 rejetées); 2020: 349/310 (+3 rejetées). Rapport PDF	Wire déclare ne pas pouvoir produire le contenu E2EE; le rapport dit coopération selon droit applicable.	Cas 2024: Wire a effectivement remis l’email d’inscription lié au compte ciblé, lequel était un email Proton; pas de contenu chat Wire remis établi dans cette procédure. TechCrunch [accès à vérifier]	Les agrégats attestent requêtes, mais seuls les documents du cas et la confirmation Wire établissent quel champ a été remis dans cette affaire.	Données précises pour chaque demande 2018–20, taux et champ par request, rapport après 2020, warrant/subpoena guides, données urgentes et existence d’ordres de conservation.
23. Affaires judiciaires	Procédure espagnole visant un activiste catalan (requête 2024) a utilisé email d’inscription fourni par Wire; police a ensuite interrogé Proton et Apple.	Wire dit avoir répondu à une demande officielle en fournissant le seul identifiant email demandé/disponible selon les éléments rapportés.	Court documents consultés par TechCrunch décrivent la chaîne et l’email remis; la police obtient ensuite identité/adresses auprès d’Apple.	C’est preuve réelle de divulgation d’un identifiant, non d’accès Wire au contenu ou d’interception live. Les captures de conversations annexées au dossier ne prouvent pas leur provenance serveur.	Copie primaire complète des requêtes/ordres et du retour Wire, champs/horaires exacts, éventuel contenu Wire produit autrement.
24. Audits	Rapports publics Kudelski/X41 2017–18 ont examiné Proteus/Cryptobox, clients Android/iOS et web/signalling; détails ci-dessous.	Wire indique avoir corrigé ou mitigé findings et, pour plusieurs rapports, auditeurs ont revu patchs.	PDFs complets donnent commit, durée, scope/exclusions, sévérités; ce sont audits ciblés datés, pas certification du produit actuel.	L’existence d’audits améliore l’historique d’évidence, mais échéance/versions (2016–17) rendent impropre une validation globale 2026.	Audits indépendants post-MLS/serveur/app actuelle, fréquence de retest, portée backend/cloud, push, store binaries et SFT moderne.
25. Vulnérabilités	GitHub Advisory iOS CVE-2026-35049: clients <4.16.0 peuvent recevoir un payload Proteus malformé de moins de 16 octets et entrer dans une boucle de crash; corrigé en 4.16.0 le 29 mai 2026. Advisory	Le dépôt marque la version fixée et l’éditeur a diffusé le correctif.	Advisory classé modéré/CVSS 6.5, vecteur disponibilité, attaque par message sans interaction selon advisory; aucune exploitation réelle signalée dans la source.	Les anciennes installations restent vulnérables si non mises à jour; pas de preuve qu’un adversaire ait exploité le bug.	CVE/NVD final, nombre de versions réellement exposées, diffusion Store par pays, rapport de retest/forensic, autres advisories privés.
26. Recherches académiques	Thèse ETH Zürich 2023 (Andreas Tsouloupas, 111 p.) analyse attaques contre versions Wire utilisant Proteus et design MLS de l’époque. DOI / thèse [accès à vérifier]	La documentation Wire actuelle décrit MLS/Proteus et leurs garanties attendues.	Travail académique indépendant rapporte notamment faiblesse PCS sous certains adversaires et attaques de redirection/ordre/confidentialité pour l’intégration étudiée; ce n’est pas un audit de production 2026.	L’étude est pertinente comme historique et liste de conditions de menace à retester, non comme affirmation qu’une attaque actuelle est confirmée.	Mapping commits corrigés à la thèse, publication de réponses Wire, réplication et analyse de la génération MLS actuelle.
27. Incidents historiques	Historique documenté ici : findings/audits 2017–18, CVE iOS 2026, et divulgation légale 2024.	Wire annonce correction des problèmes et limitation des données par E2EE.	Aucun incident public de déchiffrement massif ou compromission de Wire Cloud n’a été identifié dans ce corpus; cette absence n’établit pas qu’il n’y en a jamais eu.	Un bug de disponibilité n’est pas compromission de confidentialité; une divulgation email légale n’est pas une fuite accidentelle.	Timeline exhaustive de pannes, incidents internes, sous-traitants, notification de breach, accès internes et rapports CERT.
28. Gouvernance / société / financement	Entité légale active et contrôleur indiqués: Wire Swiss GmbH (Zug); représentants allemands documentés.	Wire se présente comme entreprise européenne/suisse de communication sécurisée.	Sources publiques consultées n’établissent pas de manière fiable propriétaire ultime, parts, financement actuel ou droits de contrôle.	Identité suisse de l’entité contractante est établie, mais elle ne répond pas à la question du contrôle économique.	Bénéficiaires effectifs, actionnaires 2026, financement, conseil, structure de holding, clauses de changement de contrôle.
29. Résistance à la censure	Wire Cloud dépend de domaines documentés, DNS, IP/load balancers, stores mobiles, FCM/APNs et endpoints centraux; Wire documente federation et self-hosting.	Wire propose déploiement privé et autonome pour organisations.	Aucun test DPI/mesure OONI ou blocage par pays n’a été mené; DNS dynamique est dit par le support, non mesuré ici.	Le service central public est bloquable par domaine/IP/store; fédération/on-prem peuvent aider une organisation à diversifier, mais ne constituent pas un mécanisme de contournement anonyme.	Mesures de disponibilité par pays, résistance à DPI, bridges/proxies, installation alternative, conséquences de révocation de certificat/app.
30. Maintenance actuelle	Au 13 oct. 2026, Android 4.36.1 (9 oct., commit `240b2a0`, signature GitHub vérifiée); iOS 4.28.0 (28 sept. selon release repo); backend publie des releases et le 12 juin 2026 a retiré une suite hybride Kyber faute de support dans sa branche OpenMLS. Android releases, iOS releases, serveur	Wire décrit support continu et mises à jour sécurité.	Activité des dépôts/release tags est vérifiable; pas de comptage reproductible des mainteneurs actifs ni test de publication Store réalisé ici.	Le retrait de Kyber signifie que le PQ hybride évoqué antérieurement n’est pas attesté comme activé dans la release serveur indiquée; « agilité » n’est pas protection PQ présente.	SLA vulnérabilité actuel, proportion de clients actifs par protocole, support versions, validité signatures tags, mainteneurs effectifs et plan PQ.

Wire — extraction d’audits (rapports primaires lus)¶

Organisme / date / commanditaire	Version / commit	Durée / méthode	Scope et exclusions	Findings, sévérité	Correctifs / recommandations / retest
Kudelski Security + X41 D-Sec, rapport public 8 fév. 2017, commanditaire Wire Swiss GmbH	Proteus `6b317191` (préfixe de révision donné dans le PDF) en Rust/CoffeeScript, Cryptobox API/C et sérialisation CBOR; revue basée sur dépôt à la date indiquée.	14 jours-personnes, 23 nov. 2016–9 janv. 2017; revue surtout manuelle de code, spécification et composants fournis (~3300 lignes Rust, 2400 CoffeeScript, 400 C).	Protocole/librairies et API; ne couvre pas app complète, backend, appels, push, déploiement ou toute la supply chain. PDF	14 findings: 5 MEDIUM et 9 LOW, aucun critique/élevé. Findings: clés DH dégénérées/invalides non rejetées, thread-safety en Rust/JS, valeurs secrètes non effacées, chaînes C et pointeurs, longueur prekey, buffer overread tests, overflow et parser CBOR laxiste.	Recommande valider clés/erreurs, effacer secrets, corriger thread-safety et parser strictement. Des corrections sont liées dans certains constats; pas de retest actuel/indépendant annoncé pour la version 2026.
Kudelski + X41, Phase 2 Android, 7 mars 2018	Android client, commit `4135eada…`; sync engine `565b72cb…`; versions de travail 2017.	9 jours-personnes, mars–nov. 2017; revue source + tests dynamiques sur APK officiel, émulateurs, appareils de test rootés.	Android app et sync; core Proteus, appels, dépendances tierces exclus. PDF	6 findings: 1 élevé, 5 faibles; chemin de traversal lors d’enregistrement fichier (élevé), PRNG / LZW, WebView remote content, intent URI fichier non assaini, deep link pouvant forcer déconnexion.	Rapport décrit assainissement canonical path/URI, validation, ouverture navigateur, correctifs; il indique patches et revue des changements. Aucun retest de l’app actuelle.
Kudelski + X41, Phase 2 iOS, 7 mars 2018	Huit commits testés : cryptobox `8e96cccb35b259187e590ca75e969cde7a6e2efd`; data-model `54302381324dfcd017154d4e59590905610d956e`; images `ba105ea632251fcadd9f388ed319e8300164ace9`; message-strategy `22e7c4210e10acfc37963b3f2e2e108496a48190`; share-engine `1aba9b92931073d6050cecc18059863cf7ebe1d2`; sync-engine `dd66a9fc2a056e320a2f62fca277cb233042147f`; system `db0abf2504f16b4c2ae67e6feaa454d1c08d843b`; transport `967db8121677940aa59b101139b6731b61977a3c`.	10,75 jours-personnes, août–nov. 2017; revue source et tests dynamiques sur app officielle / appareils de test jailbreakés.	Client iOS; Proteus, appels et dépendances tierces exclus. PDF	4 issues: 1 faible, 3 moyennes; clé WebSocket fixe réutilisée, crash sur preview PDF malformé, format strings non sûrs, collisions de cache d’assets fondées sur nonce.	Recommande clé aléatoire, validation PDF/format strings et clé cache distincte; rapport dit que patches ont été corrigés et revus. Pas de retest récent.
Kudelski + X41, Phase 2 Web/Calling, 7 mars 2018	`wire-webapp` `ef30665e6824047a60af00405b10758897db46fa`; signalling `99799d12f49fcddf7252748b8f3dceff3625d0fe`.	7,5 jours-personnes (4,5 Kudelski + 3 X41), 7 mars–5 juil. 2017; revue code, fuzz du décodeur SDP avec afl; auditeurs indiquent avoir contribué à des conseils de conception du key establishment.	Webapp base desktop/browser et signaling d’appel; Electron, codecs, WebRTC complet, deps tierces, traffic analysis et ICE exclus. PDF	7 vulnérabilités: 1 élevée (jQuery 2.1.4 via antiscroll), 5 moyennes, 1 faible; XSS possible via localisation, token dans URL, base64 permissif, DoS JSON signalling, effacement tardif de clé, libvpx avec DoS distant (CVE-2017-0393), plus les findings Web décrits dans le rapport.	Rapport dit que Wire a corrigé/mitigé et que patchs de signaling ont été revus. Certaines recommandations (ne pas mettre token dans URL) étaient acceptées comme risque par Wire. Aucun retest actuel; limites de scope restent importantes.

Lecture historique — recherche ETH 2023, non-audit. La thèse Security Analysis of the Wire Messaging Protocol étudie les versions alors disponibles. Elle rapporte des vulnérabilités de l’ordre des messages et de redirection/confidentialité des groupes contre un serveur malveillant pour Proteus, ainsi que des limites de post-compromise security sous certains adversaires; elle identifie également des défauts dans le design/intégration MLS au stade alors étudié. La version 2026 a migré vers MLS mais l’audit/retet correspondant n’a pas été retrouvé. Il faut donc convertir ces résultats en hypothèses de test, pas les présenter comme exploités ou non corrigés aujourd’hui. Thèse ETH [accès à vérifier]

Wire — dépôts, releases et état de la chaîne logicielle¶

wire-server, wire-android, wire-ios, wire-webapp, wire-audio-video-signaling, wire-proteus et plusieurs librairies sont publics. Server open source n’implique pas que l’instance Wire Cloud ou son état de production soit reproductible.
Android : release 4.36.1 datée du 9 oct. 2026, commit 240b2a0, signature committer GitHub vérifiée. Le README documente flavors Play/F-Droid et les écarts de bibliothèques d’appel/API keys; F-Droid n’est pas le binaire Play.
iOS : repo GPL public; release 4.28.0 annoncée 28 sept. 2026 (commit exact à reprendre du tag avant toute vérification binaire). Le README prévient que Store utilise amélioration AVS propriétaire et qu’un build local n’a pas la même configuration APNs/signature.
Serveur : repo public avec releases continues en 2026. Release 12 juin 2026 indique explicitement retrait de la suite hybride post-quantique basée Kyber, car non supportée par la branche Wire d’OpenMLS; ne pas décrire Kyber comme protection active.
Tags/signatures/CI : releases Android montrent tags ou commits signés « Verified » par GitHub. Ce n’est ni signature reproductible du binaire distribué ni preuve que le contenu compilé est identique. Les comptes exacts de mainteneurs actifs, la diversité des reviewers et l’attestation des artefacts n’ont pas été mesurés.
Sécurité coordonnée : SECURITY.md du dépôt Wire donne une procédure de signalement privé et versions supportées; l’iOS advisory GHSA-v6wg-c7qc-x66g / CVE-2026-35049 est publié et décrit la correction 4.16.0. Aucun retest externe/public post-fix n’y est indiqué.

Wire — mobile privacy, permissions et analytics¶

Surface	Fait observé dans les sources actuelles	Déclaration / limite
Google Play	Listing développeur : email/nom/IDs, téléphone optionnel, interactions d’app pour analytics, crash logs, photos éventuelles; données chiffrées en transit. Store	Déclaration développeur; pas une inspection indépendante d’APK. Les catégories peuvent varier par usage.
Apple App Store	Label du développeur : email, nom, téléphone, user ID liés à l’identité; usage/crash déclarés non liés; Apple prévient que la déclaration n’est pas vérifiée par Apple. Store	Ne remplace pas l’analyse des entitlements, SDK et trafic de la version installée.
Countly / crash	Politique oct. 2025 décrit Countly auto-hébergé Wire, avec consentement; events, appareil/OS, version, ID pseudo; logs jusqu’à 90 jours et usage/analytics jusqu’à 365 jours selon catégories; crash reports par OS/store si consentis.	Le privacy paper indique F-Droid sans Countly et sans FCM, mais ce point doit être retesté sur APK actuel. La politique et le PDF ne détaillent pas la totalité des SDK buildés.
Push	FCM Android / APNs Apple selon docs; F-Droid utilise WebSocket. Le payload annoncé contient UUID + réveil, pas le message.	Observation packet-level non faite; métadonnées push peuvent inclure heures, token, installation et IP observée par Apple/Google.
Permissions et contacts	Fonctionnalités nécessitent selon usage micro/caméra pour appel, sélection fichier/photos et éventuellement contacts; manifest iOS/Android actuels non extraits dans cette enquête.	Permission déclarée n’est pas permission accordée ni preuve d’un accès. Pas de test runtime, instrumentation ou comparaison APK/IPA.
Website vs app	La politique distingue HubSpot/Google Analytics/cookies du site web et les outils Messenger; le site peut traiter IP/cookies avec consentement.	Ne pas imputer les trackers du site aux clients mobiles.

À tester pour clore le volet mobile : extraire manifeste Android + permissions fusionnées, SDK, endpoints et trackers depuis Play et F-Droid; comparer avec commit et build; inspecter entitlements/Privacy Manifest iOS et labels régionaux; tracer premier lancement, opt-in Countly, contacts, partage fichier, caméra/micro, push et crash; capturer APNs/FCM payloads uniquement sur comptes et appareils de laboratoire. Ces tests n’ont pas été exécutés ici.

Wire — infrastructure OSINT observée et documentée¶

DOCUMENTÉ : Wire Support (actualisé 22 janv. 2026) publie les domaines clients listés dans le registre ci-dessus, indique load balancers à IP dynamiques, TCP/443; TURN via SRV sous turn.calling-prod-v01.wire.com; conférence via sft.calling-prod-v01.wire.com; d’autres domaines peuvent apparaître pour aperçus de liens/média. Le livre blanc Wire dit données client hébergées en Europe; le site web utilise HubSpot sur infrastructure UE selon sa politique (cela concerne le site, pas nécessairement le Messenger). Domaines/ports, privacy paper, politique web

OBSERVATION DNS/BGP DE CETTE PHASE : requêtes A/AAAA et SRV à un résolveur local (identité inconnue), puis préfixes IPv4 via RIPEstat, vers 00:29–00:32 heure de Paris le 14 octobre 2026 (13 oct. UTC). Aucun port n’a été contacté.

Endpoint documenté	Réponses DNS capturées	RIPEstat IPv4	Limite d’interprétation
`prod-nginz-https.wire.com`	A `108.128.248.229`, `54.195.173.137`, `18.203.1.6`; aucun AAAA retourné par le résolveur	Préfixes `108.128.0.0/13`, `54.195.0.0/16`, `18.202.0.0/15`, tous AS16509 (Amazon)	Pool dynamique; pas la preuve que chaque requête client touche ces trois IP.
`prod-nginz-ssl.wire.com`	A `34.240.177.63`, `54.229.239.4`, `52.208.42.237`; aucun AAAA retourné	`34.240.0.0/13`, `54.229.128.0/17`, `52.208.0.0/13`, AS16509	L’ASN identifie l’annonce réseau, pas le contrat/hôte ou la résidence des données.
`sft.calling-prod-v01.wire.com`	A `18.198.15.177`, `18.158.173.249`, `3.120.232.124`; aucun AAAA retourné	`18.198.0.0/15`, `18.156.0.0/14`, `3.120.0.0/14`, AS16509	Endpoint conférence documenté; ne prouve pas utilisation systématique.
`_turn._udp.turn.calling-prod-v01.wire.com`	SRV vers `coturn-0`…`coturn-3.coturn.calling-prod-v01.wire.com`, port UDP/3478, poids 10; A `18.184.5.76`, `63.187.91.96`, `3.125.158.35`, `3.66.84.189`; aucun AAAA retourné	Trois IP : AS16509, préfixes `63.184.0.0/14`, `3.124.0.0/14`, `3.64.0.0/12`; pas de préfixe vérifié pour `18.184.5.76`	Le résolveur a donné quatre cibles à l’instant observé; choix réel TURN dépend de client/région/call.

AS16509 est annoncé par Amazon.com, Inc. RIPEstat AS16509. La géolocalisation précise, les origins, les journaux, les traitements effectifs et la résidence réelle par type de donnée restent inconnus. Ces réponses sont un snapshot DNS courant, non du passive DNS ni un inventaire de l’ensemble du service; l’absence d’AAAA dans cette réponse n’établit pas une absence universelle d’IPv6. Aucun scan, connexion applicative ou intrusion n’a été effectué.

Wire — forensique et limites datées¶

Dans les sources consultées, aucune démonstration publique récente ne relie Cellebrite/GrayKey/Magnet + version d’outil + modèle d’appareil + version iOS/Android + Wire app build + date. Des audits Wire 2017–18 ont examiné code de stockage, intents, fichiers, logs et caches, mais ce ne sont pas des validations de capacités forensiques actuelles. Les éléments localement accessibles sur un appareil déverrouillé sont par principe hors portée de la garantie E2EE; la quantité récupérable sur appareil verrouillé dépend des secrets système, de la base, du modèle, de la version OS et du build. Aucun test de saisie contrôlé n’a été fait ici. Il faut considérer chiffrement local de DB, Keychain/Keystore, clés et contenu supprimé comme inconnus, non présumer un état en clair ou au contraire un chiffrement complet.

Wire — ce qui a effectivement été obtenu par des autorités¶

Donnée réellement communiquée dans un cas identifié : en 2024, à la suite d’une demande espagnole transmise via la Suisse, Wire a fourni l’email utilisé à l’inscription d’un compte Wire; cet email Proton a permis la demande suivante à Proton, puis à Apple. L’email a donc bien été remis; le reportage attribue cette information à des documents judiciaires et cite la confirmation de Wire. TechCrunch, 8 mai 2024 [accès à vérifier]
Contenu des messages : le dossier public cité n’établit pas que Wire a remis des conversations; Wire dit ne pas disposer des clés/contenus. Les messages/éléments reproduits dans un dossier ne démontrent pas à eux seuls une production serveur — ils peuvent venir d’appareils ou de participants.
Échelle agrégée : le PDF Wire couvre 2018–2020 et compte demandes/comptes touchés, sans lister les champs remis pour chaque ordonnance. Ce rapport ne répond pas à lui seul à « quelle donnée exacte dans chaque affaire ». Aucun rapport annuel post-2020 n’a été trouvé dans cette recherche.
Trois niveaux à ne pas confondre : (1) email, IP d’inscription et logs sont techniquement traitables selon la politique; (2) Wire déclare ne pouvoir fournir le contenu E2EE; (3) la seule remise nominativement documentée ici est l’email d’inscription dans l’affaire 2024.

Wire — matrice des métadonnées par observateur¶

Statuts fondés sur les sources citées et l’architecture documentée. NON ACCESSIBLE PAR DESIGN signifie inaccessible au correspondant dans le flux E2EE nominal; ce n’est pas une garantie face au terminal compromis, au partage ou à un membre de groupe.

Métadonnée	Fournisseur Wire Cloud	Contact	ISP / réseau local	Apple / Google	Autorités
IP	CONFIRMÉ : IP d’inscription peut être conservée; logs jusqu’à 90 j; accès réseau voit source	POSSIBLE : appel direct/WebRTC peut révéler candidat IP; TURN réduit cette exposition	CONFIRMÉ : IP source, destinations, timing et volumes	POSSIBLE : push/IP vers APNs/FCM; store voit téléchargement/IP	CONFIRMÉ : email d’inscription remis en 2024; IP/logs techniquement traitables, remise dans ce cas inconnue
Téléphone	POSSIBLE : optionnel/annuaire ou compte entreprise; label store déclare parfois optionnel	POSSIBLE si fourni dans profil, équipe ou hors Wire	NON ACCESSIBLE PAR DESIGN dans le flux réseau seul; opérateur mobile connaît abonné	POSSIBLE via compte store/appareil; lien Wire non prouvé	POSSIBLE via opérateur/store ou donnée de compte; aucun cas remis identifié
Email	CONFIRMÉ : requis pour compte perso, conservé pendant durée compte selon policy	POSSIBLE si profil/coordonnée partagé	NON ACCESSIBLE PAR DESIGN dans trafic TLS/E2EE seul	POSSIBLE compte store	CONFIRMÉ : email d’inscription divulgué dans affaire 2024
Identifiant	CONFIRMÉ : UUID interne / username / devices pour routage	CONFIRMÉ : username/display name dans contact et conversation	POSSIBLE par corrélation trafic, non lisible normalement sous TLS	POSSIBLE : ID app/store/token	POSSIBLE ou CONFIRMÉ par demande ciblée; cas 2024 associe compte/email
Graphe social	CONFIRMÉ pour membres/groupes et participants (backend conserve)	CONFIRMÉ pour conversations/groupes connus	POSSIBLE par timing/destinataires IP et volumes	POSSIBLE par notifications, pas graphe complet établi	POSSIBLE via Wire + autres sources; disclosure graph dans un cas non établie
Timestamps	CONFIRMÉ : création/vérification email, groupes et logs/routage	CONFIRMÉ : heures/messages/appels vus localement	CONFIRMÉ : horaires de trafic	PROBABLE : événements push ont timing	POSSIBLE : logs existent jusqu’à fenêtre déclarée; remise individuelle exacte inconnue
Volumes	CONFIRMÉ au niveau transport/asset et taille payload chiffré	CONFIRMÉ par messages/fichiers/appels reçus	CONFIRMÉ octets/durée	POSSIBLE taille/rythme push, payload exact inconnu	POSSIBLE via Wire, ISP ou push; cas documenté ne porte que sur email
Groupes	CONFIRMÉ : participants, devices, nom, rôles, créateur et heure UTC	CONFIRMÉ aux membres	POSSIBLE via motifs de trafic	POSSIBLE selon pushes et données OS	POSSIBLE à obtenir via Wire car backend les détient; remise en cas réel inconnu
Appareils	CONFIRMÉ : clients/public keys et participants-appareils pour E2EE	POSSIBLE via liste/verification et indicateurs conversation	CONFIRMÉ connexions réseau distinctes; identité physique pas toujours	CONFIRMÉ pour installations et push tokens côté service OS/store	POSSIBLE via Wire / Apple / Google / saisie; champ de remise non établi
Push tokens	CONFIRMÉ pour traitement FCM/APNs dans configurations concernées	NON ACCESSIBLE PAR DESIGN	POSSIBLE destination au fournisseur push + timing	CONFIRMÉ token d’installation pour push	POSSIBLE auprès Wire/Apple/Google; aucune remise de token identifiée dans l’affaire 2024

Wire — colonne provisoire TM1–TM15 (pas un classement)¶

Modèle	Évaluation	Justification courte / preuve
TM1 — fournisseur curieux	🟠	E2EE protège le contenu, mais Wire conserve identifiants/email, groupes, appareils et logs jusqu’à 90 jours. Politique, privacy paper
TM2 — fournisseur compromis	🟡	MLS/Proteus empêche en principe lecture du contenu historique en transit/queue sans clé client; groupe, IP/logs et métadonnées sont exposés; compte/appareil malveillant reste une surface. Audit serveur actuel complet non trouvé.
TM3 — fournisseur malveillant	🟡	Le serveur peut manipuler disponibilité, délivrance, membership/metadata et pousser des clients; Proteus fingerprints manuels et MLS X.509 optionnel selon backend donnent une vérification, mais l’ajout d’un client non vérifié dégrade l’état. Security whitepaper
TM4 — ISP/Wi‑Fi	🟠	TLS masque contenu mais pas destinations, IP source, timing et volumes; appel direct ajoute ICE/STUN exposure. VPN ne fait que déplacer l’observation.
TM5 — adversaire passif puissant	🟠	Cloud, push, ISP et relais d’appel offrent des points de corrélation; pas de padding/mixnet de Wire établi ni test de corrélation public actuel.
TM6 — global passive adversary	🔴	Architecture IP centralisée + routage/temps/volumes sans mixnet; aucune preuve de protection contre corrélation globale. Inférence de l’architecture, pas étude de mesure.
TM7 — contact malveillant	🟠	Pair reçoit email non requis par défaut dans le profil affiché, mais username/profil visible; appel direct peut exposer IP; partage volontaire des fichiers et métadonnées.
TM8 — harceleur/doxxer OSINT	🟡	Username unique et email requis isolent un peu si compartimentés; photos, recherche par nom, réutilisation d’alias et annonces de groupe peuvent relier identité.
TM9 — demande judiciaire classique	🟠	Wire a effectivement remis un email de compte dans l’affaire espagnole 2024; logs, groupes et identifiants existent selon policy/whitepaper; contenu E2EE déclaré inaccessible. Cas [accès à vérifier]
TM10 — enquête policière sophistiquée	🟠	Email Wire puis Proton recovery puis Apple ont permis identification dans un cas réel; ISP, push, device forensics et participants ajoutent de la visibilité. Cas documenté [accès à vérifier]
TM11 — appareil verrouillé saisi	❓	Aucun cas public actuel avec modèle/OS/Wire build/version Cellebrite/GrayKey/Magnet trouvé; protection locale actuelle non auditée ici.
TM12 — appareil déverrouillé	🔴	Client affiche plaintext, clés et pièces jointes pour usage normal; E2EE n’isole pas du processus/OS utilisateur. Les chemins exacts d’extraction n’ont pas été testés.
TM13 — spyware ciblé	🔴	Malware avec écran/processus/micro/mémoire peut lire avant/après chiffrement; E2EE ne protège pas un endpoint compromis.
TM14 — supply-chain compromise	🟠	Beaucoup de code public et releases signées, mais AVS propriétaire dans stores, aucune reproduction de binaires réalisée et serveur/cloud/update/store restent points de confiance.
TM15 — censure étatique	🟠	Domaines/serveurs centraux, push et stores sont bloquables; fédération/auto-hébergement aide organisations capables de le maintenir, mais aucun mécanisme anti-DPI/bridges démontré.

Wire — contradictions, zones inconnues, tests à réaliser¶

Durée des logs : politique actuelle et Privacy Whitepaper disent jusqu’à 90 jours; un ancien sous-domaine de politique encore indexé dit 72 heures. La page principale se déclare mise à jour octobre 2025; l’ancien document semble obsolète mais n’a pas de versionnage vérifiable. À ne pas mélanger avec les logs du site public (max. 30 jours).
Message « supprimé après livraison » vs queue quatre semaines : probablement des objets différents (payload livré vs queue par device / état de notification), mais le texte public ne permet pas ici une résolution certaine. Il faut vérifier le modèle exact ou instrumenter un compte de test.
E2EE vs métadonnées groupe : marketing « toutes communications E2EE » concerne le contenu; la politique technique révèle membres, appareils, noms de groupe et rôles lisibles côté backend après transport TLS.
MLS/Post-quantique : MLS est annoncé standard en 2026, tandis que release serveur retire le cipher hybride Kyber; post-quantique n’est donc pas démontré actif dans ce tag. Thèse 2023 concerne un état plus ancien et exige retest des correctifs.
Open source/reproductibilité : source client et server disponibles; les versions Play/iOS incluent des composants AVS propriétaires et aucun binaire officiel n’a été reproduit pour cette enquête.
Divulgation légale : cas 2024 établit remise de l’email d’inscription, non de contenu Wire. Les comptes statistiques 2018–2020 ne détaillent pas les champs remise par remise.
Forensique : pas de preuve publique qualifiée de capacité outil commercial actuel. Données locales, protections DB/Keystore et récupération d’éléments supprimés demeurent à mesurer avec variables exactes.
Tests nécessaires : (1) retest indépendant de MLS/Proteus et des commits ETH liés; (2) reproduire build et inspecter manifests/SDK/permissions/permissions runtime; (3) captures réseau par version pendant registration, contact search, message, groupe, fichier, push, appel direct/TURN/SFT; (4) vérifier purge de queue et rétention logs; (5) test d’ajout d’appareil et de dégradation de vérification; (6) acquisition forensic contrôlée avec modèle, OS, build, app et outil explicités; (7) résoudre DNS/ASN/CDN par observations passives datées des domaines listés; (8) obtenir la série de transparence post-2020 ou docs de demandes anonymisés. Aucun de ces tests n’est présenté comme réalisé.

Conclusion actuelle¶

Lire la fiche de référence Wire.