Ci sono difetti in scambio di tasti in due fasi (RSA + AES) e configurazione sicura del canale?

Question

Ci sono difetti in scambio di tasti in due fasi (RSA + AES) e configurazione sicura del canale?

Naviga le tue risposte

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

1

Per impostare un canale sicuro con il server, utilizzo la seguente configurazione nella mia applicazione:

1.Generare una chiave AES casuale e una IV casuale

2.Encrypt AES Key, IV e le credenziali del cliente con chiave pubblica RSA

3.Invia al server

4. Il server decodifica usando la chiave RSA privata

5.Server verifica le credenziali

6.Server risponde con [(OK o FAIL) + salt casuale] crittografato con il tasto AES

7. Client verifica la risposta

8. Il canale di comunicazione è designato come autentico e la sessione è valida

9.Tutte le altre comunicazioni aziendali passano tramite lo stesso tasto AES fino alla fine della sessione (Disconnessione)

Ulteriori dettagli:

1.Le chiavi RSA pubbliche e private sono hardcoded e costanti per tutta la durata dell'applicazione, ovvero non avviene l'acquisizione di chiavi pubbliche da fonti esterne

2. Tutti i testi in chiaro noti come OK FAIL ecc. vengono inviati saltosamente

Credo che questa configurazione dovrebbe essere praticamente infallibile a meno che qualcuno non abbia accesso alle operazioni client o server (o interrompa RSA)

Esistono potenziali fori di loop in questa configurazione che non sono riuscito a realizzare o ignorare?

cryptography encryption aes rsa decryption

posta Allahjane 20.10.2016 - 16:37

fonte

2 risposte

Leggi altre domande sui tag cryptography encryption aes rsa decryption

Gli eseguibili di setuid non sono autorizzati a usare lo swap? Criteri per gli amministratori delle password

score 1 · Answer 1

Il tuo concetto sembra per lo più buono, ma vedo due difetti in esso:

Autenticazione non crittografica : suggerirei che nel passaggio 2, anziché inviare le credenziali, sia sufficiente inviare un identificativo utente e derivare una chiave MAC per il segreto dell'utente che si utilizza per autenticare i dati rimanenti. Ciò ridurrebbe la possibilità che qualcuno manomettesse i dati e inoltre migliorasse la sicurezza non dovendo inviare alcun segreto.
Nessuna segretezza in avanti : se questo è un problema reale dipende dal tuo scenario ma dal momento che hai dichiarato che la chiave privata RSA è codificata nel tuo software, presumo che potrebbe esserlo (soprattutto dal momento che il tuo piano attuale è per inviare alcune credenziali segrete nel passaggio 2 sempre crittografate con la stessa chiave). Invece di inviare una chiave AES nel passaggio 2, è possibile inviare mezzo messaggio di scambio chiave Diffie-Hellman e restituire il messaggio di scambio chiavi del server nel passaggio 6 insieme alla risposta crittografata.

Non è davvero un problema, ma comunque degno di nota: non vedo un punto nel creare l'IV sul client e trasferirlo crittografato. Una IV non è una cosa segreta, potrebbe anche essere creata sul server e inviata insieme al messaggio nel passaggio 6 in testo non crittografato.

score 1 · Answer 2

Una delle cose su cui uno schema dovrebbe essere immune è il MITM e la riproduzione di token. E qui vedo un problema. Cosa impedisce a un MITM di sopprimere la risposta di un server e riprodurre un messaggio precedentemente acquisito? A seconda dei payload dell'applicazione che invii, questo può creare seri danni.

Per evitare ciò dovresti includere un numero di sequenza nella tua comunicazione. Il cliente invia il numero X, a partire da 1, la risposta del server deve contenere il 2 e così via. Sarebbe anche meglio verificare come TLS risolve questo problema e copi questo meccanismo. Forse è necessario includere un timestamp e memorizzare i dati nella cache in una sessione per ottenere la completa sicurezza di riproduzione.

Inoltre, non dici cosa significa "fine sessione". Rottura della connessione TCP / IP? Penso che sarebbe utile per la sicurezza definire chiaramente come gestire la nozione di "sessione". Se una sessione è in sospeso, lo stesso client è autorizzato ad aprire una seconda sessione per lo stesso utente? Se la sessione è inattiva per X minuti, è obbligatorio che il server riprenda una sessione oppure può rispondere "no, per favore stabilirne una nuova" (con una nuova chiave di sessione AES). Crea una possibilità di chiudere esplicitamente la sessione attraverso un messaggio corrispondente (che consente ai partner di liberare risorse di calcolo).