La selezione della forza di bit di un certificato figlio deve essere influenzata dalla CA o dalla catena?

Sembra che tu stia facendo 2 domande:

C'è qualche vantaggio se il certificato dell'entità finale ha uno spazio chiave più ampio rispetto alle CA nella catena di firma

Sono d'accordo con gli altri utenti che il risultato è misto - ma voglio suddividerlo nelle tipiche funzionalità di sicurezza:

• Riservatezza: se si utilizza la coppia di chiavi dell'entità finale per la riservatezza (crittografia delle chiavi durante l'installazione di SSL, crittografia dei dati per l'archiviazione o la trasmissione), si ottiene il beneficio della chiave più grande indipendentemente da ciò che sta facendo il firmatario CA . La rottura della crittografia è interamente correlata alla ricerca della chiave privata (o alla ricerca di una debolezza nell'algoritmo)
• Integrità: se si utilizza la coppia di chiavi dell'entità finale per la firma dei dati, il cracking della firma è collegato alla forza della propria chiave. Tuttavia, i controlli di integrità sono spesso combinati con i controlli di autenticazione - vedi sotto.

• Autenticazione: ecco il problema. Le tue capacità di autenticazione / non ripudio diminuiscono se la chiave privata della CA è più facile da indovinare. Se riesco a trovare la chiave privata della tua CA a causa dello spazio della chiave più piccolo, allora posso fingere di essere la tua CA e posso creare un certificato e una coppia di chiavi di qualsiasi dimensione che assomigli a tu e abbia una chiave coppia che controllo. Questo praticamente spara autenticazione al piede. Non verrà catturato da un elenco di certificati CA attendibili poiché l'autore dell'attacco emula uno di questi certificati trusted trusted. E sarà difficile da rilevare fino a quando non verrà trovata l'interruzione. Inoltre, la revoca di una CA è dolorosa. O si dovrebbe avere un controllo dello stato del certificato in ogni sistema di consumo che controlla lo stato dell'entità finale e della catena CA, oppure è necessario revocare ogni entità finale valida emessa dalla CA. Ciò diventa ancora più difficile se stiamo parlando di un piccolo spazio chiave in un certificato radice autofirmato. Non c'è modo di verificare lo stato della radice. Il sistema CA dovrebbe emettere un'enorme avvertenza pubblica e fare in modo che una qualsiasi parte relying rimuova la radice e tutte le CA secondarie dai propri negozi attendibili.

• Disponibilità: quando penso alla disponibilità in PKI, penso all'uso di PKI per il controllo di autenticazione / accesso per rendere i servizi disponibili solo agli utenti privilegiati. In tale ottica, la disponibilità viene ripresa tanto quanto l'autenticazione.

Quindi, il sommario - per cosa stai usando il certificato? Se la usi solo per riservatezza e integrità pura, non sei così male. Ma tieni presente che spesso i meccanismi di protezione PKI mescolano queste categorie. L'autenticazione client o server SSL è sia un modo per impostare un canale sicuro (riservatezza) e un modo per controllare l'identità del server (autenticazione). Le firme di posta elettronica sono sia un modo per comprovare la trasmissione (integrità) sia una prova che la trasmissione proviene dal mittente (autenticazione). Diventa pungente rapidamente.

Domanda successiva ...

È utile o addirittura possibile che la mia entità finale abbia una validità più lunga della CA che l'ha emessa?

Nei sistemi PKI su cui ho lavorato - assolutamente no - i certificati dell'entità finale non possono essere emessi come un periodo di validità più lungo della durata del certificato CA.

Tornando indietro dall'esperienza reale, tuttavia, sto esaminando la RFC per i certificati X509: link

Section 6.1.3  Basic Certificate Processing

include la verifica delle date di validità per ciascun certificato nella catena.

Questa sezione è parte di:

6.1  Basic Path Validation

   This text describes an algorithm for X.509 path processing.  A
   conformant implementation MUST include an X.509 path processing
   procedure that is functionally equivalent to the external behavior of
   this algorithm.  However, support for some of the certificate
   extensions processed in this algorithm are OPTIONAL for compliant
   implementations.  Clients that do not support these extensions MAY
   omit the corresponding steps in the path validation algorithm.

Quindi dovrebbe essere fatto per ogni certificato nel percorso (cioè, l'entità finale, ogni CA di firma e il Root)

I controlli di validità non sono un'estensione FACOLTATIVA, sono richiesti parte del certificato.

SE il sistema sta facendo correttamente la validazione del percorso, avere una validità più lunga sul certificato dell'entità finale non dovrebbe essere buono. Non ho guardato più lontano per vedere se è permesso. Credo che i sistemi CA che ho testato abbiano un'impostazione che non lo consente, ma penso anche che con un certo grado di creatività potrei essere stato in grado di generare un certificato che ha rotto questo stampo. Tenete presente, tuttavia, che lo stavo facendo con il privilegio di amministratore sys e forse anche con i meccanismi di test white box che non dovrebbero essere disponibili in una CA consolidata. Lo facevo anche più di 10 anni fa con le CA che oggi non sono più sul mercato - il chilometraggio può variare.

Risposta breve: Sì, c'è un potenziale vantaggio per le entità finali di scegliere una chiave pubblica più grande della chiave pubblica della CA.

La domanda non è del tutto chiara, ma presumo che la tua situazione sia che la root o il genitore usi una chiave RSA a 1024 bit (cioè, il cert dell'entità finale è firmato con una chiave RSA a 1024 bit), e la fine -entity utilizza una chiave RSA a 2048 bit (ovvero, la chiave pubblica certificata e utilizzata dall'host finale è una chiave RSA a 2048 bit).

In questa situazione, posso vedere due potenziali vantaggi per la sicurezza nell'utilizzo di un certificato di entità finale a 2048 bit invece di un certificato di entità finale a 1024 bit:

• Sei sicuro contro un utente malintenzionato che può violare RSA a 1024 bit, ma non può violare RSA a 2048 bit e può solo intercettare ma non può (o non è disposto a) manomettere attivamente le connessioni. In confronto, se hai usato una chiave RSA a 1024 bit, un tale aggressore potrebbe recuperare la tua chiave privata RSA, intercettare le connessioni e decrittografare il traffico crittografato.

• Sei al sicuro contro un utente malintenzionato che, tra cinque anni, interrompe RSA a 1024 bit ma non può rompere RSA a 2048 bit, supponendo che la transizione CA a RSA a 2048 bit nei prossimi anni (come molti CA stanno facendo e molti browser richiedono). Ciò è dovuto al fatto che un utente malintenzionato che è in grado di ripristinare la chiave di firma a 1024 bit della CA tra cinque anni non guadagna nulla in questo modo, se quella chiave non è più valida. La chiave di firma della CA non aiuta l'hacker a decifrare qualsiasi traffico crittografato con SSL a cui possa avere accesso (nemmeno il vecchio traffico che ha registrato molto tempo fa). L'unica cosa che un utente malintenzionato può fare con la chiave di firma di una CA è firmare un nuovo certificato falso e usarlo per montare un attacco man-in-the-middle sugli utenti, ma se il cert root della CA e la chiave pubblica a 1024 bit non è più accettato dai browser tra cinque anni, non aiuta affatto l'aggressore: è troppo tardi.

[Inoltre, potrebbero esserci alcuni vantaggi di gestione chiave nella scelta di una chiave a 2048 bit ora e poter continuare a usarla per diversi anni, anche se devi rinnovare il tuo cert per farlo, invece di dover cambiare le chiavi in un anno o due. Per essere chiari, questo non è un vantaggio per la sicurezza; è solo un potenziale beneficio logistico, a seconda di quanto fastidioso lo trovi dover cambiare le tue chiavi ad un certo punto in futuro.]

In conclusione: potrebbero esserci dei vantaggi nella scelta di una chiave dell'entità finale più grande della chiave della CA. Tuttavia, non voglio affermare che il vantaggio sia schiacciante, o che la dimensione della chiave pubblica dell'entità finale sia tutto ciò che conta. Contro un potente aggressore che è in grado e disposto a montare attacchi attivi e che può violare RSA a 1024 bit entro la durata di validità del certificato di root della CA, probabilmente stai hosed indipendentemente dalla dimensione della chiave pubblica che scegli.

Ci sono due tipi di attacco che un attaccante può provare a montare:

• attacco attivo: l'attaccante si intromette con i pacchetti di dati al momento ci si connette al server (eventualmente fino a correre il suo proprio server falso completo). Per fare questo, l'attaccante deve essere in grado di rompere una delle chiavi pubbliche in questo momento (del server o il tasto di uno dei CA).

• Attacco passivo: l'attaccante registra i pacchetti di dati, ma non li modifica. Successivamente, l'utente malintenzionato tenta di interrompere qualsiasi chiave utilizzata per la crittografia, per svelare i dati in chiaro. Nel caso di SSL / TLS con una delle suite di crittografia "RSA" ( non il Suite "DHE_RSA", la violazione della chiave pubblica RSA del server è sufficiente per decrittografare l'intera sessione.

Il punto importante è che la rottura della chiave di una CA in seguito non dà alcun vantaggio all'aggressore (lo aiuta solo per le sessioni di attacco che si verificano dopo la rottura) . Tuttavia, rompendo la chiave del server stesso può aiutarlo a decifrare le sessioni registrate in precedenza. Pertanto, i vincoli di sicurezza sulla chiave del server sono in realtà più stringenti rispetto alla chiave CA; ha quindi senso usare una chiave più grande per il server stesso.

(Le suite di crittografia "DHE" utilizzano la chiave del server solo per una firma, che trasferisce il problema alla chiave Diffie-Hellman effimera che il server decide di utilizzare per lo scambio di chiavi effettivo. utilizzare un tasto DH che sia più strong della propria chiave RSA o delle chiavi CA.)

Se un utente malintenzionato desidera impersonare il tuo sito, può farlo tentando di violare la chiave dell'entità finale o può rompere una delle chiavi CA della firma, il che consentirebbe loro di rilasciare i propri certificati di entità finale per qualsiasi dominio, incluso il tuo. Contro questo attacco, la catena di sicurezza è strong quanto il suo anello più debole.

Se un utente malintenzionato desidera leggere il traffico crittografato con SSL dal tuo sito, l'utente malintenzionato deve compromettere la chiave dell'entità finale; compromettere una chiave CA non aiuta qui. Se sei preoccupato per questo attacco, potrebbe avere senso avere una chiave di entità finale più lunga. Inoltre, tieni presente che questo particolare attacco può essere prevenuto con l'uso di cifrarie effimere DH, con un certo costo in termini di prestazioni.

Come per avere un certificato di entità finale con un periodo di validità più lungo di un certificato di firma, ci sono diversi possibili problemi lì. In primo luogo, una CA potrebbe non essere nemmeno d'accordo a emettere un tale certificato; può troncare il periodo di validità a quello del suo certificato di base. In secondo luogo, anche se è stato emesso un certificato, la catena non verrebbe verificata non appena fosse scaduto il primo cert della catena. Ci può essere un'eccezione a questo nel caso di un certificato firmato direttamente da una radice attendibile.

Se la lunghezza della chiave del sito Web è la stessa della chiave CA, l'utente malintenzionato può attaccare la chiave del sito Web poiché è necessario ottenere più valore con lo stesso sforzo. Il motivo è che tutti i dati crittografati precedentemente (e futuri) possono essere decifrati. Ciò consente anche attacchi MITM.

Tuttavia, se la chiave del sito Web è più grande della chiave CA, è più probabile che l'autore dell'attacco attacchi semplicemente la chiave CA, e in tal caso sono possibili solo gli attacchi MITM. Tutti i dati precedentemente crittografati con la chiave del sito web sono ancora al sicuro. Tutti i dati futuri potrebbero essere vulnerabili agli attacchi MITM.

1. CA convalida il tuo certificato, non ha nulla a che fare con la tua connessione sicura con il tuo cliente, quindi il tuo extra bit-length sarebbe vantaggioso per la tua connessione. Se un utente malintenzionato irrompe nella CA, può solo tentare MITM sui client e non rompere il codice.

2. Sì, è possibile. CA rinnoverà il suo certificato appena possibile.