Perché è un hash CSR?

In realtà non è un hash SHA1 nella CSR. È una firma del messaggio.

Per semplicità, presumo che stiamo parlando di certificati RSA, dove la chiave pubblica è (N, e) (il modulo e l'esponente pubblico che è in genere 65537) e la chiave privata è (N, d) (la modulo e l'esponente privato che può essere facilmente calcolato tramite l'algoritmo esteso di Euclid se si può calcolare il modulo in p e q).

Un certificato è semplicemente una chiave pubblica, con alcuni metadati (ad esempio, chi sei, a quale dominio si applica il certificato, chi ha firmato il certificato), più la firma del certificato.

In RSA si firma un messaggio allegando una firma alla fine del messaggio. Ottenete la firma prima eseguendo l'hashing del messaggio e quindi facendo l'esponenziazione modulare su quell'hash con il vostro esponente privato. Questa è la firma è S = H(m)^d mod N . Nota che chiunque abbia la chiave pubblica può verificare la firma calcolando S^e mod N e verificando che questo corrisponda all'hash del messaggio. Nota, se non hai la chiave privata non puoi costruire una firma valida per il messaggio, quindi questo impedisce la manomissione del certificato.

Una CSR è una richiesta di firma del certificato, ma essenzialmente è solo un certificato autofirmato che si crea su una macchina locale, quindi è possibile dare a una CA di firmare (quindi la CA non imparerà mai la propria chiave privata). Quindi tu costruisci localmente due grandi numeri primi, moltiplicali per trovare il modulo e calcola l'esponente privato. Aggiungi i tuoi meta-dati su te stesso al tuo CSR. Per buona misura, si firma immediatamente il certificato con la chiave privata associata alla chiave pubblica contenuta nel certificato.

Ciò impedisce a qualcuno di alterare il tuo CSR in transito verso la CA (per cambiare i dettagli dell'organizzazione, la password di sfida, il numero di serie, senza cambiare modulo / esponente privato).

Questo probabilmente non è l'attacco più devastante perché devi ancora fidarti che l'AC agisca in maniera fidata, e non c'è motivo di regalare i tuoi CSR a terze parti. Tuttavia, è semplice firmarlo, non richiede ulteriori sforzi, quindi è comunemente fatto.

Il RFC per i CSR - link - fornisce effettivamente una diversa ragione per cui il CSR è firmato. Non dice nulla sull'impedire che la CSR venga modificata durante il transito, ma afferma che è per impedire a qualcuno che richiede un certificato per una chiave che non è la loro (e dice che questo è solo un problema minore):

"Nota 2 - La firma sulla richiesta di certificazione impedisce a    entità dalla richiesta di un certificato con la chiave pubblica di un'altra parte.    Un simile attacco darebbe all'entità la minore capacità di fingere    essere l'autore di qualsiasi messaggio firmato dall'altra parte. Questo    l'attacco è significativo solo se l'entità non conosce il messaggio    essere firmato e la parte firmata del messaggio non identifica il    firmatario. L'entità non sarebbe ancora in grado di decodificare i messaggi    inteso per l'altra parte, ovviamente. "

(a pagina 4).

Non credo che l 'idea di "impedire che la CSR venga modificata durante il trasporto" abbia un senso molto (o alcuno?). Per quanto posso vedere, qualsiasi attacco MITM richiede che l'attaccante sia in grado di intercettare la comunicazione in entrambe le direzioni , dopo di che possono semplicemente sostituire un CSR completamente diverso per una coppia di chiavi che effettivamente controllano la metà privata di

Non riesco a vedere uno scenario plausibile in cui qualsiasi tipo di "attacco" plausibile può essere eseguito da una festa seduta tra un sottomarino CSR e una CA che non può cambiare la chiave pubblica, a meno che non stia posizionando un attaccante chi in qualche modo guadagnerebbe qualcosa dal giocherellare con i metadati del certificato e un mittente che non si preoccupa di controllare i metadati sul certificato che ritorna dalla richiesta ...