Miglior meccanismo di crittografia per l'archiviazione / lo scambio di messaggi nell'applicazione client / server

1

Quindi sto costruendo un sistema client / server che è simile all'idea di posta elettronica in cui i client scambiano messaggi attraverso il server con i seguenti requisiti principali (si noti che i client sono pre-registrati al server e devono autenticarsi prima di qualsiasi trasmissione di messaggi):

  • Ogni messaggio deve essere crittografato e nessuno può leggerlo tranne il mittente e il destinatario.
  • Il tempo di crittografia non dovrebbe richiedere molto tempo
  • Il messaggio deve essere memorizzato su entrambi i lati del client e del server (messaggio crittografato una volta creato anche se il client decide di memorizzarlo e inviarlo in un secondo momento: Crittografia a livello di applicazione ).

Ho proposto tre soluzioni per farlo e sto ancora studiando i pro e i contro di ciascuna soluzione se non ti dispiace aiutarmi:

A- Utilizzo della crittografia a chiave simmetrica con il server Ogni client ha una chiave segreta condivisa con il server Il mittente A crittografa il loro messaggio con la chiave segreta condivisa KA > il server decrittografa il messaggio con KA e lo ricodifica nuovamente con la chiave segreta condivisa del ricevitore B KB > il ricevitore B decrittografa il messaggio con la sua chiave condivisa KB

La sfida in questa soluzione è che il server deve decodificare e quindi crittografare nuovamente il messaggio. è sicuro o no? perché?

B- Utilizzo della crittografia a chiave ibrida simmetrica e asimmetrica con il server

Il server memorizza 2 diversi tipi di chiave per ogni cliente registrato

  1. Chiave condivisa tra server e client
  2. Chiave pubblica del client

• Quando il mittente A vuole crittografare un messaggio sul ricevitore B

  1. Un comunicare con il server e ottenere B chiave pubblica Bpk utilizzando il server condiviso segreto Ka-s
  2. A genera un segreto condiviso per lui e B e crittografa il messaggio con esso Ka-b (messaggio)
  3. A crittografa il segreto condiviso generato con la chiave pubblica B e lo aggiunge al messaggio crittografato Ka-b (messaggio), Bpk (Ka-b)

• Quando B riceve un messaggio crittografato

  1. B ottiene Ka-b decifrandolo usando la sua chiave privata Bpri (Bpri (Ka-b))
  2. B decrittografa il messaggio utilizzando il segreto condiviso Ka-b

La sfida in questa soluzione è l'overhead per crittografare il messaggio in cui il mittente deve generare una chiave ogni volta che vuole inviare un messaggio.

C- Utilizzo simmetrico senza coinvolgimento del server:

Ogni client registrato ha una chiave condivisa con qualsiasi altro client registrato. Se A vuole inviare un messaggio a B, può recuperare la chiave condivisa memorizzata Ka-b e crittografare il messaggio con esso quindi caricarlo sul server.

In questa soluzione il server non sarà in grado di leggere il messaggio e quindi meno sicurezza richiesta sul server.

La sfida qui è la memorizzazione di tutte le chiavi su ogni applicazione client e la gestione delle chiavi (sincronizzazione tra due client quando si rinnova una chiave condivisa scaduta)

Esistono soluzioni migliori per soddisfare entrambi i requisiti con un'elevata sicurezza?

    
posta Lamia 15.01.2016 - 13:18
fonte

2 risposte

1

Problema con A - Chiunque abbia accesso al server può decifrare il messaggio perché una copia di tutte le chiavi simmetriche è memorizzata sul server. Il testo in chiaro del messaggio può essere temporaneamente memorizzato nella RAM del server quando si esegue nuovamente la crittografia del messaggio

Problema con B - Perché non immediatamente Bpk (messaggio)? Perché usare una chiave di sessione aggiuntiva Ka-b (messaggio), Bpk (Ka-b). Per entrambi i metodi, B non è in grado di autenticare A o garantire l'integrità del messaggio. Chiunque può anche richiedere Bpk dal server. Forse potresti fare ApriK (sha1 (messaggio)), Bpk (messaggio). Quindi, quando B riceve il messaggio, può usare la sua chiave privata per decodificare il messaggio, richiedere Apk dal server, decodificare l'hash del messaggio e confrontarlo con il messaggio che ha ricevuto.

Problema con il problema di gestione della chiave C a causa di un numero elevato di chiavi. Totale n. di chiavi in system = (n) (n-1) / 2. Problema della stretta di mano Anche il non ripudio è un problema quando si usano le chiavi simmetriche. A può affermare che non ha mai inviato il messaggio a B. B ha creato il messaggio stesso utilizzando la chiave simmetrica che gli è nota.

    
risposta data 17.01.2016 - 09:02
fonte
0

Se riesci a comprimere il client con i certificati, ti suggerisco di utilizzare TLS / SSL per la crittografia dei messaggi. Basta pacchettizzare ogni client con il (i) certificato (i) per il / i server / i e sarai in grado di verificare le comunicazioni con il server corretto e che i messaggi siano criptati.

    
risposta data 15.01.2016 - 14:21
fonte

Leggi altre domande sui tag