Scambio chiavi sulla rete con più di due peer

1

Io e il mio team stiamo sviluppando un videogioco multiplayer con Client / Server-Topology . Ciò protegge la corrispondenza dai clienti che hanno l'intenzione di imbrogliare a causa dell'autorità del server ma consente comunque al server di modificare i pacchetti in uscita e in entrata così come i dati utente sensibili dei giocatori.

Abbiamo scelto di utilizzare AES come metodo di crittografia, ma abbiamo avuto il problema di informare tutti i peer della chiave utilizzata per proteggere i pacchetti di rete con questo metodo di crittografia.

Ho letto l'algoritmo di scambio di chiavi Diffie-Hellman-Merkle che ha funzionato perfettamente tra due peer (Alice e Bob come vengono chiamati negli esempi). Il problema è che il nostro gioco consente partite con un numero variabile di giocatori, che vanno da 2 a 16.

La condizione sembra essere che ogni cliente ha bisogno di generare lo stesso numero b (esponente di g ) per condividere il risultato dell'equazione con il server, in modo che entrambi abbiano lo stesso risultato che è s .

Non ho idea di come generare una chiave segreta su ogni peer, se il tempo a cui i client si connettono e il numero di connessioni sulla corrispondenza sono variabili.

    
posta Doctor Niklas 22.06.2016 - 13:40
fonte

2 risposte

3

Non dovresti distribuire il tuo schema di crittografia per questo, né condividere le chiavi simmetriche con più parti.

Per proteggere i dati durante il transito tra ciascun client e il server, è necessario utilizzare TLS per proteggere tali connessioni. TLS si prenderà cura dell'accordo di chiave simmetrica e della decrittografia della crittografia per ogni cliente nel modo giusto, evitando molte cose che non vengono prese in considerazione per la protezione dei dati durante il transito. Ma non sarà una chiave condivisa tra tutti i client, ma una chiave per ogni cliente, e anche una chiave che cambia su nuove sessioni / connessioni. Fondamentalmente farà un accordo di chiave AES in stile DH con ogni utente (può scegliere anche altri algoritmi), ma si prenderà cura di evitare molti attacchi che sono possibili in tali schemi che non riuscirai nemmeno a catturare se usi semplicemente DH per concordare una chiave simmetrica, anche se si esegue un accordo DH con ciascun utente.

Se si desidera proteggere anche i dati a riposo, vale a dire, se memorizzati, non vi è alcun guadagno sulla condivisione di una chiave. Ognuno dovrebbe generare la propria chiave segreta.

    
risposta data 22.06.2016 - 14:31
fonte
-1

Questa cosa dovrebbe essere semplice.

Per prima cosa hai bisogno di una libreria crittografica come openssl .

Se c'è una fase registrazione ,

  • potresti avere i client generare una coppia di chiavi private / pubbliche , (DH o RSA, usando openssl )
  • quindi annuncia la parte pubblica sul server, anche chiamata certificato client .

E questo è tutto. Su ogni nuova connessione client-server , verrà generata e scambiata una chiave simmetrica (AES) utilizzando i certificati.

Non hai davvero bisogno di cambiare queste chiavi spesso.
Ma se lo fai, giocare a un gioco sembra una grande opportunità per l'alta entropia , che aiuterà i calcoli di casualità , usati nella generazione delle chiavi.

    
risposta data 22.06.2016 - 14:27
fonte

Leggi altre domande sui tag