Exportación verificada

Qué es una exportación verificada

Una exportación verificada (también llamada exportación certificada) reúne una conversación, o un archivo completo, en un único .zip, para cuando alguien que no eres tú tiene que poder fiarse de un registro. Frente a una captura de pantalla, la diferencia es que hace detectable cualquier cambio y se puede comprobar de forma independiente. Quien la recibe puede confirmar con herramientas estándar que el paquete no se alteró y que existía, sin cambios, en un momento concreto. No tienes que fiarte de Text2Store para nada de esto.

Está incluida en la compra de Text2Store. Para crear una, abre una conversación, elige Exportar y luego Exportación verificada (.zip)….

Exportar desde una copia de seguridad certificada lo refuerza aún más: la prueba de la exportación llega hasta el momento en que se hizo la copia, no solo hasta la exportación. Consulta la página de copias certificadas para esa parte.

Qué hay dentro del paquete

El .zip se descomprime en un pequeño conjunto de archivos que se explican solos:

• transcript.pdf son los mensajes como transcripción legible e imprimible.
• conversation.json son los mismos mensajes como datos, incluido todo lo que el PDF no puede representar.
• attachments/ guarda cada foto, video y archivo de la conversación, con sus bytes originales.
• certificate.pdf es una portada legible: el dispositivo, la conversación, el rango de fechas, los recuentos y cómo verificarla.
• manifest.json es el núcleo: una huella SHA-256 de cada uno de los demás archivos.
• VERIFY.txt enumera comandos en inglés sencillo para comprobarlo todo tú mismo.
• DECLARATION.txt es una declaración para rellenar que una persona puede firmar (ver más abajo).
• manifest.json.tsr es el sello de tiempo de confianza, añadido si tenías conexión.
• tsa/cacert.pem es el certificado de la autoridad de sellado, para que la hora se verifique solo con el paquete.
• source/backup-timestamp.tsr solo aparece si la exportación se hizo desde una copia de seguridad certificada: el sello de creación de la propia copia, trasladado para que la prueba de la exportación llegue hasta el momento de la copia.

Qué demuestra

• Integridad. Cada archivo aparece con su huella SHA-256 en manifest.json. Volver a calcular la huella de cualquier archivo confirma que es idéntico, byte a byte, a cuando lo exportaste. Cambia un píxel de una foto y la verificación falla.
• Procedencia de tu copia de seguridad. Cada archivo adjunto registra también la huella que tenía en la copia del dispositivo de la que procede, lo que vincula el archivo exportado a esa copia concreta y no a algo escrito a mano. La exportación se niega a crearse si algún adjunto ya no coincide.
• Tiempo. Si tienes conexión, una autoridad de sellado de tiempo independiente sella todo el paquete con el estándar RFC 3161 (el mismo mecanismo que usan los sellos de tiempo de la firma de código). Eso demuestra que el paquete existía, sin cambios, en un momento concreto, lo que responde a «editaste esto la semana pasada».

Por qué no se puede colar un cambio

«Hace detectable cualquier cambio» es una afirmación precisa, así que esta es la razón de que se cumpla. No significa que el archivo no se pueda editar. Cualquier archivo se puede editar. Significa que cualquier edición se detecta. Quien quiera colar un cambio ante el verificador choca con tres muros seguidos:

• Una huella no se puede falsificar. La huella SHA-256 de cada archivo es un valor de 64 caracteres calculado a partir de sus bytes exactos. Cambia un solo byte, en cualquier sitio, y la huella cambia por completo. No se conoce ninguna forma de alterar un archivo y conservar su SHA-256, así que un archivo cambiado ya no puede coincidir con su huella registrada. Ese es el primer muro.
• La lista también tiene huella. El siguiente paso obvio sería editar la huella dentro de manifest.json para que coincida con el archivo cambiado. Eso también falla: el manifiesto lleva una huella raíz de contenido sobre su propia lista, y el sello de tiempo se toma sobre el manifiesto completo. Editar la lista rompe las dos cosas. Segundo muro.
• El sello de tiempo necesita una clave que nadie tiene. El último paso sería reconstruir el manifiesto y obtener un sello de tiempo nuevo para la versión reescrita. Para eso haría falta la clave privada de firma de la autoridad de sellado, que guarda un tercero independiente (DigiCert). Ni tú, ni Text2Store, ni un atacante puede generar un sello válido sin ella. Por eso una verificación de Text2Store solo indica Verificada cuando hay un sello de tiempo válido: el sello es el ancla que hace imposible reescribir y volver a sellar todo lo que hay debajo. Un paquete sin sello de tiempo se indica como Sin verificar, no como verificado, precisamente porque falta esa ancla. Tercer muro.
• No tienes que fiarte de nosotros. Todas estas comprobaciones usan estándares abiertos (SHA-256, RFC 3161) y se pueden reproducir con herramientas estándar incluidas en Mac y Windows. La seguridad no depende de fiarse de la palabra de Text2Store, ni siquiera de la app de Text2Store.

El límite honesto merece decirse claramente: hace los cambios detectables, no imposibles. Cualquiera puede seguir cambiando o borrando el archivo. Lo que nadie puede hacer es cambiarlo y que siga pasando la verificación. Si un paquete pasa la verificación, es el que se exportó. Si alguien lo tocó, la verificación lo dice.

Qué no demuestra (léelo, por favor)

Ser honesto con los límites es parte de lo que hace fiable todo lo demás. Una exportación verificada no demuestra:

• Que los mensajes sean verdad, ni que el teléfono no se manipulara antes de hacer la copia. Demuestra que el paquete no ha cambiado desde la exportación, no lo que pasó antes.
• Cómo se va a recibir. Text2Store nunca afirma que una exportación verificada vaya a ser aceptada por un destinatario o proceso concreto, y nunca la presenta como «admisible en un juicio» ni «autenticada». El peso de un registro siempre lo decide quien lo recibe; el software solo puede hacer que el registro sea comprobable.
• Que esté completa. Una exportación verificada solo puede contener lo que el teléfono todavía tenía al archivarlo. Los mensajes eliminados antes de capturarlos simplemente no están. La transcripción sí marca los mensajes eliminados en el dispositivo, editados o anulados, cuando ese dato sobrevivió hasta la captura.
• Cuándo se envió exactamente cada mensaje, en sentido absoluto. El sello de tiempo acredita cuándo existía la exportación, no cuándo se enviaron los mensajes. Las horas de los mensajes vienen del dispositivo.

Protegerla con contraseña (opcional)

Una exportación verificada es un .zip normal: quien tenga el archivo puede leer los mensajes. Normalmente es lo que quieres, porque se abre en cualquier sitio sin software. Pero si el archivo tiene que viajar, puedes bloquearlo. Marca Proteger este .zip con una contraseña al crear la exportación y el contenido se cifra con AES-256. Está desactivado por defecto y se elige en cada exportación.

El cifrado y la detección de cambios son cosas distintas. La contraseña impide que otros lean los mensajes. Las huellas y el sello de tiempo son lo que demuestra que nada cambió, y funcionan exactamente igual en ambos casos. Una contraseña no hace una exportación más verificable, y no ponerla no la hace menos.

Todo lo de dentro va cifrado, VERIFY.txt incluido, así que una exportación protegida no revela nada sin la contraseña. Hay algo que no puede ocultar: un zip nunca cifra su lista de nombres de archivo, así que cualquiera puede ver que el paquete contiene una transcripción, un manifiesto y algunos adjuntos. Los nombres son genéricos, así que no dicen nada de con quién hablabas ni de lo que se dijo.

Para verificar una exportación protegida en Text2Store, elígela como siempre; la app ve que está bloqueada y pide la contraseña. Para verificarla a mano, extráela primero con una de las herramientas anteriores y sigue los pasos normales de abajo.

Cómo verificarla sin fiarte de nosotros

Hay dos formas, y las dos comprueban las mismas huellas y el mismo sello de tiempo.

En la app: elige Archivo, luego Verificar una exportación…, y selecciona el .zip. Text2Store vuelve a comprobar cada huella y el sello de tiempo e indica Verificada, Alterada o Sin verificar. «Verificada» significa que los archivos coinciden y el sello de tiempo demuestra que el paquete no ha cambiado. «Alterada» significa que algo ya no coincide. «Sin verificar» significa que los archivos son coherentes entre sí, pero el paquete no lleva sello de tiempo, así que no se puede demostrar por sí solo que no se alteró (compara su huella de manifiesto con una copia de confianza). No necesita internet ni instalar nada, y funciona igual en Mac y Windows. Para ser independiente, usa su propia copia fijada del certificado de la autoridad de sellado, no la que viene en el paquete.

A mano: el VERIFY.txt incluido enumera los comandos exactos. En macOS y Linux usa shasum; en Windows, Get-FileHash en PowerShell. Para confirmar también la hora, usa openssl. Una advertencia honesta del propio VERIFY.txt: el LibreSSL que trae macOS no puede verificar la cadena de certificados de este sello, así que instala OpenSSL completo (Homebrew) o usa el verificador de la app; en Windows funciona el OpenSSL que viene con Git for Windows. VERIFY.txt también muestra el SHA-256 del certificado de la autoridad de sellado, para que lo compares con la raíz publicada por DigiCert en cacerts.digicert.com antes de fiarte de la hora acreditada.

Los detalles técnicos

Para quien quiera comprobar el mecanismo en lugar de fiarse del resumen: todo lo que sigue usa estándares publicados (SHA-256, RFC 3161, CMS) y se puede reproducir con herramientas estándar. Nada es propietario ni secreto. Esa apertura es la clave: una afirmación que puedes confirmar por tu cuenta vale más que una que tienes que creerte.

Las huellas y el manifiesto

Cada archivo del paquete se resume con SHA-256 sobre sus bytes exactos. manifest.json enumera cada archivo con su ruta y su 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..."
}

El content_root_sha256 es una única huella de toda la lista, así que la propia lista también hace detectable cualquier cambio. Se obtiene tomando una línea path:sha256 por elemento, ordenando esas líneas, uniéndolas con saltos de línea y resumiendo el resultado con SHA-256. Cualquiera puede recalcularla a partir del manifiesto y confirmar que coincide.

Vincular los adjuntos a la copia del dispositivo

Cada adjunto registra también source_backup_sha256, la huella que tenía ese archivo en la copia de seguridad del iPhone o iPad de la que procede. La exportación se crea frente a la referencia de sumas de comprobación de esa copia y se niega a crearse si algún adjunto ya no coincide, así que una foto exportada queda vinculada a esa copia concreta del dispositivo y no a algo añadido a mano.

Qué queda fuera de la lista de huellas

Solo dos archivos no figuran en la lista, por una razón estructural: manifest.json no puede contener su propia huella, y manifest.json.tsr (el sello de tiempo) se crea a partir de la huella del manifiesto, así que existe después de sellarlo. Todo lo demás, incluidos los archivos legibles certificate.pdf, VERIFY.txt, DECLARATION.txt y el tsa/cacert.pem de la autoridad, se resume en el manifiesto como cualquier otro archivo. Un verificador recalcula el SHA-256 del propio manifiesto y lo trata como la huella del paquete.

El sello de tiempo de confianza

manifest.json.tsr es un token de sello de tiempo RFC 3161, una estructura CMS SignedData cuyo messageImprint es el SHA-256 de manifest.json. Para aceptarlo, un verificador confirma que la firma del token es válida, que el certificado del firmante enlaza con la raíz de DigiCert (el token incluye toda su cadena de firma, del certificado final a la raíz pasando por el intermedio), que estaba dentro de su periodo de validez en el momento acreditado, que lleva el uso extendido de clave crítico id-kp-timeStamping (como exige RFC 3161) y que la huella es igual al SHA-256 de este manifiesto. El verificador de Text2Store hace todo esto en código puro sin acceso a la red, y fija su propia copia de la raíz de DigiCert en lugar de fiarse del cacert.pem del paquete, así que un certificado sustituido no puede engañarlo. VERIFY.txt muestra el SHA-256 de ese certificado para que lo compares con la raíz publicada por DigiCert en cacerts.digicert.com.

Comprobarlo tú mismo, con exactitud

Resume cualquier archivo y compáralo con su sha256 del manifiesto:

# macOS / Linux
shasum -a 256 transcript.pdf

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

Comprueba que el sello de tiempo cubre exactamente este manifiesto y enlaza con la autoridad:

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

El VERIFY.txt del paquete detalla estos comandos, incluido cómo recalcular la huella raíz, para que solo tengas que copiar y pegar.

Qué cuenta como aprobado

Un verificador solo debe indicar Verificada si se cumple todo lo siguiente: cada archivo de la lista está presente y coincide con su huella, la huella raíz se recalcula, no hay archivos de más ni duplicados, y un sello de tiempo es válido sobre manifest.json. Un paquete sin sello de tiempo está Sin verificar: coherente, pero sin un ancla independiente, porque el manifiesto no puede demostrar su propia integridad sin esa firma externa. Cualquier discrepancia, archivo de más o sello que no se verifique da Alterada.

La declaración firmada

Algunos procesos piden una declaración humana junto a un registro: una persona que explique por escrito cómo se hizo. El software no puede hacer esa declaración; solo una persona puede. Por eso el paquete incluye DECLARATION.txt: una plantilla sencilla para rellenar, que una persona (tú, o un responsable de registros) puede adaptar y completar con la huella del manifiesto que calculó.

Es una plantilla, nada más. No es asesoramiento jurídico, y si estás preparando algo para un procedimiento formal, haz que lo revise un abogado antes.

Horas y zonas horarias

En los PDF legibles, las horas de los mensajes se muestran en la hora local del equipo que exporta, con un desfase UTC explícito (por ejemplo, 2026-06-30 21:14 -08:00), con la zona horaria indicada arriba, para que coincidan con lo que veías en el teléfono y no haya ambigüedad. Los datos legibles por máquina (conversation.json) y el sello de tiempo lo guardan todo en UTC, así que un experto siempre puede reconstruir las horas exactas.

El límite honesto

Una exportación verificada solo es tan completa como la copia que tiene detrás. Text2Store solo puede incluir lo que tu teléfono aún tenía al archivarlo. El mejor hábito es sencillo: haz copias con regularidad, para que una conversación quede bien capturada mucho antes de que la necesites. iOS mantiene recuperable un mensaje eliminado durante unas semanas, así que una copia reciente a menudo recoge más de lo que esperas. Consulta las preguntas frecuentes para más información.

Relacionado

RSMF para revisión de eDiscovery, exportar a PDF y los chats de WhatsApp en tu copia.

¿Preguntas?

Escribe a hello@text2store.com y te ayudamos.