Firme digitali per file: dimostrare autenticità e origine

Una firma digitale è una prova crittografica che una persona o entità specifica ha creato un file e che il file non è cambiato da allora. Tecnicamente: fai l'hash del file con SHA-256, poi "firmi" l'hash con la tua chiave privata usando RSA-PSS, ECDSA o Ed25519. Chiunque abbia la tua chiave pubblica può verificare la firma — se è valida, sa che hai creato il file e che è identico byte per byte a ciò che hai firmato. Le firme sono ciò che macOS usa per verificare gli aggiornamenti delle app, ciò che Git usa per la paternità dei commit (git commit -S), e ciò che PGP usa per le email firmate. Risolvono un problema che la sola crittografia non può: provare chi ha inviato cosa.

Firme vs. crittografia: lavori diversi

La crittografia mantiene i contenuti segreti. Le firme provano la paternità e l'integrità. Sono complementari, non alternative.

• Solo cifratura: il destinatario conosce il contenuto ma non chi lo ha inviato. Chiunque abbia la chiave pubblica avrebbe potuto cifrarlo.
• Solo firma: il destinatario sa chi lo ha inviato e che non è stato manomesso, ma il contenuto è visibile a chiunque intercetti.
• Firma e cifratura: piena autenticità, integrità e riservatezza. La modalità default di PGP.

I servizi di trasferimento file si concentrano tipicamente sulla crittografia. Le firme entrano in gioco per i contesti ad alta fiducia: distribuzione software, documenti legali, contratti, catene di prove forensi.

Come funziona davvero la firma

Il flusso canonico di firma Ed25519:

1. Fai l'hash del messaggio: h = SHA-512(messaggio).
2. Calcola un nonce deterministico: r = SHA-512(prefisso_chiave_privata || h).
3. Calcola il punto firma: R = r·G (dove G è il punto base della curva).
4. Calcola s = r + SHA-512(R || chiave_pubblica || h)·chiave_privata mod ℓ.
5. La firma è (R, s), 64 byte in totale.

La verifica usa solo la chiave pubblica, il messaggio e la firma. Se la matematica torna, il verificatore sa che la firma è stata prodotta da chi deteneva la chiave privata corrispondente.

RSA-PSS (PKCS#1 v2.2) e ECDSA funzionano in modo simile ma con matematica sottostante diversa. Ed25519 è preferito per i nuovi sistemi perché è deterministico (nessun nonce casuale per firma da sbagliare) e più veloce.

I tre algoritmi di firma comuni

| Algoritmo | Dimensione chiave | Dimensione firma | Velocità | Note | |-----------|------------------|------------------|----------|------| | RSA-PSS-2048 | 256 byte | 256 byte | ~1000 firme/s | Ampiamente supportato, generazione chiave lenta | | ECDSA P-256 | 32 byte | 64 byte | ~30.000 firme/s | Curva NIST, richiede RNG sicuro per firma | | Ed25519 | 32 byte | 64 byte | ~50.000 firme/s | Deterministico, default moderno |

Tutti e tre sono approvati in FIPS 186-5 del NIST (2023). Ed25519 è la scelta per i nuovi protocolli: WireGuard, SSH (default da OpenSSH 8.0), Signal, firma dei commit Git e firma dei pacchetti Cargo di Rust.

Firma del codice: un caso d'uso da 100 miliardi di dollari

La distribuzione software si affida alle firme. Senza di esse, gli utenti non possono distinguere il vero installer dal malware:

• Apple Developer ID + Notarization. Tutte le app macOS devono essere firmate e notarizzate da Catalina (2019). Usa RSA-2048 o ECDSA P-256.
• Microsoft Authenticode. Eseguibili Windows firmati con certificati RSA-3072 o ECDSA P-384.
• Android APK v2/v3. Firme Ed25519 sui contenuti APK.
• Debian apt, Red Hat dnf, npm, PyPI, Homebrew. Tutti usano firme distaccate (tipicamente GPG Ed25519 o RSA) sui manifesti dei pacchetti.

Un incidente famoso: nel 2020, l'aggiornamento Orion di SolarWinds era firmato con il certificato legittimo dell'azienda dopo che gli aggressori avevano compromesso il sistema di build. La firma era valida — provava solo che il codice proveniva da una fonte compromessa. Le firme garantiscono l'identità del firmatario, non il giudizio del firmatario.

PGP e firme distaccate per i file

GnuPG (gpg) è ancora il cavallo da lavoro per le firme di file al di fuori della PKI aziendale. Una firma distaccata mantiene il file non modificato e mette la firma in un file .sig separato:

gpg --detach-sign --armor documento.pdf
# Produce documento.pdf.sig

gpg --verify documento.pdf.sig documento.pdf
# gpg: Good signature from "Alice <alice@example.com>"

Il punto debole di PGP è la distribuzione delle chiavi: come sa il verificatore che la chiave di firma appartiene davvero ad Alice? Le opzioni includono keyserver, web of trust, keybase.io, o verifica fuori banda (impronta digitale pubblicata su un biglietto da visita).

Alternative moderne: Sigstore (usato da Kubernetes, npm) esegue la firma keyless usando token di identità OIDC, con log di trasparenza che sostituiscono il web of trust. minisign di Frank Denis offre una firma Ed25519 semplice senza la complessità di PGP.

Aggregazione di hash-based signatures

Per le raccolte di file, firmare ognuno individualmente è inefficiente. Meglio: fai l'hash di ogni file, costruisci un albero di Merkle, firma la radice. Vantaggi:

• Una firma copre molti file.
• I singoli file possono essere verificati rispetto alla radice con log(n) hash fratelli.
• Usato dai log di trasparenza dei certificati, Git e sempre più dagli strumenti della supply chain software come in-toto.

Una release da 10.000 file firmata in questo modo produce una firma più un hash radice a 32 byte, verificabile rispetto a qualsiasi sottoinsieme dei file.

Timestamp: provare quando

Una firma prova chi, ma non quando. Un aggressore che ruba la tua chiave privata può retrodatare le firme. Le Trusted Timestamping Authorities (TSA) risolvono questo firmando un timestamp sulla tua firma, ancorando il tutto a un momento specifico.

Standard:

• RFC 3161 timestamping — usato da Microsoft Authenticode, firme PDF Adobe.
• RFC 5544 (CMS con timestamp).
• Roughtime — un protocollo più recente di Google per il tempo verificato a bassa latenza.

La firma di documenti legali (DocuSign, Adobe Sign, firme qualificate EU eIDAS) si basa su timestamp RFC 3161 da autorità fidate per stabilire quando è stato firmato un contratto.

Firme nel trasferimento file

La maggior parte dei servizi di trasferimento file orientati al consumatore non espone le firme direttamente — il tag di autenticazione AES-GCM prova l'integrità all'interno del trasferimento, e TLS prova l'identità del server, ma non c'è un modo incorporato per provare l'identità del mittente.

Per i trasferimenti ad alta fiducia, la firma avviene prima dell'upload:

1. Il mittente firma il file con Ed25519 o PGP, producendo file.ext e file.ext.sig.
2. Entrambi i file vengono caricati su qualsiasi servizio di trasferimento (HexaTransfer, SwissTransfer, WeTransfer).
3. Il destinatario scarica entrambi, verifica la firma con la chiave pubblica del mittente.

Questo disaccoppia l'autenticità dal meccanismo di trasferimento — il servizio di trasferimento potrebbe essere compromesso senza invalidare la firma, purché la chiave privata del mittente rimanga segreta e il destinatario abbia la chiave pubblica corretta.

Firme qualificate eIDAS dell'UE

Il Regolamento eIDAS dell'Unione Europea (UE 910/2014, rivisto nel 2024 come eIDAS 2.0) definisce tre livelli di firma:

• Firma elettronica — di base, include le firme manoscritte scansionate.
• Firma elettronica avanzata (AES/AdES) — collegata al firmatario, rileva manomissioni. Le firme PGP si qualificano.
• Firma elettronica qualificata (QES) — AdES più un certificato qualificato da un Trust Service Provider, memorizzato su un Qualified Signature Creation Device (smart card o HSM).

La QES ha lo stesso peso legale di una firma manoscritta in tutti gli Stati membri dell'UE. I fornitori includono DocuSign EU, Adobe Sign EU, Namirial e DTrust. Gli equivalenti statunitensi ai sensi dell'ESIGN Act e UETA sono meno formalmente stratificati ma funzionalmente comparabili.

Quando le firme sono superflue

Non ogni file ha bisogno di una firma. Salta quando:

• Il destinatario si fida del canale di trasferimento end-to-end (Signal, USB di persona).
• Il contenuto non è critico per la sicurezza (foto di riunioni, ricette, bozze di documenti).
• L'integrità da sola è sufficiente ed è fornita da AES-GCM o TLS.

Aggiungi le firme quando:

• Il peso legale o contrattuale è importante (contratti, prove giudiziarie, cartelle cliniche).
• La fiducia nella supply chain è in gioco (release software, aggiornamenti firmware).
• Il file verrà inoltrato attraverso intermediari non attendibili.
• Hai bisogno di una traccia di audit duratura che sopravviva al trasferimento originale.

Come metterlo in pratica

Per un flusso di lavoro semplice: genera una chiave Ed25519 con ssh-keygen -t ed25519 -f ~/.ssh/signing_key, firma un file con openssl pkeyutl -sign -inkey signing_key -in file -out file.sig, condividi la tua chiave pubblica fuori banda, e spedisci il file tramite qualsiasi servizio di trasferimento sicuro. I destinatari verificano con openssl pkeyutl -verify.

Provalo su hexatransfer.com — gratis, senza registrazione, fino a 10 GB.