Le firme elettroniche spiegate da zero

Ultimo aggiornamento: 13 luglio 2026

Questa guida non presuppone nessuna conoscenza pregressa. Se hai scaricato StackSign e ti sei trovato davanti a termini come CAdES, trust list, QES o timestamp senza sapere cosa significano, questo è il punto di partenza giusto: prima leggi questa guida, poi README.md (cosa fa StackSign) e CLAUDE.md (come è fatto il codice) avranno molto più senso.

Indice

1. Perché servono le firme elettroniche
2. Come funziona crittograficamente una firma digitale
3. Il certificato digitale
4. La catena di fiducia
5. Trust List e LOTL
6. I tre livelli di firma eIDAS: SES, AES, QES
7. Formati tecnici: CAdES, PAdES, XAdES
8. Timestamp: la prova della data
9. Profili di conformità: -B, -T, -LT, -LTA
10. Container ASiC
11. Perché in Italia si trovano buste annidate
12. Cos'è DSS e perché è nato
13. Cos'è un keystore
14. Come si legge l'esito di una validazione
15. Glossario rapido
16. Per approfondire

1. Perché servono le firme elettroniche

Un foglio di carta firmato a mano ha tre proprietà che diamo per scontate: si vede chi lo ha firmato, non si può alterare il contenuto senza che si noti, e chi ha firmato non può facilmente negare di averlo fatto. Un file digitale, per sua natura, non ha nessuna di queste proprietà: è infinitamente copiabile, modificabile senza lasciare traccia visibile, e non esiste un "inchiostro" digitale che leghi in modo univoco una persona a un contenuto.

La firma elettronica è l'insieme di tecniche (soprattutto crittografiche) che ricostruisce queste tre garanzie nel mondo digitale:

• autenticità — è verificabile chi ha firmato;
• integrità — è verificabile che il contenuto non sia stato alterato dopo la firma;
• non ripudio — il firmatario non può negare di aver firmato, perché solo lui poteva materialmente produrre quella firma.

In Europa, il Regolamento eIDAS (UE n. 910/2014, electronic IDentification, Authentication and trust Services) è la normativa che dà valore legale a questi meccanismi in modo uniforme in tutti gli Stati Membri: definisce cosa serve perché una firma elettronica valga legalmente, chi può erogare questi servizi (i "prestatori di servizi fiduciari") e come si distinguono i diversi livelli di affidabilità. StackSign è un servizio che verifica la conformità a eIDAS di un documento firmato.

2. Come funziona crittograficamente una firma digitale

Alla base di ogni firma elettronica avanzata o qualificata ci sono due strumenti matematici:

L'hash. Una funzione di hash (es. SHA-256) trasforma un file di qualsiasi dimensione in una sequenza di byte di lunghezza fissa (l'impronta digitale del file). Due proprietà la rendono utile: è deterministica (lo stesso file produce sempre lo stesso hash) ed è praticamente impossibile trovare due file diversi con lo stesso hash, o modificare un file mantenendo lo stesso hash. Basta quindi confrontare due hash per sapere se un file è stato alterato, senza dover confrontare l'intero contenuto.

La crittografia asimmetrica. A ogni firmatario è associata una coppia di chiavi matematicamente collegate: una chiave privata, segreta, che solo lui possiede, e una chiave pubblica, distribuibile a chiunque. Ciò che viene cifrato con la chiave privata può essere decifrato solo con la chiave pubblica corrispondente (e viceversa) — questa proprietà è ciò che rende possibile la firma.

Mettendo insieme i due strumenti, firmare un documento significa:

1. calcolare l'hash del documento;
2. cifrare quell'hash con la propria chiave privata → il risultato è la firma digitale.

Verificare una firma significa, per chiunque:

1. ricalcolare l'hash del documento ricevuto;
2. decifrare la firma con la chiave pubblica del presunto firmatario;
3. confrontare i due valori — se coincidono, il documento non è stato alterato e la firma è stata prodotta da chi possiede quella chiave privata.

Questo dimostra integrità e "possesso della chiave privata". Manca però un ultimo tassello: come facciamo a sapere che quella chiave pubblica appartiene davvero alla persona che dice di essere? Qui entra in gioco il certificato digitale.

3. Il certificato digitale: legare una chiave pubblica a un'identità

Un certificato digitale (standard X.509) è un documento elettronico che lega una chiave pubblica a un'identità verificata, ed è a sua volta firmato da un ente terzo fidato che garantisce quel legame. I campi principali (che ritrovi identici nel report di StackSign) sono:

• Subject (soggetto) — l'identità a cui appartiene la chiave pubblica: una persona fisica (nome, cognome, codice fiscale) o un'organizzazione. Nel report di StackSign è certificateSubject.
• Issuer (emittente) — chi ha emesso e firmato il certificato, cioè chi garantisce che il soggetto è davvero chi dice di essere. Nel report è certificateIssuer.
• Validità (notBefore / notAfter) — il periodo in cui il certificato è considerato valido. Un certificato scaduto (o revocato prima) non può più essere usato per firmare validamente — anche se la firma esiste già è la data di firma a dover cadere in questo intervallo, non la data di validazione (vedi la sezione sui timestamp).
• Serial number — numero univoco assegnato dall'emittente, usato ad esempio per identificare il certificato nelle liste di revoca.
• Chiave pubblica e firma dell'emittente — la chiave pubblica del soggetto, e la firma con cui l'emittente certifica l'intero contenuto.

L'emittente del certificato è una Certification Authority (CA): un ente che, dopo aver verificato l'identità reale del richiedente (con un documento d'identità, SPID, CNS, o in banca allo sportello), emette un certificato che lega quella identità a una chiave pubblica.

4. La catena di fiducia (chain of trust)

Chi certifica il certificatore? Anche una CA ha un proprio certificato, emesso a sua volta da un'altra CA — tipicamente una CA intermedia, il cui certificato è emesso da una Root CA. La Root CA è l'unica che non ha un emittente esterno: il suo certificato è self-signed (firma se stessa). La sua affidabilità non si può quindi "dimostrare" crittograficamente, va accettata a priori: per questo si parla di trust anchor ("ancora di fiducia").

Validare una firma significa quindi risalire la catena — certificato del firmatario → CA intermedia → Root CA — fino a raggiungere un trust anchor che il validatore riconosce come affidabile. Se la catena si interrompe prima di arrivare a un trust anchor conosciuto, l'esito della validazione resta indeterminato (è esattamente quello che succede validando i documenti di test di StackSign, firmati con una PKI usa-e-getta non presente in nessuna trust list ufficiale).

5. Trust List e LOTL: come l'UE distribuisce la fiducia

Rimane un problema pratico: chi decide quali CA sono affidabili nell'Unione Europea, e come fa un software a saperlo senza doverlo configurare a mano?

Ogni Stato Membro pubblica una propria Trusted List (TL): l'elenco ufficiale dei prestatori di servizi fiduciari (TSP — Trust Service Provider) autorizzati o qualificati sul proprio territorio, con i relativi certificati di CA (in Italia, l'ente competente è AgID; tra i TSP italiani più noti ci sono ArubaPEC, InfoCert, Aruba). Sono quindi 27 liste diverse, una per Stato.

La LOTL (List Of Trusted Lists) è "la lista delle liste": un documento unico, pubblicato dalla Commissione Europea, che punta a tutte le TL nazionali. La LOTL stessa è firmata da certificati la cui autenticità è annunciata nella Gazzetta Ufficiale dell'Unione Europea (Official Journal, OJ) — è questo il vero trust anchor di partenza per l'intero sistema eIDAS.

Nel tempo i certificati con cui la Commissione firma la LOTL cambiano; per non dover ridistribuire manualmente un nuovo trust anchor a ogni software validatore ogni volta, la LOTL usa un meccanismo di pivot: ogni versione contiene un riferimento verificabile crittograficamente alla versione precedente, così un validatore che parte da un vecchio trust anchor può risalire la catena dei pivot fino ai certificati di firma più recenti, senza doversi mai fidare "alla cieca" di un nuovo certificato. È esattamente il meccanismo che TrustConfiguration e OjKeystoreUpdater di StackSign implementano (vedi CLAUDE.md).

6. I tre livelli di firma elettronica secondo eIDAS

eIDAS distingue tre livelli di firma elettronica, con valore legale crescente:

Questa distinzione è esattamente ciò che DSS calcola e che StackSign espone nel campo qualification del report (QESIG = firma qualificata di persona fisica, ADESIG_QC = firma avanzata con certificato qualificato, NOT_ADES = non conforme, e così via): non basta che la firma sia crittograficamente valida, bisogna anche stabilire che livello di garanzia legale offre.

7. Formati tecnici di firma: perché ne esistono diversi

Il "come" tecnico con cui una firma viene incorporata in un file dipende dal tipo di documento:

• CAdES (CMS Advanced Electronic Signature) — la firma e il documento originale vengono avvolti in un'unica struttura binaria (CMS/PKCS#7). In Italia è il classico file .p7m. È adatto a firmare qualsiasi tipo di file, ma il risultato non è più direttamente apribile con il programma originale: prima va "sbustato" per recuperare il contenuto.
• PAdES (PDF Advanced Electronic Signature) — la firma viene incorporata dentro il PDF stesso, come un campo firma del documento. Il file resta un PDF apribile normalmente: è la firma che genera il classico "pallino verde" di Adobe Acrobat Reader.
• XAdES (XML Advanced Electronic Signature) — la firma viene incorporata dentro un documento XML. È il formato tipico della fatturazione elettronica.

Nel report di StackSign questa distinzione è il campo containerFormat.

8. Timestamp: la prova della data

Una firma digitale, da sola, prova chi ha firmato e che il contenuto non è cambiato — ma non prova quando è stata apposta: l'orologio del computer del firmatario non è un dato verificabile da terzi, si potrebbe falsificare a piacere.

Un timestamp (marca temporale) è un attestato firmato da un ente terzo fidato — una TSA (Time Stamping Authority) — che certifica "l'hash di questo documento esisteva già a questa data e ora". Lo standard di riferimento è l'RFC 3161.

Perché è importante:

• protegge la firma nel tempo. Un certificato ha una validità limitata (di norma qualche anno) e può anche essere revocato prima della scadenza. Senza un timestamp, non c'è modo di provare che la firma sia stata apposta mentre il certificato era ancora valido, una volta che quel periodo di validità è passato. Con un timestamp sulla firma, invece, si dimostra che al momento della firma il certificato era valido — e la firma resta verificabile anche anni dopo la scadenza del certificato. Questo concetto si chiama prova di esistenza (POE — Proof Of Existence), ed è quello che nel report di StackSign è il campo bestSignatureTime: coincide con l'ora di validazione per le firme senza timestamp, con l'ora del timestamp per quelle che ce l'hanno.
• dà "data certa" anche a documenti non firmati. Un timestamp può essere applicato anche a un documento senza firma, per attestarne solo l'esistenza a una certa data (nel report di StackSign, questi sono i standaloneTimestamps).

Anche i prestatori di marcatura temporale possono essere qualificati (QTSA), e in quel caso compaiono anch'essi nelle trust list nazionali, esattamente come le CA.

9. I profili di conformità (baseline): -B, -T, -LT, -LTA

Ogni formato (CAdES, PAdES, XAdES) prevede quattro livelli progressivi di "solidità" nel tempo, detti baseline profiles:

È questo che nel report di StackSign vedi nel campo signatureLevel (es. CAdES_BASELINE_B, CAdES_BASELINE_T): non è solo "che formato" ma anche "quanto è solida nel tempo" quella firma.

10. Container ASiC: firmare più file con un'unica firma

ASiC (Associated Signature Container, ETSI EN 319 162, estensioni .asice/.asics) è un formato contenitore (un file ZIP) che raggruppa uno o più file di dati insieme a un manifest che elenca cosa è coperto dalla firma — invece di "avvolgere" ogni singolo file separatamente. Una firma sola può quindi coprire più file fratelli.

È importante non confonderlo con le buste annidate (vedi punto successivo): in ASiC c'è un solo livello di firma che copre più file tramite un manifest; nelle buste annidate, invece, c'è un vero e proprio annidamento — una firma che ne avvolge un'altra, che a sua volta ne avvolge un'altra ancora.

11. Perché in Italia si trovano buste annidate

In Italia, per ragioni storiche (la firma digitale era disciplinata da normative nazionali già prima di eIDAS, e l'ecosistema si è consolidato attorno al formato CAdES/.p7m), è pratica comune trovare un documento già firmato ulteriormente "avvolto" in una busta di firma esterna: un .p7m che contiene un altro .p7m (doppio P7M, tipico quando più soggetti firmano in sequenza con strumenti diversi), oppure una busta CAdES che avvolge un PDF già firmato PAdES (tipico in ambito bancario, dove una firma di controllo/contabile si aggiunge sopra un documento già firmato dal cliente).

DSS — la libreria su cui si basa StackSign — valida correttamente un livello di busta alla volta, ma non fa da sé lo "sbustamento" ricorsivo: puntato su uno di questi documenti, produce un report che riguarda solo l'involucro più esterno. È esattamente questo il problema che StackSign risolve: itera ricorsivamente su ogni livello (NestedSignatureValidator), valida ogni firma trovata e aggrega tutti i risultati in un unico report — vedi README.md per i dettagli.

12. Cos'è DSS e perché è nato

DSS (Digital Signature Service) è una libreria Java open source sviluppata e mantenuta dalla Commissione Europea (DG DIGIT): è l'implementazione di riferimento degli standard tecnici ETSI (in particolare ETSI EN 319 102-1, che definisce nel dettaglio come si crea e si valida una firma conforme a eIDAS).

È nata perché eIDAS impone requisiti tecnici molto dettagliati e in continua evoluzione (nuovi algoritmi, nuove versioni degli standard, aggiornamenti delle trust list): reimplementare tutto questo da zero, correttamente e in modo aggiornato, sarebbe estremamente costoso e rischioso per ogni singolo fornitore di software, banca o pubblica amministrazione. DSS è oggi lo standard de facto: è alla base di moltissimi portali di validazione ufficiali degli Stati Membri UE.

Concretamente, DSS sa creare e validare firme CAdES/PAdES/XAdES a tutti i livelli di conformità, gestire il download e l'aggiornamento delle trust list, verificare timestamp, ed effettuare i controlli di revoca via OCSP/CRL — tutto secondo gli standard ETSI. StackSign lo usa come motore di validazione, aggiungendo lo sbustamento ricorsivo e un report aggregato più ricco di quello nativo (vedi README.md).

13. Cos'è un keystore

Un keystore è un file protetto da password che contiene chiavi crittografiche e/o certificati — il formato più comune è PKCS#12 (estensione .p12).

Nel contesto di StackSign, il keystore OJ (ojKeystore.p12) non contiene la chiave privata di nessuno: contiene i certificati pubblici con cui la Commissione Europea firma la LOTL, cioè il trust anchor di partenza descritto al punto 5. È un file che serve a verificare firme, non a produrle — per questo, a differenza di un keystore usato per firmare, può essere ridistribuito e aggiornato liberamente (vedi CLAUDE.md per come StackSign lo mantiene aggiornato in modo automatico e verificabile tramite il meccanismo dei pivot).

14. Come si legge l'esito di una validazione

Ogni firma validata da DSS (e quindi da StackSign) riceve un'indication, secondo lo standard ETSI EN 319 102-1:

• TOTAL_PASSED — tutti i controlli sono passati: la firma è valida.
• TOTAL_FAILED — la firma non è valida (es. il documento è stato modificato dopo la firma e l'hash non corrisponde più, oppure il certificato era già revocato al momento della firma).
• INDETERMINATE — non si può stabilire con certezza l'esito (es. manca un dato di revoca necessario, oppure — il caso più comune quando si validano firme di test — la catena di certificati non arriva a un trust anchor conosciuto).

Ogni indication è accompagnata da una subIndication più specifica che ne spiega il motivo (es. NO_CERTIFICATE_CHAIN_FOUND, HASH_FAILURE, EXPIRED...) — nel report di StackSign, il "perché" testuale ed esteso di questi codici si trova nei campi adesValidationDetails e qualificationDetails.

15. Glossario rapido

16. Per approfondire

• Regolamento eIDAS (UE) n. 910/2014 — il testo normativo
• Trusted List Browser — la LOTL e le trust list nazionali, consultabili online
• Repository DSS su GitHub — codice sorgente e documentazione tecnica
• ETSI EN 319 102-1 — lo standard che definisce le procedure di validazione (indication/subIndication)
• trust-list-nazionali.html — perché le TL nazionali che compongono la LOTL non sono tutte uguali (es. AgID in Italia pubblica anche servizi non qualificati)