Condividi o non condividi la chiave pubblica per i server?

4

Per crittografare le comunicazioni dal nostro client (personalizzato) ai nostri server (personalizzati) il nostro schema attuale è un po 'come questo:

  1. Il client utilizza la chiave pubblica raggruppata A per crittografare il materiale di una chiave casuale.
  2. Il server della lobby lo decrittografa con la chiave privata, utilizza il materiale della chiave crittografato per configurare un canale crittografato con crittografia simmetrica.
  3. Il client riceve un'altra chiave pubblica B1 dal server della lobby per accedere al server di gioco 1, sul canale crittografato. (Il Game Server 2 dovrebbe avere la chiave pubblica B2 ecc., Ognuno di questi viene generato al riavvio del server)
  4. Il client si connette al server di gioco e segue lo stesso schema di 1-2 per proteggere le comunicazioni.

Tralasciando il modo in cui il materiale chiave viene generato e utilizzato, eventuali cambiamenti nella sicurezza lo cambiamo in:

  1. Il client utilizza la chiave pubblica in bundle A per crittografare il materiale chiave
  2. Il server della lobby decodifica con la chiave privata, utilizza il materiale della chiave crittografato per configurare un canale crittografato con crittografia simmetrica.
  3. Il client si connette al server di gioco e segue lo stesso schema di 1-2 per proteggere le comunicazioni con THE SAME PUBLIC KEY "A" utilizzato dalla lobby (quindi entrambi i server di lobby e di gioco utilizzano la stessa chiave privata)

In altre parole, otteniamo una maggiore sicurezza solo utilizzando la chiave pubblica in bundle per l'accesso alla lobby?

Un'alternativa finale sarebbe con un server di login separato:

  1. Creiamo un server di login al quale il client si connette nel modo 1-2
  2. Il client riceve quindi una nuova chiave simmetrica C e un numero identificativo D
  3. Il client si connette al server della lobby, presenta il numero D in testo normale.
  4. La lobby e il client ora continuano a comunicare usando la chiave (supponiamo che C sia in un db condiviso o simile) C
  5. Il client si connette al server di gioco, di nuovo segue 3-4 per configurare un canale crittografato.

Alcuni di questi schemi sono significativamente peggiori o migliori degli altri? Non vedo alcuna differenza enorme.

    
posta Nuoji 31.12.2012 - 14:35
fonte

1 risposta

7

Un vantaggio potenzialmente significativo di non utilizzando la stessa chiave privata sia per la lobby che per i server di gioco è che, anche se una o più chiavi del server di gioco sono compromesse, la chiave del server lobby ( la cui metà pubblica è in bundle con il client, rendendo difficile il cambiamento) è ancora al sicuro.

Presumibilmente, i server di gioco presentano una superficie di attacco significativamente più grande (e più frequentemente mutevole) rispetto a un server di lobby dedicato, quindi è logico progettare il sistema in modo da essere in grado di recuperare da un attacco sui server di gioco, rendendo Il server lobby è difficile da compromettere il più possibile.

La terza alternativa condivide anche questo vantaggio, dal momento che solo il server di login deve conoscere la metà privata della chiave in bundle. In effetti, a seconda di cosa altro a parte l'autenticazione del server "lobby", separare le funzioni di autenticazione critiche su un server dedicato potrebbe essere una buona idea.

Inoltre, la terza alternativa garantisce che i client non saranno in grado di ignorare il server di lobby / login anche se in qualche modo riescono ad acquisire una copia delle chiavi pubbliche del server di gioco (ad esempio da un altro client compromesso). (Il client potrebbe ancora ignorare il server di login se in qualche modo ha acquisito la chiave simmetrica di un altro client, ma poiché tali chiavi sono legate agli ID client, i tuoi server dovrebbero essere in grado di rilevarlo.) A seconda del tuo caso d'uso, questo può o non può essere un vantaggio, ma almeno non dovrebbe ferire.

    
risposta data 31.12.2012 - 17:30
fonte

Leggi altre domande sui tag