Firma (crittografica)

Una firma crittografica è una breve stringa di byte che dimostra che un messaggio specifico è stato prodotto da qualcuno in possesso di una chiave privata, senza rivelare la chiave privata. La verifica della firma richiede solo la corrispondente chiave pubblica (per gli algoritmi asimmetrici) o il segreto condiviso (per quelli simmetrici).

Il flusso asimmetrico di base (usando RSA, ECDSA o Ed25519):

1. Il firmatario calcola l’hash del messaggio (tipicamente SHA-256).
2. Il firmatario cifra l’hash con la propria chiave privata. Output: la firma.
3. Il verificatore calcola l’hash del messaggio ricevuto con la stessa funzione di hash.
4. Il verificatore decifra la firma con la chiave pubblica. Output: un hash.
5. Se i due hash corrispondono, la firma è valida e il messaggio non è stato manomesso.

Le firme simmetriche (HMAC) usano un segreto condiviso invece di una coppia di chiavi. Il firmatario e il verificatore possiedono entrambi il segreto; entrambi calcolano HMAC(segreto, messaggio) e confrontano. Più veloci delle firme asimmetriche; utili solo quando le parti si fidano già l’una dell’altra (non si vuole HMAC per la verifica di terze parti perché chiunque possieda il segreto può falsificare firme).

Dove compaiono le firme nello stack operativo: token JWT (il terzo segmento), catene di certificati TLS, code signing (notarizzazione Apple, Windows Authenticode), commit e tag Git (firmati con GPG), transazioni Bitcoin, distribuzione di pacchetti software (gestori di pacchetti Linux, formule Homebrew). Ogni contesto abbina la firma a uno specifico algoritmo e a una storia di gestione delle chiavi; il primitivo sottostante è lo stesso.

Firme post-quantum e la migrazione imminente: RSA, ECDSA ed Ed25519 sono tutti vulnerabili all’algoritmo di Shor su un computer quantistico sufficientemente grande. Il programma di crittografia post-quantum del NIST ha selezionato tre schemi di firma nel 2024 — ML-DSA (Dilithium), SLH-DSA (SPHINCS+) e FN-DSA (Falcon) — come sostituzioni nella traccia degli standard. Le macchine quantistiche reali abbastanza grandi da rompere RSA a 2048 bit non esistono ancora, ma i sistemi crittografici con lunghi cicli di vita (certificati radice, chiavi di code signing per software archiviato, backup cifrati destinati a rimanere riservati per decenni) stanno migrando preventivamente. Le firme ibride (classiche + post-quantum) sono la tipica strategia di transizione. Riferimento: NIST — Post-Quantum Cryptography Standardization.

Esempio pratico

Firma il messaggio "transfer $100 to alice" con una chiave Ed25519. Primo passo: calcola l’hash del messaggio con SHA-512 producendo un digest di 64 byte. Secondo passo: l’algoritmo Ed25519 combina quel digest con lo scalare della chiave privata a 32 byte tramite generazione deterministica del nonce (RFC 8032), producendo una firma a 64 byte (R, s). Terzo passo: chiunque possieda la chiave pubblica a 32 byte può verificare ricalcolando il punto sulla curva e controllando che l’equazione sB = R + H(R, A, M) · A sia valida. La firma è breve (64 byte) e la verifica è rapida (~50 µs su una CPU moderna). La cosa fondamentale è che Ed25519 è deterministico — firmare lo stesso messaggio con la stessa chiave due volte produce byte identici. La firma RSA-2048 dello stesso messaggio produrrebbe una firma a 256 byte; ECDSA su P-256 produrrebbe ~71 byte con codifica DER. La scelta dell’algoritmo bilancia dimensione della firma, velocità di verifica e compattezza della chiave.

Quando e perché è importante

L’uso improprio delle firme è la vulnerabilità crittografica più comune dopo l’hashing delle password. Gli errori classici: firmare un blob JSON la cui forma canonica è ambigua (riordinare le chiavi cambia i byte e rompe la firma, o peggio, consente a un attaccante di creare due messaggi semanticamente diversi con gli stessi byte), usare un nonce ECDSA deterministico ripetuto su due messaggi (che rivela la chiave privata — è così che la chiave master della PlayStation 3 è stata estratta nel 2010), e accettare firme senza verificare che il campo algoritmo corrisponda a quello atteso (la classe di vulnerabilità “alg: none” nelle prime librerie JWT). Le regole difensive: blocca l’algoritmo sul verificatore, canonicalizza il messaggio prima dell’hash (usa COSE/JOSE, non JSON ad hoc), preferisci Ed25519 a ECDSA per il nuovo codice, e conserva le chiavi private in HSM o enclave supportate da hardware quando il modello di minaccia lo giustifica. Riferimento: RFC 8032 — Edwards-Curve Digital Signature Algorithm (EdDSA).