Memorizza la chiave privata sul server, quindi usa k1 per accedere, k2 per verificare HMAC e k3 per decrittografare la chiave privata

Question

Memorizza la chiave privata sul server, quindi usa k1 per accedere, k2 per verificare HMAC e k3 per decrittografare la chiave privata

#1 da (2 voti)
#2 da (1 voti)

3

Sto lavorando a un programma proof-of-concept per crittografare le e-mail con meno difficoltà per gli utenti finali con un processo come:

Per creare un account:

Genera un salt casuale e IV e ottieni una password dall'utente.
Genera una chiave a 384 bit con PBDKF2-HMAC-SHA512 (o forse scrypt?).
Dividilo in tre chiavi a 128 bit (k1, k2, k3).
Genera una coppia di chiavi RSA (per GPG ).
Cripta la chiave privata con k3.
Genera un HMAC della chiave privata crittografata, utilizzando k2.
Invia sale, IV, k1, numero di iterazioni, chiave pubblica, HMAC e chiave privata crittografata al server.

Per accedere:

Richiedi il nostro numero di sale e il numero di iterazioni dal server (forse fai qualcosa qui per evitare la fuoriuscita di indirizzi email).
Rigenera k1, k2, k3 con PBKDF2.
Invia k1 al server, che lo controlla rispetto alla versione memorizzata. Questo è usato per evitare di rendere pubblica la chiave crittografata. In teoria, questo non dovrebbe avere importanza, ma sembra meglio proteggere i dati crittografati per ogni evenienza.
Se k1 corrisponde, il server restituisce una chiave privata crittografata AES-128 e IV, con un MAC HMAC-SHA-1.
Usa k2 per verificare l'HMAC.
Utilizza k3 per decrittografare la chiave privata.

Per gli accessi futuri, possiamo semplificare le cose dal momento che il server ha la chiave pubblica e abbiamo la chiave privata.

L'idea è che anche se il server è compromesso, l'unica informazione che ha è k1, sale, IV e la chiave privata crittografata, ma per fare casino con la chiave, ha bisogno di k2 e per decodificare la chiave ha bisogno di k3.

Poiché il client deve solo decodificare la chiave una sola volta (e può quindi memorizzarla nel portachiavi del sistema operativo), il numero di iterazioni potrebbe essere molto alto.

Sono corretto supponendo che ciò possa proteggere i clienti da un server compromesso? Penso che i soli vettori di attacco rimasti sarebbero hackerare il client, forzare brute la password (che dovrebbe essere incredibilmente difficile, dato che possiamo usare molte iterazioni di PBKDF2) e la crittoanalisi dei tubi di gomma.

EDIT: Più specificamente, questo è inteso a proteggere la password di un utente, la chiave privata e le e-mail crittografate da un utente malintenzionato, anche se quell'attaccante sta lavorando con il proprietario del server. Le e-mail non cifrate sono praticamente impossibili da proteggere, dal momento che un hacker che controlla il server potrebbe salvarle tutte via via che entrano. La crittanalisi del social engineering e del tubo di gomma sono rilevanti, ma il mio obiettivo era principalmente quello di ridurre i possibili attacchi a quelli che possono essere tenuto segreto.

authentication encryption pbkdf2

posta Brendan Long 22.06.2013 - 23:00

fonte

2 risposte

Leggi altre domande sui tag authentication encryption pbkdf2

Esistono implementazioni di algoritmi di hashing delle password per i principali framework che utilizzano hardware specializzato come GPU / FPGA? Caricamento di immagini sicure di XSS, codice php e virus

score 2 · Answer 1

Ci sono un paio di problemi:

1 - Nella sequenza di accesso - passaggio # 4 - stai inviando k1 per la verifica sul server. Il server non ha una copia di k1. In base al thread di creazione dell'account, il passaggio 3 (generare k1, k2, k3) si è verificato presumibilmente lato client e non faceva parte della trasmissione del server (passaggio 7)

2 - Se memorizzi k1, allora è effettivamente una password - la ripetizione del valore k1 è tutto ciò che è necessario per accedere al passo 4 di accesso.

3 - La cosa che si trova tra l'attaccante e la capacità di imitare l'utente è la crittografia AES a 128 bit della chiave privata. È memorizzato sul server, quindi, se il server è incrinato, è possibile ottenere la chiave crittografata. Se offri anche k1, potresti offrire la possibilità di ottenere dati aggiunti. Ci sono fondamentalmente due possibili calcoli che l'attaccante può calcolare fino a quando non trova una combo vincente:

Decodifica AES (test-k3, chiave privata crittografata) = crea una chiave che può decodificare qualsiasi e-mail crittografata.
key gen con PBDKF2-HMAC-SHA512 (salt, # interations, test-password) = k1 (noto), k2 (sconosciuto), k3 (sconosciuto)

Ora siamo nel regno in cui la domanda è "quanto sono facili queste cose?" e davvero non lo so. Questa è una buona domanda per crypto.SE - siamo nel mondo della difficoltà di crittografia, che non è il mio strong seme.

4 - non negare il valore di guardare le trasmissioni e la colocation dei server. Se l'attaccante ha violato l'account / login server, cos'altro si trova su quel server? Se serve anche la posta elettronica o le transizioni utente con privilegi post-autenticazione - il problema non sono i passaggi precedenti, sono le altre risorse di alto valore. Inoltre, osservando quando un utente effettua l'accesso e il suo modello generale di comportamento, prove ed errori fornirà sufficienti informazioni di ingegneria sociale che la fastidiosamente parte matematica dell'hacking crittografico è irrilevante. Se riesco a rompere il server, chiamare l'utente e scusarmi, e chiedergli di dirmi la sua password al telefono, il lavoro di hacking della crittografia è obsoleto.

score 1 · Answer 2

Alcune cose a cui pensare:

Quali sono i tuoi vettori di attacco identificati? In alternativa, quali sono i tipi specifici di compromissione alla sicurezza delle informazioni che stai cercando di impedire?
Il tuo schema è molto complesso. Più uno schema è complesso, più le parti mobili hanno, quindi più debolezze possibili e più facile è lavorare le opere. C'è un modo più semplice per proteggersi dai tuoi vettori di attacco identificati?
Il fattore limitante qui è la forza della password dell'utente e la sua predisposizione all'ingegneria sociale (non deve essere la crittografia a tubo di gomma). Queste cose sono l'anello debole della catena, quindi tutto ciò che puoi fare è assicurarti che sia l'unico anello debole (quindi non è colpa tua se un attaccante è entrato).

Più in particolare gli aspetti tecnici di questo schema:

Avere un MAC separato è un punto debole; poiché il controllo non è integrato con la decrittazione della chiave privata, a seconda della modalità di crittografia, un utente malintenzionato potrebbe sequestrare il software client come oracle di decrittografia per recuperare la chiave privata. Prendi in considerazione l'utilizzo di una modalità di crittografia autenticata che integra il controllo dell'HMAC con la decrittografia del messaggio.
Corollario a quanto sopra, c'è poco valore nell'usare una chiave diversa per calcolare l'HMAC di quanto non si fosse usato per cifrare il testo cifrato che si sta digerendo. Un utente malintenzionato che può modificare i dati nel DB può bloccare l'accesso (abilitando l'ingegneria sociale fingendo di "recuperare" l'account) rimescolando l'HMAC o la chiave, senza segreti. Qualcuno che cerca di ottenere la chiave privata non si preoccuperà affatto dell'HMAC, poiché non è necessario rompere l'HMAC per violare la chiave crittografata. Quindi, considera la combinazione di k2 e k3 in una singola chiave a 256 bit che crittografa la chiave RSA privata utilizzando una modalità autenticata.
Il server non funziona in questo schema oltre alla corrispondenza dei dati e non hai menzionato la protezione del traffico tra client e server. Lo schema è quindi sfruttabile per ottenere un dump dei dati osservando le richieste di accesso in ingresso e riproducendole, senza dover conoscere alcun segreto usato per generare l'hash della password (k1) che viene trasmesso. Prendi in considerazione la necessità di una connessione sicura tra client e server per mitigare ciò.