Perché PKI usa una funzione di hash?

3

Presenterò la mia domanda con la mia comprensione della PKI nel caso in cui abbia qualche idea sbagliata.

  1. Il proprietario del dominio D genera una coppia di chiavi pubblica-privata (d, e) e costruisce un certificato c composto da (d, D, intervallo di tempo, altri metadati).

  2. D convince l'autorità di certificazione X che le informazioni in c sono accurate.

  3. X calcola H (c) usando una funzione di hash crittografica H.

  4. X crittografa H (c) usando la loro chiave privata per generare c ', e restituisce a D.

  5. Provo ad accedere a D, e D mi invia (c, c ')

  6. Il mio browser applica la chiave pubblica di X a c 'e la confronta con H (c).

  7. Se corrispondono, il mio browser si fida di c condizionale per fidarsi di X. Ripeti fino all'autorità di certificazione radice implicitamente attendibile.

I problemi con H possono indebolire lo schema; questo è il motivo per cui le persone smettono di usare MD5 e si stanno allontanando da SHA1. Quindi, perché non saltare semplicemente il passaggio 3 e crittografare c direttamente?

Da quanto ho capito, uno dei motivi è limitare la lunghezza del messaggio da crittografare / decifrare nei passaggi 4, 6. Tuttavia il mio browser ha solo bisogno di (d, D, intervallo di tempo) (e nemmeno di D per le CA intermedie ). Questo è limitato, probabilmente < 10 volte la lunghezza di H (c), e in genere molto più breve del contenuto della pagina che il mio browser presumibilmente decrypt comunque. I metadati potrebbero essere utili per controllare le CA per mantenerle oneste, ma tali informazioni potrebbero essere fornite separatamente dalla CA (ad esempio, scritte in questo append solo log ).

    
posta stewbasic 30.05.2016 - 01:13
fonte

3 risposte

0

La tua domanda principale è:

Problems with H can weaken the scheme; this is why people stopped using MD5 and are moving away from SHA1. So why not just skip step 3 and encrypt c directly?

Sì, MD5 può attualmente essere rotto in circa 2 supposizioni 24.1 (24.1 bit di sicurezza). SHA1 offre attualmente circa 80 bit di sicurezza contro gli stessi attacchi. Stai sostenendo che abbandonare completamente l'hash e ottenere 0 bit di sicurezza è in qualche modo un miglioramento?

La tua comprensione è vicina, ma a quanto pare ti mancano alcuni concetti chiave.

@ La risposta di LieRyan dà la risposta diretta: che la crittografia asimmetrica come RSA può funzionare solo su input a lunghezza fissa.

Per approfondire, hai detto:

[the certificate is] usually much shorter than the page content which my browser will presumably decrypt anyway.

Stai mescolando insieme un sacco di idee sbagliate diverse e paragonando le mele alle arance.

  1. Quello che stai descrivendo con "crittografia dell'hash" è chiamato firma RSA . Sono scettico riguardo persino a chiamarlo "criptare l'hash" perché tecnicamente si sta decrittando l'hash usando la chiave decrittazione .

  2. In pratica le autorità di certificazione reali utilizzano Digital Signature Algorithm (DSA) o Elliptic Curve DSA che si basano su calcoli matematici completamente diversi e non possono assolutamente essere descritti come "crittografia dell'hash".

  3. Confrontando i tempi di esecuzione di "decrittografia dell'hash" (ovvero "verifica della firma") con il tempo di decodifica del contenuto della pagina Web, mele e arance sono in esecuzione perché la firma è eseguita con un crypto asimmetrico (RSA o Crittografia a curva ellittica (ECC)), che come detto da @LieRyan, può solo crittografare un singolo blocco a lunghezza fissa, mentre il contenuto della pagina Web è crittografato con simmetrico cryto (in genere AES ) progettato per crittografare / decrittografare i dati di massa molto rapidamente.

Ignorando tutto quanto sopra, c'è ancora una buona risposta alla domanda:

So why not just skip step 3 and encrypt c directly?

Perché questo sarebbe molto più facile per un malintenzionato. Stai proponendo che il server web fornisca una versione crittografata del loro certificato che posso decifrare con la chiave pubblica della CA. Come attaccante posso cambiare un byte del testo cifrato, decifrarlo con la chiave pubblica della CA e vedere cosa dice, ripetere diverse miliardi di volte finché non ho quello che sembra essere un certificato legittimo da quella CA che afferma che sono il proprietario del sito web (vale a dire la chiave pubblica è quella che possiedo).

L'aggiunta di un hash al processo arresta quel tipo di attacco perché devi anche controllare quale sia la pre-immagine hash del testo cifrato modificato, e riprova se non corrisponde. Aggiungendo un passo hash, abbiamo aumentato i costi di esecuzione di questo attacco da "un paio di mesi su un laptop e ~ $ 10.000 in elettricità" a "secoli su un supercomputer e una centrale elettrica a misura del sole".

(Sto solo esagerando leggermente - supponendo che potremmo fare calcoli a singolo elettrone, solo costruire un contatore da 0 a 2 ^ 256 richiederebbe energia equivalente a metà della materia nella galassia della Via Lattea ).

    
risposta data 30.05.2016 - 20:25
fonte
3

Il motivo principale di ciò è che l'algoritmo di crittografia asimmetrico utilizzato nella firma (RSA) non può essere utilizzato per crittografare una grande quantità di dati ed è estremamente lento. In particolare, RSA non può crittografare dati più grandi delle dimensioni della chiave :

RSA, as defined by PKCS#1, encrypts "messages" of limited size. With the commonly used "v1.5 padding" and a 2048-bit RSA key, the maximum size of data which can be encrypted with RSA is 245 bytes. No more.

La maggior parte dei dati crittografati quando si utilizza la crittografia asimmetrica viene effettivamente crittografata utilizzando una crittografia simmetrica, ad esempio AES, con una chiave generata in modo casuale che viene quindi crittografata utilizzando RSA e inviata insieme ai dati. Ecco come funzionano TLS, PGP, S / MIME e molti altri sistemi di crittografia basati su PKI.

Un certificato PKI di solito contiene più dati di quelli che possono essere contenuti nel limite di dimensione RSA perché un certificato contiene una chiave pubblica RSA, che di solito ha le stesse dimensioni della chiave RSA della stessa CA. Quindi abbiamo bisogno di un modo per ridurre la dimensione dei dati crittografati, pur rappresentando fedelmente l'intero dato. Quindi, l'uso dell'hashing. L'hash può quindi essere crittografato utilizzando RSA direttamente, invece di utilizzare il metodo RSA + AES.

Se insistiamo sul fatto che l'intero certificato debba essere firmato utilizzando un semplice RSA, la CA sarà in grado di firmare solo i certificati la cui lunghezza della chiave è strettamente inferiore alla chiave della CA. E ogni fase delle CA intermedie sarebbe in grado di firmare solo le chiavi consecutivamente più piccole.

The metadata could be useful for auditing CAs to keep them honest

I metadati non sono in realtà solo usati per mantenere onesto CA. Anche i metadati in un certificato codifica:

  1. lo scopo del certificato (certificato di firma del codice, certificato S / MIME, certificato client, certificato server),
  2. identificando le informazioni sul proprietario della chiave che la CA era in grado di verificare (nome legale, identificativo dell'organizzazione, indirizzo dell'organizzazione e giurisdizione legale), questo dovrebbe essere usato dal peer per decidere se stanno comunicando con l'entità giusta
  3. come trovare l'elenco di revoche di certificati o il risponditore OCSP e
  4. il processo utilizzato dalla CA per verificare il certificato, che rappresenta la forza dell'attestazione (EV, OV o DV).

Alcune informazioni come CRL / OCSP non possono essere comunicate in modo sicuro in un canale laterale, in quanto ciò potrebbe vanificare lo scopo del campo.

    
risposta data 30.05.2016 - 17:46
fonte
0

Perché la crittografia asimmetrica (aka chiave pubblica) è LENTA ... Letteralmente migliaia di volte più lento della crittografia simmetrica. È più veloce crittografare solo una piccola quantità di dati (l'hash) rispetto a una grande quantità di dati.

    
risposta data 30.05.2016 - 21:02
fonte

Leggi altre domande sui tag