Che danno si potrebbe fare se un certificato dannoso ha identico "identificatore chiave soggetto"?

Question

Che danno si potrebbe fare se un certificato dannoso ha identico "identificatore chiave soggetto"?

#1 da (17 voti)
#2 da (0 voti)

11

Sto osservando l'attributo Subject Key Identifier di un Certificato CA e sto cercando di capire il ruolo che svolge nella convalida e deduco in che modo la validazione del software client potrebbe sbagliare.

Qual è il ruolo del codice identificativo della chiave soggetto nella convalida di un certificato CA o di fine?
Qualsiasi conoscenza su come implementare i pacchetti software più diffusi sarebbe utile
Qual è la cosa peggiore che un utente malintenzionato potrebbe fare se potesse generare una chiave pubblica che contiene anche lo stesso hash?

Mentre leggo RFC3280 vedo che l'identificatore chiave oggetto (SKI) è come la colla usata per costruire e verificare la catena PKI. Lo SKI sembra anche essere una versione più sicura rispetto al numero seriale e al nome del certificato che è stato utilizzato anche per unire due certificati insieme.

Per quanto riguarda la convalida del client dell'hash del certificato, i client eseguono semplicemente un "pattern match" dello SKI, oppure lo SKI della catena è effettivamente calcolato come descritto di seguito:

For CA certificates, subject key identifiers SHOULD be derived from
the public key or a method that generates unique values. Two common
methods for generating key identifiers from the public key are:
  (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 rischio di esempio che sto tentando di mitigare è un certificato CA non valido con una chiave pubblica che non ha hash su uno SKI corretto (fatto da modifica manuale ASN.1 e dimettendo il certificato dalla radice dell'attaccante)

public-key-infrastructure certificates certificate-authority threat-mitigation

posta random65537 10.01.2013 - 00:13

fonte

2 risposte

0

Gli identificatori di chiavi di rouge ostacolerebbero la ricerca di percorsi inequivocabili.

Nel peggiore dei casi è necessario verificare la validità di diversi percorsi potenziali. Ma avresti comunque un certificato con un identificatore del rouge nel tuo negozio di fiducia? Se non ti fidi di questo, non c'è bisogno di controllare quel percorso. E se ti fidi di questo, allora quel percorso non verrebbe convalidato.

risposta data 19.05.2016 - 22:58

fonte

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

Best practice per la sicurezza della posta elettronica È realistico ricordare solo la password per il gestore di password?

score 17 · Accepted Answer

Il Subject Key Identifier non svolge un ruolo nella convalida, almeno non nell'algoritmo che costituisce la sezione 6 di RFC 5280 . È pensato per essere un aiuto per la costruzione del percorso , l'attività che ha luogo prima della convalida: questo è quando l'entità che vuole convalidare un certificato assembla potenziali catene di certificati che saranno poi elaborate attraverso la sezione 6 algoritmo. La sezione 4.2.1.2 descrive questa estensione e include questo testo:

To facilitate certification path construction, this extension MUST appear in all conforming CA certificates, that is, all certificates including the basic constraints extension (Section 4.2.1.9) where the value of cA is TRUE. In conforming CA certificates, the value of the subject key identifier MUST be the value placed in the key identifier field of the authority key identifier extension (Section 4.2.1.1) of certificates issued by the subject of this certificate. Applications are not required to verify that key identifiers match when performing certification path validation.

Questi "MUST" sono obblighi per la CA: per conformarsi al profilo che descrive la RFC 5280, CA deve fare attenzione ad abbinare il Authority Key Identifier dei certificati che emette al proprio Subject Key Identifier . Prendi nota dell'ultima frase: questa corrispondenza è non parte di ciò che la convalida deve verificare.

Si consiglia all'RFC di calcolare l'identificatore della chiave tramite hashing, in quanto minimizzerà le collisioni, garantendo così la massima efficienza di questa estensione per la creazione di percorsi. Tuttavia, l'hashing non è obbligatorio. CA può scegliere l'identificatore in qualsiasi modo come ritengono opportuno; e i verificatori certamente non ricalcolano gli identificatori. Questo è puro test di uguaglianza byte-byte. Inoltre, so che l'implementazione della convalida del percorso da parte di Microsoft è pronta per essere costruita e provare a convalidare i percorsi in cui gli identificatori delle chiavi non corrispondono.

Il peggio che una CA canaglia possa fare riutilizzando gli identificatori delle chiavi è rendere più difficile la costruzione del percorso; questo potrebbe innescare un tipo di rifiuto del servizio per i verificatori che eseguono il percorso attraverso gli identificatori delle chiavi e sono troppo pigri provare diversamente In pratica, i verificatori tendono a costruire percorsi facendo corrispondere il DN del soggetto e dell'emittente, non gli identificatori chiave, quindi l'impatto pratico dovrebbe essere vicino a zero.