Session — dossier de preuves approfondi (complément, é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.
Ce complément sépare le protocole Session V1 déployé, le réseau Session, les services annexes (push, fichiers, appels et communautés) et la feuille de route V2. Les sources de code sont des branches publiques consultées, pas un audit du binaire des stores. Les constats de papier décrivent les versions/configurations de leur étude, pas automatiquement chaque release actuelle.
| Catégorie | FACT | VENDOR CLAIM | INDEPENDENT EVIDENCE | INFERENCE | UNKNOWN |
|---|---|---|---|---|---|
| 1. Architecture | Application multi-plateforme; identité stable par Account ID/clé; messages via requêtes onion vers un swarm de nœuds, stockage temporaire répliqué; fichiers via service distinct; appels WebRTC beta et communautés sont des chemins différents. Routage, FAQ | Nœuds distribués et onion requests visent à éviter un serveur de messagerie central connaissant IP et correspondants. Session Network | L’étude USENIX 2026 analyse le protocole client-serveur/swarm courant V1 et montre que décentralisation du stockage n’empêche pas substitution de clé par un nœud malveillant. Article, PDF | « Décentralisé » décrit le stockage/routage, pas l’absence de points de confiance: seed, swarms, push, fichiers, appels et distribution d’apps restent distincts. | Part réelle des nœuds indépendants, concentration de propriété/hosting, bascules et comportements exacts selon chaque version/réseau. |
| 2. Protocole cryptographique | L’implémentation V1 étudiée combine Ed25519 (signature/identité), X25519, clés éphémères par message, BLAKE2 et NaCl crypto_box/XSalsa20-Poly1305; messages persistants signés et compteur applicatif. USENIX 2026 |
Le protocole est présenté comme E2EE; V2 doit apporter PFS/PQ et meilleure liaison d’appareils; le code PFS/PQ est en branche de développement, non livré dans le protocole courant selon update du 2 août. Roadmap | WOOT 2026 relève absence de FS et de déni plausible en V1, absence d’authentification mutuelle robuste des clés publiques et absence de binding cryptographique fiable au compteur monotone; il construit des attaques de substitution, falsification d’horodatage, suppression/rejeu. | E2EE contre un relais passif ne suffit pas à l’authentification de la bonne identité ni à l’intégrité de l’ordre/actualité face à un nœud actif. | Correctifs/proposition post-publication, statut réel des contre-mesures sur les tags Oct 2026 et retest externe. |
| 3. Création d’identité | Compte créé sans numéro/e-mail; Account ID est dérivé de clés stables et récupération via phrase secrète. Le client Android courant demande création/restauration localement. | Aucun identifiant téléphonique ni mail nécessaire; l’adresse IP n’est pas liée à l’Account ID selon l’éditeur. Privacy app | L’article WOOT confirme que clés longues dérivées du seed sont déterministes/stables; clé publique connue reste liée au même pseudonyme dans le temps. | Cela réduit l’association automatique à une identité civile, mais augmente la linkabilité interne du pseudonyme et ne neutralise pas OSINT/réutilisation. | Entropie/mécanisme précis dans toutes builds stores actuelles, éventuel lien réseau par les parcours onboarding, et protection/effacement mémoire réel. |
| 4. Contact discovery | Ajout par Account ID, QR ou partage d’invitation; pas d’annuaire téléphonique obligatoire; manifest Android consulté ne déclare pas READ_CONTACTS. |
Le service est conçu pour ne pas collecter le carnet d’adresses ni exiger numéro/e-mail. FAQ | USENIX rapporte vérification de fingerprint hors bande possible mais non imposée et UX de comparaison longue/peu pratique; boîte de demandes réduit certaines surprises mais pas le risque de substitution pour un contact connu. | L’utilisateur doit authentifier indépendamment l’Account ID/fingerprint par canal fiable; l’existence d’un QR n’est pas en soi une vérification si transmis sur canal compromis. | Comportement des variantes desktop/iOS, éventuelles suggestions/contact import et taux de vérification utilisateur réel. |
| 5. Métadonnées serveur | Le routage transmet ID destinataire, timestamp, expiration et namespace à un nœud du swarm; messages répliqués dans swarm et expirent par défaut après 14 jours selon docs. Onion routing | Onion layers empêchent chaque hop d’apprendre l’IP et le correspondant complet; les messages ne sont pas accessibles au serveur. | Paper WOOT montre une manipulation active possible par nœud sur l’authentification/compteurs, sans déchiffrer le texte. | Chiffrement masque le corps mais pas nécessairement toutes les propriétés de routage/cadence; timing/volume multi-point et présence dans un swarm restent surfaces. | Champs exacts vus par chaque hop pour chaque namespace, format récent, retention logs et observabilité du graphe via collusion de nœuds. |
| 6. IP utilisateur | À l’onboarding, le client Android contacte un seed node pour la liste de nœuds; ce point reçoit l’IP. Lors des messages normaux l’architecture onion est conçue pour masquer IP au node destinataire. | La politique dit que seed voit IP mais ne la journalise pas; push standard/rapide et appels ont des exceptions. Policy, FAQ | Aucun test réseau passif/pcap n’a été réalisé ici; WOOT n’est pas une mesure de l’observabilité IP des déploiements. | Un seed compromis/logging, fournisseur réseau ou corrélation temporelle peut relier une source à des fenêtres d’activité, même si payload relay ne reçoit pas l’IP source directement. | Rétention réelle seed/nodes, logs opérateurs, DNS/IP de chaque endpoint, adresse vue à travers VPN et résistance à un adversaire multi-hop. |
| 7. Exposition IP au correspondant | FAQ dit explicitement que les appels WebRTC beta peuvent révéler l’IP au pair; appels désactivés par défaut, aucune conférence de groupe. FAQ | Appels futurs onion-routés sont annoncés; les messages texte n’exposent pas directement l’IP au correspondant selon design. | Aucun test ICE/capture sur version courante. | Pseudonyme distinct ne protège pas contre un correspondant qui appelle ou partage un lien externe; passerelle TURN change l’exposition pair↔service, sans effacer métadonnées de l’opérateur. | Candidats ICE réellement émis par build, effets VPN, mode TURN, OS et appels beta selon release/région. |
| 8. Messages | Chats individuels E2EE et messages stockés côté réseau temporairement; disparition configurable. | Par défaut, messages de l’infrastructure expirent en 14 jours; l’éditeur ne peut lire le contenu. FAQ | WOOT 2026 montre falsification de l’ordre/timestamp, drop et replay sous modèle nœud actif; il n’a pas cassé la primitive de chiffrement ni observé attaque mainnet. | L’E2EE ne garantit pas livraison, ordre/actualité véridiques ou authenticité de l’interlocuteur sans vérification de clés. | Politique exacte de disparition pour chaque conversation/version, notifications, copies locales, captures côté destinataire et propagation des messages supprimés. |
| 9. Groupes | Groupes fermés annoncés E2EE, jusqu’à 100 membres selon FAQ; « Communities » publiques/self-hosted ne sont pas E2EE et serveur peut recevoir contenu en clair au niveau applicatif. FAQ | Groupes fermés utilisent le même modèle de protection E2EE que 1:1. | WOOT traite fermé/one-to-one mais exclut communautés; findings d’authentification/compteur concernent le protocole évalué. | Un membre compromis peut copier le contenu; « communauté Session » ne doit jamais être assimilée à un groupe privé E2EE. | Audit indépendant du protocole de groupe sur tag actuel, confidentialité des membership lists et correctifs spécifiques après WOOT. |
| 10. Appels | Appels audio/vidéo en beta 1:1, P2P WebRTC, option désactivée par défaut; pas d’appel de groupe dans FAQ. FAQ | Média décrit E2EE; STUN/TURN STF et le pair voient l’IP; aucun contenu accessible à STF. | Pas de mesure indépendante de la suite ICE, TURN, identité cryptographique du média ou rétention. | Appel ne bénéficie pas automatiquement du modèle d’anonymat des onion messages; l’IP pair est une exposition directe documentée. | État fonctionnel par store/OS, chiffrements exacts SDP/WebRTC, relais obligatoire éventuel et comportement après update 1.33.6/2.15.5. |
| 11. Fichiers | Service de fichiers central distinct; téléchargement est chiffré E2EE selon FAQ, plafond 10 MB indiqué; FAQ dit métadonnées EXIF retirées sur desktop mais pas sur mobile. | Onion routing masque IP au serveur de fichiers; fichiers sont chiffrés et service ne peut pas les lire. FAQ | Pas d’analyse APK/IPA ni capture du fichier actuel; Quarkslab 2021 a trouvé attachements iOS historiques en clair sur stockage local (voir audit plus bas). | E2EE réseau n’efface pas EXIF, copies locales, thumbnails, caches ou partage vers un autre app; absence EXIF mobile est une limite explicitement documentée. | Le chiffrement nouvellement activé des flux d’attachements iOS 2.15.5, algorithmes, serveur/régions, durée fichiers, URL/headers/logs et EXIF exacts par format. |
| 12. Multi-device | Restauration d’un même Account ID via phrase de récupération sur autre device; pas de modèle publié de clés d’appareil indépendantes pour V1. | V2 prévoit groupe privé d’appareils, rotation et approbation d’un nouveau device, selon roadmap officielle. | WOOT traite l’identité et la sécurité V1, pas audit de l’onboarding multi-device actuel. | Même secret de compte restauré sur plusieurs appareils élargit la surface: compromission d’un terminal peut exposer identité/communications, et l’utilisateur peut ne pas voir tous les appareils actifs. | Limite de devices, sessions révoquées, signaux d’ajout, cohérence des clés, état de session ancienne après restauration et effacement de compte. |
| 13. Notifications push | Android rapide passe par FCM et push backend STF; mode lent repose sur polling. iOS utilise APNs dans mode rapide. | Apple/Google voient IP/token; STF reçoit Account ID/token; l’éditeur affirme que le push n’inclut ni contenu ni contact ni heure exacte du message. FAQ | Aucune capture push, inspection des payloads ou vérification indépendante du lien token↔ID. | Le chemin rapide ajoute des observateurs/horodatages et une dépendance Google/Apple, même si payload opaque; mode lent réduit ce chemin au coût batterie/latence. | Payload exact, timing, durée de conservation FCM/APNs/STF, permutation token, lien d’identité et comportement réel par OS/version. |
| 14. Stockage local | Le code Android courant décrit signal_v4.db/session.db sous SQLCipher et une clé scellée par Android Keystore; les préférences contiennent des secrets enveloppés. Architecture |
Android déclare allowBackup=false; l’éditeur décrit les données comme chiffrées au repos et le Keystore comme protection de clé. |
Quarkslab 2021 a examiné des bases chiffrées sur Android 10/Session 1.4.1 et trouvé des pièces jointes iOS 1.6.0 en clair. Le parser ALEAPP 2026 lit des artefacts de préférences sur quatre images Android 14/15, mais note l’échec de déchiffrement des bases lorsque le Keystore matériel est non exportable. Audit PDF, ALEAPP | Artefacts récupérables après acquisition n’impliquent pas contenu DB en clair; résultat dépend notamment de l’état verrouillé, du matériel Keystore, de l’OS et de la voie d’instrumentation. | Correspondance exacte versionCode/release et modèle Android, déchiffrement de DB/WAL sur appareils verrouillés/déverrouillés, iOS/Desktop actuels, effacement sûr et validation indépendante des résultats Frida 2025. |
| 15. Sauvegardes | Android manifest allowBackup=false; récupération de compte via mnemonic n’équivaut pas à sauvegarde de base de messages. |
Le seed permet de rétablir le compte; disponibilité du contenu d’historique dépend du réseau et de l’expiration. | Aucun backup courant analysé. | Un secret de recovery stocké dans cloud/clipboard/capture écran peut annuler l’avantage; restauration d’identité ne garantit pas historique. | Mécanisme précis iOS/desktop, backup OS/cloud, export et sauvegarde locale, secrets résiduels / migration. |
| 16. Analytics / SDK tiers | Android source consultée désactive analytics/crash analytics; Gradle conserve Firebase Messaging dans variants concernés tout en excluant analytics/core/measurement. Google Play et App Store déclarent « aucune donnée collectée » (auto-déclaration éditeur). Gradle, Play, App Store | L’app ne collecte pas données personnelles de messagerie; policy distingue app, website et endpoints réseau. | Source manifeste/build public vérifiée, mais pas instrumentation runtime; labels des stores ne sont pas audit indépendant. | « No data collected » n’exclut ni IP nécessaire aux services tiers, ni FCM/APNs, ni données visibles par contact/relay, ni collecte de l’OS/store. | SDK inclus dans IPA, télémétrie réellement émise sur toutes plateformes/releases, attestation store labels contre build distribué. |
| 17. Code source | Repos publics session-foundation Android, iOS, desktop; chacun contient code client et scripts de build; Session Router/libsession et infrastructure sont des repos/composants séparés. | Projet présente ses apps comme open-source et invites vérification communautaire. GitHub org | Lecture partielle des repos/release pages; aucune revue complète des backends/nœuds déployés. | « Client ouvert » n’implique pas code serveur, configuration opérateur ni binaire identique entièrement vérifiés. | Inventaire exact de composants propriétaires, dépendances firmware/SDK, correspondance source de chaque release et services réseau exécutés. |
| 18. Reproductibilité des builds | Repos affichent signatures de commits et release hashes/signatures; Android 1.33.6 publiée le 11 oct. 2026 (tag/release), iOS 2.15.5 aussi le 11 oct.; desktop 1.18.1 publié le 10 juil. 2026. Android, iOS, Desktop | Le projet publie des hash/signature pour sécuriser les releases; ce n’est pas une affirmation équivalente à build reproductible de chaque store binary. | Aucun build indépendant n’a été reproduit/comparé à APK/AAB/IPA/EXE dans cette investigation. | Signature authentifie une origine/clée dans un modèle de confiance; elle ne prouve pas que source publique reproduit le binaire. | Reproductibilité exactes par canal/commit, provenance Android Play, TestFlight/App Store, notarisation et rotation/custody des release keys. |
| 19. Supply chain | Android CI et dép. Gradle/Firebase sont publics; desktop Electron/Node avec workflow de release signée; repos Android/desktop actifs au moment du relevé. | Releases signées et CI automatisée. | Pas d’audit de secrets CI, dépendances transitoires, provenance attestée ou vérification indépendante des binaires. | Le client a plusieurs plateformes, SDK push, stores et libraries cryptographiques: supply chain et review capacité comptent séparément de protocole. | SBOM/signatures SLSA, mainteneurs avec droits de release, nombre d’actifs soutenus, audits dépendances, apps stores comparées et incidents de pipeline. |
| 20. Infrastructure | Documentation annonce 1 500+ nœuds/50+ pays; seed node au démarrage, swarm, push STF, file server, STUN/TURN, communautés auto-hébergées; site utilise Cloudflare. Network, privacy | Nœuds sont indépendamment opérés et onion routing répartit confiance; seed IP n’est pas conservée selon policy. | Article WOOT compte 1 596 nœuds et 274 swarms via explorer en nov. 2025, photographie historique; pas de mesure actuelle faite ici. | Multiplicité de nœuds ne prouve pas diversité opérateur/ASN/hosting; services périphériques peuvent être centralisés. | DNS/ASN/hosting/régions/certificats actuels de chaque service, distribution réelle des opérateurs, rétention et dépendance CDN/cloud non cartographiées. |
| 21. Juridiction | Session Technology Foundation est fondation suisse; page publique donne dirigeants/board mais n’établit pas à elle seule quelles sociétés, sous-traitants ou juridictions contrôlent chaque endpoint. Foundation | STF dit ne pas posséder messages/IP identifiants et publie des rapports de transparence. | Recherche ici n’a pas vérifié registre, contrats, sous-traitants, choix de loi ou propriété des opérateurs de nœuds. | Domicile de fondation n’implique pas immunité extraterritoriale; demandes peuvent viser Apple/Google/hosting/ISP ou opérateurs individuels. | Entités juridiques exactes responsables par app, lieu de contrôle des serveurs tiers, procédures de contestation et portée transfrontalière. |
| 22. Demandes policières | STF publie rapports: 2025 indique 17 demandes/enquêtes, 0 divulgation et « no data held »; Q4 2024 après début de stewardship, 8 demandes signalées. Transparency, 2025 report | Fondation affirme n’avoir remis aucune donnée d’utilisateur; le rapport compte requêtes ou inquiries et répond qu’aucune donnée n’est tenue. | Publication émise par la partie concernée; aucune ordonnance ni réponse tierce jointe/validée indépendamment dans ce dossier. | Ceci établit ce que STF déclare avoir reçu/remis, pas qu’aucune donnée n’a été obtenue ailleurs (store, ISP, device, correspondant, opérateur). | Copies des demandes/redactions, demandes visant tiers/old operator, données obtenues en saisie terminal ou par autres juridictions, cases non publiées. |
| 23. Affaires judiciaires connues | Aucun cas public retrouvé dans cette recherche où un tribunal identifie des données Session effectivement produites par STF, swarm, Apple/Google ou un nœud, avec nature de donnée vérifiée. | Rapports indiquent zéro disclosure STF pour leurs périodes. | Aucun jugement/affidavit/FOIA propre à Session avec résultats de production n’a été vérifié ici. | « Aucun cas trouvé » n’est pas preuve d’absence; les documents peuvent être scellés ou l’app n’être qu’un moyen parmi d’autres. | Recherches judiciaires par pays, alias anciens (Loki/Oxen), demandes de saisie, affaires pénales et productions hors juridiction. |
| 24. Audits | Rapport Quarkslab public (2021, 78 pp.) est l’audit indépendant détaillé principal identifié; audits de build/infrastructure actuels non identifiés ici. PDF | Éditeur dit plusieurs findings corrigés sur releases postérieures. | Étude académique USENIX WOOT 2026 sur V1 actuelle à son étude constitue analyse distincte et révèle vulnérabilités de protocole non résolues par l’ancien scope; pas audit contractuel complet des apps. | Un audit d’app Android/iOS 2020 ne certifie pas l’état des clients, réseau, endpoints annexes et crypto V1 en 2026; corrections annoncées ≠ retest. | Audit indépendant post-correctifs incluant desktop, build pipeline, backend, mobile courant; statut de toute revue crypto V2. |
| 25. Vulnérabilités | WOOT 2026 décrit key substitution/impersonation par nœud malveillant, modification d’horodatage, suppression/rejeu; Quarkslab a trouvé plusieurs issues Android/iOS/desktop historiques. | L’éditeur annonce des corrections 2021 et développe V2; release Android 1.33.6 / iOS 2.15.5 ne cite pas explicitement fixes WOOT dans notes vues. | Papier fournit modèle de menace et attaque en app environnements; éthique limite explicitement test à observation passive en opérations standard, pas d’attaque active sur mainnet; divulguée en déc. 2025–avr. 2026, réponse substantielle en attente à la date papier. | Findings graves pour authenticité/ordre, mais pas preuve d’exploitation en conditions réelles; status courant doit rester « vulnérabilité publiée, correctif non établi ici », pas « activement exploitée ». | Réponse auteur/session post-conférence, ticket/advisory, commit exact patch, release stable contenant fix et retest indépendant. |
| 26. Recherche académique | USENIX WOOT 2026, paper 16 pages publié août 2026, analyse Session Protocol V1 déployé; Quarkslab 2021 antérieur; le papier exclut communities non-E2EE. USENIX | Docs officielles disent V2 en développement; update 6 oct. annonce une revue crypto indépendante future. Update | Étude précise protocol primitives, attaques et disclosure; ne rapporte aucune attaque mainnet conduite. | Source académique indépendante pertinente, mais borne d’étude et date de commit comptent; ne pas la généraliser à V2 non déployé ni à toutes features. | Corpus de protocoles/commits exacts, réplication indépendante de chaque attaque, réponse de l’éditeur, recherche adversarial trafic/metadata actuelle. |
| 27. Incidents historiques | Quarkslab a documenté faiblesses de TLS/routage/logs/stockage sur anciennes apps; WOOT rapporte un rapport responsable de vulnérabilités, mais aucune exploitation observée dans son étude. | Rapports de transparence disent zéro donnée communiquée; roadmap et updates reconnaissent équipe/budget réduits. | Aucun incident public confirmé de compromission massive ou exploitation de ces attaques dans la base consultée. | Finding de sécurité, faille exploitée, exposition metadata, panne et disclosure légale sont catégories distinctes. | Historique complet incidents, interruptions réseau, événements de fuite/nœuds compromis, exploitation non publiée et détails d’incidents sous NDA. |
| 28. Gouvernance / société / financement | STF publie en 2026 que financement communautaire a permis continuer après le 8 juillet avec une petite équipe jusqu’en 2027; update 2 août dit équipe technique de 3 développeurs. Donation, future, V2 | Les mises à jour d’octobre décrivent activité continue, correctifs, lancement Pro; l’équipe dit V2 est financée mais séquencée après Pro. | Données d’équipe et budget sont annonces du projet; aucune vérification financière indépendante consultée. | Projet actif, mais capacité de réponse/audit limitée par taille; risque continuité/maintenance distinct de propriétés cryptographiques. | États financiers, dépendance donateurs, contrôles board, succession clés, effectifs actifs réels par client/backend au 13 oct. |
| 29. Résistance à la censure | Swarm distribué et onion requests éliminent un serveur unique pour messages; app distribution, seed, push, file host, DNS, internet mobile et communautés restent blocables. | Le réseau prétend fonctionner à travers plusieurs nœuds indépendants et éviter la centralisation. | Aucun test OONI, mesure DPI, blocage par pays/ASN ou test de bootstrap réellement exécuté. | Résilience partielle contre panne d’un seul node; l’existence de points de démarrage/services annexes et du token/staking n’établit pas résistance à un état-censeur/global. | Canaux bootstrap alternatifs, reachability censurée, stratégies bridges, stores, transaction staking, performance et test real-country. |
| 30. Maintenance actuelle | Android 1.33.6 et iOS 2.15.5 publiés GitHub le 11 oct. 2026; Desktop 1.18.1 le 10 juil. 2026; les repos montrent développement/release actif. La version en store peut différer. | Updates 6 oct. disent stabilité, router 1.1.0 et V2 indépendant; le protocole de messages V1 reste courant, V2 pas encore déployé. Update 6 oct. | WOOT publie août 2026 et décrit disclosure sans résolution à la date de rédaction; aucune réponse/correctif ultérieur établi. | Activité de releases ≠ réponse aux findings précis, ni maintenance équivalente sur les trois clients. | Propagation stores, cadence durable, active maintainer count par repo, suivi des issues USENIX, dates de release des fixes, support long terme. |
Session — mise à jour réseau et recherche indépendante, 14 octobre 2026¶
- Architecture actuelle : Session a migré de l’ancien réseau Oxen au Session Network en mai 2025; ce n’est donc plus exact de décrire les nœuds courants comme des Oxen Service Nodes. La documentation courante décrit des swarms de 5–7 nœuds pour le stockage temporaire des messages, un réseau Session Node et une couche d’incitation Session Token/Arbitrum. Ces chiffres et propriétés de décentralisation restent des déclarations fournisseur, pas un audit indépendant de la diversité réelle des opérateurs. Annonce de migration, page réseau, architecture Android.
- Services non entièrement décentralisés : l’architecture Android distingue messages/configs/swarms des API dédiées, notamment Pro, version de l’app et enregistrement push. Le code indique que plusieurs de ces requêtes utilisent par défaut l’onion transport, mais l’autorité et le modèle de données restent côté serveur; le bootstrap des seed nodes est un chemin distinct. Il ne faut donc pas résumer l’ensemble des flux par « aucun serveur / aucune IP observée ». Architecture Android.
- Étude académique supplémentaire : Yu et Haines, Practical Attacks on Session Messenger and Oxen Blockchain, IACR ePrint 2026/773, accepté à EuroS&P 2026, annonce sept vulnérabilités dont des attaques réalistes de prise de contrôle du consensus Oxen et des vulnérabilités sérieuses du protocole de groupes Session V1. L’abstract et le programme IEEE sont consultables; le PDF complet IACR a renvoyé 403 lors de cette passe, donc les détails finding-par-finding, commits, sévérités, corrections et retests sont UNKNOWN ici. Puisque le réseau a changé en 2025, les findings de consensus Oxen ne sont pas transposables au réseau actuel sans analyse de la nouvelle implémentation; les findings groupe V1 peuvent être pertinents, mais leur version exacte et leur correction courante n’ont pas été établies. IACR ePrint 2026/773 [accès à vérifier], programme EuroS&P 2026.
- L’étude WOOT 2026 reste distincte : elle analyse Session Protocol V1 et décrit des attaques d’authentification/chronologie/livraison. La documentation officielle indique encore en octobre 2026 que Protocol V2, qui doit réintroduire PFS et ajouter du post-quantique, est en développement; aucune correspondance commits → versions de store → retest indépendant n’est établie. USENIX WOOT 2026, état officiel V2.
- Appels et push — preuves fournisseur détaillées : la FAQ actuelle précise que les appels beta utilisent WebRTC P2P et partagent l’IP avec le contact et le STUN/TURN géré par STF; ils sont désactivés par défaut et il n’existe pas d’appels de groupe. En mode push rapide, FCM/APNs voit l’IP et le token du téléphone, tandis que STF reçoit le Session Account ID et le push token selon l’éditeur; ces éléments n’ont pas été capturés indépendamment. FAQ Session, appels et notifications.
- Disclosure de l’opérateur : le rapport PDF 2025 de STF indique 17 demandes reçues, 0 cas de données fournies et 17 cas « no data held ». C’est une déclaration annuelle primaire du steward, pas une preuve indépendante que les opérateurs des nœuds, stores, ISP ou appareils ne détiennent rien. Rapport STF 2025 (PDF).
Session — audit Quarkslab 2021 : extraction des éléments du PDF¶
Organisme/date/version. Quarkslab, rapport REP-v1.4 daté du 4 mai 2021, Charlie Boulo et Marwan Anastas; mandat d’Oxen, rapport public de 78 pages. Les cibles indiquées sont Android 1.4.1 sur Android 10 (Pixel 2/3), iOS 1.6.0 sur iOS 13.4.1 (iPhone 8) et une révision Desktop identifiée dans le rapport. Rapport PDF, présentation Quarkslab
Durée, méthode, limites. Le mandat total représente environ 42 jours de travail étalés sur plus d’un an, avec une dizaine de jours environ par client mobile, puis du temps supplémentaire consacré au protocole avant Desktop. L’audit combine revue de code et interactions utilisateur, tests dynamiques (dont Frida) et scénarios de client/réseau/serveur compromis; le rapport qualifie l’examen de limité/non exhaustif en raison de l’ampleur du code et de dépendances tierces. Il ne certifie pas le fonctionnement d’un réseau mondial, tokenomics/Lokinet, l’ensemble de l’infrastructure, la supply chain de releases ni les versions 2026. Le protocole et le produit ont évolué depuis.
| Finding dans le rapport | Sévérité/source | Description et recommandation rapportée | Réponse/correction éditeur documentée | Retest indépendant |
|---|---|---|---|---|
| SESS-AND-03 | Android — High | Validation du certificat TLS manquante sur récupération d’IP/clé publique de nœud; permet scénario MITM/substitution au bootstrap. Le rapport recommande validation stricte du certificat. | Oxen annonce correctif Android 1.5.4 puis pinning dans 1.9.0. | Aucun retest Quarkslab post-fix trouvé. |
| SESS-AND-05 | Android — Moderate | Certaines requêtes/communications ne passaient pas par Lokinet; conséquence: IP exposée au serveur concerné. | Annoncé corrigé Android 1.5.4. | Non établi. |
| SESS-AND-06 / AND-07 | Android — Moderate | Seed copiable au clipboard et possibilité de screenshot/lecture visuelle; risque d’exposition locale, particulièrement si malware/OS capture. | L’éditeur considère le choix de partage/visualisation intentionnel (fonctionnement utilisateur). | Non; différence entre UX et mitigation locale reste un choix de produit. |
| SESS-AND-01 | Android — Low | Notifications par défaut divulguaient du contenu. | Toggle d’aperçu ajouté, mais défaut historique avec contenu complet conservé. | Pas de test des réglages/defaults 2026. |
| SESS-AND-02 | Android — Low | Vue/activité pouvait exposer des données lors du passage arrière-plan. | Annoncé corrigé Android 1.5.4. | Non établi. |
| SESS-AND-04 | Android — Low | Générateur de seed de 128 bits, plutôt que 256 bits. | Oxen répond que 128 bits restent impraticables à brute-force pour dériver le compte; auditeurs discutent le compromis mais ne donnent pas d’exploitation réalisable. | Aucun retest; ce finding n’est pas équivalent à une vulnérabilité exploitable confirmée. |
| SESS-IOS-01 | iOS — Moderate | Fichiers attachés stockés en clair dans le sandbox dans la version testée. | Réponse dit chiffrement local de base de données par mot de passe en cours de développement; pas de version corrective ferme identifiée dans le rapport. | Non établi; historique seulement. |
| SESS-IOS-02 | iOS — Moderate | Pinning/bootstrap server certificate absent. | Éditeur indique pinning iOS 1.9.4. | Non établi. |
| SESS-IOS-03 | iOS — Moderate | Téléchargement de fichiers pouvait contourner Lokinet et exposer l’IP. | Annoncé corrigé iOS 1.5.3. | Non établi. |
| SESS-IOS-05 | iOS — Moderate | Logs pouvaient contenir des données sensibles. | Annoncé corrigé iOS 1.7.0. | Non établi. |
| SESS-IOS-06 / IOS-07 | iOS — Moderate | Seed clipboard; enregistrement d’écran non bloqué. | Comportements présentés comme intentionnels/usages contrôlés par l’utilisateur. | Non établi. |
| SESS-IOS-04 | iOS — Low | Seed de 128 bits, même discussion sécurité/usage que Android. | Éditeur défend le niveau d’entropie pour compte Ed25519. | Non établi. |
| SESS-DES-01 | Desktop — Moderate | Données de circuit onion apparaissaient en clair dans des logs. | Éditeur annonce fix Desktop 1.5.3. | Non établi. |
| SESS-DES-02 | Desktop — Low | Updater n’était pas routé par onion; FAI pouvait apprendre une connexion de mise à jour. | Limitation reconnue; intention d’amélioration évoquée. Une résolution précise ne ressort pas du rapport. | Non établi. |
Conclusion de portée. Pour chaque fix ci-dessus, le rapport donne une réponse du fournisseur mais aucune campagne de retest indépendante attachée ne prouve la correction sur un binaire stable actuel. Le résultat ne doit donc servir ni à déclarer les anciennes failles présentes aujourd’hui, ni à certifier qu’elles sont corrigées. Les versions et contextes de test sont explicitement historiques.
Session — preuves forensiques Android (2023–2026) et limites de transfert¶
| Source et statut | Résultat précis publié | Limites établies |
|---|---|---|
| CISC-W’23 / équipe FaS de Kookmin, présentation du 2 décembre 2023; résumé de projet KISIA publié en 2024 | Le programme confirme le travail « déchiffrement de fichiers temporaires Session ». Le résumé de l’équipe indique extraction/analyse des clés de base et de fichiers temporaires au moyen d’Android Keystore, puis construction d’un outil de déchiffrement de DB/fichiers. | Le PDF KISIA a renvoyé une page d’erreur dans cette passe; je n’ai donc pas pu lire le rapport complet. Aucune version Session, modèle, patch Android, état verrouillé, type d’acquisition ni outil commercial n’apparaît dans le résumé indexé. À retenir comme travail étudiant public et piste, non comme preuve d’une extraction d’un téléphone actuel verrouillé. Programme, résumé KISIA. |
| Kim et al., JKIISC 35(5), pp. 1209–1227, publication catalogue daté du 31 oct. 2025 | L’abstract décrit une analyse de DB, logs et fichiers temporaires Session Android, avec extraction dynamique de clé par Frida annoncée comme applicable à un appareil réel; l’article est repéré sous DOI 10.13089/JKIISC.2025.35.5.1209. | Le texte intégral ne s’est pas ouvert depuis KCI/publisher pendant cette passe. L’abstract ne permet pas de confirmer modèles, OS/build Session, niveau de privilège/root, état de verrouillage, Frida version, extraction commerciale, tables décodées ou retest. Sa phrase d’introduction suggérant une hausse d’usage criminel après l’évolution de Telegram n’est pas étayée dans l’abstract par des données d’adoption; elle n’est pas utilisée comme preuve. Notice KCI, catalogue bibliographique. |
ALEAPP sessionMessenger.py, parser tiers créé/mis à jour le 7 août 2026 |
Les métadonnées du parser nomment quatre images testées : Android 14 / Session versionCode 372 et 376; Android 15 / versionCode 417 et 419. Le code extrait les champs de compte/profil et les secrets DB/attachement/logs tels qu’ils apparaissent dans XML de préférences; il ne déchiffre pas le contenu DB ni les pièces jointes, et ne fait que lister chemins/tailles d’app_parts. Ses notes disent que le déchiffrement essayé échoue avec les clés Keystore matérielles non exportables dans ces images; la technique d’extraction par offset de blob citée ne s’applique qu’à un environnement virtualisé sans Keystore matériel. |
Code/parser tiers et notes de l’auteur, pas étude évaluée par les pairs; les quatre images/données brutes ne sont pas fournies par la page source, modèles exacts non documentés dans les métadonnées. Un parser d’image acquise ne prouve ni déverrouillage ni contournement d’Android Keystore. Code ALEAPP. |
Synthèse calibrée. Les résultats ne se contredisent pas nécessairement : ils peuvent concerner des versions, appareils virtualisés/réels, privilèges et états de verrouillage différents. Le code Session actuel confirme une DB SQLCipher dont la clé est scellée sous Android Keystore; les preuves publiques 2023/2025 suggèrent que le contenu peut être extrait sous certaines conditions (notamment instrumentation Frida), tandis que le parser 2026 ne réussit pas à décoder les bases sur ses images à Keystore matériel. Non établi : déchiffrement de la base sur appareil stock, verrouillé et matériellement protégé, avec version commerciale Cellebrite/GrayKey/Magnet actuelle. Architecture Android officielle
Session — étude USENIX WOOT 2026 : findings protocolaires et statut¶
L’article Practical Attacks on a Decentralized Secure Messenger Session (Kota Urushigaki, Hayato Kimura, Atsushi Tanaka, Takanori Isobe), présenté à WOOT 2026 en août, étudie Session Protocol V1 déployé à la date de recherche. La V2 évoquée est alors en développement et non déployée; les communautés ouvertes sont exclues car non E2EE. Les auteurs ont examiné le code et les opérations standard et ont limité leurs essais à l’observation passive/éthique : ils disent expressément ne pas avoir lancé d’attaque active contre le mainnet. Page USENIX, PDF
Les attaques reposent sur deux faiblesses de conception relevées par les auteurs : (a) l’absence d’authentification mutuelle obligatoire et cryptographiquement complète des clés entre correspondants; (b) absence de liaison cryptographique suffisante avec des compteurs/ordre monotones. Ils démontrent dans le modèle d’application des scénarios d’usurpation/substitution de clé par node malveillant, de manipulation de timestamp, et de drop/rejeu/duplication. L’article ne prétend pas retrouver la clé de chiffrement ni casser XSalsa20/Poly1305; l’impact est l’identité, la chronologie et la fiabilité de livraison.
La comparaison de fingerprint existe comme vérification hors bande, mais elle nécessite une action utilisateur longue et est facultative; la friction est un facteur humain, non preuve que tout utilisateur est vulnérable. Le papier explique l’attaque économique d’un node malicieux avec données de token/prix et snapshots de réseau 2025 : ces montants et nombres de nodes sont historiques, pas un coût ni un état du réseau au 13 octobre 2026.
Les auteurs indiquent notification responsable à partir du 2 décembre 2025, relances en janvier et mars 2026 et contact alternatif; une réponse développeur mentionnée en avril n’avait pas encore abouti à une réponse technique substantielle lors de rédaction. Les notes de release Android 1.33.6 et iOS 2.15.5 du 11 octobre que nous avons consultées ne citent pas explicitement les findings. Cela ne prouve pas qu’aucun correctif discret n’existe : correctif actuel et retest restent UNKNOWN tant que commits/advisory et tests ne sont pas rapprochés.
Session — matrice des métadonnées (ce que chaque partie peut obtenir)¶
Les termes « CONFIRMÉ » et « PROBABLE » décrivent capacité/visibilité documentée ou nécessaire au protocole, pas remise à une autorité. « NON ACCESSIBLE PAR DESIGN » exprime la propriété visée, non une mesure adversariale; aucun retour judiciaire réel n’est inféré de la table.
| Métadonnée | Fournisseur / relais | Contact | ISP | Apple / Google | Autorités |
|---|---|---|---|---|---|
| IP | CONFIRMÉ au seed pendant bootstrap selon policy; NON ACCESSIBLE PAR DESIGN au destinataire de message pour onion path, mais push/appels/fichiers à distinguer. | NON ACCESSIBLE PAR DESIGN via texto; CONFIRMÉ potentiellement pair d’appel WebRTC. | CONFIRMÉ IP source, destination de sortie, temps/volumes et activité vers Tor-like network. | CONFIRMÉ/PROBABLE au service push lors session/token; détails lien vers Account ID non indépendamment établis. | POSSIBLE par seed si logs, ISP, push, opérateur node ou terminal; aucun cas de remise documenté ici. |
| Téléphone | NON ACCESSIBLE PAR DESIGN comme champ de compte requis; peut être volontairement partagé. | POSSIBLE si partagé dans profil/chat/hors app. | NON ACCESSIBLE PAR DESIGN via flux app seul; opérateur mobile connaît l’abonné selon pays/contrat. | POSSIBLE via compte Apple/Google, pas association Session démontrée. | POSSIBLE via opérateur/store/appareil si données légales disponibles. |
| NON ACCESSIBLE PAR DESIGN à l’inscription; POSSIBLE si support/web ou partage. | POSSIBLE si révélé; pas requis. | NON ACCESSIBLE PAR DESIGN à partir du seul flux chiffré, mais autres activités/réutilisation OSINT. | POSSIBLE compte de store; mapping au compte Session inconnu. | POSSIBLE auprès tiers ou device; production réelle inconnue. | |
| Identifiant | CONFIRMÉ Account ID au swarm/serveurs nécessaires à l’adressage; seed reçoit IDs réseau selon flux. | CONFIRMÉ ID/fingerprint du correspondant avec qui il échange; signature/key trust problème WOOT si non vérifié. | NON ACCESSIBLE PAR DESIGN au contenu Account ID de chaque message par simple IP observation; timing peut corréler. | POSSIBLE identifiant store/token/app, lien utilisateur↔Account ID non établi. | POSSIBLE par nœud/serveur/terminal ou demandes tierces, mais aucune production réelle établie. |
| Graphe social | PROBABLE corrélation de IDs/réception au swarm et push backend; limites de ce que chaque node voit dépendent onion layer; pas de mesure collusion. | CONFIRMÉ relation et membres connus localement; groupe révèle autres membres selon interface. | POSSIBLE par timing/volume et destination réseau; relation logique pas directement visible sans corrélation. | POSSIBLE tokens/timing; graphe Session non démontré. | POSSIBLE par logs, saisies, membres/contacts; aucun cas de retour identifié. |
| Timestamps | CONFIRMÉ requêtes de relais et push portent nécessairement timing; message timestamp est vulnérable à manipulation selon WOOT. | CONFIRMÉ timestamp présenté/local et activité; authenticité de chronologie peut être compromise selon finding. | CONFIRMÉ heures de connexions et volumes. | PROBABLE heure de push/session. | POSSIBLE si logs tiers/relay/device disponibles. |
| Volumes | CONFIRMÉ/PROBABLE taille/cadence réseau visible au point d’entrée/hop; champs exacts de chaque nœud inconnus. | CONFIRMÉ contenu, taille, nombre de messages et fichiers reçus. | CONFIRMÉ octets/durée par session. | PROBABLE payload/timing push, volume global. | POSSIBLE par ISP/service/appareil; retention/production inconnue. |
| Groupes | PROBABLE pattern de groupe/IDs via swarm/notifications; communauté n’est pas E2EE et son serveur peut voir contenu. | CONFIRMÉ membres et contenu auxquels le compte a accès. | POSSIBLE par tailles/timing, pas liste directe prouvée. | INCONNU lien des notifications au membership exact. | POSSIBLE via terminal, membres, logs ou serveur de communauté; cas effectif inconnu. |
| Appareils | PROBABLE push registrations et Account ID/token; V1 ne publie pas d’inventaire/approbation complète de devices. | POSSIBLE à inférer du comportement; aucun inventaire complet visible établi. | CONFIRMÉ connexions IP distinctes du terminal via réseau. | CONFIRMÉ token/appareil push; mapping identité app dépend payload/service. | POSSIBLE via Apple/Google, opérateur et device saisi; remise Session documentée inconnue. |
| Push tokens | CONFIRMÉ STF backend reçoit Account ID/token selon architecture annoncée; éditeur dit lien non révélateur de messages/heures. | NON ACCESSIBLE PAR DESIGN au correspondant. | NON ACCESSIBLE PAR DESIGN token, mais destination APNs/FCM et timing visibles. | CONFIRMÉ token fourni à APNs/FCM; logs, durée et association compte non établis indépendamment. | POSSIBLE via store/push/STF si conservé; aucun retour avéré dans un dossier public retrouvé. |
Session — première colonne TM1–TM15¶
Ces cellules sont des évaluations provisoires et non des scores de classement. La colonne complète des autres finalistes reste à construire avant la Phase 3.
| Modèle | Cellule | Justification courte et source |
|---|---|---|
| TM1 — fournisseur curieux | 🟡 | Message body chiffré et pas de numéro/e-mail requis, mais bootstrap/push/metadata/services périphériques existent; scope de l’éditeur à distinguer des opérateurs. Policy |
| TM2 — fournisseur compromis | 🟡 | Onion protège contre une lecture simple de contenu, mais node actif peut manipuler authenticité/timestamp/livraison selon attaques WOOT; compromission push/seed ajoute corrélation. WOOT |
| TM3 — fournisseur malveillant | 🟠 | La substitution de clé par nœud malveillant est le finding central de l’étude V1; vérification fingerprint OOB atténue si faite correctement mais n’est pas imposée. WOOT |
| TM4 — ISP / Wi‑Fi / réseau local | 🟡 | Onion requests masquent normalement nœud destinataire, mais ISP voit IP vers réseau, heure/volume; activités seed, push et appels ont chemins propres. Routage |
| TM5 — observation passive multi-points | 🟠 | Évite un serveur unique pour chemin des messages, mais pas de preuve anti-corrélation trafic; timing/volumes et seed/push points permettent hypothèses. Aucune mesure multi-point faite. |
| TM6 — adversaire global passif | 🔴 | Pas de preuve indépendante de résistance globale; V1 faible latence avec timings, sans mixnet/cover traffic établi ici, facilite corrélation en principe. INFERENCE, pas démonstration empirique. |
| TM7 — correspondant malveillant | 🟠 | Correspondant voit messages et identifiant stable; appel P2P peut révéler IP; fichier/metadata partagé persiste; usurpation/chronologie sous node actif. FAQ, WOOT |
| TM8 — harceleur/doxxer OSINT | 🟡 | Pas de téléphone/e-mail obligatoire, mais Account ID persistant, QR/invitations, avatar et réutilisation de pseudonyme créent linkability. FAQ |
| TM9 — demande judiciaire classique | 🟡 | STF rapporte 17 inquiries/demandes en 2025 et 0 données divulguées; seed/ISP/push/stores/nœuds et terminaux peuvent être visés séparément. Rapport |
| TM10 — enquête sophistiquée | 🟠 | Corrélation ISP/push/seed, demandes à stores, saisie d’appareil ou interlocuteur contourne protection du corps en transit; aucune extraction actuelle par tool versionnée testée. |
| TM11 — appareil verrouillé | ❓ | Le parser ALEAPP 2026 documente des artefacts Android 14/15 (Session versionCodes 372/376/417/419) mais dit ne pas avoir déchiffré les DB avec le Keystore matériel testé; l’étude Frida 2025 ne donne pas état de verrouillage ni patch OS. Aucun tuple actuel Cellebrite/GrayKey/Magnet + appareil/OS/build + état verrouillé établi. ALEAPP, KCI |
| TM12 — appareil déverrouillé | 🔴 | Messages, compte et clés doivent être rendus accessibles par client actif; E2EE réseau ne protège plus l’écran/mémoire/exports. No current extraction test; conclusion de menace d’endpoint. |
| TM13 — spyware ciblé | 🔴 | Maliciel avec accès aux processus/écran/notifications peut capturer avant chiffrement/après déchiffrement; cryptographie transport ne protège pas terminal compromis. |
| TM14 — supply-chain compromise | 🟠 | Repos publics et releases signées, mais reproductibilité store binaries non démontrée, SDKs push et pipeline restent tiers; signatures seules n’assurent pas le contenu source/binaire. |
| TM15 — censure étatique | 🟠 | Distribution de nœuds rend certaines pannes moins fatales, mais seed, endpoints push/fichiers/app stores/domaines et internet peuvent être bloqués; aucune mesure censorship/OONI. |
Session — contradictions et tests expérimentaux requis¶
- « Anonyme » et non lié à l’IP : l’inscription sans numéro/e-mail et onion requests sont des propriétés de conception; elles ne prouvent pas l’anonymat global. Policy dit que le seed voit l’IP sans la conserver, alors que push rapide et appels ont observateurs identifiés. Vérifier par captures passives de chaque parcours.
- Chiffrement vs intégrité/authenticité : les primitives E2EE ne sont pas le finding WOOT; l’étude expose falsification de clé/ordre/rejeu via une faiblesse de protocole V1. Les notes de releases publiées 11 oct. ne suffisent ni à confirmer ni à exclure une correction.
- V1 vs V2 : roadmap officielle parle PFS/PQ, mais les mises à jour disent que l’E2EE Protocol V2 est encore distinct du Router 1.1.0. L’update 6 oct. évoque PFS/PQ du router comme couche de transport des nouvelles sessions; cela n’est pas une preuve de PFS/PQ du contenu E2EE Session V2.
- Communautés vs groupes : communautés auto-hébergées ne sont pas E2EE; ne pas les compter comme une variante de groupe privé protégée.
- Labels mobiles vs flux réseau : « No data collected » est auto-déclaré. Il coexiste avec l’IP reçue par seed, Apple/Google push et permissions appareil nécessaires (caméra/micro/fichiers). Pas de contradiction logique si labels excluent certaines données de transit, mais leur portée est facilement surinterprétée.
- Audit historique vs état actuel : fixes Quarkslab sont principalement annoncés par l’éditeur; aucune revalidation indépendante connue. L’audit ne portait ni sur le protocole V1 actuel, ni sur les services 2026.
- Forensics / Android Keystore : le résumé de projet 2023 rapporte un déchiffrement DB/fichiers via Keystore; l’abstract JKIISC 2025 décrit extraction dynamique Frida sur « real devices » sans préciser OS, version ou état de verrouillage; le parser ALEAPP 2026 expose des artefacts de préférences sur Android 14/15 mais dit que le déchiffrement DB a échoué sur les clés Keystore matérielles de ses images. Ces résultats ne s’annulent pas : virtualisation, instrumentation, élévation de privilèges, versions et état du téléphone diffèrent ou sont inconnus. Aucun ne prouve un déverrouillage commercial d’un téléphone stock verrouillé. KISIA, JKIISC, ALEAPP.
- Expériences nécessaires : (1) rapprocher finding WOOT → issue/advisory → commit → Android/iOS/Desktop release et effectuer retest indépendant; (2) reproduire build signé vs store; (3) pcap onboarding, messaging, FCM/APNs slow/fast, fichier et appel avec/ sans VPN; (4) observer les candidats ICE et logs TURN; (5) inspecter iOS entitlements/SDK, Android AAB final, push payload; (6) acquisition forensic comparative sur Android 14/15 et versionCodes 372/376/417/419, puis versions stores actuelles, avec modèle/patch/root/verrouillage/état Keystore explicités; comparer XML de préférences,
signal_v4.db,session.db, WAL,app_partset logs, sans assimiler l’extraction de fichiers au déverrouillage; (7) corrélation trafic multi-nœuds sous mesure contrôlée; (8) inventorier DNS/ASN/hosting des endpoints à une date donnée; (9) confirmer transparence/judicial production par dockets et obtenir rapports expurgés si publics. Aucun de ces tests n’est revendiqué comme effectué ici.