Raggiungere PFS con crittografia a chiave pubblica

I'm seeking to understand how Perfect Forward Secrecy (PFS) works for non SSL applications.

Bene, ripetiamo brevemente di cosa tratta PFS : vuoi impedire a chiunque ottenga la tua chiave principale per poter decrypt messages ha catturato in anticipo .

Ad esempio, assumiamo il caso di SSL / TLS in cui la chiave privata del certificato del server viene compromessa. Senza PFS sarebbe quindi possibile che un utente malintenzionato decodifichi tutti i messaggi che sono stati crittografati con questa chiave. Più in particolare, la chiave privata viene solitamente utilizzata per crittografare le chiavi di sessione, che in cambio vengono utilizzate per la crittografia dei dati effettivi. Il problema rimane lo stesso, aggiunge solo un livello di astrazione.

How is this implemented? How would I create an application (let's say a chat application) and keep each message (or conversation) forward secret?

Quindi, quello che vuoi ottenere è scambiare le chiavi in modo che il compromesso di un singolo messaggio non infranga l'intero sistema . Invece di usare una chiave statica, ad es. La tua chiave privata per lo scambio di chiavi di sessione, devi trovare uno schema costruito attorno a tasti temporali . Questo è esattamente ciò che lo scambio di chiavi Diffie-Hellman (DHKE) è circa. Il problema con il DHKE classico è che i partner di comunicazione non sono autenticati, quindi Man-in-the-middle gli attacchi diventano possibili.

Pertanto devi combinare questi due schemi : utilizzare RSA per autenticazione e utilizzare DHKE per creare una chiave di sessione effimera . In tale configurazione né il compromesso di una singola chiave di sessione né il compromesso della chiave master stessa consentirebbero a un utente malintenzionato di decrittografare i messaggi da altre sessioni precedenti.

Funziona alla grande ed è fondamentalmente il modo in cui viene raggiunto PFS in SSL / TLS. Un altro esempio abbastanza popolare per tale schema è Off-the-Record Messaging (OTR) , sebbene le chiavi debbano essere verificate manualmente , piuttosto che attraverso una infrastruttura a chiave pubblica basata su RSA.

More specifically, I'm interested in how Moxie Marlinspike accomplishes this in TextSecure and other applications.

TextSecure si basa essenzialmente su OTR . Tuttavia, hanno migliorato OTR in modo da renderlo adatto alle applicazioni mobili. Il problema più grande in un ambiente mobile è che non è possibile aspettarsi che entrambe le parti siano online nello stesso momento. Le connessioni mobili vengono interrotte tutto il tempo, quindi il DHKE classico diventerebbe un problema, perché ci potrebbe volere molto tempo prima che entrambe le parti abbiano concordato una chiave di sessione, che idealmente sarebbe stata usata solo per un singolo messaggio. In sostanza ciò che desideri è che lo scambio di chiavi sia in modo asincrono . Diventa un po 'più complicato di così, perché TextSecure risolve anche un paio di altri problemi, come la decrittazione fuori ordine e la prevenzione della divulgazione dei metadati attraverso i cleartext.

I've heard that they use a "racheting" protocol which gives each session its own specific key which prevents a compromise of the private key of one of the users.

Ciò a cui ti riferisci è Axolotl Ratchet e troverai una descrizione dettagliata degli obiettivi e dei meccanismi interni qui .

(e.g. A user encrypts a message to bob using bob's public key. How do I add PFS into the equation?)

In breve: non utilizzare la chiave pubblica di bob per crittografare il messaggio. Usa la sua chiave pubblica per l'autenticazione, crea chiavi temporali per la crittografia, ad es. usando DHKE.

PFS di solito include i tasti effimeri , cioè le chiavi che esistono per la durata della conversazione ma che vengono buttate via più tardi.

Un modo per farlo è creare una coppia di chiavi RSA effimera per la durata della conversazione:

• Sia Alice che Bob hanno entrambe le chiavi RSA a lungo termine, ed entrambe conoscono le rispettive chiavi pubbliche.
• Alice genera una coppia di chiavi RSA a 768 bit. Questa è la sua chiave effimera. Firma la chiave pubblica effimera con la sua chiave privata a lungo termine e invia le informazioni a Bob.
• Bob riceve il pacchetto, verifica la sua autenticità con la chiave pubblica a lungo termine di Alice, quindi conserva una copia della chiave pubblica effimera di Alice.
• Bob sceglie una chiave simmetrica casuale a 128 bit, la crittografa con la chiave pubblica effimera di Alice, la firma con la sua chiave privata a lungo termine e la invia ad Alice.
• Alice verifica l'autenticità del pacchetto utilizzando la chiave pubblica di Bob, la decrittografa con la sua chiave privata temporanea.
• Entrambe le parti ora conoscono una chiave a 128 bit che può essere utilizzata per crittografare le loro comunicazioni con un codice simmetrico, ad es. AES.
• Alla fine della conversazione, Alice scarta la sua chiave privata effimera.

Poiché la chiave privata di Alice viene distrutta alla fine della conversazione, non c'è modo di scoprire quale fosse la chiave simmetrica dopo il fatto, anche se una delle loro chiavi a lungo termine è compromessa.

Questo può essere ottenuto anche con l'algoritmo di scambio chiavi Diffie-Hellman in modo simile - questo è il punto in cui vedi DHE / ECDHE in suite di crittografia.