Quanti certificati può generare un CA prima che la sua chiave segreta sia rinnovata?

Questa è una grande opportunità per mettere a fuoco le basi di come funzionano le CA. Presumo che stiamo parlando di CA radice qui, dal momento che il rinnovo di una CA subordinata non è davvero un grosso problema.

How often do CA's renew the keys, and under what circumstances (number of certificates issued, time, etc.)?

Ripeterò questa domanda:

What factors increase an attacker's likelihood of cracking the CA's private key?

Supponendo che non stiamo parlando di hack, backdoor, minacce interne, ecc. e parliamo solo di cracking basato su informazioni pubbliche, allora la risposta è: scelta dell'algoritmo, dimensione della chiave e quantità di tempo.

Il calcolo è simile a questo: diciamo che scegliamo RSA-4096, quindi dovremmo cercare il runtime degli attacchi più noti contro RSA, cercare i costi per l'affitto di quella quantità di potenza di calcolo su Amazon, fare qualche legge di Moore calcoli e indovina per quanto tempo ci vorrebbe un attaccante per romperlo. Risulta per RSA ed ECC che gli attacchi più noti richiedono solo la chiave pubblica; una firma perde zero informazioni sulla chiave privata, quindi vedere molte firme non aiuta.

Si noti che questo non è vero per alcuni degli algoritmi di firma post-quantici. In particolare con le firme basate su hash [ article1 ], [ article2 ], le chiavi private sono essenzialmente enormi raccolte di chiavi monouso in cui ogni firma rivela una chiave privata. Una volta che il worlf passa alla crittografia post-quantistica, la tua domanda diventerà molto più pertinente.

In the case that a CA needs to renew its key pair, what happens with the previous certificates that are still valid? are these signed again under the new key?

Questo è davvero un problema fondamentale nel modo in cui le CA sono progettate. Ho visto che viene gestito in due modi diversi:

1. La CA semplicemente non emetterà certs che sopravvivono. Supponiamo che tu abbia una CA che emette certificati di 1 anno. Quando la CA stessa ha meno di un anno su di essa, si alzerà in piedi una nuova CA di emissione. La vecchia CA è ancora in giro per controlli di revoca e cose, ma non rilascia più nuovi certificati.

2. Certificare in modo incrociato la vecchia CA con quella nuova in modo che durante la convalida di un certificato emesso dalla vecchia CA, esso venga associato alla CA corrente. Questo è un po 'hacky perché c'è tecnicamente una CA scaduta nella catena. La maggior parte dei motori TLS non supporta questo tipo di cose, quindi l'ho visto solo in ambienti chiusi come l'e-mail aziendale o i sistemi di badge ID in cui si ha maggiore controllo sui client.

A causa dell'interruzione del rollover su una CA radice, si desidera che sia valida per un lungo periodo di tempo. Una rapida occhiata ai certificati radice del mio browser mostra i certificati di 15 anni, i certificati di 20 anni e anche alcuni certificati di 30 anni.

Non penso che ci sia un limite tecnico, in termini di standard x509 come pubblicato da ISO / IEC / ITU-T (non ho una copia di ISO 9594-8 per confermare che, se qualcuno lo fa, può per favore controlla questo?). Tuttavia, secondo RFC 5280 : "il numero di serie DEVE essere un numero intero positivo" e "Le CA conformi NON DEVONO utilizzare i valori serialNumber" più di 20 ottetti ", quindi un singolo certificato CA può emettere 2 certificati ¹⁵⁹ -1 discendenti diretti con numeri di serie univoci conformi a RFC 5280.

In pratica, ogni CA ha spesso limiti di implementazione sulla propria infrastruttura che limita ulteriormente ciò che sarà effettivamente in grado di generare. Tuttavia, le implementazioni non CA possono trattare il campo del numero di serie come un BLOB, in modo che siano in grado di gestire anche numeri seriali di dimensioni eccessive o errate.

In termini di gestione dei rischi aziendali, è senz'altro saggio che una CA limiti il numero di certificati che possono essere emessi da un singolo certificato radice o intermedio. In questo modo, se, per qualsiasi motivo, devono revocare il certificato root o intermedio, dovranno solo riemettere un numero inferiore di certificati anziché cosa è successo a Symantec , in cui un problema con una delle sue filiali fa sì che il i certificati per la loro intera base di utenti devono essere revocati, in quanto i browser non sono in grado di distinguere tra i certificati emessi dalle controllate problematiche rispetto ai certificati emessi dalle filiali conformi.

In sostanza ti stai chiedendo quanto sia necessario testo in chiaro per arrivare alla chiave privata quando fai una firma RSA o ECDSA, perché hai il certificato e l'hash (algoritmo di firma dell'input) e la firma (output). Attualmente non esiste un attacco praticamente fattibile contro queste firme quando si usano dimensioni di chiavi comuni. Ciò significa che cercare di ottenere la chiave privata della CA dai certificati rilasciati non è un problema nella pratica, indipendentemente da quanti certificati siano stati emessi.

Ancora, (sub-) i certificati CA saranno rinnovati di volta in volta anche perché sono scaduti o perché l'algoritmo della firma utilizzato per firmare la CA è ritenuto non sicuro.

How often do CA's renew the keys, and under what circumstances (number of certificates issued, time, etc.)?

la domanda non ha senso Il periodo di rinnovo della chiave CA dipende da diversi fattori. Ad esempio, dimensioni della chiave, sicurezza della chiave, dimensioni CRL. Non esiste una correlazione diretta tra il rinnovo della chiave CA e un numero di certificati firmati.

what happens with the previous certificates that are still valid? are these signed again under the new key?

no, i certificati precedentemente emessi non vengono riscritti dalle nuove chiavi CA. Tecnicamente, il rinnovo della chiave CA implica una nuova CA con un nome di corrispondenza "accidentale".