Chiave pubblica condivisa vs Certificato

2

Ho un sistema in cui i client comunicano in modo sicuro con un server remoto su internet utilizzando TLS. In questo scenario, come i certificati server firmati da CA sono migliori della pre-condivisione della chiave pubblica del server? Quando la chiave privata del server viene compromessa, le nuove coppie di chiavi sostituiranno quelle vecchie, quindi è faticoso eseguire di nuovo il processo di pre-condivisione per tutti i client. In questo caso, presumo che il certificato abbia un vantaggio. Ma ho ragione?

    
posta Kumar 19.07.2017 - 15:46
fonte

2 risposte

2

Confrontiamo i flussi di lavoro dei due processi, in particolare il modo in cui la chiave di handle compromette.

Segreto precondiviso

Il server genera una coppia di chiavi, la copia su ogni macchina client (manualmente, tramite uno script, ecc.). Durante la connessione al server, il client verificherà che la chiave pubblica presentata corrisponda a quella che hanno memorizzato nella cache per quel server (concettualmente, questo è lo stesso metodo di identificazione delle impronte digitali di SSH).

Upside : non è necessario l'inconveniente di ottenere un certificato firmato da una CA. È possibile generare la coppia di chiavi del server e avviare immediatamente la distribuzione ai client.

Lato negativo : il recupero da un compromesso chiave è difficile o impossibile perché non esiste alcun meccanismo per il server che notifica i client di un compromesso chiave, tranne che spinge una nuova coppia di chiavi a tutti i client. Si consideri che un utente malintenzionato ha la chiave privata del server e può intercettare il traffico tra il client e il server (sia per bloccare il push della coppia di chiavi aggiornato, sia per man-in-the-middle la connessione del client al server). Il client si fiderà dell'attaccante e crede che stia parlando con il server autentico e non c'è nulla che tu possa fare per impedirlo perché a un livello fondamentale, i segreti pre-condivisi non hanno meccanismi di revoca.

Certificato

Sì, è fastidioso (ea volte costoso) ottenere un certificato, ma la fiducia non dipende più dalla possibilità di spingere la chiave precondivisa ai client.

Parte del processo di convalida di un certificato è che il client raggiunga la CA e si assicuri che il certificato non venga revocato e che se non riesce a raggiungere la CA, ciò viene considerato un errore. Lo spoofing di questo controllo di revoca richiede che l'hacker comprometta non solo la chiave privata del server, ma anche la chiave privata della CA. Se il server si rende conto che la sua coppia di chiavi è stata compromessa e chiede alla CA di revocarla, tutti i client lo sapranno immediatamente perché i controlli di revoca online falliranno.

La revoca è la ragione principale per utilizzare i certificati qui, ma considera anche che un utente malintenzionato può intercettare il push della chiave pubblica iniziale e sostituirlo con la propria chiave pubblica. Forse sei l'amministratore di rete e puoi garantire la distribuzione sicura delle chiavi pubbliche, ma i certificati rendono questo un punto controverso perché anche se l'attaccante può intercettare la distribuzione del certificato, lo spoofing di un certificato richiede di compromettere la CA.

    
risposta data 19.07.2017 - 16:47
fonte
0

Con chiavi precondivise, è necessario proteggere TUTTI gli endpoint: server e client. Se uno solo dei partecipanti è compromesso, devi ridistribuire un nuovo set di chiavi.

Inoltre, l'unica volta che hai bisogno di un canale sicuro esterno con una PKI è quando configuri inizialmente la tua catena di fiducia. Dopodiché, non dovrai più utilizzare un canale sicuro a meno che la tua root non sia compromessa.

    
risposta data 19.07.2017 - 16:39
fonte

Leggi altre domande sui tag