Strano utilizzo della RSA: quanto è sicuro?

Question

Strano utilizzo della RSA: quanto è sicuro?

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

4

Il seguente schema di comunicazione è sicuro?

A mio parere, usa il modulo RSA e l'esponente della chiave pubblica come un segreto crittografico, che è uno strano uso di RSA, ma può essere facilmente rotto a causa di ciò?

Descrizione della comunicazione fornita dal venditore:

Il client genera una nuova coppia di chiavi RSA a 1024 bit sulla sua macchina ogni 10 ore e carica la chiave pubblica sul server. Il client viene autenticato tramite password e Server si autentica con il certificato SSL / TLS.
Se il server desidera che il client fornisca i dati, il server genera la chiave AES e la invia al client crittografando il messaggio con la chiave pubblica del cliente utilizzando la libreria OpenSSL.
Il client invia i dati crittografati con AES al server.

Potenziale problema: il server è autenticato contro il client nella seconda parte della comunicazione?

cryptography encryption rsa

posta random_crane 28.12.2015 - 14:28

fonte

3 risposte

Leggi altre domande sui tag cryptography encryption rsa

Overflow di dati anziché nascondere Come posso proteggere le chiavi pubbliche dei client memorizzati su un server?

score 1 · Answer 1

Per quanto posso vedere, avrebbero dovuto usare TLS per ottenere una crittografia migliore con meno lavoro.

L'uso di RSA per scambiare la chiave di sessione AES effimera è uno dei modi più comuni con cui TLS è configurato.

Diversi problemi con questo schema personalizzato:

RSA a 2048 bit è considerato lo standard minimo per RSA al giorno d'oggi. L'RSA a 1024 bit è oggi considerato forzato bruto da un aggressore altamente avanzato nel prossimo futuro.
La crittografia AES non autentica il mittente e l'aggiunta dell'autenticazione a una crittografia è piuttosto complessa da eseguire correttamente. Ti suggerisco di cambiare il punto # 3 per utilizzare Crittografia autenticata , le recenti librerie TLS supportano AEAD, ad esempio, con GCM
Nel passaggio 2, la chiave di sessione viene inviata tramite la rete. TLS userebbe Diffie-Hellman per fare in modo che il client e il server derivino una chiave di sessione simmetrica rispetto alla comunicazione non sicura canale.

score 0 · Answer 2

Potential problem: is the Server authenticated against the Client in the 2nd part of communication?

Se la chiave pubblica è distribuita pubblicamente, allora sì, sarebbe un modo piuttosto sbagliato di fare una trasmissione sicura. Sembra anche piuttosto debole usare una password come passo 1.

score 0 · Answer 3

Questa impostazione è sostanzialmente sicura .

Non segue le migliori prassi normali, ma non riesco a vedere un modo diretto per attaccare il protocollo. La chiave pubblica RSA è mantenuta privata, quindi qualcuno esterno non può facilmente fare il passaggio 2.

C'è ancora il rischio di difetti di implementazione, tra cui:

Superamenti del buffer
Injection flaws
Problemi di gestione della password (ad esempio, nessun blocco)
Debolezze crittografiche (ad esempio casualità insufficiente)

In particolare, sarei interessato a vedere se al passo 2 potresti inviare tutti gli zeri al server. Potrebbe essere che qualunque sia la chiave RSA, questo risulterà in un tasto AES di tutti gli zeri usati. Questo però non funzionerà se usano il padding.

Un'implementazione migliore sarebbe quella di abolire completamente il passaggio 1 e nel passaggio 2 il server autenticare con un certificato client. I dati saranno quindi inviati direttamente su questa connessione TLS senza ulteriore crittografia.