Ricochet Refresh — dossier de preuves (situation 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.
Séparation cruciale des versions. Version stable Ricochet Refresh 3.0.46, publiée le 23 septembre 2026; elle embarque Tor 0.4.9.13. La branche maint-3.0 est la branche de release. Une 3.1.0-alpha.0 séparée expérimente une réécriture Rust du backend Tor/protocole et n’est pas traitée comme stable. Le Ricochet historique (v2 onion, dernier développement ancien) n’est pas Ricochet Refresh v3. L’audit NCC de 2015 porte sur le Ricochet historique, pas sur 3.0.46.
Sources primaires principales : site et version 3.0.46, release 3.0.46 / hashes / signatures / composants, branche stable, code et historique, conception, protocole v3, déclaration du projet sur les attaques médiatisées de 2019–2021, audit NCC original / PDF 24 pages, miroir PDF lisible, registre australien Blueprint for Free Speech Inc..
| # | Catégorie | FACT | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN |
|---|---|---|---|---|---|---|
| 1 | Architecture | Client desktop peer-to-peer sur Tor Onion Services v3; chaque utilisateur héberge un service onion local, les contacts se connectent au travers du rendezvous Tor. | Pas de serveur de chat, ni d’entité centralisée qui stocke ou relaie les messages; ne s’affilie pas au Tor Project. | Le protocole maint-3.0 décrit une connexion par service onion et channels chat/contact/fichier; la release 3.0.46 inclut Tor 0.4.9.13. | Le réseau d’application n’a pas de broker central, mais dépend du réseau Tor, de ses autorités/consensus/relays, et de l’intégrité des clients. | Disponibilité selon NAT/OS, dépendance exacte aux autorités/HSDirs/guards et comportement de reprise, non mesurés ici. |
| 2 | Protocole cryptographique | Identité v3 service onion Ed25519; preuve de contact signée avec clé privée Ed25519-v3. Transport protégé par Tor onion-service; pas d’E2EE applicative distincte clairement documentée dans le protocole 3.0. | Communications chiffrées E2EE et « private by default ». | Le protocole décrit l’authentification de service onion et les channels, sans Double Ratchet; l’audit historique recommandait justement couche crypto applicative, mais il portait v2/2015. | Confidentialité dépend essentiellement du chiffrement Tor entre endpoints et du poste; point de terminaison compromis, mauvais client ou vulnérabilité Tor peuvent atteindre contenu/métadonnées. | Primitives/paramètres exacts et garanties PFS de la version Tor embarquée; app-level encryption supplémentaire éventuellement présente ailleurs que dans le protocole public. |
| 3 | Création d’identité | Profil produit un identifiant stable dérivé de l’adresse onion v3; pas de téléphone/e-mail/compte de connexion requis. | Anonymat sans identité civile, ID partagé au choix. | Le site indique que l’adresse onion est l’identité; la branche stable stocke un fichier profil local. | Pseudonyme stable, non identité civile; si publié/réutilisé, l’ID devient un pivot permanent de corrélation. | Génération du secret privé, protection matérielle OS, rotation, duplication/copie de profil et mécanisme de récupération. |
| 4 | Contact discovery | L’ajout se fait en transmettant l’ID onion par un canal externe puis en acceptant une demande entrante; pas de recherche centralisée de carnet. | Aucun annuaire de comptes ou synchronisation de contacts. | Le guide de conception et le protocole décrivent la demande de contact authentifiée au service onion. | Le canal par lequel l’ID est partagé (Discord, e-mail, site) peut faire le lien entre pseudonymes; le contact connaît l’ID reçu. | Indexation externe d’IDs onion, découverte secondaire et protection réelle des demandes non sollicitées. |
| 5 | Métadonnées serveur | Pas de serveur applicatif central; Tor transporte circuits et onion descriptors. Contacts savent leur propre connexion et le statut en ligne/offline observé. | « Nobody knows who you talk to or when » / aucune métadonnée. | Protocole et site établissent l’absence de serveur applicatif, pas l’absence d’observation par relay, guard, correspondant ou adversaire multi-points. | « Sans serveur » réduit les logs centraux, mais ne supprime ni timestamps locaux, ni état en ligne visible au contact, ni corrélation Tor. | Visibilité exacte des HSDirs/guards/points d’introduction, champs et rétention de données Tor en condition réelle. |
| 6 | IP utilisateur | Le client se connecte à Tor; le guard voit l’IP source; l’ISP voit la connexion au guard. | Aucun contact ne voit l’emplacement/IP. | Site et modèle Tor décrivent routage multi-hop; fournisseur affirme que l’IP utilisateur est masquée aux contacts. | Tor déplace la confiance d’un serveur vers le chemin réseau, sans effacer l’observation du premier relais et les corrélations de trafic. | Fuites DNS/IPv6, erreurs de configuration du Tor embarqué, journaux locaux et variabilité par OS. |
| 7 | IP exposée au correspondant | Les messages/fichiers traversent le service onion plutôt qu’une connexion IP directe déclarée par l’app. | Le contact ne peut pas connaître IP ou localisation de l’utilisateur. | L’architecture Tor et le protocole n’annoncent pas de candidate ICE/STUN/directe au contact; aucun test pcap indépendant de 3.0.46 effectué ici. | Protection contre divulgation IP directe au contact plausible par design, mais pas contre dé-anonymisation par timing/collusion/global observer. | Fuite involontaire hors Tor dans 3.0.46, liens ouverts dans navigateur externe, métadonnées de fichiers et appels OS. |
| 8 | Messages | Chat texte direct, maintenu dans une connexion active via Tor; protocole v3 contient texte, acknowledgement et delta de timestamp; aucun store-and-forward serveur. | Seulement le destinataire peut lire le message. | Protocole public décrit les champs message et transport Tor; guide annonce temps réel et données locales. | Le pair sait que la connexion/activité a lieu; le service n’a pas de boîte offline centrale. | Persistance exacte des conversations dans profile, crash dumps, logs et caches dans stable v3.0.46. |
| 9 | Groupes | Pas de groupe/chatroom multi-participants documenté dans le protocole stable; usage 1:1. | Produit présenté comme chat privé, non comme plateforme de groupes. | Le protocole documente un canal chat par contact et ne liste pas de canal de groupe. | Peu d’exposition de membership de groupe par application; pas un outil de groupe. | Fonctionnalité éventuelle dans branche 3.1 ou extensions non officielles. |
| 10 | Appels | Aucun audio/vidéo décrit pour Ricochet Refresh 3.0.46 stable. | — | README et protocole stable détaillent chat/fichiers, pas appels. | Pas de risque ICE/STUN de call selon documentation actuelle, mais pas d’usage VoIP. | Fonction appels dans forks/alpha; permissions éventuelles intégrées à des builds tiers. |
| 11 | Fichiers | Le protocole stable inclut un file-transfer channel sur même liaison onion; filename, taille et hash sont dans l’en-tête; transport par chunks avec ACK. | Transfert sécurisé intégré, sans serveur central. | Protocole maint-3.0 décrit metadata du fichier et transfert séquencé; aucune analyse indépendante du fichier système actuel trouvée. | Le contact destinataire connaît nom/taille/hash; le corps fichier traverse la couche Tor, mais métadonnées internes/EXIF persistent. | Chiffrement additionnel, quotas, répertoire temporaire, suppressions, comportement antivirus et intégrité côté UI dans v3.0.46. |
| 12 | Multi-device | Pas de compte cloud/multi-device documenté; l’identité est un onion service et un profil local par installation. | Profil local sur son propre ordinateur. | Avertissement officiel de l’alpha 3.1 conseille sauvegarde du profil avant essai; post officiel donne le chemin ricochet.json par OS. | Copier le profil peut dupliquer la même identité privée, pas établir un protocole de synchronisation multi-device sûr. | Comportement d’export, import, concurrence de profils et usage simultané sur différentes machines. |
| 13 | Push | App desktop Windows/macOS/Linux; pas d’APNs/FCM recensé; présence online requiert service onion et Tor actif. | Pas de dépendance push mobile. | Site/release ne proposent pas d’app mobile. | Pas de fournisseur push pour l’app desktop officielle; présence permanente expose des fenêtres d’activité à des observateurs. | Télémétrie système OS, notifications desktop et éventuels services tiers du site. |
| 14 | Stockage local | Profil local stable identifié comme ricochet.json dans les emplacements Windows/macOS/Linux communiqués par l’éditeur; ID/contacts/clé nécessaires au service localement. | Les données de compte résident sur l’ordinateur, pas sur un serveur. | L’audit NCC 2015 trouvait contacts/config/Tor cookie/.torrc non chiffrés sur disque, mais ce constat cible le Ricochet historique. | Une saisie peut révéler au minimum l’ID et les contacts si l’actuelle version n’a pas de chiffrement OS; cela doit être retesté sur 3.0.46. | Chiffrement des profils actuels, stockage historique messages, caches, fichiers reçus, logs, mémoire et permissions par OS. |
| 15 | Sauvegardes | Export/back-up du profil est recommandé avant l’alpha 3.1; pas de backup cloud propriétaire connu. | Données restent sous contrôle local; profil sauvegardable. | Les releases alpha avertissent d’une migration incompatible potentielle de profil; l’éditeur demande d’en faire une copie. | Backup non chiffré emporte identité onion et contacts; elle doit être traitée comme une clé d’identité. | Mécanisme d’encryption, recommandations de backup chiffré et inclusion par OS backups. |
| 16 | Analytics / SDK | Source de l’app est public; code de release dépend de Qt, OpenSSL et Tor; aucune app mobile/tracker Play/App Store pour le stable officiel. | Produit ouvert, pas d’enregistrement/centralisation d’usage. | Repositories publics et logs des releases; pas d’analyse de binaire/traffic de télémétrie effectuée ici. | Pas d’analytics central inherent au protocole; site download, OS et système de mise à jour restent des canaux distincts. | SDK analytics/crash reporting dans binaires actuels; scripts build et site web; privacy labels mobiles n/a. |
| 17 | Code source | Dépôt public C++/Qt; branche maint-3.0 stable et branche main alpha. Dossier séparé ricochet-build publie les scripts de build. | Open source; développeurs invitent aux contributions. | Repos montrent source, documentation et CI, mais code ouvert n’est pas une review actuelle. | App déployée comprend Tor embarqué, Qt, OpenSSL et pipeline; dépôt app seul ne couvre pas la supply chain complète. | Revue complète et version source commitisée précisément pour les binaires 3.0.46, provenance des sous-modules. |
| 18 | Reproductibilité des builds | Assets 3.0.46 incluent hash et signatures .asc; page confirme signatures GPG des releases. | Releases signées; hashes fournis. | Tag v3.0.46-release/commit 154f32b annoncé comme signé « verified », mais la clé était signalée expirée; aucun rebuild bit-à-bit tiers trouvé. | Hash/signature aident intégrité, mais une clé expirée accroît la nécessité de vérifier fingerprint/historique; cela n’équivaut pas à une build reproductible. | Expiration à la date de signature, révocation éventuelle, provenance CI complète et équivalence source-binaire multiplateforme. |
| 19 | Supply chain | 3.0.46 a mis à jour Tor 0.4.9.13 et tor-expert-bundle 15.0.23; versions stables anciennes cassent avec évolution Tor du 1 septembre 2026; site dit installer >3.0.43. | Publication régulière « monthly-ish » pour suivre Tor/OpenSSL/Qt. | Changelog décrit dépendances et signatures; la nécessité de versions récentes a été annoncée par l’éditeur avant coupure Tor. | Dépendance forte au bundle Tor et au rythme d’update; une version obsolète perd la capacité de connexion et garde des bugs upstream. | SBOM signé complet, build workers, approbation à deux mainteneurs, vulnérabilités héritées restantes. |
| 20 | Infrastructure OSINT | Pas d’infrastructure applicative de messages à résoudre; sites d’information/téléchargement ricochetrefresh.net et GitHub; trafic client passe sur le réseau Tor. | Aucune organisation/infrastructure centralisée à attaquer pour héberger les données. | Site officiel et GitHub sont publiquement identifiés; réseaux Tor ont autorités de directory et opérateurs relay distincts. | Compromettre le site/GitHub/update peut substituer les binaires; ce n’est pas la même chose que compromission d’un serveur de messages. | DNS actuel/registrar/ASN/CDN/région du site et GitHub release assets; non résolu par observation passive dans ce dossier. |
| 21 | Juridiction | L’opérateur de développement est Blueprint for Free Speech Inc., organisme australien inscrit au registre des charities; pas d’opérateur de messagerie central. Le site parle aussi d’une branche allemande distincte (e.V.). | Organisation non gouvernementale/nonprofit soutenant la liberté d’expression. | ABN Lookup/ACNC australien confirment l’entité australienne; mentions allemandes ne prouvent pas l’entité contractante du logiciel. | Une injonction à l’entité australienne peut viser site/builds/données de support qu’elle possède, pas un historique de messages central inexistant. | Structure juridique contractuelle entre Inc., e.V., projet, hébergeurs, clés de release et obligations précises de conservation. |
| 22 | Demandes policières | Aucun guide law-enforcement/transparency report Ricochet Refresh trouvé; aucun backend central de chat à remettre par design. | Aucun serveur de données; pas d’inscription. | Cas Boystown documenté par enquête journalistique à partir de dossiers: l’attaque a utilisé Ricochet historique et les données du fournisseur téléphonique, pas une remise de contenu par Blueprint. | Autorités peuvent viser ISP, relays, distribution, site, correspondant ou appareil; l’absence d’entreprise de stockage ne neutralise pas une enquête réseau. | Dossiers judiciaires complets non ouverts ici; demandes reçues par Blueprint/hosting, conservation effective et remises de données administratives. |
| 23 | Affaires judiciaires | Affaire Boystown (Allemagne, activité d’enquête 2019–2021) a lié une cible utilisant Ricochet historique aux entry guards Tor; un ordre judiciaire a demandé à Telefónica d’identifier quels clients O2 s’y connectaient. | Blueprint affirme ne connaître aucun utilisateur dé-anonymisé avec la version actuelle Ricochet Refresh; dit que les faits rapportés concernent 2019–2021 et l’ancienne application, et que les preuves détaillées ne lui ont pas été fournies. | Tagesschau/Panorama rapporte l’identification répétée de Tor entry nodes et l’ordonnance du tribunal de Francfort au fournisseur; ce n’est pas une preuve de contenu obtenu depuis Ricochet ni de break cryptographique. | Données effectivement obtenues rapportées: mapping IP/entry-node et identité d’abonné par FAI, après corrélation ciblée. L’ID Ricochet/activité servait à cibler; aucun message en clair n’est annoncé. | Affidavit complet, méthode exacte et portée judiciaire; si d’autres utilisateurs furent collectés incidemment; résultat final applicatif exact et détails techniques non publiés intégralement. |
| 24 | Audits | Un audit public NCC Group existe pour Ricochet original en 2015, version de rapport 1.2 du 15-02-2016; aucun audit public de Ricochet Refresh 3.x identifié. | L’éditeur présente le produit Refresh comme amélioré et annonce mises à jour fréquentes. | Le PDF NCC peut être lu; son périmètre n’est pas le client Refresh/Tor onion v3 actuel. | L’audit constitue une leçon historique, pas une garantie de l’actuel binaire. | Aucun commit précis du code historique dans rapport; aucun rapport Refresh indépendant ni retest trouvé. |
| 25 | Vulnérabilités | L’audit historique trouva une faille High de validation de demande contact pouvant exposer l’IP lors de l’acceptation, une Medium sur liens Unicode, et six notes informatives; l’app actuelle met à jour Tor en versions récentes. | Le projet dit vanguards-lite inclus depuis 3.0.12 (juin 2022) rend les attaques de guard-discovery plus difficiles; mises à jour régulières des dépendances. | L’enquête allemande rapporte désanonymisation de l’ancien Ricochet via timing/guard discovery, pas bris du chiffrement du message; rapports médias n’apportent pas toutes pièces techniques publiques. | La protection évoluée et le modèle onion v3 atténuent certaines attaques, mais ne prouvent pas l’immunité aux corrélations globales, ciblées ou endpoint. | CVE/retest spécifiques du stable 3.0.46, exploitation observée post-3.0.12 et effet exact de vanguards-lite contre la méthode Boystown. |
| 26 | Recherche académique | La recherche Tor sur les attaques de traffic analysis décrit classe de corrélation; pas d’évaluation académique actuelle publiée pour Refresh 3.0.46 identifiée. | L’éditeur réfute les garanties absolues et qualifie les attaques puissantes de coûteuses/étatiques. | Documents journalistiques indépendants et travaux Tor sur traffic analysis établissent que Tor n’est pas résistant à un adversaire global; aucune mesure de l’app stable trouvée. | Le chat temps réel produit des timings reconnaissables, donnant un signal actif/corrélable même si contenu reste chiffré. | Analyse formelle du protocole Refresh contre adversaire global/passif, simulation vanguards/traffic padding et étude indépendante après 2022. |
| 27 | Incidents historiques | Ricochet original a eu protocole v2 à identité RSA/SHA-1 tronquée et une dé-anonymisation de contact request auditée en 2015; Refresh a porté Tor onion v3 et ajouté vanguards-lite. | Développeurs disent que l’ancien Ricochet est abandonné car technologie Tor v2 retirée, et que Refresh est mis à jour. | Cas Boystown concernait une version de Ricochet déclarée par sources comme abandonnée/ancienne, pas preuve d’une compromission de Refresh. | Histoire montre que la résistance aux métadonnées peut échouer sans casser E2EE; il faut distinguer famille applicative, versions et Tor. | Liste chronologique complète des incidents mineurs/bugs par release, retests de l’ancienne faille High et éventuels incidents non publics. |
| 28 | Gouvernance / financement | Projet soutenu par Blueprint for Free Speech Inc.; organisme australien nonprofit/charity et branche allemande e.V. distincte; financement d’un projet NGI/NLnet antérieur documenté. | Organisation non gouvernementale, nonprofit; projet pour journalistes/whistleblowers. | Registre ACNC/ABN australien, site Blueprint, crédits NGI établissent la gouvernance générale mais pas comptes opérationnels du produit. | Structure nonprofit et financement connus n’impliquent pas de contrôle indépendant du code ni assurance de continuité. | Budget, nombre exact de mainteneurs rémunérés, possession/rotation clé release, responsabilités juridiques du site hébergeur. |
| 29 | Résistance à la censure | Utilise Tor, donc accès peut être bloqué par filtrage Tor, guards/IP, téléchargements GitHub/site et magasins desktop; pas de mobile. | Résiste au monitoring/censure locale selon les objectifs de conception; aucun bridge n’est une propriété explicite du protocole de chat. | Cas de Tor, consensus et vanguards sont documentés; l’app a modifié les versions Tor en fonction des changements network. | Censorship circumvention dépend de la configurabilité du Tor intégré et de bridges; architecture P2P n’empêche pas le blocage du transport. | Configuration bridge/obfs4/Snowflake dans 3.0.46, comportement dans pays censurés et possibilité de modifier relay/ports par utilisateur. |
| 30 | Maintenance actuelle | Stable 3.0.46 (23-09-2026), Tor 0.4.9.13; 3.1.0-alpha.0 est une réécriture Rust distincte destinée aux tests et sauvegarde recommandée. | Le site indique releases « monthly-ish » suivant mises à jour amont; le mainteneur publie des mises à jour. | Releases septembre 2026 et commit/tag signés visibles; comptes GitHub affichent 1,612 commits mais ce total couvre l’historique et ne mesure pas les mainteneurs actifs. | Maintenance récente démontrée; néanmoins la portée des audits externes actuels n’est pas démontrée. | Mainteneurs actifs par composant, tests automatisés/coverage, retest et date de disponibilité de 3.1 stable. |
Ricochet Refresh — extraction du PDF NCC et limite de portée¶
Organisme/commanditaire/version/méthode. NCC Group Security Services, Inc.; projet Ricochet + Open Technology Fund; deux consultants à l’engagement, auteurs nommés Jesse Hertz, Patricio Jara-Ettinger, Mark Manning; rapport v1.2 du 15 février 2016. Le tableau de bord du PDF donne dates 16–22 novembre 2015 et 16 person-days; page OTF indique 16–25 novembre (écart de date documentaire). Source code review white-box C++, Qt, Protocol Buffers; revue de code et documents de design, fuzzing AFL et analyse dynamique qualifiée de cursory. Exclusions explicites: fichiers de layout QML hors périmètre; Tor lui-même hors périmètre; tests additionnels recommandés. Pas de hash commit/version source commitée dans le rapport; aucun retest NCC public trouvé.
Résultats (sévérités NCC, pas CVSS):
| ID | Sévérité NCC | Finding, impact, recommandation | Correction/retest public |
|---|---|---|---|
| 007 | High (impact High, exploitabilité Medium) | HTML/unicode dans nickname/message de contact request; si victime accepte, rendu peut déclencher requête révélant l’IP réelle ou phishing/homographe. Whitelist stricte/validation encodage. | Le rapport indique des tickets de bug déjà connus; pas de preuve de retest NCC. Modern v3 transporte la demande par Tor, mais un navigateur/lien externe ou endpoint reste un chemin à tester. |
| 006 | Medium (impact Medium, exploitabilité Medium) | Unicode dans liens peut produire homographe vers site attaquant; visite révèle IP et métadonnées de navigateur; clipboard peut exposer à bug OS. Restreindre caractères/encoder. | Rapport signale un pull request ouvert, mais ne confirme pas merge/retest dans Refresh actuel. |
| 001 | Informational (impact High, exploitatibilité Low) | HMAC supplémentaire dans l’authentification client jugé cryptographiquement complexe et inutile; simplifier par preuve de propriété de clé déjà utilisée côté serveur. | Pas de mapping documenté vers code Refresh ou retest. |
| 002 | Informational (impact Low, exploitabilité Low) | Processus local pouvant usurper socket Tor control et demander un cookie 32 bytes arbitraire; valider chemin/répertoire allowlist ou référence opaque. | Le rapport recommande; pas de statut public de correction/reretest. |
| 003 | Informational (impact High, exploitabilité Low) | Ricochet v2 utilisait hostname fondé sur 80 bits de SHA-1 de clé RSA 1024; adversaire étatique pouvait chercher collision/impersonation. Renforcer vérification/identifiant. | L’architecture Refresh v3 utilise ED25519-v3 et adresse onion v3; la vieille faiblesse précise est historiquement dépassée, sans audit de migration. |
| 004 | Informational (impact Medium, exploitabilité Low) | Messages protégés seulement par le transport Tor, pas d’encryption applicative indépendante; recommander layer crypto additionnelle. | La documentation 3.0 décrit encore le transport onion comme couche de confidentialité; aucun audit Refresh ne valide une couche ajoutée. |
| 008 | Informational (impact High théorique, exploitabilité None dans code observé) | Buffer overread dans CryptoKey::loadFromData, alors appelé avec QByteArray terminé NUL et format DER dans chemin considéré non exploitable; borner la longueur ou retirer code mort. | Pas de correspondance ou retest Refresh établi. |
| 005 | Informational (impact Low, exploitabilité Low) | Fichiers config/metadata en clair: contacts, config Ricochet/Tor, cookies d’auth Tor, .torrc; recommander chiffrement local/OS. | Chemin profile actuel connu mais chiffrement stable 3.0.46 non vérifié; aucun retest. |
Le PDF qualifie l’application d’ensemble comme de bonne qualité dans son périmètre, mais note input validation insuffisante, cryptographie conçue « needs improvement » et stockage au repos en clair pour l’ancien Ricochet. Cela ne doit être ni résumé comme « Ricochet Refresh a passé NCC », ni comme preuve que la version actuelle présente toujours les huit findings.
Ricochet Refresh — forensics et law enforcement¶
- Forensics: aucune étude publique de Cellebrite, GrayKey ou Magnet nommant Ricochet Refresh stable + version d’appareil, OS exact et date d’acquisition n’a été trouvée. Le profil ricochet.json et les clés onion locales sont une cible forensique évidente; c’est une inférence à partir de l’architecture, pas un test d’extraction testé. Les logs/chat history/caches de 3.0.46 doivent être examinés directement sur Windows/macOS/Linux, locked/unlocked et avec chiffrement disque activé/désactivé.
- Affaire documentée: enquêtes presse Panorama/STRG_F et Tagesschau (18 septembre 2024) sur Boystown rapportent que, pendant 2019–2021, le BKA/Généralstaatsanwaltschaft Frankfurt a utilisé une corrélation active de trafic Tor contre une cible utilisant Ricochet historique: activité de chat connue, observation de relais, découverte d’entry guards, puis ordonnance judiciaire au tribunal de Francfort demandant à Telefónica/O2 de retrouver les abonnés connectés à des nœuds identifiés. L’information effectivement obtenue rapportée est une attribution réseau/abonné par fournisseur télécom après corrélation; aucune remise de plaintext par Ricochet/Blueprint n’est décrite. Les articles s’appuient sur des pièces d’enquête, mais le dossier judiciaire complet et les données brutes de mesure ne sont pas publiés ici.
- Réponse de l’éditeur: Blueprint dit ne connaître aucun utilisateur de la version actuelle Refresh dé-anonymisé; affirme que l’affaire concernait l’ancien Ricochet, avant migration v3 et vanguards-lite (introduit par l’app 3.0.12 en juin 2022), et que les détails techniques/éléments de preuve ne lui ont pas été transmis. C’est la position éditeur, non une preuve indépendante d’immunité. Vanguards-lite vise la difficulté de guard discovery; ne neutralise pas toutes formes de correlation globale/timing.
- Demandes et autorités: aucun rapport de transparence/guide légal de Blueprint pour Ricochet Refresh trouvé. Le service applicatif ne dispose pas d’historique central documenté; l’affaire montre cependant le rôle effectif d’un opérateur téléphonique sous ordonnance. Une demande à hébergeur GitHub/site peut viser visiteurs de téléchargement/logs de support selon ce qu’ils conservent, mais aucun cas de remise associée à Refresh n’est établi.
Ricochet Refresh — matrice métadonnées¶
| Métadonnée | Fournisseur Blueprint / app | Contact | ISP | Apple / Google | Autorités |
|---|---|---|---|---|---|
| IP | NON ACCESSIBLE PAR DESIGN au service de messages; POSSIBLE au site/support/distribution si logs existants, inconnus | NON ACCESSIBLE PAR DESIGN par connexion onion selon l’architecture; POSSIBLE via lien ouvert navigateur, contact externe ou endpoint | CONFIRMÉ: connexions à guards Tor, IP source et temps; PROBABLE corrélations multi-points | N/A pour app desktop officielle; compte store possible pour téléchargement indirect | CONFIRMÉ/POSSIBLE via FAI/ordonnance: Boystown a rapporté une identification d’abonné après correlation Tor; aucun IP conservé par Blueprint démontré |
| Téléphone | NON REQUIS; POSSIBLE support/financement si utilisateur fournit lui-même | POSSIBLE si donné hors bande | POSSIBLE par l’abonnement identifié après IP/session | POSSIBLE via compte Apple/Google pour téléchargement, pas via Ricochet | POSSIBLE auprès FAI/store ou terminal |
| NON REQUIS; POSSIBLE support/contact éditeur | POSSIBLE si donné hors bande | NON ACCESSIBLE PAR DESIGN via Tor seul | POSSIBLE au store ou service e-mail | POSSIBLE chez store/éditeur/FAI si corrélé, aucune remise Refresh connue | |
| Identifiant | POSSIBLE site/download may log account/IP, rétention INCONNUE; pas de compte chat | CONFIRMÉ ID onion stable; qui contacte qui peut être observable par le pair | POSSIBLE par timing et activité Tor | POSSIBLE identité install/store (hors messagerie) | POSSIBLE ID onion public + corrélation traffic; cas Boystown rapporté |
| Graphe social | NON ACCESSIBLE PAR DESIGN au serveur app; Tor metadata/observateurs peuvent aider, UNKNOWN exact | CONFIRMÉ par contacts enregistrés et connexions actives | POSSIBLE par analyse corrélative; cas historique ciblé montre un chemin | NON ACCESSIBLE PAR DESIGN directement; possible compte/store activity séparée | POSSIBLE par appareil, correspondants, traffic timing/ISP; incident historique établit ciblage d’un contact/ID |
| Timestamps | UNKNOWN données Blueprint; Tor réseau observe timing à chaque point où il voit flux | CONFIRMÉ état online/connexion, heure des messages côté client | CONFIRMÉ sessions Tor/durée; données historiques peuvent exister chez opérateur | POSSIBLE store/OS de lancement/téléchargement | POSSIBLE; cas de timing analysis documenté par presse à partir d’actes |
| Volumes | NON ACCESSIBLE PAR DESIGN au service message; POSSIBLE hébergeur download si logs | CONFIRMÉ tailles et trafic/messages/fichiers reçus | CONFIRMÉ octets/durée Tor | POSSIBLE metadata OS/store | POSSIBLE FAI/relay/terminal; contenu n’est pas nécessairement connu |
| Groupes | N/A pour protocole stable documenté | N/A | NON ACCESSIBLE PAR DESIGN comme membership explicite, corrélation possible | N/A | N/A |
| Appareils | POSSIBLE données support/website s’il y en a; aucun compte app | CONFIRMÉ même ID/contact, pas nécessairement matériel exact | POSSIBLE empreinte timing/réseau, pas preuve d’appareil | CONFIRMÉ Apple/Google pour l’installation si store utilisé | POSSIBLE par saisie, FAI et store |
| Push tokens | NON ACCESSIBLE PAR DESIGN (pas de push mobile officiel) | NON ACCESSIBLE PAR DESIGN | NON ACCESSIBLE PAR DESIGN | N/A app officielle desktop; OS notification local seulement | NON ACCESSIBLE PAR DESIGN via fournisseur de push; terminal/OS possible |
Ricochet Refresh — TM1 à TM15 (provisoire)¶
| TM | Résistance | Justification |
|---|---|---|
| TM1 fournisseur curieux | ✅ | Pas de serveur central de messages; les données de site/support restent hors du protocole et non auditées. |
| TM2 fournisseur compromis | 🟡 | Compromettre Blueprint ne livre pas le chat côté serveur, mais update/site/repository signés sont une surface de ciblage. |
| TM3 fournisseur malveillant | 🟡 | Pas d’autorité de compte; néanmoins app/updates peuvent être ciblés, et le chat s’appuie sur Tor plutôt que sur un ratchet vérifiable séparément. |
| TM4 ISP / Wi-Fi | 🟡 | Tor masque destinations onion mais ISP voit guards, horaires, volume et peut contribuer à une corrélation. |
| TM5 adversaire passif puissant | 🟡 | Tor évite qu’un relais isolé voit l’origine et la destination simultanément; observations multiples/timing peuvent corréler. |
| TM6 adversaire global passif | 🔴 | Pas de mixnet/padding global; l’affaire historique illustre la possibilité de relier activité connue et réseau, même si version ancienne. |
| TM7 contact malveillant | 🟡 | Le contact ne reçoit pas l’IP directement via onion transport, mais connaît l’ID stable, messages/fichiers et peut piéger via demande/lien externe. |
| TM8 doxxer OSINT | 🟡 | Pas de numéro/e-mail requis; IDs onion stables, réutilisation pseudo, contenus de fichier et divulgation de l’ID sont des pivots. |
| TM9 demande judiciaire classique | 🟡 | Pas d’historique central; service site/hébergeurs, FAI/Tor usage et terminal restent saisissables ou requis. |
| TM10 police sophistiquée | 🟠 | Corrélation réseau + ordres au FAI + saisie endpoint peuvent révéler identité/IP; cas historique de l’ancienne app rapporté. |
| TM11 appareil verrouillé saisi | 🟡 | Pas de chiffrement actuel du profil confirmé; fichier profil et contacts sont locaux. Protection dépend du chiffrement disque/OS et de verrouillage. |
| TM12 appareil déverrouillé | 🔴 | Clé onion, contacts, messages/caches locaux potentiellement ouverts au processus; aucune protection au repos protège un profil chargé. |
| TM13 spyware ciblé | 🔴 | Malware local observe messages, frappes, IDs, fichiers, microphone/écran et clés avant/après Tor. |
| TM14 supply-chain | 🟡 | Code et tags/releases/hashes publics, mais pas de rebuild reproductible indépendant; signature clé release déclarée expirée et dépendances bundle Tor/Qt/OpenSSL. |
| TM15 censure étatique | 🟡 | Tor apporte contournement potentiel, mais guards, bootstrap, téléchargement et binaire peuvent être bloqués; bridges/obfsf4 dans le client stable non vérifiés. |