Let's Seal: una sorta di Let's Encrypt per firmare e verificare documenti

Verificare che un file non sia stato modificato, attribuirlo a uno specifico firmatario e dimostrare che esisteva già in un determinato momento richiede spesso strumenti separati: firma digitale, certificato X.509, marca temporale e un sistema affidabile per controllare la cronologia delle prove. Let’s Seal nasce per riunire questi elementi in un unico modello aperto, chiamato SEAL – Sealed Evidence Anchored to a Ledger – pensato per documenti PDF, immagini, video, email, file XML, software e immagini container.

Le tecnologie utilizzate non sono nuove. Le firme digitali basate su crittografia asimmetrica risalgono agli anni ’70; lo standard X.509 ha poi introdotto un modello strutturato per collegare una chiave pubblica a un’identità, mentre formati come CMS, PAdES, XML-DSig e S/MIME hanno adattato lo stesso principio a documenti, messaggi di posta e dati strutturati. Più di recente, C2PA ha esteso il concetto di provenienza verificabile a fotografie, video e altri contenuti multimediali.

Il problema è che una firma, da sola, non risolve tutto. Può dimostrare che un file non è cambiato, ma non sempre offre una prova temporale indipendente; una marca temporale certifica l’esistenza di un’impronta digitale, ma non chiarisce necessariamente chi abbia firmato il contenuto; un certificato, infine, ha valore soltanto se il verificatore riconosce l’autorità che lo ha emesso. SEAL prova a collegare queste informazioni in una prova unica, verificabile anche con strumenti esterni al servizio.

Che cosa dimostra un sigillo SEAL

Il progetto Let’s Seal, che presenta un’evidente assonanza con il ben più noto Let’s Encrypt per la generazione di certificati da usare sul web via HTTPS, combina firme digitali standard, certificati X.509, OpenTimestamps e un registro pubblico basato su alberi di Merkle. Tramite OpenTimestamps, l’impronta crittografica del file viene collegata a una transazione registrata sulla blockchain di Bitcoin: una prova pubblicamente verificabile che consente di dimostrare che quel contenuto esisteva già prima della conferma del relativo blocco.

L’obiettivo non è creare un nuovo algoritmo crittografico, ma definire regole comuni per stabilire se un file è integro, chi lo ha firmato e quale riferimento temporale indipendente accompagna la firma.

Una prova SEAL mira a stabilire tre proprietà distinte: il file non ha subito modifiche dopo la firma, esisteva entro una determinata data e risulta associato a uno specifico certificato. Il progetto aggiunge inoltre un registro pubblico append-only, cioè strutturato in modo da rendere rilevabili eventuali riscritture della cronologia.

L’integrità deriva normalmente da un’impronta SHA-256: il software calcola un digest di 256 bit a partire dal contenuto; anche la modifica di un singolo byte produce, con probabilità estremamente elevata, un risultato differente. La firma crittografica applicata al digest permette poi di controllare che l’impronta provenga dalla chiave privata collegata al certificato dichiarato.

Il sistema Let’s Seal non sostituisce un notaio, non identifica automaticamente una persona secondo criteri legali e non attribuisce al file il valore di una firma elettronica qualificata ai sensi del regolamento eIDAS.

Un formato di firma diverso per ogni tipo di file

SEAL non racchiude ogni documento in un contenitore proprietario. Cerca, al contrario, di usare il formato di firma più adatto al tipo di dato. Per i PDF adotta PAdES, famiglia di specifiche ETSI che inserisce la firma direttamente nel documento. Il PDF continua quindi ad aprirsi con i normali lettori, mentre un validatore compatibile può esaminare firma, certificati e porzione del file coperta dalla sottoscrizione.

Fotografie, video e file audio usano invece un manifest C2PA incorporato nel contenuto: le Content Credentials possono trasportare informazioni sulla provenienza, sul programma che ha elaborato il file e sulle operazioni dichiarate.

Per i documenti XML il progetto ricorre a XML-DSig mentre le email sono firmate tramite S/MIME 4.0, definito dalla RFC 8551, usando una struttura multipart/signed e una firma CMS separata dal corpo del messaggio.

Per tutti gli altri tipi di file SEAL, genera un cosiddetto sidecar con estensione .sig basato su CAdES o CMS. In pratica, il contenuto originale resta invariato e viaggia insieme a un piccolo file che ne firma l’hash corrispondente.

Questa scelta migliora l’interoperabilità, ma introduce una responsabilità pratica: quando la firma è separata, bisogna conservare e trasferire entrambi i file. Perdere il sidecar non altera il documento, però elimina la prova crittografica associata.

La root Let’s Seal non è automaticamente riconosciuta

Il progetto gestisce una propria Certification Authority. I certificati usati per firmare devono costruire una catena valida fino alla root Let’s Seal, identificata anche tramite un’impronta SHA-256 pubblicata nella specifica. La radice, per scelta progettuale, non compare negli archivi fiduciari dei sistemi operativi, dei browser, di Adobe Acrobat e dei client di posta.

Di conseguenza, un’applicazione generica può riconoscere che la firma è matematicamente valida, ma segnalarla come non attendibile. Per ottenere un esito positivo occorre importare o configurare esplicitamente la root, oppure usare un verificatore che la includa come trust anchor. Non è un’anomalia: la validità crittografica dice che la firma corrisponde alla chiave pubblica; la fiducia dice invece che il verificatore accetta l’autorità che ha rilasciato quel certificato.

SEAL versione 1.1 è una specifica pubblica e implementabile senza royalty, distribuita con licenza CC BY 4.0; il codice di riferimento usa Apache 2.0 (repository GitHub ufficiale). Ciò favorisce audit, fork e implementazioni alternative. Non significa però che SEAL abbia già attraversato un processo formale presso ETSI, ISO, IETF o W3C.

Al momento rappresenta soprattutto una proposta tecnica aperta che combina standard esistenti secondo regole comuni. L’interoperabilità reale dovrà emergere dalla disponibilità di implementazioni indipendenti, test di conformità, gestione stabile delle versioni e adozione da parte di soggetti esterni al progetto. Definire pubblicamente un formato è il primo passo; far sì che software differenti producano e interpretino lo stesso risultato senza ambiguità è la parte più difficile.

L’idea di fondo, comunque, è valida: evitare un nuovo contenitore proprietario e costruire una prova verificabile con PAdES, C2PA, XML-DSig, S/MIME, CMS, OpenTimestamps e strutture Merkle già note.

SEAL, firma digitale e identità elettronica: le differenze

I termini utilizzati da Let’s Seal possono creare qualche equivoco, soprattutto in Italia, dove esiste già un sistema regolamentato di firme elettroniche, marche temporali, identità digitali e servizi fiduciari. SEAL usa formati come PAdES, CAdES e certificati X.509, gli stessi mattoni tecnici presenti in molte soluzioni europee; ciò non significa però che un sigillo SEAL equivalga automaticamente a una firma digitale italiana o a una firma elettronica qualificata ai sensi di eIDAS.

La differenza principale riguarda il modo in cui il certificato è collegato all’identità: con SEAL, il sistema può verificare il controllo di un dominio Internet oppure associare la firma a un indirizzo email confermato tramite un provider di identità. Una prova del genere permette di affermare, per esempio, che la chiave appartiene a chi controllava example.com o a chi ha effettuato l’accesso a uno specifico account. Non dimostra necessariamente che dietro quella chiave vi sia la persona anagrafica indicata nel nome visualizzato.

La firma elettronica qualificata segue un percorso più rigoroso. Un prestatore di servizi fiduciari qualificato identifica il titolare, rilascia un certificato qualificato e permette di firmare attraverso un dispositivo o un servizio conforme ai requisiti eIDAS. Il certificato contiene dati associati a una persona fisica identificata e il prestatore compare nelle Trusted List europee. Nell’Unione europea questa firma produce lo stesso effetto giuridico di una firma autografa.

In Italia si usa spesso il termine “firma digitale” per indicare la particolare firma elettronica qualificata basata su crittografia asimmetrica disciplinata dal Codice dell’amministrazione digitale (CAD). Anche una firma SEAL usa una coppia di chiavi, un certificato e algoritmi crittografici; manca però, nella configurazione ordinaria del progetto, il passaggio decisivo rappresentato da un prestatore qualificato, da un certificato qualificato e da una root riconosciuta attraverso le liste di fiducia europee.