Olvid — dossier probatoire approfondi (état au 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 : applications Olvid grand public et services officiels décrits par l’éditeur. Les certificats ANSSI/Synacktiv cités ci-dessous portent sur des versions 2020–2021 et ne certifient pas les builds 2026. FACT signifie constat vérifiable dans un document/code public consulté, pas test actuel de production; VENDOR CLAIM reprend une affirmation de l’éditeur; INDEPENDENT EVIDENCE désigne une source tierce; INFERENCE est la conséquence analytique; UNKNOWN n’est pas remplacé par une supposition.
| Catégorie | FACT | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN |
|---|---|---|---|---|---|
| 1. Architecture | Client multi-plateforme, serveurs de relais, stockage de pièces jointes, notifications, TURN, services de transfert et sauvegarde; les endpoints et certains sous-traitants sont publiés par l’éditeur. Réseau requis | Les serveurs ne sont pas dans la frontière de confiance cryptographique et ne pourraient ni lire le contenu ni savoir qui parle à qui. Technologie | L’analyse formelle 2026 modélise le cœur cryptographique, pas l’ensemble du service opéré. ePrint 2026/1622 [accès à vérifier] | Le chiffrement peut limiter la lecture du contenu sans supprimer l’exposition réseau, IP, disponibilité, push et services tiers. | Architecture complète et actuelle du backend, flux par build et séparation exacte des données sur chaque endpoint. |
| 2. Protocole cryptographique | La spécification publique d’octobre 2024 nomme un protocole « Full Ratchet »; la spécification 2020 et la FAQ plus ancienne décrivent des primitives et protocoles antérieurs. L’éditeur dit employer des clés éphémères à usage unique par message/fichier. Spécifications 2024, FAQ | L’éditeur revendique E2EE, forward secrecy et chiffrement des métadonnées. Technologie | Terzo et al. (2026) ont formalisé avec Tamarin l’échange authentifié CCCD et le Full Ratchet (FRP), à partir de la spécification et du code Android v3.6; résultats positifs dans leur modèle : authentification mutuelle, secret de clé de session, forward secrecy standard, anti-rejeu, et post-compromise security pour la session FRP modélisée après guérison du canal. Le papier identifie aussi des échecs dans des modèles plus forts (dont eCK/MEX) et des limites de récupération/entropie. PDF intégral, ePrint [accès à vérifier] | Preuve symbolique sous hypothèses de primitives idéales, adversaire actif et éléments modélisés; elle n’est ni une preuve de l’app complète, ni une validation de toutes les garanties de « PCS » ou des versions 2026. | Algorithmes/négociation dans chaque build 2026; conformité exacte de l’implémentation courante, déploiement PQ et portée des propriétés hors modèle. |
| 3. Création d’identité | L’app demande nom/prénom à l’utilisateur, selon sa politique; compte réseau avec numéro ou e-mail non requis d’après l’éditeur. L’identité Olvid et ses clés sont créées localement. Politique | Les éléments d’identification restent sur le téléphone et ne sont envoyés qu’aux contacts invités. | Les rapports CSPN de 2020/21 ont examiné des mécanismes d’identité/authentification sur versions précises, pas la création d’identité des builds actuels. Rapports Synacktiv | Pas de numéro obligatoire réduit la liaison directe à un abonné mobile, mais nom/photo, invitation, achats professionnels, support ou appareil peuvent identifier l’utilisateur. | Génération et stockage des clés en build actuel; suppression effective côté tous appareils, relais, sauvegardes et stores. |
| 4. Contact discovery | La doc d’administration décrit ajout de contacts par invitation distante et annuaire d’organisation; la politique dit que l’app n’accède pas au carnet d’adresses. FAQ admin, Politique | Pas d’annuaire public imposé; l’utilisateur choisit les personnes invitées. | Les audits CSPN évaluent l’authentification du contact par des canaux d’introduction précis (QR/e-mail/SMS selon configuration), pas l’ensemble des sources de découverte actuelles. | L’absence d’import du carnet d’adresses réduit une collecte, mais liens d’invitation et annuaire organisationnel restent des surfaces de corrélation. | Télémétrie exacte d’invitation, liens d’annuaire et rétention des requêtes; code/manifests actuels des permissions. |
| 5. Métadonnées serveur | L’éditeur publie de nombreux services réseau (API, WebSocket, transfert, pièces jointes, sauvegarde, TURN, cartes); une ancienne spécification (2020) décrit des échanges d’identité/deviceUID, requêtes et horodatages côté serveur. | La politique actuelle affirme que données et métadonnées sont chiffrées et que l’opérateur ne peut pas voir les interlocuteurs; elle dit aussi que les IP sont utilisées pour le fonctionnement sans être conservées. Politique | L’étude formelle 2026 précise que le serveur voit les clés publiques des destinataires nécessaires au routage, tailles et timing des messages; elle indique qu’un opérateur ayant ses propres contacts peut parfois relier une clé publique à une personne. Les CSPN excluaient les serveurs et ne vérifient pas les journaux de production. PDF, § analyse de confidentialité | « Métadonnées chiffrées » ne masque pas IP, connexion, taille, cadence, service contacté ni tous les identifiants de routage. Les auteurs qualifient l’anonymat cryptographique de pseudonymat dans ce modèle; cela ne prouve pas une identification universelle. | Champs visibles par endpoint et groupe, liens de clés ↔ personnes, traces réellement journalisées/conservées, versions du protocole effectivement déployées. |
| 6. IP utilisateur | Les clients se connectent aux endpoints publiés; certains sont sur AWS/CloudFront/API Gateway, AWS S3, Clever Cloud et Scaleway. FAQ admin | La politique dit que les IP sont utilisées techniquement mais ne sont ni consultées/collectées ni conservées par Olvid; elle reconnaît que le fournisseur AWS peut voir l’IP. | Aucune résolution DNS/ASN, capture réseau ou mesure de journaux n’a été faite dans cette enquête. | L’ISP voit le trafic vers des endpoints et l’IP source; cloud/CDN peut techniquement traiter l’IP, même sans preuve qu’il la journalise ou l’associe à une identité Olvid. | IPs/CNAME/ASN actuels par région, journaux AWS/CDN et politiques effectives de rétention. |
| 7. IP exposée au correspondant | La documentation publie un service TURN pour appels; l’éditeur décrit le relais d’appels et permet sur Android de configurer son propre TURN. FAQ admin | Le TURN est conçu pour relayer audio/vidéo; le correspondant ne reçoit normalement que l’IP du relais dans un appel relayé. | Aucun test ICE/STUN ni vérification de l’IP vue par le pair n’a été réalisé. | TURN masque l’IP au correspondant si le flux passe effectivement par le relais, mais expose les IP des deux côtés au fournisseur TURN. | Routage direct/fallback par plateforme et build, candidates ICE réellement échangées, IPv6, VPN et fuite IP au correspondant. |
| 8. Messages | Le serveur API fournit l’envoi/réception et les pièces jointes sont hébergées sur plusieurs services dédiés. L’ancienne spécification décrit une queue jusqu’au retrait par le destinataire. | Le fournisseur affirme que le contenu est E2EE et effacé du relais après récupération; contenus/champs de messages seraient protégés. FAQ | L’analyse académique 2026 porte sur le cœur cryptographique; elle ne mesure pas les pratiques de rétention ni toutes les couches de messagerie. | Le contenu chiffré ne prouve ni suppression immédiate sur tous les caches/backups ni masquage des tailles et timestamps. | Durée actuelle des messages non livrés, receipts, retries, journaux, caches CDN et fichiers orphelins. |
| 9. Groupes | Les fonctionnalités professionnelles et grand public évoluent; les certificats CSPN anciens ne démontrent pas la sécurité des groupes actuels. | L’éditeur étend ses mécanismes d’authentification et de confidentialité aux discussions; cela doit être lu selon fonctionnalité et version. | Aucun audit indépendant de groupes Olvid actuels ni analyse des métadonnées de groupe n’a été identifié ici. | Un membre voit nécessairement les messages et membres qui lui sont accessibles; le serveur peut encore observer des signaux réseau même si champs groupe sont chiffrés. | Adhésion/retrait, historique, admin, appels de groupe, métadonnées et fuites latérales par version. |
| 10. Appels | Service TURN officiel sur UDP 5349/TCP 443, avec endpoints géolocalisés annoncés; TURN personnalisable seulement sur Android selon FAQ actuelle. FAQ admin | L’éditeur présente appels audio/vidéo relayés et chiffrés. | Aucun appel n’a été intercepté ou testé; l’audit CSPN iOS/Android cité ci-dessous ne valide pas le service d’appel 2026. | TURN voit au minimum les IP, heures, volumes et durées; E2EE média éventuel ne masque pas ces métadonnées de transport. | Chiffrement média, appels de groupe, enregistrement, journaux TURN, comportement iOS/Desktop, fallback direct et rétention exacte. |
| 11. Fichiers | Les documents d’administration identifient plusieurs backends de pièces jointes; les profils disposent aussi d’un service de sauvegarde séparé. | L’éditeur dit chiffrer les pièces jointes et utiliser des URLs signées/uniques; ses pages techniques revendiquent une clé éphémère par fichier. | Les rapports CSPN 2020/21 incluent le chiffrement de pièces jointes dans le scope des versions mobiles auditées; ils ne couvrent pas le stockage cloud courant dans son ensemble. | Les fournisseurs de stockage peuvent voir connexions, taille, timing et objets; confidentialité du contenu ne garantit pas l’absence de métadonnées, de caches ou de résidus locaux. | Rétention objet, clés et format actuels, noms/mime/hash visibles, aperçu de lien et nettoyage local exacts. |
| 12. Multi-device | Transfert/import de profil sur second appareil documenté via transfer.olvid.io; app annonce synchronisation sans appareil maître. FAQ admin, Technologie | L’éditeur dit que le service de transfert relaie un profil chiffré. | Les audits de certification anciens ont précédé/limité le multi-appareil courant; aucun audit dédié actuel identifié. | Le multi-device multiplie les endpoints et les copies locales; sécurisation d’un appareil ne sécurise pas les autres. | Clés par appareil, révocation, synchro/rétention, visibilité opérateur du graphe d’appareils et données résiduelles après dissociation. |
| 13. Notifications push | La FAQ liste APNs et FCM pour mobile, WebSocket pour desktop. L’ancienne spec (2020) décrit des masques de push et une charge utile iOS chiffrée. | L’éditeur affirme masquer les identifiants et le contenu sensible aux fournisseurs push. | L’ancienne spécification n’établit pas le payload de chaque version 2026; aucune capture APNs/FCM actuelle. | Apple/Google observent des tokens et horaires; les masques peuvent limiter la liaison au profil, mais doivent être vérifiés en implémentation. | Payload exact, token-service mapping, affichage sur écran verrouillé, APNs/FCM retention, push silencieux et analytics associés. |
| 14. Stockage local | Clients mobiles et desktop sont publics en partie; une ancienne spec CSPN décrit données locales chiffrées, mais elle ne prouve pas le format actuel. | L’éditeur dit que la désinstallation supprime les données personnelles du téléphone. | Analyse formelle 2026 ne porte pas sur une extraction forensique locale; aucune extraction actuelle documentée avec couple OS/app/version ici. | Une session déverrouillée, sauvegarde, notification, fichier partagé ou snapshot système peut produire des artefacts au-delà du stockage DB principal. | Schéma SQLite, clés/KeyStore, WAL, caches, pièces jointes, journaux, notifications et effacement sécurisé par version. |
| 15. Sauvegardes | iCloud/Google Drive sont listés pour sauvegarde de profil; WebDAV automatique est documenté pour Android. FAQ admin | L’éditeur décrit les sauvegardes de profil comme chiffrées; l’utilisateur peut choisir un serveur WebDAV côté Android. | Pas d’inspection de sauvegarde ni de mesure d’entropie/passphrase par build. | Une sauvegarde élargit la frontière de confiance à Apple/Google/WebDAV et aux secrets de restauration; E2EE en transit n’établit pas le chiffrement au repos ou sa qualité. | Clé, KDF, chiffrement du contenu et métadonnées de sauvegarde, récupération compte store, rétention/versioning. |
| 16. Analytics / SDK tiers | Les endpoints documentés incluent AWS, Clever Cloud, Scaleway, APNs/FCM, iCloud/Drive; l’app peut contacter les sites pour prévisualiser des liens. | Olvid affirme absence de trackers, et que l’app n’accède pas aux contacts/fichiers sans action dédiée. FAQ, Politique | Le listing Google Play auto-déclare « aucune donnée collectée/partagée »; pas de vérification APK/manifeste/SDK ou label iOS détaillé faite ici. | Services push/cloud et prévisualisation sont des tiers opérationnels, même s’ils ne sont pas des SDK analytiques. | Inventaire SDK, Firebase, Sentry, crash reporting, telemetry, permissions par build et divergence store/code. |
| 17. Code source | Dépôts officiels iOS/Android publics sous AGPLv3 selon leurs fichiers; Android changelog: 4.5.1 build 311 daté 23 sept. 2026; le moteur Android a été extrait dans un dépôt distinct lors de la série 4.5. Le dépôt serveur officiel olvid-aws-server publie des fonctions Lambda pour distribution/transfert, mais indique que des éléments Enterprise/Store sont retirés et que des constantes sont anonymisées. Android, iOS, serveur |
Le site dit que le code est ouvert et invite à l’examiner. | Le papier 2026 indique que les sources serveur ont été publiées en janvier 2026. Lecture ciblée des dépôts/changelogs seulement : le repo serveur consulté expose un périmètre partiel et n’établit pas que le déploiement de production corresponde à ce dépôt. | Code public améliore l’inspectabilité, mais un dépôt incomplet/anonymisé, les services exploités et les composants Enterprise ne sont pas vérifiables comme un serveur intégralement reproductible. | Complétude exacte du backend, code Enterprise, correspondance déploiement ↔ repo, maintainers actifs et gouvernance de revue. |
| 18. Reproductibilité des builds | Guides de build/CI existent; le build Android par défaut récupère le moteur comme dépendance Maven Central. Le dépôt n’établit pas une reproduction bit-à-bit des binaires Play/App Store; aucune compilation/recomparaison n’a été effectuée ici. Android build | Pas de claim précis de reproduction bit-à-bit iOS/Android vérifié dans les éléments consultés. | Le papier académique 2026 cite l’application Android v3.6 et examine le code; cela ne lie pas ce snapshot aux binaires ni aux builds actuels. | Code source, CI vert ou signature store ne suffisent pas à établir que le binaire distribué correspond au commit et aux dépendances publiés. | Correspondance APK/IPA/MSI publié ↔ commit, provenance CI, signatures, SBOM et reproduction par tiers. |
| 19. Supply chain | Le repo Android distingue les variantes full (Google/Firebase, Billing, Drive) et nogoogle/F-Droid avec dépendances différentes; le moteur est séparé et tiré de Maven Central. Le README indique que les credentials push sont liés à la signature Play officielle. Repo serveur officiel présent mais un seul commit observé lors de la consultation et périmètre partiel. Android, serveur |
L’éditeur maintient officiellement les clients, mais pas de preuve que toutes les dépendances/artefacts sont audités en continu. | Lecture ciblée des README/configurations, non audit de dépendances, workflows CI, clés, signatures ou SBOM; les variantes ne sont donc pas équivalentes par défaut. | Stores, Maven Central, Google SDKs, AWS, CDN, cloud de fichiers, push et outils de build forment des maillons distincts du protocole. | Inventaire complet des dépendances et CVE, provenance du moteur publié, rotation/protection des credentials, signatures de tags/releases et correspondance de chaque variant distribué. |
| 20. Infrastructure | La FAQ admin publie endpoints/ports et rôles : API/WebSocket/transfert de profil derrière CloudFront/API Gateway; pièces jointes via AWS S3 ou Clever Cloud Cellar; sauvegardes S3; cartes Clever Cloud, recherche d’adresses Scaleway, TURN et push APNs/FCM. FAQ admin | La même FAQ annonce trois pools TURN « géolocalisés » et donne des domaines/IP/régions. | DNS A/AAAA et RIPEstat observés le 14 oct. 2026; AWS ip-ranges.json mappe les IP publiques de eu.turn vers eu-west-3, ap.turn vers ap-southeast-1, us.turn vers us-east-1. Cela contredit les labels géographiques écrits dans la FAQ pour les deux derniers, pas nécessairement le déploiement actuel; détails ci-dessous. AWS ranges, RIPEstat AS16509, AS14618, AS213394 |
Le DNS échantillonné confirme fronts AWS et Clever Cloud, mais pas leur contrat, l’usage par une session, le lieu des données à l’origine, ni la résidence de chaque copie. | Logs, région réellement sélectionnée pour chaque utilisateur, origine CloudFront/API Gateway, prises en charge de fallback, flux exacts, stockages/télémétrie tiers et rétention effective. |
| 21. Juridiction | Éditeur Olvid SAS immatriculé à Paris; politique mentionne AWS et traitement de données de facturation/support. Politique, Conditions | L’entreprise dit minimiser les données des utilisateurs gratuits et répondre conformément au droit applicable. | Aucune analyse indépendante du contrôle effectif des données par filiale/cloud/juridiction n’a été faite. | Droit français pour l’entité n’exclut pas les pouvoirs légaux du pays du fournisseur/cloud ou du store qui détient certaines données. | Régime contractuel précis de chaque sous-traitant, entité contrôleur par store, conflits de lois et lieu de conservation par flux. |
| 22. Demandes policières | Politique autorise une communication pour demandes légales/réglementaires, décisions judiciaires, subpoenas ou procédures. Politique, § partage | L’éditeur soutient que son service de messagerie ne détient pas de données personnelles ou de contenu déchiffrable à remettre; les licences professionnelles impliquent toutefois des données de facturation/support. | Aucun rapport de transparence Olvid, dossier judiciaire, affidavit ou remise réelle de données n’a été identifié dans les recherches de cette passe. | Capacité techniquement accessible (IP côté opérateur, données cloud/store/appareil) ≠ données annoncées ≠ production effectivement remise. | Quels champs ont été remis en cas réel, existence de demandes sous scellés, demandes à AWS/Apple/Google et réquisitions françaises/étrangères. |
| 23. Affaires judiciaires connues | Aucun cas documenté de production Olvid n’a été retrouvé ici; la politique formalise néanmoins la possibilité de répondre au droit. | L’éditeur affirme ne pas avoir de données de messages/interlocuteurs à fournir. | Recherche non exhaustive par dénomination de société, juridiction et fournisseurs; absence de cas retrouvé n’est pas preuve d’absence. | Une réquisition peut viser adresse IP, achat/licence, compte store, hébergeur, appareil ou contact plutôt que contenu. | Dossiers non publiés, saisies d’appareils, ordres visant fournisseurs et demandes d’interception. |
| 24. Audits | Deux évaluations CSPN ANSSI/Synacktiv publiées: iOS Olvid 0.8.2 en 2020 et Android 0.9.2 build 113 en 2021; détails ci-dessous. Une analyse formelle académique distincte du cœur cryptographique a été lue intégralement (2026). | Olvid présente les certifications comme validation de la sécurité de l’app. Page audits | Les CSPN sont ponctuelles et limitées; le papier académique n’est pas un audit produit ni une certification. | Ces éléments n’établissent pas l’état actuel des clients, serveurs, appels, multi-device ou supply-chain. | Audits complets post-2021 des versions 2026, revues cloud et retests des correctifs revendiqués. |
| 25. Vulnérabilités | Rapports CSPN décrivent notamment usurpation conditionnelle, confusion d’homonymes et rejeu de commitment. Le papier 2026 signale malleabilité de signatures sur valeurs EC non canoniques, DoS persistant par remplissage de la DB (expérience Pixel 4, env. 100 KB/min; Android/build non précisés), et multiplication scalaire non constante via une PoC Flush+Reload sur Java compilé en natif sous Linux x86. | Olvid a indiqué aux auteurs en 2025–2026 prévoir des corrections (constantes, calcul EC constant-time, contrôle des valeurs non canoniques); statut public/version/commit et retest non établis. | Le papier est une analyse indépendante de code Android v3.6, non preuve d’exploitation réelle ou de présence dans les builds actuels. La PoC temporelle n’est pas une exploitation Android de bout en bout. PDF | Ces résultats montrent des limites crypto et d’implémentation concrètes dans le snapshot étudié; ils ne signifient pas compromission générale ni vulnérabilité actuelle confirmée. | Versions affectées, commits de correction, effet sur iOS/Android actuels, conditions d’attaque et retest indépendant. |
| 26. Recherche académique | Terzo et al. (2026), « Formal Security Analysis of the Olvid Messenger », ePrint 2026/1622, soumis le 5 août et accepté comme contribution CCS 2026; à la date du 13 oct., la conférence (15–19 nov.) n’a pas encore eu lieu. PDF complet et appendices lus. ePrint [accès à vérifier], PDF | — | Modèle Tamarin basé sur la spécification et code Android v3.6 (tag/release v3.6_263, SHA non cité); tests symboliques d’authentification/secret/FS/anti-rejeu, plus revue ciblée du code Java. Les auteurs indiquent environ 8–9 mois-personnes de modélisation et 11,5 h de calcul cumulées sur Tamarin 1.10.0; ce n’est pas une durée d’audit en jours-personnes. |
Résultats et faiblesses dépendent des hypothèses formelles; le papier ne couvre pas les groupes, la gestion des appareils, sauvegardes, services backend ou tout l’appareil mobile. Une thèse distincte de Padoue examine l’anonymat; son évaluation par les pairs et les détails de réplication restent à distinguer. | Reproduction locale des preuves/PoC, portée exacte des variantes et état des correctifs courants. |
| 27. Incidents historiques | Pas d’incident de compromission globale d’Olvid confirmé dans cette enquête; les papiers CSPN/formel documentent des vulnérabilités et limites, non des incidents de production. | L’éditeur dit ne pas connaître de faille compromise dans son service; non vérifié exhaustivement. | Le papier rapporte divulgation responsable (contact le 2 avril 2025, réunion le 9 avril, réponse écrite le 10 avril; échanges ultérieurs en nov. 2025 et mai 2026) mais ne rapporte pas d’exploitation observée en production. | Absence de notification publique trouvée n’exclut pas bug, panne, incident cloud ou exploitation ciblée. | Historique complet incidents, pannes, compromissions fournisseur, notifications CNIL et réponse de l’entreprise. |
| 28. Gouvernance / société / financement | Olvid SAS est une société française (RCS Paris); pas d’analyse des actionnaires ni des contrats de financement réalisée. Politique | L’entreprise présente son origine et sa gouvernance comme indépendantes des serveurs/cloud. | Aucun audit de gouvernance, comptes, investisseurs ou concentration des droits de signature trouvé ici. | Société française ne signifie pas que services, code, clés de publication ou données sont entièrement souverains/locaux. | Bénéficiaires effectifs, financement, contrôle des releases, gouvernance sécurité, succession clés et dépendance fournisseurs. |
| 29. Résistance à la censure | Architecture mobile dépend de domaines API, CDN, push, stockage et TURN publiés; possibilité d’infrastructure entreprise/personnalisée documentée pour certains éléments, mais pas de réseau public décentralisé établi. | L’éditeur revendique la robustesse aux serveurs compromis, pas une résistance mesurée à la censure réseau. | Aucune mesure OONI ou test multi-ISP/pays n’a été faite. | CDN et multiples fournisseurs peuvent améliorer disponibilité ou au contraire concentrer/blocquer des points; chiffrement n’empêche pas le blocage des domaines/IP/stores. | Fonctionnement hors serveurs Olvid, relais de repli, obfuscation, Tor, accès en pays censurés et mesures DPI. |
| 30. Maintenance actuelle | Changelog Android consulté : 4.5.1 build 311 publié le 23 sept. 2026; dépôts Android/iOS et moteur montrent du code public récent. Android, iOS | L’éditeur distribue des clients mis à jour et annonce l’extraction du moteur Android partagé. | Version/date Android établies dans le changelog; release stable exacte sur chaque store/région et statut iOS non appariés aux binaires ici. | Maintenance récente vérifiable pour Android, mais l’activité du dépôt ne prouve pas la couverture de correctifs, le support serveur ni une cadence homogène. | Versions iOS/Android effectivement installées, délais de patch, nombre de mainteneurs actifs, maintenance du backend et support des anciennes releases. |
Olvid — observation DNS/BGP et rapprochement des régions annoncées¶
Snapshot DNS effectué le 14 octobre 2026 vers 00:38–00:39 heure de Paris (13 oct. UTC), avec le résolveur local non identifié; RIPEstat et le fichier IP-range officiel AWS consultés ensuite en lecture seule. Les adresses/TTL ci-dessous sont un point de mesure, parfois avec une rotation A en quelques dizaines de secondes. Aucun port applicatif n’a été contacté. Les régions AWS décrivent l’annonce réseau publiée par AWS, pas à elles seules la localisation de chaque traitement applicatif ou sauvegarde.
| Endpoint documenté | Réponses DNS observées | Routage / région publiée | Observation et limite |
|---|---|---|---|
server.olvid.io (API message) |
A: 15.188.206.243, 15.224.188.72, 15.224.194.9; AAAA: 8 réponses sous 2600:9000:274d:* |
A: AS16509, préfixes AWS 15.188.0.0/16 et 15.224.128.0/17 (AWS ranges en eu-west-3); AAAA exemple 2600:9000:274d::/48, AS16509 |
Réponses A antérieures, à TTL ~30 s, étaient différentes (15.188.22.231, 13.37.97.205, 13.37.198.59), preuve d’un pool/rotation court; cela ne révèle pas l’origin applicatif. |
ws-server.olvid.io (notifications WebSocket) |
A: 13.39.45.111, 13.39.58.182, 15.224.61.60; 8 AAAA sous 2600:9000:274d:* |
A dans AS16509; AAAA dans AS16509; CloudFront/AWS edge possible d’après docs + plage, pas preuve de la cible d’une session donnée | TTL A ~27 s et AAAA 60 s; pas d’observation de payload push. |
transfer.olvid.io (transfert/appairage profil) |
A: 35.180.107.37, 35.181.73.239, 15.224.197.197; pas d’AAAA direct observé |
AS16509; préfixes AWS 35.180.0.0/16, 35.181.0.0/16, 15.224.0.0/16, tous eu-west-3 dans le fichier AWS consulté |
Concorde avec un service AWS à ce snapshot; ne montre ni chiffrement de transfert ni contenu des logs. |
eu.turn.olvid.io |
A: 35.180.107.30; pas d’AAAA observé |
AS16509; 35.180.0.0/16, eu-west-3 (Paris selon AWS) |
Cohérent avec l’étiquette (Paris) de la FAQ. |
ap.turn.olvid.io |
A: 13.214.105.6; pas d’AAAA observé |
AS16509; 13.214.0.0/15, AWS ap-southeast-1 (Singapore) |
La FAQ actuelle associe pourtant ap.turn.olvid.io à « North Virginia »; discordance fournisseur ↔ registre AWS. |
us.turn.olvid.io |
A: 3.93.110.92; pas d’AAAA observé |
AS14618 (Amazon AES); 3.80.0.0/12, AWS us-east-1 (Northern Virginia) |
La FAQ associe pourtant us.turn.olvid.io à « Singapore »; discordance fournisseur ↔ registre AWS. |
upload.attachments.olvid.io, download.attachments.olvid.io |
Les deux renvoient domain.par.clever-cloud.com puis un pool A comprenant 91.208.207.214, .215, .216, .217, .218, .220, .221, .222, .223; pas d’AAAA numérique observé |
91.208.207.0/24, AS213394, titulaire RIPEstat Clever Cloud SAS |
Le routage public corrobore l’association déclarée par Olvid à Clever Cloud Cellar; ne prouve pas l’isolation/stockage ou le titulaire de données. |
olvid-attachment-chunks.s3.eu-west-3.amazonaws.com |
CNAME s3-r-w.eu-west-3.amazonaws.com; A 52.95.155.40, 3.5.205.38 |
AS16509; AWS classe les deux préfixes eu-west-3 et service S3 |
Région du service endpoint publiée, pas preuve qu’aucune réplication, logs ou métadonnée ne sort de la région. |
olvid-backup.s3.dualstack.eu-west-3.amazonaws.com |
CNAME s3.dualstack.eu-west-3.amazonaws.com; A 3.5.205.31, 52.95.155.61; AAAA 2a05:d030:2000:80::305:cca9, 2a05:d030:2000:c0::305:ce4e |
IPv6 exemple dans AS16509; nom d’endpoint et alias AWS indiquent eu-west-3 |
La policy de backup, les ACL, chiffrement et rétention restent à examiner séparément; le DNS ne les établit pas. |
La FAQ indique également invitation.olvid.io, configuration.olvid.io, openid-redirect.olvid.io, map.olvid.io, pelias.olvid.io et web.olvid.io; ces noms n’ont pas été résolus dans ce snapshot. Elle précise que des requêtes vers le site lié peuvent être faites pour récupérer une prévisualisation. L’écart région/étiquette n’est pas résolu par un seul snapshot; répétition depuis plusieurs résolveurs/régions et confirmation du fournisseur seraient nécessaires. Sources: FAQ réseau Olvid, régions AWS, fichier AWS IP ranges, RIPEstat AS16509, AS14618, AS213394.
Olvid — audits, certificats et analyse indépendante¶
Les rapports ci-dessous sont bien les documents PDF publics d’ANSSI/Synacktiv; leurs métadonnées et conclusions ont été extraites des rapports, et non déduites de la seule page marketing. Aucun commit n’est donné dans les rapports; les évaluations portent sur des versions applicatives binaires précises.
| Évaluation | Organisme / date / version | Durée et scope | Exclusions / méthode | Findings, gravité et recommandations | Corrections / retest |
|---|---|---|---|---|---|
| Certification iOS CSPN-2020/30 + RTE public | ANSSI, certificateur; Synacktiv CESTI, évaluateur; rapport daté du 27 avril 2020 / certification signée 18 septembre 2020; Olvid iOS 0.8.2, configuration iPhone 11 iOS 13.4.1, iPhone 8 iOS 13.3, iPhone 7 iOS 13.2.3. Certificat ANSSI [accès à vérifier], RTE Synacktiv | 40 jours-personnes; authentification utilisateur et interlocuteur, chiffrement messages et pièces jointes, sauvegarde chiffrée des contacts. Revue de code source, analyse statique et dynamique, recherche de comportements suspects et relecture protocolaire. | Serveur Olvid explicitement hors périmètre; versions ultérieures, appels/multi-device courant et infrastructure non évalués. Deux appareils jailbreakables étaient utilisés pour l’analyse; aucun commit SHA dans le rapport. CSPN est un niveau d’évaluation défini, pas une preuve d’absence de faille. | V-01 usurpation partielle par scénario combinant contrôle réseau et du canal d’introduction, avec probabilité estimée de 10⁻⁴ dans les conditions décrites; attaque complexe, non exécutée, seuil de résistance expert/attaque forte. V-02 confusion d’homonymes, jugée non exploitable, risque d’usage. V-03 rejeu de commitment dans conditions complexes après échecs précédents; impact jugé limité mais amélioration recommandée. Ce ne sont pas des scores CVSS. | Le RTE indique qu’aucun correctif n’a été appliqué à la version évaluée. Aucune preuve publique de retest indépendant sur une version ultérieure n’a été identifiée dans cette passe; recommandations détaillées à l’éditeur, état de V-03 à établir. |
| Certification Android CSPN-2021/12 + RTE v1.2 | ANSSI, certificateur; Synacktiv CESTI, évaluateur; Olvid Android 0.9.2, build 113; certificat 26 mai 2021, RTE v1.2 daté du 2 juin 2021. Certificat ANSSI, RTE Synacktiv | 35 jours-personnes; fonctions de sécurité analogues : identité/authentification, messages/pièces jointes chiffrés et sauvegarde de contacts. Méthodes CSPN, revue manuelle source, analyse statique/dynamique et tests protocole. | Serveurs hors scope; pas de validation des clients actuels ni des composants séparés depuis 2026. Rapport ne fournit pas de commit source dans les éléments lus. | V-01 possibilité théorique d’usurpation partielle (probabilité 1/10 000 dans scénario construit), nécessitant contrôle du canal de contact QR/e-mail/SMS en plus de la position réseau; serveur seul insuffisant. V-02 homonymie/confusion de contact, non exploitable. Le rapport juge que cela ne réduit pas substantiellement la sécurité globale au niveau évalué; pas de classification CVSS. | Aucun correctif n’était appliqué au build évalué; recommandation de défense autour du contrôle d’introduction et de l’ergonomie d’identité. Pas de retest indépendant post-correction trouvé ici. |
| Analyse formelle académique, hors audit CSPN | Terzo, Cremers, Gonzalez, Schwabe, Yarom et Zhang; « Formal Security Analysis of the Olvid Messenger », ePrint 2026/1622, soumis le 5 août 2026; accepté pour CCS 2026, conférence à venir au 13 oct. ePrint [accès à vérifier], PDF intégral, artefact lié par les auteurs | Environ 8–9 mois-personnes de formalisation/modélisation (rapporté par les auteurs), calcul Tamarin 1.10.0 totalisant env. 11,5 h sur Apple M4/24 GB; ces mesures ne sont pas la durée d’un audit. Tamarin et PoC Flush+Reload fournis dans artefact. | Cœur crypto seulement : CCCD et FRP; preuve symbolique Tamarin fondée sur spec/code. Source Android v3.6 tag v3.6_263, sans SHA dans l’article. Exclut groupes, gestion d’appareils, sauvegardes, backend, stockage et audit complet du client. Adversaire réseau Dolev–Yao et primitives idéalisées; le PoC local est distinct du modèle formel. |
Propriétés établies dans le modèle : authentification mutuelle, secret de clé de session, FS standard, anti-rejeu; KCI/PCS selon protocole et conditions. Limites : échec de modèles eCK/MEX plus forts, absence d’accumulation d’entropie entre certains ratchets; compromis de clés éphémères peut exposer le seed suivant. Revue source : signatures EC non canoniques/malléables; DoS DB persistant (Pixel 4, env. 100 KB/min, build/Android non précisés); deux chemins de multiplication EC non constante. PoC timing vise Java compilé en natif par GraalVM sur Intel i7-10710U / Ubuntu 20.04.6 avec attaquant local/co-résident; pas de démonstration Android réelle ni d’exploitation en production. Pas de tableau CVSS/recommandations de sévérité formelles. | Divulgation responsable aux développeurs en avril 2025; réponse indiquant en nov. 2025 qu’ils prévoyaient du temps pour les correctifs; en mai 2026, les auteurs indiquent qu’une zone a reçu un correctif source et donnent conseils supplémentaires. Les intentions/fix partiel ne précisent pas commits/releases; statut de déploiement et retest indépendant inconnus. Artefact annoncé reproductible, mais non exécuté ici (Tamarin absent de l’environnement). |
Lecture prudente des audits. Les CSPN sont des évaluations approfondies de versions mobiles anciennes, avec un serveur exclu et un scope défini; les certificats ANSSI eux-mêmes ne garantissent pas l’absence de vulnérabilités. Les findings V-01 étaient conditionnels et n’ont pas été présentés comme une exploitation observée. Les qualifiers « non exploitable »/« résistance élevée » des évaluateurs ne signifient pas « risque nul ». Pour les versions 2026, la preuve la plus récente indépendante est l’analyse formelle prépublication, qui porte sur un modèle crypto limité. Ni les corrections historiques ni leurs retests ne sont prouvés pour les builds actuels dans ce dossier.
Olvid — matrice des métadonnées¶
Statut = possibilité/absence technique d’accès établie par sources publiques, pas preuve d’une remise policière. « Contact » désigne le correspondant; « Apple/Google » inclut stores, APNs/FCM et sauvegardes associées. Les affirmations de politique restent des déclarations fournisseur.
| Métadonnée | Fournisseur Olvid / cloud | Contact | ISP | Apple / Google | Autorités |
|---|---|---|---|---|---|
| IP | CONFIRMÉ techniquement visible aux endpoints; Olvid affirme ne pas la conserver; AWS peut la voir selon politique. | POSSIBLE en appel direct/fallback ou hors canal; appels via TURN sont relayés selon doc. | CONFIRMÉ IP source et destination réseau. | POSSIBLE via push/store/sauvegarde; lien au profil Olvid non établi. | POSSIBLE via Olvid, AWS/CDN, ISP, store ou appareil; aucune production effective trouvée. |
| Téléphone | NON ACCESSIBLE PAR DESIGN comme identifiant requis selon éditeur; peut apparaître achat/support. | POSSIBLE si partagé hors profil ou dans le chat. | NON ACCESSIBLE PAR DESIGN dans le seul payload chiffré; opérateur télécom connaît l’abonné de la SIM. | POSSIBLE au compte Apple/Google; mapping Olvid non établi. | POSSIBLE via opérateur télécom, store, appareil ou données d’achat. |
| POSSIBLE pour support, licence ou correspondance; non requis au compte gratuit selon politique. | POSSIBLE si partagé dans invitation/conversation. | NON ACCESSIBLE PAR DESIGN par le seul flux chiffré. | POSSIBLE au compte store; lien de profil inconnu. | POSSIBLE auprès d’Olvid pour compte pro/support, store, mail ou appareil; remise documentée inconnue. | |
| Identifiant | CONFIRMÉ le serveur voit la clé publique du destinataire nécessaire au routage dans le protocole modélisé; lien avec un nom civil et visibilité exacte en production restent inconnus. Analyse formelle 2026 | CONFIRMÉ identité et données de profil communiquées au contact choisi selon l’éditeur. | NON ACCESSIBLE PAR DESIGN comme ID de profil applicatif, mais endpoints/IP visibles. | POSSIBLE token d’installation/store; mapping profil inconnu. | POSSIBLE via données détenues, terminal, licence ou réquisition fournisseur. |
| Graphe social | PROBABLE le serveur de routage voit la clé publique destinataire et peut corréler certains échanges; le papier 2026 indique qu’un opérateur ayant ses propres contacts peut relier certaines clés à des personnes. Graphe complet/non propriétaire : non établi. | CONFIRMÉ contacts et discussions dont le correspondant est membre. | POSSIBLE inférence timing/volume, pas graphe directement depuis une seule ligne. | POSSIBLE corrélation de push, sauvegardes et compte; non démontré. | POSSIBLE via terminal, contacts, autres membres, opérateur ou corrélation; aucune remise Olvid documentée. Analyse formelle |
| Timestamps | CONFIRMÉ timing des messages/routage visible dans le modèle formel 2026; logs/rétention de production restent inconnus. Connexions, queues, fichiers, push et TURN ajoutent d’autres traces possibles. | CONFIRMÉ dans l’historique local. | CONFIRMÉ connexion et volume temporel. | PROBABLE horodatages de push, sauvegarde et activité store. | POSSIBLE chez chaque détenteur si conservés; cas réel non établi. |
| Volumes | CONFIRMÉ taille des messages et volume réseau/objets techniquement observables aux relais/cloud; existence et rétention de logs inconnues. | CONFIRMÉ messages/fichiers reçus localement. | CONFIRMÉ octets et durées de flux. | POSSIBLE tailles/fréquences de notifications/sauvegardes selon payload. | POSSIBLE auprès du fournisseur/cloud/ISP si logs existent. |
| Groupes | INCONNU visibilité exacte du service pour les groupes courants; audit 2020/21 ne couvre pas état actuel. | CONFIRMÉ pour les membres du groupe et discussions auxquelles ils ont accès. | POSSIBLE corrélation de trafic répétée, sans liste directe. | POSSIBLE push/timing; appartenance non établie. | POSSIBLE via terminaux/membres ou services ayant traces. |
| Appareils | CONFIRMÉ transfert/import d’un second appareil est une fonction et un endpoint dédiés; visibilité des logs inconnue. | POSSIBLE par appareils actifs, états et notifications, sans inventaire fiable. | CONFIRMÉ IP/connexion de chaque appareil vu au réseau. | PROBABLE token APNs/FCM et compte store liés à un terminal, mais mapping Olvid inconnu. | POSSIBLE par réquisition de traces, cloud/store ou saisie. |
| Push tokens | CONFIRMÉ serveurs APNs/FCM figurent au chemin; liaison token ↔ identité côté backend non vérifiée. | NON ACCESSIBLE PAR DESIGN au correspondant selon architecture push. | NON ACCESSIBLE PAR DESIGN comme token; IP et timing de connexion visibles. | CONFIRMÉ token traité par service push; payload exact actuel inconnu. | POSSIBLE auprès d’Olvid/Apple/Google si conservé et légalement demandé; remise effective inconnue. |
Olvid — première colonne TM1–TM15¶
Appréciation provisoire et spécifique aux preuves disponibles, pas classement de produits. Les catégories d’endpoint portent sur l’exposition du terminal, pas sur une faiblesse de l’E2EE.
| Modèle | Cellule | Justification probatoire courte |
|---|---|---|
| TM1 — fournisseur curieux | 🟠 | Analyse formelle 2026 : serveur voit clés publiques de routage, taille et timing; les auteurs jugent certaines clés corrélables par un opérateur qui connaît ses contacts. La rétention en production reste inconnue. PDF |
| TM2 — fournisseur compromis | 🟡 | L’analyse formelle indépendante appuie plusieurs propriétés crypto du cœur, sous modèle symbolique; backend peut observer/retarder/bloquer transport et disponibilités. Elle ne couvre pas tout le service. ePrint [accès à vérifier] |
| TM3 — fournisseur malveillant | 🟡 | Authentification hors bande et mécanismes d’identité documentés; les évaluations CSPN anciennes montrent des scénarios conditionnels de spoofing du canal d’introduction et n’auditent pas les releases 2026. RTE Android |
| TM4 — ISP / Wi-Fi | 🟠 | Le réseau voit IP, endpoints, horaires et volumes; aucun test d’obfuscation actuel démontré. FAQ réseau, analyse formelle |
| TM5 — observateur passif multi-points | 🟠 | Cloud/CDN, push, ISP et clé destinataire/timing peuvent offrir des points corrélables; aucune preuve de défense indépendante générale contre l’analyse de trafic. FAQ, papier 2026 |
| TM6 — adversaire global passif | 🔴 | Pas de mixnet ni résultat de résistance globale établi; architecture faible latence avec endpoints, TURN, push et clouds identifiables. FAQ réseau |
| TM7 — contact malveillant | 🟡 | Le contact reçoit contenu/profil partagés; TURN-only documenté pour appels masque l’IP du pair mais expose les deux côtés au relais. Spec appels, FAQ |
| TM8 — harceleur/doxxer OSINT | 🟡 | Pas de numéro/e-mail obligatoire et pas d’accès carnet revendiqué; nom/photo, invitation, clé stable et réemploi hors app restent corrélables. Politique, papier 2026 |
| TM9 — réquisition ordinaire | 🟡 | Pas de cas de remise Olvid trouvé; la politique autorise la réponse légale et l’infrastructure/cloud/store/ISP peuvent détenir des catégories distinctes. Politique, FAQ réseau |
| TM10 — enquête sophistiquée | 🟠 | Agrégation possible de données AWS/store/ISP, appareils, sauvegardes et contacts; aucune preuve de remise de données Olvid dans un cas public consulté. Politique, analyse formelle |
| TM11 — appareil verrouillé | ❓ | Aucun résultat public exact associant outil Cellebrite/GrayKey/Magnet + modèle + OS + build Olvid n’a été établi; les CSPN 2020/21 ne sont pas des tests d’extraction forensic contemporaine. RTE iOS, RTE Android |
| TM12 — appareil déverrouillé | 🔴 | Le client déchiffre les conversations sur le terminal; l’accès local à l’app/session contourne la protection de transport. L’état DB/artefacts version 2026 reste à mesurer. Politique |
| TM13 — spyware ciblé | 🔴 | Un spyware ayant accès à l’écran, mémoire ou processus après déchiffrement peut capturer le contenu; la multiplication scalaire non constante étudiée en 2026 ne prouve pas une infection réelle. Papier 2026 |
| TM14 — supply-chain compromis | 🟠 | Sources clients publiques mais builds distribués non reproduits; backend public incomplet/anonymisé, moteur/Maven, magasins, CI, signatures et cloud restent à auditer. Android, backend |
| TM15 — censure étatique | 🟠 | Plusieurs domaines/API, fournisseurs cloud, push et TURN peuvent être bloqués; aucun mécanisme Tor/bridge ni campagne de mesure pays établi. FAQ réseau |
Olvid — contradictions, limites et tests restant à faire¶
- Anonymat vs pseudonymat cryptographique : le papier indépendant 2026 conclut que le serveur voit clés publiques de destinataire, tailles et timing, et que des contacts propres à l’opérateur peuvent permettre de relier une clé à une personne; ses auteurs recommandent de comprendre la propriété comme pseudonymat plutôt qu’anonymat cryptographique. L’équipe Olvid aurait répondu que le terme « anonymat » est employé dans un sens non technique (serveur ne connaît pas nom/contact) et reconnaît que les utilisateurs sont identifiés par clés publiques. Le désaccord porte donc en partie sur la définition, mais les observables réseau/routage restent réels. PDF
- IP : politique dit IP techniquement utilisée mais non conservée par Olvid; même politique indique qu’AWS peut voir les IP. Cela distingue l’application/opérateur du sous-traitant, mais la durée effective des logs cloud reste inconnue.
- Certifications : les CSPN sont réelles et substantielles, mais datent de 2020/2021, évaluent iOS 0.8.2 / Android 0.9.2 build 113 et excluent le serveur. Elles ne sont pas une certification du produit complet actuel.
- Crypto / PQ : la page technologie contient encore une formulation ancienne affirmant qu’aucun standard post-quantique NIST n’existe; c’est un indice de contenu vieillissant, pas preuve de l’état crypto courant. Le PDF intégral de l’ePrint a été lu; il reste à lire la spécification 2024 au-delà des éléments extraits et à établir les algorithmes/négociation du build courant.
- Données effectivement obtenues par police : capacité/possibilité légale documentée; aucune livraison dans un cas réel identifié. Ne pas transformer le silence de la recherche en « aucune donnée jamais remise ».
- Tests prioritaires : (1) relever DNS/CNAME/TLS/ASN et permissions réseau depuis des résolveurs autorisés; (2) capture passive d’un compte de test pour lister domaines, IP, timing/volumes et appels/push; (3) audit manifests/permissions/SDK des versions exactes Play/App Store; (4) reconstruire APK/IPA et comparer aux artefacts signés; (5) test ICE/correspondant et serveur TURN; (6) inspecter sauvegarde iCloud/Drive/WebDAV et DB locale/WAL/fichiers; (7) analyse forensic verrouillée/déverrouillée avec outil + modèle + OS + build Olvid notés; (8) reproduire Tamarin et la PoC localement, sans en extrapoler à Android; (9) retrouver commits/releases et retester les corrections annoncées aux auteurs; (10) rechercher dossiers judiciaires par entité et fournisseurs sans conclure à l’absence depuis les seuls résultats indexés.