Qual è la strategia comune per l'emissione di richieste OCSP

Question

Qual è la strategia comune per l'emissione di richieste OCSP

#1 da (1 voti)

0

Attualmente sto definendo un PKI per i certificati di firma del codice su un dispositivo incorporato (senza connessione Internet). Definisco il comportamento dell'emittente del certificato (autorità di rilascio FW) e del codice FW che autentificherà il certificato della chiave pubblica utilizzata per firmarlo durante l'aggiornamento FW, Voglio definire una strategia per controllare lo stato di revoca della firma del codice certificati emessi da una CA. il sistema generale funzionerà come segue:

1.firmware code shall be signed by a private key(key#1priv)

2.The public key paired with that private key(key#1pub) shall be sent in a csr (constructed by a HSM) to the CA and obtain a code signing certificate

3.CA's public key will be downloaded to the drive in a secured way

4.During FW update the FW will receive the certificate for key#1pub , authenticate it with CA's public key and then proceed with the authentication of the FW code using key#1pub

La mia domanda è:

Nel caso in cui la chiave privata della CA sia stata compromessa, dalla mia comprensione, un csr deve essere nuovamente inviato alla CA e un nuovo certificato deve essere firmato dalla chiave privata revocata. secondo quanto ho capito dalla lettura online, una richiesta OCSP deve essere inviata alla CA è l'ordine di trovare lo stato di revoca del certificato in base al suo numero di serie, come fa il richiedente il certificato a sapere quando emettere tale richiesta OCSP? in altre parole, qual è la prassi comune per i tempi di invio delle richieste OCSP alla CA?

Grazie.

public-key-infrastructure certificates certificate-authority ocsp

posta Dima Shifrin 11.06.2017 - 10:59

fonte

1 risposta

Leggi altre domande sui tag public-key-infrastructure certificates certificate-authority ocsp

Considerazioni sulla sicurezza durante l'apertura della porta per un servizio? XSS basato su DOM e il carattere "#"

score 1 · Accepted Answer

Penso che tu abbia sbagliato. Per descrivere le idee di base sull'utilizzo di un'agenzia di certificazione e di revoca:

La CA dovrebbe essere localmente attendibile sul dispositivo installando il suo certificato di origine sul dispositivo.
La CA rilascia il certificato in base al CSR.
Il dispositivo può verificare la fiducia nel certificato utilizzando il certificato radice installato localmente della CA.
La CA può revocare i certificati che ha emesso. Le informazioni di revoca sono firmate dalla CA in modo che possano essere verificate utilizzando la CA radice installata localmente.
Ma il certificato CA non può essere revocato. Poiché il certificato di origine della CA è autofirmato, la revoca sarebbe stata firmata dalla chiave privata della CA stessa, ma il certificato di origine dovrebbe essere revocato perché proprio questa chiave privata è compromessa, il che significa che non ci si può fidare di nulla firmato con questa chiave. Ciò significa che se la CA viene compromessa, è necessario rimuoverla come attendibile dal dispositivo. Vedi Come vengono gestite le revoche di CA root? e < a href="https://security.stackexchange.com/questions/90254/can-a-rootca-be-revoked"> Può essere revocata una RootCA? per ulteriori informazioni.

Quindi, non c'è modo di verificare la revoca della CA.
Ma si può controllare la revoca del certificato rilasciato dalla CA. Questo dovrebbe essere fatto ogni volta che viene utilizzato il certificato, ad esempio ogni volta che la firma è verificata nel tuo caso. Poiché ciò potrebbe essere troppo spesso le risposte OCSP e gli elenchi di revoche di certificati (CRL) hanno un certo tipo di tempo di vita e potresti riutilizzare l'ultimo risultato finché è ancora considerato valido.