Email certificat i xifrat: com equilibrar confidencialitat i prova del contingut

El correu electrònic certificat (ERDS, electronic registered delivery service segons eIDAS) busca aportar prova fefaent de l’enviament, la lliurament i el contingut d’una comunicació digital. La forma en què es xifra la informació durant l’enviament condiciona quin tipus d’evidència pot emetre’s.

En aquest article comparem dos models freqüents:

• TLS (xifrat del canal): protegeix la transmissió i permet acreditar el contingut.
• E2EE (xifrat d’extrem a extrem): maximitza la confidencialitat, però limita o impedeix acreditar el contingut sense introduir “finestres de confiança”.

Què ha d’acreditar un email certificat?

Perquè la comunicació tingui validesa probatòria:

• Enviament: qui envia i a qui.
• Lliurament: quan el servidor de destí va acceptar el missatge.
• Contingut: el text exacte i els adjunts (integritat).
• Segells temporals: dates/hores confiables.
• (Opcional) Lectura: obertura del missatge pel destinatari.

Sense accés al contingut en clar (contingut sense xifrar) en algun punt controlat, el tercer de confiança no pot calcular un hash verificable del contingut ni signar-lo i custodiar-lo amb garanties.

Model TLS: seguretat en trànsit amb traçabilitat probatòria

Què és

TLS (Transport Layer Security) xifra el canal entre clients i servidors de correu: les dades viatgen xifrades en trànsit.

Què permet

El prestador pot rebre i processar el missatge en clar dins del seu perímetre segur, calcular el hash del contingut (text + adjunts), segellar-lo temporalment, signar-lo i custodiar l’evidència.

Avantatges:

• Confidencialitat en trànsit i protecció contra manipulació.
• Compatibilitat universal (no exigeix res al destinatari).
• Prova sòlida del contingut (hash verificable + custòdia).

Resultat: equilibri entre seguretat i prova del contingut.

Model E2EE: confidencialitat absoluta, dilema probatori

Com funciona

El remitent xifra amb la clau pública del destinatari; només aquest, amb la seva clau privada, pot desxifrar. En teoria, ningú més (ni tan sols el prestador) pot llegir el missatge.

Conseqüència

El prestador no pot veure el contingut → no pot calcular el hash del contingut en clar, ni incloure’l en un certificat amb prova de contingut. Podrà acreditar enviament/lliurament de “alguna cosa xifrada”, però no què es va enviar.

E2EE autèntic converteix al prestador en testimoni del sobre, no de la carta.

Serveix un hash de la DATA xifrada enviada per SMTP?

Hipòtesi: “Encara que sigui E2EE, el prestador podria hashear la DATA (ciphertext) que circula per SMTP.” Serviria com a element representatiu de contingut enviat?

Problemes clau:

• El hash representaria el ciphertext, no el contingut en clar.
• El xifrat modern és probabilístic (usa IV/salt/nonce): el ciphertext canvia encara que el contingut sigui el mateix, per la qual cosa el hash del ciphertext no és un identificador estable del contingut.
• Sense la clau privada del destinatari, no existeix un mecanisme públicament verificable per vincular aquest hash del ciphertext amb el text/adjunts originals.

Conclusió: el hash del tràfic xifrat no resol la prova del contingut.

Quan es parla de “xifrat del contingut”: opcions i sacrificis

Per xifrar i certificar contingut a la vegada, hi ha esquemes híbrids que introdueixen finestres de confiança (trust windows). En tots els casos, ja no es pot parlar d’E2EE “pur”.

Si ningú llevat del destinatari pot accedir al contingut, el prestador no pot acreditar el contingut íntegre per si mateix. Per poder fer-ho, ha d’existir alguna “finestra” (temporal o procedimental) en què sí pugui veure’l.

Preguntes freqüents (FAQ)

Per què TLS no “debilitza” la prova?
Perquè xifra el transporte i permet al prestador, com a tercer de confiança, verificar el contingut en clar en un entorn controlat per hashejar-lo, signar-lo i custodiar-lo. Això enforteix la prova.

E2EE impedeix tota prova?
No. Permet acreditar enviament/lliurament d’un ciphertext, però no el contingut sense cooperació del destinatari o sense introduir una finestra d’accés.

Què és exactament “desxifrat intern” i “custòdia”?

• Desxifrat intern: obertura temporal del contingut dins del perímetre del prestador per poder hashear/segellar.
• Custòdia: conservació segura a llarg termini d’evidències (hashes, segells, certificats i, segons model, contingut), amb traçabilitat i controls.

La “lectura” és prova forta?
És un indici (basat en senyals d’obertura), útil però no infal·lible. La prova forta se centra en contingut, enviament i lliurament.

Quan triar cada model?

• Necessito acreditar el contingut (contractes, reclamacions, notificacions amb termini):
  TLS + certificació de contingut → equilibri entre confidencialitat i prova.

• Prima la confidencialitat absoluta (salut, banca, defensa) i puc usar altres mecanismes per provar el contingut (p. ex., document signat electrònicament):
  E2EE real → màxima privacitat, amb limitació probatòria.

Conclusió

No hi ha un xifrat “millor” en abstracte.

Si l’objectiu és provar el contingut, el model ha de permetre que el tercer de confiança accedeixi al missatge en clar en un punt controlat per hashejar-lo, segellar-lo i custodiar-lo. TLS ofereix aquest equilibri.

L’E2EE autèntic prioritza la privacitat, però renuncia a la prova del contingut llevat de cooperació del destinatari o la introducció de finestres de confiança, que per definició deixen de ser E2EE pur.