it-swarm-eu.dev

Che danno si potrebbe fare se un certificato dannoso avesse un identico "Identificatore chiave oggetto"?

Sto guardando il Subject Key Identifier attributo di un certificato CA e sto cercando di capire il ruolo che svolge nella convalida e dedurre come il software client di convalida potrebbe sbagliarlo.

  • Qual è il ruolo dell'identificatore chiave oggetto nella convalida di un certificato CA o End?
    Qualsiasi conoscenza di come sono stati implementati i pacchetti software più diffusi sarebbe utile

  • Qual è il peggio che un utente malintenzionato potrebbe fare se fosse in grado di generare una chiave pubblica che contenesse anche lo stesso hash?

Mentre leggo RFC328 Vedo che l'identificatore chiave oggetto (SKI) è come la colla utilizzata per costruire e verificare la catena PKI. Anche lo SKI sembra essere una versione più sicura rispetto al numero seriale e al nome del certificato utilizzati anche per unire due certificati.

Per quanto riguarda la convalida del client dell'hash del certificato, i clienti eseguono semplicemente una "corrispondenza del modello" dello SKI o lo SKI della catena viene effettivamente calcolato come descritto di seguito:

Per i certificati CA, gli ID chiave oggetto devono DOVREBBE essere derivati
la chiave pubblica o un metodo che genera valori univoci. Due comuni
I metodi per generare identificatori di chiavi dalla chiave pubblica sono:

  (1) The keyIdentifier is composed of the 160-bit SHA-1 hash of the
  value of the BIT STRING subjectPublicKey (excluding the tag,
  length, and number of unused bits).

  (2) The keyIdentifier is composed of a four bit type field with
  the value 0100 followed by the least significant 60 bits of the
  SHA-1 hash of the value of the BIT STRING subjectPublicKey
  (excluding the tag, length, and number of unused bit string bits).

Un esempio di rischio che sto cercando di mitigare è un certificato CA non valido con una chiave pubblica che non ha un hash su uno SKI corretto (fatto mediante modifica manuale ASN.1 e dimissioni del certificato dalla radice dell'attaccante)

13

Il Subject Key Identifier does not gioca un ruolo nella validazione, almeno non nell'algoritmo che costituisce la sezione 6 di RFC 528 . È pensato per essere un aiuto per creazione di percorsi , l'attività che si svolge prima della convalida: questo è quando l'entità che vuole convalidare un certificato riunisce il potenziale catene di certificati che verranno quindi elaborate tramite l'algoritmo della sezione 6. La Sezione 4.2.1.2 descrive questa estensione e include questo testo:

Per facilitare la costruzione del percorso di certificazione, questa estensione DEVE apparire in tutti i certificati CA conformi, ovvero in tutti i certificati inclusa l'estensione dei vincoli di base (Sezione 4.2.1.9) in cui il valore di cA è TRUE. In certificati CA conformi, il valore dell'identificatore chiave soggetto DEVE essere il valore inserito nel campo identificatore chiave dell'estensione identificatore chiave autorità (Sezione 4.2.1.1) dei certificati emessi dall'oggetto del presente certificato. Le applicazioni non sono tenute a verificare che gli identificatori chiave corrispondano quando si esegue la convalida del percorso di certificazione.

Questi "DEVE" sono obblighi per la CA: per conformarsi al profilo descritto da RFC 5280, la CA deve aver cura di abbinare il Authority Key Identifier dei certificati che emette per se stesso Subject Key Identifier. Prendi nota dell'ultima frase: questa corrispondenza è no parte di ciò che la convalida deve verificare.

RFC raccomanda di calcolare l'identificatore chiave mediante hash, poiché minimizzerà le collisioni, garantendo così la massima efficienza di questa estensione per la costruzione di percorsi. Tuttavia, l'hash non è obbligatorio. CA può scegliere l'identificatore in qualsiasi modo lo ritenga opportuno; e i verificatori certamente fanno no ricalcola gli identificatori. Questo è puro test di uguaglianza da byte a byte. Inoltre, so che l'implementazione di Microsoft della validazione dei percorsi è pronta per essere costruita e prova a convalidare i percorsi in cui gli identificatori chiave non corrispondono.

Il peggio che una CA canaglia potrebbe fare riutilizzando gli identificatori chiave è rendere più difficile la creazione di percorsi; questo potrebbe innescare una sorta di denial of service per i verificatori che eseguono la creazione di percorsi attraverso identificatori chiave e sono troppo pigri per provare diversamente. In pratica, i verificatori tendono a costruire percorsi abbinando il soggetto e il DN dell'emittente, non gli identificatori chiave, quindi l'impatto pratico dovrebbe essere vicino allo zero.

19
Thomas Pornin

Gli identificatori chiave Rouge ostacolerebbero la ricerca di percorsi inequivocabili.

Nel peggiore dei casi è necessario verificare la validità di numerosi percorsi potenziali. Ma avresti comunque un certificato con un identificativo rouge nel tuo negozio di fiducia? Se non ti fidi, non è necessario controllare quel percorso. E se ti fidi, allora that path non verificherebbe.

0
Robert Siemer