Come gestire correttamente i CRL nelle firme elettroniche a lungo termine?

Question

Come gestire correttamente i CRL nelle firme elettroniche a lungo termine?

#1 da (4 voti)

3

Che cos'è un modo consigliato di gestire CRL s nelle firme elettroniche a lungo termine (in particolare CAdES-A )?

Il problema che vedo è che CRL s non è protetto da modifiche (sono in testo semplice, non firmato) e non è nemmeno obbligatorio in CAdES-T o CAdES-A .

In quanto tali, possono essere falsificati e tale falsificazione non può essere facilmente rilevata, se l'autorità di timestamp utilizzata ( TSA ) non è più attiva. Non riesco a capire un modo di gestire CRL s in modo da evitare dubbi sulla validità a lungo termine di un documento con timestamp con CAdES-A .

Lo stesso problema che ho con la verifica dell'affidabilità di TSA s stessi, se non esistono più.

Uno scenario tipico che mi preoccupa è questo:

Un utente malintenzionato può utilizzare la propria autorità di timestamp (= non attendibile) per falsificare un indicatore di data ( CAdES-T o CAdES-A ) di un documento. Nessuno sarà ora in grado di verificare se questo% diTSA ora irraggiungibile è stato considerato attendibile o meno al momento in cui il timbro sembra essere emesso. Per creare una parvenza di credibilità, l'utente malintenzionato può aggiornare il timestamp con un timestamp valido di un TSA attendibile e attendere diversi anni. L'aggiornamento del timestamp è possibile a causa del fatto che i timestamp possono essere emessi automaticamente senza verifica della credibilità dei timestamp precedenti.
In base a un principio simile, un utente malintenzionato può utilizzare un certificato revocato di un'autorità di timestamp attendibile. Può anche allegare un CRL modificato dal quale elimina il codice S / n del certificato timestamp utilizzato (che è possibile poiché CRL non è firmato). In questo modo, l'attaccante può creare una serie di timestamp da diversi TSA s. È possibile che dopo 10 anni almeno uno dei TSA s non esista e nessuno sarà in grado di ricevere il suo CRL non modificato corretto per verificare la validità del timestamp.

Sfortunatamente, le specifiche di firma a lungo termine non trattano questi problemi in dettaglio, o piuttosto non li menzionano affatto. Ad esempio in rfc5126 , specialmente nelle sezioni C.4.1.1 e C.4.3.

Modifica

(Un'altra sotto-domanda è stata spostata qui .)

certificate-revocation timestamp

posta xarx 02.04.2014 - 21:20

fonte

1 risposta

Leggi altre domande sui tag certificate-revocation timestamp

Come prevenire l'attacco di Starvation DHCP? Heartbleed: questo scenario è possibile? quanto male sarebbe?

score 4 · Accepted Answer

Un CRL è un oggetto firmato, proprio come un certificato. Questo è il motivo per cui non devono essere coperti dalla firma del documento reale. Tuttavia, per l'archiviazione a lungo termine, devono essere timestamp.

Lo sfondo teorico è il seguente:

In un dato momento T , puoi convalidare i certificati e verificare le firme usando il CRL appena scaricato, che garantisce lo stato di revoca dei certificati coinvolti nella data corrente ( T ).
Se, mentre la data corrente è T , si desidera preparare un'ulteriore verifica della firma alla data T ' (più tardi di T ), quindi assemblare tutti gli oggetti necessari per eseguire la verifica e inserirli tutti in una borsa (qualche formato di archivio), per il quale si ottiene un timestamp. La marca temporale indica che tutti i contenuti della busta esistevano alla data T .
Alla data T ', si verifica il timestamp, che include la convalida del certificato TSA e del download CRL e così via; in particolare, si convalida il timestamp alla data T ', che è la data corrente. Una volta verificata la data e l'ora, allora sai che tutti gli oggetti nella borsa esistevano già alla data T , quindi puoi virtualmente proiettarti in passato e verificare la firma come se la data corrente fosse T .

L'idea alla base di questo viaggio nel tempo è che se alla data T avevi convalidato la firma, lo ricorderesti ancora e agirai sul risultato. Pertanto, finché hai la prova (il timestamp) che tutti gli oggetti usati (certificati e CRL) esistevano già alla data T , allora puoi considerare che ha convalidato il certificato alla data T e lo ricordi ancora adesso
Recurse. Nella descrizione sopra, si convalida il timestamp alla data T ', quindi a quello che era timestamp alla data T . Il timestamp stesso può scadere (solitamente perché il certificato TSA scadrà), quindi se si desidera prepararsi per la convalida a lungo termine, è necessario ottenere un timestamp più recente con una durata maggiore. Il nuovo timestamp dovrebbe coprire tutto ciò che è necessario per convalidare il primo timestamp alla data T ', includere il CRL.

In ultima analisi, dovresti applicare un nuovo timestamp ogni due o tre anni circa, a seconda della velocità di scadenza del TSA. Ogni nuovo timestamp si trova su una busta contenente tutti gli oggetti necessari per convalidare il timestamp precedente.

Tutti i timestamp qui sono RFC 3161 , cioè sono CMS SignedData . Di conseguenza, è possibile a posteriori incorporare certificati e CRL aggiuntivi in una struttura di data e ora. RFC 5126 dichiara come tale alla fine di sezione-4.4.1 :

  NOTE 2: Time-stamp tokens that may themselves include unsigned
  attributes required to validate the time-stamp token, such as the
  complete-certificate-references and complete-revocation-references
  attributes, as defined by the present document.

Oltre agli attributi non firmati specifici di CAdES, i certificati extra e il CRL possono sempre essere inseriti nei campi certificates e crls della struttura SignedData , come specificato in CMS . L'effetto complessivo è lo stesso: la struttura di SignedData è il formato "borsa" di cui sto parlando, quindi il timestamp è tutto.

Questa struttura dei francobolli a catena del tempo può essere in qualche modo più facile da capire nella sintassi dei record di prova , uno standard in competizione che si concentra su firme a lungo termine e, a mio parere, lo fa meglio di CAdES.