Email certificado y cifrado: cómo equilibrar confidencialidad y prueba del contenido

El correo electrónico certificado (ERDS, electronic registered delivery service según eIDAS) busca aportar prueba fehaciente del envío, la entrega y el contenido de una comunicación digital. La forma en que se cifra la información durante el envío condiciona qué tipo de evidencia puede emitirse.

En este artículo comparamos dos modelos frecuentes:

• TLS (cifrado del canal): protege la transmisión y permite acreditar el contenido.
• E2EE (cifrado de extremo a extremo): maximiza la confidencialidad, pero limita o impide acreditar el contenido sin introducir “ventanas de confianza”.

¿Qué debe acreditar un email certificado?

Para que la comunicación tenga validez probatoria:

• Envío: quién envía y a quién.
• Entrega: cuándo el servidor de destino aceptó el mensaje.
• Contenido: el texto exacto y los adjuntos (integridad).
• Sellos temporales: fechas/horas confiables.
• (Opcional) Lectura: apertura del mensaje por el destinatario.

Sin acceso al contenido en claro (contenido sin cifrar) en algún punto controlado, el tercero de confianza no puede calcular un hash verificable del contenido ni firmarlo y custodiarlo con garantías.

Modelo TLS: seguridad en tránsito con trazabilidad probatoria

Qué es

TLS (Transport Layer Security) cifra el canal entre clientes y servidores de correo: los datos viajan cifrados en tránsito.

Qué permite

El prestador puede recibir y procesar el mensaje en claro dentro de su perímetro seguro, calcular el hash del contenido (texto + adjuntos), sellarlo temporalmente, firmarlo y custodiar la evidencia.

Ventajas:

• Confidencialidad en tránsito y protección contra manipulación.
• Compatibilidad universal (no exige nada al destinatario).
• Prueba sólida del contenido (hash verificable + custodia).

Resultado: equilibrio entre seguridad y prueba del contenido.

Modelo E2EE: confidencialidad absoluta, dilema probatorio

Cómo funciona

El remitente cifra con la clave pública del destinatario; solo este, con su clave privada, puede descifrar. En teoría, nadie más (ni siquiera el prestador) puede leer el mensaje.

Consecuencia

El prestador no puede ver el contenido → no puede calcular el hash del contenido en claro, ni incluirlo en un certificado con prueba de contenido. Podrá acreditar envío/entrega de “algo cifrado”, pero no qué se envió.

E2EE auténtico convierte al prestador en testigo del sobre, no de la carta.

¿Sirve un hash de la DATA cifrada enviada por SMTP?

Hipótesis: “Aunque sea E2EE, el prestador podría hashear la DATA (ciphertext) que circula por SMTP.” ¿Serviría como elemento representativo de contenido enviado?

Problemas clave:

• El hash representaría el ciphertext, no el contenido en claro.
• El cifrado moderno es probabilístico (usa IV/salt/nonce): el ciphertext cambia aunque el contenido sea el mismo, por lo que el hash del ciphertext no es un identificador estable del contenido.
• Sin la clave privada del destinatario, no existe un mecanismo públicamente verificable para vincular ese hash del ciphertext con el texto/adjuntos originales.

Conclusión: el hash del tráfico cifrado no resuelve la prueba del contenido.

Cuando se habla de “cifrado del contenido”: opciones y sacrificios

Para cifrar y certificar contenido a la vez, hay esquemas híbridos que introducen ventanas de confianza (trust windows). En todos los casos, ya no se puede hablar de E2EE “puro”.

Si nadie salvo el destinatario puede acceder al contenido, el prestador no puede acreditar el contenido íntegro por sí mismo. Para poder hacerlo, debe existir alguna “ventana” (temporal o procedimental) en la que sí pueda verlo.

Preguntas frecuentes (FAQ)

¿Por qué TLS no “debilita” la prueba?
Porque cifra el transporte y permite al prestador, como tercero de confianza, verificar el contenido en claro en un entorno controlado para hashearlo, firmarlo y custodiarlo. Eso fortalece la prueba.

¿E2EE impide toda prueba?
No. Permite acreditar envío/entrega de un ciphertext, pero no el contenido sin cooperación del destinatario o sin introducir una ventana de acceso.

¿Qué es exactamente “descifrado interno” y “custodia”?

• Descifrado interno: apertura temporal del contenido dentro del perímetro del prestador para poder hashear/sellar.
• Custodia: conservación segura a largo plazo de evidencias (hashes, sellos, certificados y, según modelo, contenido), con trazabilidad y controles.

¿La “lectura” es prueba fuerte?
Es un indicio (basado en señales de apertura), útil pero no infalible. La prueba fuerte se centra en contenido, envío y entrega.

¿Cuándo elegir cada modelo?

• Necesito acreditar el contenido (contratos, reclamaciones, notificaciones con plazo):
  TLS + certificación de contenido → equilibrio entre confidencialidad y prueba.

• Prima la confidencialidad absoluta (salud, banca, defensa) y puedo usar otros mecanismos para probar el contenido (p. ej., documento firmado electrónicamente):
  E2EE real → máxima privacidad, con limitación probatoria.

Conclusión

No hay un cifrado “mejor” en abstracto.

Si el objetivo es probar el contenido, el modelo debe permitir que el tercero de confianza acceda al mensaje en claro en un punto controlado para hashearlo, sellarlo y custodiarlo. TLS ofrece ese equilibrio.

El E2EE auténtico prioriza la privacidad, pero renuncia a la prueba del contenido salvo cooperación del destinatario o la introducción de ventanas de confianza, que por definición dejan de ser E2EE puro.