Quali sono le chiavi di crittografia asimmetriche?

La crittografia asimmetrica, nota anche come crittografia a chiave pubblica, si basa su una coppia matematicamente collegata di chiavi: una pubblica e una privata. La chiave pubblica è condivisa apertamente - utilizzata da chiunque per crittografare i messaggi o verificare le firme digitali. La chiave privata è tenuta segreta dal suo proprietario per operazioni di decifrazione o firma.

Gli algoritmi più utilizzati sono RSA (Rivest-Shamir-Adleman) e ECC (Elliptic Curve Cryptography). RSA si basa sulla difficoltà pratica di factoring di grandi prodotti primi, mentre ECC sfrutta la struttura algebrica delle curve ellittiche sui campi finiti per una sicurezza equivalente con dimensioni molto più piccole.

Capire che la crittografia asimmetrica non è solo una curiosità matematica, ma la roccia delle comunicazioni sicure, tutto da HTTPS a crittografia via email (PGP) per bloccare i portafogli della catena, aiuta a capire perché la gestione del ciclo di vita chiave è mission-critical.

Il ciclo di vita delle chiavi di crittografia

Il ciclo di vita di una coppia di chiavi di crittografia asimmetrica si estende dalla generazione iniziale alla distruzione definitiva sicura. Ogni fase introduce rischi specifici che devono essere affrontati in modo proattivo.

1. Generazione chiave

La generazione di chiavi è la base della sicurezza crittografica. Il processo deve utilizzare un generatore di numeri casuali crittografico (CSPRNG) per garantire imprevedibilità. Debole casualità—sia da un algoritmo difettoso, valori prevedibili di seme, o problemi di entropia hardware—può rendere la coppia chiave breakable anche se il problema matematico sottostante rimane duro.

Per RSA, la generazione prevede la selezione di due grandi prime indipendenti (di solito 2048 bit o più grandi), l'elaborazione del prodotto [n], e la derivazione di esponenti pubblici e privati. Per ECC, il generatore seleziona un integer casuale all'interno di un ordine di curva definita.

Un dettaglio spesso sovrapposto è che le chiavi devono essere generate con uno scopo specifico e una vita in mente. Una chiave destinata alla firma del codice dovrebbe avere parametri diversi di uno utilizzato per l'autenticazione del server TLS. Tagging chiavi con metadati (proprietario, scopo, data di creazione, scadenza) dal momento della generazione semplifica le operazioni del ciclo di vita futuro.

2. Distribuzione chiave

Mentre la chiave privata non è mai distribuita, la chiave pubblica deve essere consegnata a tutte le parti che ne hanno bisogno. La sfida critica qui è garantire la [autennticity[[[]]] della chiave pubblica: il ricevitore deve essere certo che la chiave appartiene veramente all'entità rivendicata.

La soluzione standard utilizza Public Key Infrastructure (PKI) con certificati digitali rilasciati da Autorità di certificazione (CA). Un certificato lega l'identità di un'entità (ad esempio, un nome di dominio o un nome di organizzazione) alla sua chiave pubblica, firmato dalla chiave privata della CA. Tuttavia, la sicurezza dell'intero PKI dipende dalla gestione del ciclo di vita chiave della CA, come visto in passato CA compromessi (ad esempio, DigiNotar, Como).

Le alternative a PKI per la distribuzione chiave includono il web OpenPGP del modello di fiducia e l'approccio Trust-on-first-use del Protocollo Signal (TOFU) . Ciascuno ha i trade-off tra scalabilità e presupposti di sicurezza. Indipendentemente dal metodo, la fase di distribuzione è dove si manifestano molti attacchi, come lo spoofing DNS per reindirizzare a un server chiave falso o fronting di dominio per confondere i percorsi di fiducia.

3. Utilizzo chiave

Durante la fase di utilizzo, la coppia chiave è attivamente utilizzata: chiave pubblica per la crittografia o la verifica della firma, chiave privata per la decrittografia o la firma. La sicurezza di questa fase spesso si incerna su come la chiave privata è protetta mentre è in uso. Se un aggressore ottiene l'accesso alla memoria del sistema mentre la chiave privata è caricata, possono copiarla.

Per la decrittazione, la chiave privata deve essere disponibile online (ad esempio, in un server TLS che termina HTTPS). Questo crea una finestra di vulnerabilità, se il server è compromesso, la chiave può essere esfiltrata. Le mitigazioni includono l'utilizzo di chiavi di sessione con brevi vite e non persistono la firma a lungo termine di chiave privata al di là della stretta iniziale, o l'utilizzo di architetture TLS keyless dove le chiavi private.

Per le operazioni di firma (codifica, firma dei documenti, autorizzazione delle transazioni), la chiave privata dovrebbe essere idealmente archiviata offline e accessibile solo tramite un'interfaccia sicura con l'approvazione fisica o multi-fattore. Il recente furto di certificati di firma del codice utilizzati nell'attacco SolarWinds ha mostrato i devastanti effetti di fuga di un compromesso chiave di firma—gli attacchi potrebbero firmare aggiornamenti dannosi come legittimi.

4. Rotazione chiave e scalo

La rotazione chiave è il processo di recedere una coppia chiave esistente e generarne una nuova dopo un periodo o un evento predeterminato. I vantaggi sono duplice: limita la quantità di dati crittografati sotto una singola chiave (riduzione dell'impatto di un compromesso futuro), e costringe il sistema a ristabilire la fiducia in una coppia di chiavi fresche.

Le date di scadenza sono incorporate nei certificati X.509 per far rispettare la rotazione. Quando un certificato scade, la coppia chiave diventa tecnicamente invalida ai fini di tale certificato, anche se le chiavi crittografiche possono ancora essere valide.

Per la terminazione TLS, il nuovo certificato e la coppia chiave devono essere implementati prima della scadenza del vecchio, con la sovrapposizione della validità consentita.Per la crittografia, i dati crittografati sotto la vecchia chiave pubblica devono essere ri-crittografati sotto la nuova chiave dopo una finestra di migrazione. Questo è particolarmente impegnativo per ambienti di dati memorizzati a lungo termine. Alcuni sistemi utilizzano un approccio ibrido: una chiave di crittografia KK (chiave) che consente di crittografare i tasti di rotazione dei dati

5. Rivocazione e distruzione chiave

La ragione più comune è il sospetto o la conferma del compromesso chiave privato. Altri trigger includono la partenza dei dipendenti, l'algoritmo deprecato come non sicuro (ad esempio, passando da SHA-1 a SHA-256 nei certificati), o le modifiche di politica organizzativa. La revoca richiede una trasmissione tempestiva e affidabile: in PKI, in Certificati di revoca (CRL) e nei codici di controllo di stato online (CRL).

I CRL possono essere grandi e intensivi e la gestione del browser dei controlli di revoca varia ampiamente. Molti browser oggi si affidano a CRLite o alle banche dati di revoca aggregata per motivi di performance. Il mancato raggiungimento di tutte le parti in carica nel tempo ha portato a incidenti in cui i certificati compromessi sono rimasti attendibili per giorni o settimane.

La distruzione sicura della chiave privata non è più necessaria, sia per rotazione, revoca o decommissione, è il passo finale. Semplicemente la cancellazione del file può lasciare i resti recuperabili sul disco. NIST SP 800-88 raccomanda la cancellazione crittografica: sovrascrivendo la chiave con zero o utilizzando meccanismi di distruzione chiave hardware in HSMs che zero fisicamente il materiale recuperato al comando.

Migliori pratiche di gestione

La gestione efficace del ciclo di vita richiede politiche sistematiche e controlli tecnici applicati in tutte le fasi.

Deposito sicuro

Le chiavi private non devono mai essere memorizzate in testo normale su disco o in file di configurazione dell'applicazione. Lo standard del settore è un modulo di sicurezza hardware (HSM) - un dispositivo fisico resistente alle manomissioni che genera, memorizza e utilizza chiavi private senza mai esporre al sistema host.

L'accesso chiave dovrebbe essere limitato solo ai processi e agli utenti che lo richiedono assolutamente, utilizzando l'autenticazione robusta (ad esempio, l'accesso basato sul ruolo, l'autenticazione multifattore per le operazioni amministrative).Per chiavi ad alto valore (chiavi di base CA, chiavi di firma del codice), prendere in considerazione l'autorizzazione multi-partita in cui due o più amministratori devono approvare qualsiasi operazione di utilizzo chiave.

Rotazione regolare

Strumenti come Certbot (Critto di Let) rinnovano automaticamente i certificati TLS ogni 60–90 giorni. Per PKI interni, utilizzare Azure Key Vault o HashiCorp Vault per applicare i programmi di rotazione e integrare con le piattaforme di gestione del ciclo di vita del certificato. La rotazione dovrebbe anche attivare la ri-crittografia di qualsiasi dato che è stato crittografato sotto la vecchia chiave, questa è spesso la parte più difficile e deve essere pianificata in anticipo nel sistema.

Frequenze di rotazione del documento per tipo di chiave: chiavi TLS ogni anno; chiavi di codice ogni 2-3 anni; chiavi CA root ogni 5-10 anni (ma le chiavi subordinate che firmano possono ruotare più frequentemente).

Distribuzione chiave autentica

Per le chiavi pubbliche, ottenere certificati da CA affidabili e utilizzare la Trasparenza del Certificato per rilevare la dissoluzione. Per le chiavi interne, distribuire una CA privata con una chiave di root strettamente gestita. Distribuire certificati o chiavi pubbliche tramite repository firmato, gestione di endpoint sicuro (ad esempio, spinte MDM), o impronte digitali verificate manualmente (per gruppi di fiducia più piccoli). Evitare di usare semplicemente HTTP, e-mail senza crittografia chiave non autenticata.

Il certificato di implementazione, se del caso, è a conoscenza del rischio operativo: la mancanza può causare interruzioni e la pinning non protegge dal compromesso del server pinned. Un'alternativa è quella di utilizzare le intestazioni Expect-CT e Expect-Staple per far rispettare i controlli di revoca e la trasparenza del certificato senza incodifica.

Monitoraggio e verifica

Centralizzare i log per tutti gli eventi chiave del ciclo di vita: generazione, distribuzione, utilizzo, rotazione, revoca e distruzione. Utilizzare un sistema di sicurezza Information and Event Management (SIEM) per correlare gli eventi chiave con altre telemetrie di sicurezza. Ad esempio, un improvviso aumento dei tentativi di decrittazione falliti può indicare una chiave che viene testata da un aggressore.

Controlla regolarmente l'inventario chiave: quali chiavi esistono, chi li possiede, quando sono stati generati, quando scadono, e se sono ancora necessari. Molte organizzazioni soffrono di "sfioramento chiave"—centri di certificati non utilizzati che ingombrano i depositi di fiducia o i server, ogni potenziale rischio.

Eseguire test di penetrazione periodici specificatamente mirando a punti deboli di gestione chiave: prova per la capacità di leggere chiavi private da dump di memoria, verificare che i certificati revocati non possono essere ripristinati, e confermare che la distruzione chiave rende effettivamente la chiave irrecuperabile.

Pianificazione di risposta incidente per il compromesso chiave

Non importa quanto sia robusta la gestione del ciclo di vita, rimane la possibilità di un compromesso chiave. Ogni organizzazione dovrebbe avere una cartella di gioco che risponde: Come si rileva un compromesso chiave? (ad esempio, certificati inattesi rilasciati, login impossibili con firme forgiate). Come lo conterremo? (Richiesta immediatamente il certificato, genera nuove chiavi, notifica le parti interessate).

Passi pratici: pre-generare elenchi di revoca offline per la vostra CA privata, mantenere liste di contatti di tutte le parti di affidamento, e testare il processo di revoca almeno ogni anno. Per i servizi cloud, capire come il fornitore gestisce il compromesso chiave e quali accordi di livello di servizio si applicano.

Conclusioni

Il ciclo di vita delle chiavi di crittografia asimmetriche – di generazione in distruzione sicura – è un ciclo continuo di fiducia e di rischio. Ogni fase introduce vulnerabilità che, se ignorate, possono ridurre la crittografia più forte. Adottando best practice come lo storage basato su HSM, la rotazione automatizzata, la distribuzione autenticata e l'audit approfondito disciplina, le organizzazioni possono mantenere l'integrità e la disponibilità dei loro sistemi crittografici.