Perché una chiave privata crittografata può essere forzata bruta?

Un testo semplice costituito da una chiave privata RSA può essere facilmente riconosciuto, poiché soddisfa determinate proprietà matematiche. In particolare:

d = e^-1 mod (p-1)(q-1)

Ciò significa che, data la chiave pubblica e un candidato d , puoi calcolare

d . e mod (p-1)(q-1)

Se il risultato è 1 , hai trovato la chiave corretta.

La soluzione è usare una passphrase strong per proteggere le tue chiavi private.

Questa è un'idea che vale la pena investigare.

Come mostra @caf, una chiave privata RSA ha molte strutture interne, che sono facilmente riconoscibili. Sarebbe molto difficile progettare uno schema di crittografia basato su password in modo tale che la decrittazione di una chiave RSA crittografata con la password errata restituisca comunque qualcosa che assomiglia a una chiave privata RSA valida.

Tuttavia, questo è relativamente facile da fare con i tasti DSA (e anche con la variante della curva ellittica ECDSA ). Una chiave privata DSA utilizza i parametri chiave (chiamati p , q e g ) che non devono essere segreti (sono presenti anche nella corrispondente chiave pubblica); l'unica parte veramente privata nella chiave è x , un modulo intero q . Qualsiasi modulo intero q è una chiave privata DSA valida. In questo modo puoi creare una crittografia basata su password di x in questo modo:

• Scegli q come numero a 256 bit (cioè 2 ²⁵⁵ < q < 2 ²⁵⁶ ).
• Utilizza un codice a blocchi con blocchi a 256 bit (ad es. Rijndael - AES è Rijndael con blocchi a 128 bit e 128 bit, 192 bit o 256 bit, ma il Rijndael originale ha anche una modalità con blocchi a 256 bit).
• Per crittografare x con una password, devi prima ottenere una chiave dalla password (usa bcrypt !) e quindi criptare x (come stringa a 256 bit) con Rijndael. Se la stringa risultante non è (se interpretata come un numero) nell'intervallo [0..q-1] , quindi crittografarla di nuovo, e di nuovo, fino a tornare all'intervallo previsto. In media, dovrai chiamare Rijndael meno di due volte, quindi non è molto difficile da calcolare.
• Per decodificare x , basta ricavare una chiave dalla password digitata e applicare la decrittazione di Rijndael. Ancora una volta, fallo in modo ricorsivo finché non torni all'intervallo [0..q-1] .

Quindi questo è fattibile. È una buona idea? Il vantaggio di tale crittografia è che la password non può più essere forzata brutalmente da un utente malintenzionato che ha ottenuto una copia della chiave privata crittografata. D'altra parte, se l'utente malintenzionato ha anche una copia della chiave pubblica, può facilmente verificare che abbia decodificato con la password corretta. Essendo la chiave pubblica, beh, destinata a essere pubblica, non è necessariamente mantenuta riservata come la chiave privata. Il server di destinazione ce l'ha. In realtà, i tutti server per i quali viene utilizzata la chiave privata per l'accesso hanno una copia della chiave pubblica. Quindi la chiave pubblica è solo moderatamente riservata, nel migliore dei casi. Pertanto, il vantaggio offerto dalla "crittografia della password non verificabile" come descritto sopra, sembra debole. D'altra parte, ha il seguente svantaggio: se l'utente digita la sua password, il server è ancora interrogato, e SSH non può più fare la distinzione tra "l'utente armeggia con la sua tastiera" e "c'è qualcosa di sbagliato sul server".

Quindi, mentre quello che chiedi è fattibile almeno per alcuni tipi chiave, è comprensibile che non sia stato ancora implementato (ancora). Non è una vittoria incontrastata; è un compromesso tra usabilità e sicurezza (perdi un po 'di usabilità per guadagnare un po' di sicurezza).

Il file "chiave privata" memorizza sia le chiavi pubbliche che quelle private.

Il file è crittografato con un algoritmo simmetrico.

Se rubo una pen-drive con il file su di essa, posso offline brute-force la passphrase, così come posso forzare brute-force qualsiasi altro file crittografato. Una volta decodificato il file, ho entrambe le chiavi pubbliche e private.

Raramente sono usate chiavi per l'autenticazione. Normalmente, vengono utilizzati per stabilire un canale sicuro di fiducia, dopodiché devi autenticarti con un nome utente / password. Rubare la tua chiave e decrittografare le chiavi non mi darà ancora accesso al server, ma mi consentirà di gestire la tua connessione.

Non sono sicuro di quello che stavi chiedendo, ma spero che questo aiuti.

Si noti che è sempre possibile generare la chiave pubblica dalla chiave privata, quindi se l'utente malintenzionato ha la chiave pubblica (che è plausibile, essendo pubblica), la verifica della risposta è sempre banale. Immagino che questo sia fondamentale per tutti gli algoritmi di crittografia asimmetrica.

È praticamente impossibile creare un sistema che faccia ciò che vuoi.

Dovremmo dare per scontato che l'utente malintenzionato abbia la tua chiave pubblica (la chiave pubblica è pubblica e archiviata su molte macchine). Dato un candidato per la chiave privata, l'utente malintenzionato può utilizzare la chiave pubblica per verificare se questo candidato è corretto (ad esempio, controllando se la chiave privata candidata decrittografa correttamente la roba che è stata crittografata sotto la chiave pubblica). Pertanto, dato un candidato per la password, l'utente malintenzionato sarà sempre in grado di verificare la sua validità recuperando il candidato corrispondente chiave privata e quindi controllandolo contro la chiave pubblica. Questo non è specifico per il particolare algoritmo a chiave pubblica utilizzato o per il formato per l'archiviazione e la crittografia della chiave privata. È un limite fondamentale che sarà presente in quasi tutti i metodi immaginabili per l'archiviazione della chiave privata SSH.

In breve, la ragione per cui SSH ha questo rischio è perché non esiste un modo realistico per evitare il rischio.

Pertanto, è necessario scegliere una passphrase strong per proteggere la chiave privata SSH.

SSH non deriva la passphrase, garantisce che la persona dall'altra parte abbia accesso ad alcune informazioni segrete. Se non riesci a capire direttamente la matematica, ecco un riassunto che puoi assumere per fede:

I can verify that you know something, without knowing the something myself.

Per una descrizione più approfondita di cosa succede con gli scambi di chiavi di Diffie-Hellman, guarda wikipedia . Fondamentalmente, puoi vedere che eseguire una determinata operazione su alcuni numeri dà il risultato che ti aspetteresti se ho la parte segreta della chiave, ma non hai un modo semplice per ricavare il bit segreto. Le chiavi pubbliche (in RSA) contengono effettivamente tutte le informazioni nelle chiavi private, ma è difficile da raggiungere.

La tua domanda: non capisco perché sia facile dire il risultato della decrittazione corretta dal risultato di una decrittazione errata.

Suppongo tu stia parlando di un client che fornisce una password crittografata al server. Nella maggior parte dei sistemi, se fornisci la password errata per 3 volte, il sistema ti bloccherà. In un certo senso questo è un attacco denial-of-service. Quindi non puoi continuare a provare ad autenticarti finché non ci riesci.

Mentre lo scambio di chiavi Diffie-Hellman --- che di per sé è soggetto all'attacco man-in-the-middle quando usato da solo --- viene utilizzato da client e server per calcolare la chiave di sessione, l'autenticazione viene eseguita da ciascuno parte dimostrando all'altro che ha la chiave privata corrispondente alla sua chiave pubblica. Ma non puoi autenticarti senza la chiave privata. Non è che la passphrase sia usata per decrittografare la chiave privata e puoi continuare a provare diverse passphrase e ottenere diverse chiavi "private" e puoi provarle una per una finché non "funziona". La passphrase protegge la chiave privata --- analoga alla memorizzazione di un foglio con chiave privata in un armadietto; a meno che tu non possa aprire l'armadietto con la chiave giusta, non puoi accedere alla carta.

Infine, anche se il server consente al client la libertà di continuare a provare l'autenticazione tramite la forza bruta, è computazionalmente impossibile da eseguire, sia che si tratti della chiave AES a 128 bit (crittografia simmetrica) o della RSA a 1024 bit (crittografia a chiave pubblica ). Se gli attacchi di forza bruta fossero fattibili, allora un tale schema crittografico sarà difficilmente utile.