Export vérifié

Ce qu’est un export vérifié

Un export vérifié (aussi appelé export certifié) regroupe une conversation, ou toute une archive, dans un seul .zip, pour les cas où quelqu’un d’autre que vous doit pouvoir s’y fier. Ce qui le distingue d’une capture d’écran : il rend toute modification détectable et se vérifie de façon indépendante. Celui qui le reçoit peut confirmer avec des outils standard que le paquet n’a pas été modifié et qu’il existait, inchangé, à un moment précis. Vous n’avez à faire confiance à Text2Store pour rien de tout cela.

Il est inclus dans l’achat de Text2Store. Pour en créer un, ouvrez une conversation, choisissez Exporter, puis Export vérifié (.zip)….

Exporter depuis une sauvegarde certifiée renforce encore cela : la preuve de l’export remonte jusqu’au moment de la sauvegarde, et pas seulement de l’export. Voir la page des sauvegardes certifiées pour cette partie.

Ce que contient le paquet

Le .zip se décompresse en un petit ensemble de fichiers qui s’expliquent d’eux-mêmes :

• transcript.pdf contient les messages sous forme de transcription lisible et imprimable.
• conversation.json contient les mêmes messages sous forme de données, y compris tout ce que le PDF ne peut pas représenter.
• attachments/ contient chaque photo, vidéo et fichier de la conversation, dans ses octets d’origine.
• certificate.pdf est une page de garde lisible : l’appareil, la conversation, la période, les totaux et la marche à suivre pour vérifier.
• manifest.json en est le cœur : une empreinte SHA-256 de chacun des autres fichiers.
• VERIFY.txt liste des commandes en anglais simple pour tout vérifier vous-même.
• DECLARATION.txt est une déclaration à compléter qu’une personne peut signer (voir plus bas).
• manifest.json.tsr est l’horodatage de confiance, ajouté si vous étiez en ligne.
• tsa/cacert.pem est le certificat de l’autorité d’horodatage, pour que la date se vérifie à partir du seul paquet.
• source/backup-timestamp.tsr n’apparaît que si l’export a été fait depuis une sauvegarde certifiée : l’horodatage de création de la sauvegarde, repris pour que la preuve de l’export remonte jusqu’à la sauvegarde.

Ce qu’il prouve

• L’intégrité. Chaque fichier figure avec son empreinte SHA-256 dans manifest.json. Recalculer l’empreinte d’un fichier confirme qu’il est identique, octet par octet, à ce qu’il était lors de l’export. Changez un pixel d’une photo et la vérification échoue.
• La provenance depuis votre sauvegarde. Chaque pièce jointe enregistre aussi l’empreinte qu’elle avait dans la sauvegarde de l’appareil dont elle provient, ce qui relie le fichier exporté à cette sauvegarde précise plutôt qu’à quelque chose saisi à la main. L’export refuse de se construire si une pièce jointe ne correspond plus.
• La date. Si vous êtes en ligne, le paquet entier est horodaté par une autorité d’horodatage indépendante selon la norme RFC 3161 (le même mécanisme que pour les horodatages de signature de code). Cela prouve que le paquet existait, inchangé, à un moment précis, ce qui répond à « vous avez modifié ceci la semaine dernière ».

Pourquoi une modification ne peut pas passer inaperçue

« Rend toute modification détectable » est une affirmation précise, alors voici pourquoi elle tient. Cela ne veut pas dire que le fichier ne peut pas être modifié. Tout fichier peut l’être. Cela veut dire que toute modification est repérée. Celui qui voudrait faire passer une modification devant le vérificateur se heurte à trois murs successifs :

• Une empreinte ne se falsifie pas. L’empreinte SHA-256 de chaque fichier est une valeur de 64 caractères calculée à partir de ses octets exacts. Changez un seul octet, n’importe où, et l’empreinte change complètement. On ne connaît aucun moyen de modifier un fichier en gardant son SHA-256 : un fichier modifié ne peut donc plus correspondre à son empreinte enregistrée. C’est le premier mur.
• La liste a aussi son empreinte. L’étape suivante évidente serait de modifier l’empreinte dans manifest.json pour qu’elle corresponde au fichier changé. Cela échoue aussi : le manifeste porte une empreinte racine du contenu sur sa propre liste, et l’horodatage de confiance porte sur le manifeste entier. Modifier la liste casse les deux. Deuxième mur.
• L’horodatage exige une clé que personne n’a. La dernière étape serait de reconstruire le manifeste et d’obtenir un nouvel horodatage de confiance pour la version réécrite. Il faudrait pour cela la clé privée de signature de l’autorité d’horodatage, détenue par un tiers indépendant (DigiCert). Ni vous, ni Text2Store, ni un attaquant ne peut produire un horodatage valide sans elle. C’est précisément pourquoi une vérification Text2Store n’indique Vérifié qu’en présence d’un horodatage de confiance valide : c’est l’ancre qui rend impossible de réécrire et de resceller tout ce qui se trouve dessous. Un paquet sans horodatage de confiance est indiqué Non vérifié, et non vérifié, justement parce que cette ancre manque. Troisième mur.
• Vous n’avez pas à nous faire confiance. Chacun de ces contrôles repose sur des normes ouvertes (SHA-256, RFC 3161) et peut être reproduit avec des outils standard fournis avec Mac et Windows. La sécurité ne repose pas sur la parole de Text2Store, ni même sur l’app Text2Store.

La limite honnête mérite d’être dite clairement : les modifications sont rendues détectables, pas impossibles. Chacun peut toujours modifier ou supprimer le fichier. Ce que personne ne peut faire, c’est le modifier et qu’il passe encore la vérification. Si un paquet passe la vérification, c’est bien celui qui a été exporté. S’il a été touché, la vérification le dit.

Ce qu’il ne prouve pas (à lire)

Être honnête sur les limites fait partie de ce qui rend le reste digne de confiance. Un export vérifié ne prouve pas :

• Que les messages sont vrais, ni que le téléphone n’a pas été manipulé avant la sauvegarde. Il prouve que le paquet n’a pas changé depuis l’export, pas ce qui s’est passé avant.
• La façon dont il sera reçu. Text2Store n’affirme jamais qu’un export vérifié sera accepté par un destinataire ou une procédure donnés, et ne le présente jamais comme « recevable devant un tribunal » ou « authentifié ». Le poids d’un document est toujours la décision du destinataire ; un logiciel ne peut que rendre un document vérifiable.
• L’exhaustivité. Un export vérifié ne peut contenir que ce que le téléphone avait encore au moment de l’archivage. Les messages supprimés avant la capture sont tout simplement absents. La transcription signale les messages supprimés sur l’appareil, modifiés ou annulés, quand cette information a survécu jusqu’à la capture.
• Le moment exact où chaque message a été envoyé, au sens absolu. L’horodatage de confiance atteste quand l’export existait, pas quand les messages ont été envoyés. Les heures des messages viennent de l’appareil.

Le protéger par un mot de passe (facultatif)

Un export vérifié est un .zip ordinaire : quiconque a le fichier peut lire les messages. C’est généralement ce qu’on veut, car il s’ouvre partout sans logiciel. Mais si le fichier doit circuler, vous pouvez le verrouiller. Cochez Protéger ce .zip par un mot de passe lors de la création de l’export, et le contenu est chiffré en AES-256. C’est désactivé par défaut et se choisit export par export.

Chiffrement et détection des modifications sont deux choses distinctes. Le mot de passe empêche de lire les messages. Les empreintes et l’horodatage prouvent que rien n’a été modifié, et ils fonctionnent exactement de la même façon dans les deux cas. Un mot de passe ne rend pas un export plus vérifiable, et s’en passer ne le rend pas moins vérifiable.

Tout ce qu’il contient est chiffré, VERIFY.txt compris : un export protégé ne livre rien sans le mot de passe. Une chose qu’il ne peut pas cacher : un zip ne chiffre jamais sa liste de noms de fichiers, donc chacun peut voir que le paquet contient une transcription, un manifeste et des pièces jointes. Les noms sont génériques : ils ne disent rien de la personne avec qui vous parliez ni de ce qui a été dit.

Pour vérifier un export protégé dans Text2Store, choisissez-le comme d’habitude ; l’app voit qu’il est verrouillé et demande le mot de passe. Pour vérifier à la main, extrayez-le d’abord avec l’un des outils ci-dessus, puis suivez les étapes habituelles plus bas.

Comment le vérifier, sans nous faire confiance

Il y a deux façons, et elles contrôlent les mêmes empreintes et le même horodatage.

Dans l’app : choisissez Fichier, puis Vérifier un export…, et sélectionnez le .zip. Text2Store recontrôle chaque empreinte et l’horodatage et indique Vérifié, Altéré ou Non vérifié. « Vérifié » signifie que les fichiers correspondent et que l’horodatage de confiance prouve que le paquet est inchangé. « Altéré » signifie que quelque chose ne correspond plus. « Non vérifié » signifie que les fichiers sont cohérents entre eux mais que le paquet ne porte aucun horodatage de confiance, de sorte qu’on ne peut pas prouver à lui seul qu’il est inchangé (comparez son empreinte de manifeste avec une copie de confiance). Il ne faut ni Internet ni rien à installer, et cela fonctionne de la même façon sur Mac et Windows. Pour rester indépendante, l’app utilise sa propre copie épinglée du certificat de l’autorité d’horodatage, et non celle du paquet.

À la main : le fichier VERIFY.txt fourni liste les commandes exactes. Sous macOS et Linux, utilisez shasum ; sous Windows, Get-FileHash dans PowerShell. Pour confirmer aussi la date de confiance, utilisez openssl. Une précision honnête tirée de VERIFY.txt lui-même : le LibreSSL fourni avec macOS ne sait pas vérifier la chaîne de certificats de cet horodatage, installez donc OpenSSL complet (Homebrew) ou utilisez le vérificateur intégré ; sous Windows, l’OpenSSL fourni avec Git for Windows fonctionne. VERIFY.txt affiche aussi le SHA-256 du certificat de l’autorité d’horodatage, pour que vous le compariez à la racine publiée par DigiCert sur cacerts.digicert.com avant de vous fier à la date attestée.

Les détails techniques

Pour qui veut vérifier le mécanisme plutôt que se fier au résumé : tout ce qui suit repose sur des normes publiées (SHA-256, RFC 3161, CMS) et peut être reproduit avec des outils standard. Rien n’est propriétaire ni secret. Cette ouverture est le but : une affirmation que l’on peut confirmer soi-même vaut plus qu’une affirmation qu’il faut croire.

Les empreintes et le manifeste

Chaque fichier du paquet est haché en SHA-256 sur ses octets exacts. manifest.json liste chaque fichier avec son chemin et son SHA-256 :

{
  "format": "text2store/verified-export",
  "artifacts": [
    { "path": "transcript.pdf", "sha256": "9f2c..." },
    { "path": "conversation.json", "sha256": "4a1e..." },
    { "path": "attachments/0001.jpg", "sha256": "b7d0...",
      "source_backup_sha256": "b7d0..." }
  ],
  "content_root_sha256": "e3b1..."
}

Le content_root_sha256 est une empreinte unique de toute la liste, si bien que la liste elle-même rend toute modification détectable. On l’obtient en prenant une ligne path:sha256 par élément, en triant ces lignes, en les joignant par des retours à la ligne et en hachant le résultat en SHA-256. Chacun peut la recalculer à partir du manifeste et confirmer qu’elle correspond.

Relier les pièces jointes à la sauvegarde de l’appareil

Chaque pièce jointe enregistre aussi source_backup_sha256, l’empreinte que ce fichier avait dans la sauvegarde de l’iPhone ou de l’iPad dont il provient. L’export est construit par rapport à la référence d’empreintes de cette sauvegarde et refuse de se construire si une pièce jointe ne correspond plus : une photo exportée est ainsi liée à cette sauvegarde précise plutôt qu’à un fichier ajouté à la main.

Ce qui se trouve hors de la liste des empreintes

Seuls deux fichiers ne figurent pas dans la liste, pour une raison structurelle : manifest.json ne peut pas contenir sa propre empreinte, et manifest.json.tsr (l’horodatage) est produit à partir de l’empreinte du manifeste, il n’existe donc qu’une fois le manifeste scellé. Tout le reste, y compris les fichiers lisibles certificate.pdf, VERIFY.txt, DECLARATION.txt et le tsa/cacert.pem de l’autorité, est haché dans le manifeste comme n’importe quel autre fichier. Un vérificateur recalcule le SHA-256 du manifeste lui-même et le traite comme l’empreinte du paquet.

L’horodatage de confiance

manifest.json.tsr est un jeton d’horodatage RFC 3161, une structure CMS SignedData dont le messageImprint est le SHA-256 de manifest.json. Pour l’accepter, un vérificateur confirme que la signature du jeton est valide, que le certificat du signataire remonte à la racine DigiCert (le jeton embarque toute sa chaîne de signature, du certificat final à la racine en passant par l’intermédiaire), qu’il était dans sa période de validité à la date attestée, qu’il porte l’usage étendu de clé critique id-kp-timeStamping (comme l’exige RFC 3161), et que l’empreinte correspond au SHA-256 de ce manifeste. Le vérificateur intégré de Text2Store fait tout cela en pur code, sans accès réseau, et épingle sa propre copie de la racine DigiCert au lieu de se fier au cacert.pem du paquet, si bien qu’un certificat substitué ne peut pas le tromper. VERIFY.txt affiche le SHA-256 de ce certificat pour que vous le compariez à la racine publiée par DigiCert sur cacerts.digicert.com.

Le vérifier vous-même, précisément

Hachez un fichier et comparez au sha256 indiqué dans le manifeste :

# macOS / Linux
shasum -a 256 transcript.pdf

# Windows (PowerShell)
Get-FileHash transcript.pdf -Algorithm SHA256

Vérifiez que l’horodatage de confiance couvre exactement ce manifeste et remonte à l’autorité :

openssl ts -verify -data manifest.json -in manifest.json.tsr -CAfile tsa/cacert.pem

Le fichier VERIFY.txt du paquet détaille ces commandes, y compris le recalcul de l’empreinte racine, pour un simple copier-coller.

Ce qui compte comme réussi

Un vérificateur ne doit indiquer Vérifié que si toutes les conditions suivantes sont réunies : chaque fichier listé est présent et correspond à son empreinte, l’empreinte racine se recalcule, il n’y a aucun fichier en trop ni en double, et un horodatage de confiance est valide sur manifest.json. Un paquet sans horodatage de confiance est Non vérifié, cohérent mais non ancré de façon indépendante, car le manifeste ne peut pas prouver sa propre intégrité sans cette signature extérieure. Toute divergence, tout fichier en trop, ou un horodatage qui ne se vérifie pas donne Altéré.

La déclaration signée

Certaines procédures demandent une attestation humaine à côté d’un document : une personne qui déclare par écrit comment le document a été produit. Un logiciel ne peut pas faire cette déclaration ; seule une personne le peut. Le paquet contient donc DECLARATION.txt : un modèle simple à compléter, qu’une personne (vous, ou un responsable des dossiers) peut adapter et remplir avec l’empreinte du manifeste qu’elle a calculée.

C’est un modèle, rien de plus. Ce n’est pas un conseil juridique, et si vous préparez quelque chose pour une procédure formelle, faites-le d’abord relire par un avocat.

Heures et fuseaux horaires

Dans les PDF lisibles, les heures des messages sont affichées dans l’heure locale de l’ordinateur qui exporte, avec un décalage UTC explicite (par exemple 2026-06-30 21:14 -08:00), le fuseau étant indiqué en haut, pour qu’elles correspondent à ce que vous voyiez sur le téléphone et restent sans ambiguïté. Les données lisibles par machine (conversation.json) et l’horodatage de confiance gardent tout en UTC, pour qu’un expert puisse toujours reconstituer les heures exactes.

La limite honnête

Un export vérifié n’est complet que dans la mesure où la sauvegarde qui le sous-tend l’est. Text2Store ne peut inclure que ce que votre téléphone avait encore lors de l’archivage. La meilleure habitude est simple : sauvegardez régulièrement, pour qu’une conversation soit capturée bien avant que vous en ayez besoin. iOS garde un message supprimé récupérable pendant quelques semaines, si bien qu’une sauvegarde récente en attrape souvent plus qu’on ne le croit. Voir la FAQ pour en savoir plus.

Voir aussi

Le RSMF pour la revue eDiscovery, exporter en PDF et les discussions WhatsApp de votre sauvegarde.

Des questions ?

Écrivez à hello@text2store.com, nous vous aiderons.