Libros blancos técnicos

Este libro blanco describe la arquitectura del sistema de Transferencia Segura de PDF Pro, un mecanismo de transferencia de archivos de conocimiento cero en el que los archivos se cifran en el lado del cliente utilizando AES-256-GCM antes de subirse. El servidor solo almacena texto cifrado opaco y no tiene capacidad para descifrar, inspeccionar o leer el contenido de los archivos en ningún momento. El sistema admite dos modos de clave: una clave aleatoria autogenerada (transportada a través del fragmento de la URL, que nunca se envía al servidor) o una clave derivada de una contraseña mediante PBKDF2. En ambos modos, la clave de cifrado existe únicamente en los navegadores del remitente y el destinatario. Este documento detalla las primitivas criptográficas, el flujo de datos, el modelo de amenazas y las limitaciones honestas del sistema.

El sistema de Transferencia Segura sigue una separación estricta cliente-servidor en la que todas las operaciones criptográficas ocurren exclusivamente en el navegador:

• Cliente (navegador): derivación de claves, cifrado, descifrado, lectura de archivos y reconstrucción de archivos.
• Servidor (Supabase Storage + funciones sin servidor): almacena blobs cifrados, gestiona metadatos (expiración, número de descargas), aplica las políticas de acceso.

El servidor está diseñado intencionalmente para ser una "tubería tonta" para los datos cifrados. No tiene conocimiento de la clave de cifrado, la contraseña ni el contenido de los archivos. Esto se aplica de forma arquitectónica, no solo por política.

Todo el cifrado de archivos usa el algoritmo de cifrado autenticado AES-256-GCM, accedido a través de la Web Crypto API nativa del navegador. Esto proporciona tanto confidencialidad (los datos no se pueden leer) como integridad (los datos no se pueden modificar sin que se detecte).

1.3.1 Parámetros del algoritmo

1.3.2 Implementación del cifrado

// Flujo de cifrado simplificado (Web Crypto API)

const iv = crypto.getRandomValues(new Uint8Array(12));
const salt = crypto.getRandomValues(new Uint8Array(16));

// Derivar la clave desde la contraseña (ver Sección 1.4)
const key = await deriveKey(passphrase, salt);

// Cifrar el archivo
const ciphertext = await crypto.subtle.encrypt(
  { name: "AES-GCM", iv: iv },
  key,
  fileArrayBuffer
);

// Paquete: [salt (16B)] + [iv (12B)] + [ciphertext + tag]
const blob = concatenate(salt, iv, ciphertext);

El blob cifrado final es la concatenación de tres componentes: el salt de 16 bytes (usado para la derivación de clave), el IV de 12 bytes (usado para AES-GCM) y el texto cifrado con la etiqueta de autenticación GCM de 16 bytes adjuntada. Este blob es lo que el servidor recibe y almacena.

La Transferencia Segura admite dos modos de clave mutuamente excluyentes. El modo lo elige el remitente en el momento de crear la transferencia.

1.4.1 Modo A — Clave autogenerada (predeterminado)

En el modo predeterminado no interviene ninguna contraseña. El navegador genera directamente una clave AES de 256 bits criptográficamente aleatoria:

• El navegador genera una clave AES-GCM aleatoria de 256 bits mediante crypto.getRandomValues() y crypto.subtle.generateKey().
• La clave se exporta como bytes en bruto y se coloca en el fragmento de la URL (#).
• Según la especificación HTTP, el fragmento de la URL nunca se envía al servidor — se procesa exclusivamente por el navegador.
• El remitente comparte la URL completa (incluido el fragmento) con el destinatario a través de su canal preferido (p. ej., una app de mensajería, correo electrónico).
• El navegador del destinatario extrae la clave del fragmento de la URL y la utiliza para descifrar el archivo.

1.4.2 Modo B — Transferencia protegida con contraseña

Cuando el remitente opta por establecer una contraseña, la clave se deriva de esa contraseña mediante PBKDF2:

• El usuario proporciona una contraseña.
• La contraseña se usa para derivar una clave AES-256 mediante PBKDF2-SHA256.
• Parámetros: 600.000 iteraciones, salt aleatorio de 16 bytes.
• La clave derivada cifra el archivo.
• El salt se almacena junto con el texto cifrado (antepuesto al blob cifrado).
• La contraseña se comparte fuera de banda (por separado del enlace).
• No es posible recuperar la contraseña — ni el servidor ni PDF Pro pueden recuperar una contraseña olvidada.

1.4.3 Parámetros de PBKDF2 (Modo B)

1.4.4 Implementación de la derivación de claves (Modo B)

async function deriveKey(passphrase, salt) {
  // Importar la contraseña como material de clave en bruto
  const keyMaterial = await crypto.subtle.importKey(
    "raw",
    new TextEncoder().encode(passphrase),
    { name: "PBKDF2" },
    false,
    ["deriveKey"]
  );

  // Derivar la clave AES-256-GCM
  return crypto.subtle.deriveKey(
    {
      name: "PBKDF2",
      salt: salt,
      iterations: 600000,
      hash: "SHA-256"
    },
    keyMaterial,
    { name: "AES-GCM", length: 256 },
    false,
    ["encrypt", "decrypt"]
  );
}

El ciclo de vida completo de una transferencia segura sigue este recorrido:

1.5.1 Envío (subida) — Modo A (clave autogenerada)

1. El remitente selecciona un archivo en el navegador.
2. El navegador genera una clave AES-GCM aleatoria de 256 bits y un IV aleatorio de 12 bytes mediante crypto.getRandomValues().
3. El navegador cifra el archivo usando AES-256-GCM, produciendo texto cifrado + etiqueta de autenticación.
4. El navegador concatena [IV | ciphertext+tag] en un único blob.
5. El navegador sube el blob cifrado al servidor mediante HTTPS.
6. El servidor almacena el blob en Supabase Storage y crea un registro de metadatos (ID de transferencia, expiración, límite de descargas, nombre del archivo, tamaño del archivo).
7. El servidor devuelve una URL de transferencia. El navegador añade la clave exportada al fragmento de la URL (#).
8. El remitente comparte la URL completa (con el fragmento) con el destinatario.

1.5.2 Envío (subida) — Modo B (contraseña)

1. El remitente selecciona un archivo e introduce una contraseña en el navegador.
2. El navegador genera un salt aleatorio de 16 bytes y un IV de 12 bytes mediante crypto.getRandomValues().
3. El navegador deriva una clave AES-256 a partir de la contraseña mediante PBKDF2 (600K iteraciones).
4. El navegador cifra el archivo usando AES-256-GCM, produciendo texto cifrado + etiqueta de autenticación.
5. El navegador concatena [salt | IV | ciphertext+tag] en un único blob.
6. El navegador sube el blob cifrado al servidor mediante HTTPS.
7. El servidor almacena el blob en Supabase Storage y crea un registro de metadatos (ID de transferencia, expiración, límite de descargas, nombre del archivo, tamaño del archivo).
8. El servidor devuelve una URL de transferencia que contiene el ID de la transferencia.
9. El remitente comparte la URL de la transferencia y la contraseña con el destinatario a través de canales separados.

1.5.3 Recepción (descarga) — Modo A

1. El destinatario abre la URL completa de la transferencia (con la clave en el fragmento).
2. El navegador extrae la clave AES del fragmento de la URL (nunca se envía al servidor).
3. El navegador descarga el blob cifrado desde el servidor mediante HTTPS.
4. El navegador extrae el IV (primeros 12 bytes) del blob.
5. El navegador descifra el texto cifrado usando AES-256-GCM con la clave y el IV extraídos.
6. Si el descifrado tiene éxito (la etiqueta GCM es válida), se presenta al usuario el archivo en texto claro.
7. El servidor actualiza el contador de descargas y, si la opción "borrar al leer" está activada, elimina el blob.

1.5.4 Recepción (descarga) — Modo B

1. El destinatario abre la URL de la transferencia e introduce la contraseña en el navegador.
2. El navegador descarga el blob cifrado desde el servidor mediante HTTPS.
3. El navegador extrae el salt (primeros 16 bytes) y el IV (siguientes 12 bytes) del blob.
4. El navegador deriva la clave AES-256 a partir de la contraseña + salt mediante PBKDF2 (600K iteraciones).
5. El navegador descifra el texto cifrado usando AES-256-GCM con la clave derivada y el IV.
6. Si el descifrado tiene éxito (la etiqueta GCM es válida), se presenta al usuario el archivo en texto claro.
7. Si el descifrado falla (contraseña incorrecta = clave incorrecta = etiqueta GCM inválida), se muestra un error.
8. El servidor actualiza el contador de descargas y, si la opción "borrar al leer" está activada, elimina el blob.

Todas las transferencias seguras son efímeras por diseño. No existe opción de almacenamiento permanente.

1.7.1 Opciones de expiración

1.7.2 Garantía de eliminación

Cuando una transferencia expira o se borra al leer, el blob cifrado se elimina permanentemente de Supabase Storage. El registro de metadatos se conserva durante 30 días en estado de borrado lógico (para investigación de abusos) antes de purgarse permanentemente. El registro de metadatos no contiene la clave de cifrado, la contraseña ni ninguna información que pueda usarse para reconstruir el archivo.

1.8.1 Supuestos

• Entorno de ejecución del navegador de confianza (sin extensiones maliciosas)
• Canal seguro para compartir el enlace/contraseña
• La terminación HTTPS es de confianza
• El dispositivo del destinatario no está comprometido
• Sin prevención de captura de pantalla

1.8.2 Fuera del alcance

• Malware en los dispositivos endpoint
• Ingeniería social / ataques de phishing
• Capturas de pantalla por parte de los destinatarios
• Extensiones de navegador comprometidas
• Ataques con computación cuántica (consideración futura)

• La fortaleza de la contraseña depende del usuario. Podemos imponer una longitud mínima en la interfaz, pero no podemos evitar que los usuarios elijan contraseñas débiles. La seguridad del cifrado es directamente proporcional a la entropía de la contraseña.
• La transmisión de la contraseña es fuera de banda. No proporcionamos un canal seguro para compartir la contraseña. Si esta se comparte por un canal inseguro (p. ej., correo electrónico sin cifrar junto con la URL de la transferencia), el modelo de seguridad se debilita.
• Los metadatos del archivo no están cifrados. El nombre original y el tamaño del archivo se almacenan en texto claro en el servidor. Esto revela el tipo y la naturaleza aproximada del archivo transferido, aunque su contenido permanezca cifrado.
• Confianza en el código del cliente. Los usuarios deben confiar en que el JavaScript servido por nuestra CDN es el código correcto y sin modificar. Una CDN comprometida o un secuestro de DNS podrían servir JavaScript malicioso. Esta es una limitación fundamental de toda la criptografía basada en web.
• Sin forward secrecy. Si la contraseña se ve comprometida en algún momento antes de que se elimine el blob cifrado, una copia almacenada de ese blob podría descifrarse. El borrado al leer y los tiempos de expiración cortos mitigan esto.
• Dependencia del modelo de seguridad del navegador. La seguridad del sistema depende de la implementación de la Web Crypto API del navegador y de su aislamiento de memoria. Un navegador comprometido o una extensión maliciosa podrían socavar todas las protecciones del lado del cliente.
• Computación cuántica. AES-256 se considera resistente a ataques cuánticos (el algoritmo de Grover reduce la seguridad efectiva a 128 bits, que sigue siendo inviable). Sin embargo, PBKDF2 con SHA-256 no está diseñado específicamente para resistencia postcuántica. No es una preocupación a corto plazo, pero la mencionamos por completitud.

Este libro blanco describe la arquitectura del sistema de Firma con Privacidad de PDF Pro, un mecanismo criptográfico de firma de documentos en el que el PDF nunca sale del navegador del firmante. El sistema utiliza ECDSA con la curva P-256 y hashing SHA-256 para producir firmas digitales separadas. Al servidor solo se transmiten el hash del documento, la firma criptográfica y la clave pública. Las claves privadas se generan, se cifran y se almacenan exclusivamente en el navegador del usuario mediante IndexedDB, protegidas por derivación de clave PBKDF2 (600.000 iteraciones) y cifrado AES-256-GCM. Este documento detalla la arquitectura completa de firma y verificación, el modelo de gestión de claves, el esquema del payload firmado, el diseño del registro de auditoría, el modelo de amenazas y las limitaciones honestas.

El sistema de Firma con Privacidad se diseña en torno a una restricción fundamental: el PDF nunca debe transmitirse al servidor. Esto se aplica arquitectónicamente mediante un modelo de firma separada.

• Cliente (navegador): generación de claves, almacenamiento de claves (cifradas en IndexedDB), hashing del documento (SHA-256), generación de firma (ECDSA P-256), verificación de firma.
• Servidor (Supabase): almacena claves públicas, registros de firma (hash + firma + metadatos) y eventos del registro de auditoría. Nunca recibe el PDF, las claves privadas ni las contraseñas de las claves.

2.3.1 Parámetros del algoritmo

2.3.2 Flujo de firma

// 1. Calcular el hash del PDF (en el cliente)
const fileBuffer = await file.arrayBuffer();
const hashBuffer = await crypto.subtle.digest("SHA-256", fileBuffer);
const hashHex = Array.from(new Uint8Array(hashBuffer))
  .map(b => b.toString(16).padStart(2, '0')).join('');

// 2. Firmar el hash con la clave privada (en el cliente)
const signature = await crypto.subtle.sign(
  { name: "ECDSA", hash: "SHA-256" },
  privateKey,   // CryptoKey desde IndexedDB (descifrada)
  hashBuffer
);

// 3. Enviar al servidor: hash + firma + clave pública (NO el PDF)
await submitSignature({
  documentHash: hashHex,
  signature: base64Encode(signature),
  publicKey: exportedPublicKeyJWK
});

2.4.1 Generación de claves

// Generar par de claves ECDSA P-256 (Web Crypto API)
const keyPair = await crypto.subtle.generateKey(
  {
    name: "ECDSA",
    namedCurve: "P-256"
  },
  true,   // extraíble (necesario para cifrado + almacenamiento)
  ["sign", "verify"]
);

// Exportar la clave pública como JWK para registrarla en el servidor
const publicKeyJWK = await crypto.subtle.exportKey("jwk", keyPair.publicKey);

// Exportar la clave privada como JWK para su almacenamiento cifrado
const privateKeyJWK = await crypto.subtle.exportKey("jwk", keyPair.privateKey);

Las claves privadas persistentes nunca se almacenan en texto claro. Antes de escribirse en IndexedDB, la clave privada (exportada como JSON JWK) se cifra siguiendo el mismo patrón que la Transferencia Segura:

2.5.1 Parámetros de protección

2.5.2 Esquema de almacenamiento

// Estructura del registro de IndexedDB para una clave de firma cifrada
{
  "keyId":       "uuid-v4-unique-identifier",
  "publicKey":   { /* formato JWK, sin cifrar */ },
  "encryptedPrivateKey": {
    "salt":       "base64-encoded-16-bytes",
    "iv":         "base64-encoded-12-bytes",
    "ciphertext": "base64-encoded-aes-gcm-ciphertext"
  },
  "algorithm":   "ECDSA",
  "curve":       "P-256",
  "createdAt":   "2026-04-16T00:00:00.000Z",
  "userId":      "supabase-auth-user-id"
}

PDF Pro utiliza un modelo de firma separada, lo que significa que la firma se almacena por separado del documento. Este es el mecanismo crítico de privacidad: el documento nunca sale del dispositivo del firmante.

2.6.1 Qué se envía al servidor

• Hash SHA-256 del PDF (32 bytes, codificado en hexadecimal en 64 caracteres).
• Firma ECDSA sobre el hash (64 bytes, codificada en base64).
• Clave pública del firmante (formato JWK).
• Metadatos: nombre a mostrar del firmante, correo del firmante (si está autenticado), marca de tiempo, ID de firma.

2.6.2 Qué NO se envía al servidor

• El PDF en sí — nunca se transmite.
• La clave privada — nunca sale del navegador.
• La contraseña de firma — nunca sale del navegador.
• Ningún contenido de página, texto o imágenes del PDF.

El siguiente esquema JSON define el registro de firma completo almacenado en el servidor:

{
  "schemaVersion":  "1.0",
  "signatureId":    "uuid-v4",
  "documentHash":   "sha256-hex-64-chars",
  "hashAlgorithm":  "SHA-256",
  "signature":      "base64-encoded-ecdsa-signature",
  "signatureAlgorithm": "ECDSA",
  "curve":          "P-256",
  "publicKey": {
    "kty": "EC",
    "crv": "P-256",
    "x":   "base64url-encoded-x-coordinate",
    "y":   "base64url-encoded-y-coordinate"
  },
  "signer": {
    "identityLevel": "authenticated | self-asserted",
    "displayName":   "string or null",
    "email":         "string or null",
    "userId":        "supabase-uid or null"
  },
  "timestamp":      "ISO-8601-UTC",
  "metadata": {
    "fileName":     "original-file-name.pdf",
    "fileSize":     123456,
    "pageCount":    12,
    "clientVersion": "2.0.0",
    "userAgent":    "browser-user-agent-string"
  },
  "auditChain": {
    "previousEventHash": "sha256-of-previous-audit-event or null",
    "eventHash":         "sha256-of-this-record"
  }
}

La verificación de firmas es un proceso en dos fases: verificación criptográfica en el cliente seguida de comprobación cruzada en el servidor.

2.8.1 Fase 1: Verificación criptográfica en el cliente

1. El usuario carga un PDF en el navegador.
2. El navegador calcula el hash SHA-256 del PDF cargado.
3. El navegador consulta al servidor cualquier registro de firma que coincida con ese hash.
4. Para cada registro de firma devuelto, el navegador realiza la verificación ECDSA:

   const isValid = await crypto.subtle.verify(
     { name: "ECDSA", hash: "SHA-256" },
     importedPublicKey,
     signatureBuffer,
     hashBuffer
   );

5. Si isValid === true, la firma es criptográficamente válida: el documento no se ha modificado desde la firma y la firma fue producida por el titular de la clave privada correspondiente.

2.8.2 Fase 2: Comprobación cruzada en el servidor

1. El servidor confirma que la clave pública del registro de firma está registrada a un usuario conocido (para firmas autenticadas).
2. El servidor confirma que el registro de firma no ha sido revocado.
3. El servidor confirma la integridad del registro de auditoría (validación de la cadena de hashes).
4. El servidor devuelve el nivel de identidad del firmante y el estado de registro.

2.8.3 Resultados de la verificación

Todos los eventos de firma y verificación se registran en un registro de auditoría a prueba de manipulaciones. Los eventos se encadenan por hash: cada evento incluye el hash SHA-256 del evento anterior, formando una cadena de solo-adición similar a una blockchain.

2.9.1 Tipos de eventos de auditoría

2.9.2 Estructura de la cadena de hashes

// Cada evento de auditoría incluye:
{
  "eventId":            "uuid-v4",
  "eventType":          "DOCUMENT_SIGNED",
  "timestamp":          "ISO-8601-UTC",
  "data":               { /* payload específico del evento */ },
  "previousEventHash": "sha256-of-previous-event-json",
  "eventHash":          "sha256-of-this-event-json-without-eventHash"
}

// Detección de manipulación: para verificar la cadena, calcula:
// SHA-256(JSON.stringify(event without eventHash field))
// y confirma que coincide con eventHash.
// Después confirma que previousEventHash coincide con el eventHash del evento anterior.

Si se modifica algún evento de la cadena, todos los enlaces de hash posteriores se romperán, haciendo que la manipulación sea detectable de inmediato. Esto proporciona una sólida garantía de integridad del registro de auditoría.

Nota: en la interfaz del producto, 'self_asserted' puede mostrarse como 'Identidad autoafirmada' o 'Firma de invitado'. 'authenticated' puede mostrarse como 'Cuenta autenticada'. Son etiquetas de visualización para los mismos niveles de identidad subyacentes.

2.11.1 Supuestos

• Entorno de ejecución del navegador de confianza
• La implementación de la Web Crypto API es correcta
• IndexedDB no es accesible para otros orígenes
• El usuario protege su contraseña
• El código del servidor coincide con el comportamiento publicado

2.11.2 Fuera del alcance

• Malware en los dispositivos endpoint
• Ingeniería social / ataques de phishing
• Capturas de pantalla por parte de los destinatarios
• Extensiones de navegador comprometidas
• Ataques con computación cuántica (consideración futura)

• No son Firma Electrónica Cualificada (QES). Las firmas de PDF Pro no cumplen los requisitos del Reglamento UE 910/2014 (eIDAS) para Firmas Electrónicas Cualificadas. No somos un Prestador Cualificado de Servicios de Confianza (QTSP), y nuestras claves de firma no se generan en un Dispositivo Cualificado de Creación de Firma (QSCD).
• No son cualificadas bajo eIDAS. Bajo eIDAS, solo las Firmas Electrónicas Cualificadas tienen el equivalente legal de las firmas manuscritas en todos los estados miembros de la UE. Las firmas de PDF Pro son, como mucho, firmas electrónicas avanzadas, y su valor legal depende de la jurisdicción específica y del caso de uso.
• No son de confianza para Adobe. Las firmas de PDF Pro no aparecen en la Adobe Approved Trust List (AATL). Al abrir un documento firmado por PDF Pro en Adobe Acrobat, la firma no se mostrará como "de confianza" en la interfaz de Adobe. La verificación debe realizarse mediante el sistema de verificación de PDF Pro.
• No somos una autoridad de certificación. No emitimos certificados X.509. Nuestra infraestructura de clave pública es propietaria de PDF Pro y no es interoperable con sistemas PKI como los que utilizan las administraciones públicas o las autoridades de certificación.
• No son notarización. Las firmas de PDF Pro no constituyen notarización, apostilla ni ninguna forma de autenticación de documentos certificada por el gobierno.
• Sin verificación de identidad real. Verificamos direcciones de correo mediante Supabase Auth, pero no realizamos verificación de documentos de identidad oficiales, verificación biométrica ni comprobación presencial de identidad.

2.12.1 Para qué SÍ son adecuadas las firmas de PDF Pro

• Flujos de trabajo empresariales — aprobaciones internas de documentos, validaciones de equipo, autorizaciones de compras donde las partes confían en el modelo de identidad de PDF Pro.
• Verificación de integridad — demostrar que un documento no se ha modificado desde un punto específico en el tiempo.
• No repudio (limitado) — demostrar que el titular de una clave privada específica firmó un documento concreto en un momento determinado. La fortaleza del no repudio depende de lo bien que se proteja la clave privada y de cómo se vincule la clave pública a una identidad.
• Cumplimiento de auditoría — proporcionar un registro de auditoría a prueba de manipulaciones de los eventos de firma de documentos para requisitos de cumplimiento interno.
• Firma de contratos — en muchas jurisdicciones, las firmas electrónicas (incluidas las no cualificadas) son legalmente válidas para la mayoría de los contratos comerciales bajo leyes como ESIGN (EE. UU.), UETA (EE. UU.) y el artículo 25(1) de eIDAS (UE).