Seguridad para un juego multijugador en línea de baja latencia

4

Estoy diseñando un juego multijugador en línea y estoy buscando un buen intercambio de comunicaciones seguras con un uso mínimo de la CPU y el ancho de banda. Mi solución ideal solo usaría paquetes UDP ya que TCP es una mala elección para los requisitos en tiempo real del juego. Sin embargo, no tengo ningún problema en recurrir a TCP para el servidor de inicio de sesión.

Aquí está mi idea.

Cuando los usuarios inician sesión por primera vez en el servicio :

  1. Los usuarios se conectan a un servidor de autenticación (que posee un certificado de Verisign) a través de SSL.
  2. El servidor de autenticación valida las credenciales de inicio de sesión del usuario.
  3. Si el inicio de sesión es válido, el servidor genera dos pares de claves públicas / privadas AES de 256 bits. Al usuario se le envía una clave privada y una clave pública para recordar, que luego se puede utilizar para la comunicación simétrica. El servidor recuerda los pares de teclas opuestas.
  4. Además, se genera un entero de 32 bits aleatorio y se envía al usuario. Llamaré a esto la "clave de ofuscación" por ahora.
  5. La conexión SSL ha finalizado. De aquí en adelante, todos los datos se envían a través de UDP.

Cuando un usuario necesita realizar una transacción segura con un servidor :

  1. Para las solicitudes, la carga útil se cifra mediante la clave pública que recibió el cliente.
  2. Para las respuestas, la carga útil se descifra mediante la clave privada que recibió el cliente.

Mi primera pregunta: ¿es seguro y recomendable ?

El otro problema que estoy tratando de resolver es enviar paquetes oportunos para actualizaciones que no tienen que ser tan seguras, pero son extremadamente frecuentes, como el movimiento y la posición del jugador.

El envío de los datos en claro es peligroso debido a la repetición de paquetes triviales y los ataques de intermediarios. Sin embargo, creo que realizar el cifrado AES para cada paquete sería un uso intensivo de la CPU. En cambio, estoy considerando una ofuscación de cifrado XOR simple de la siguiente manera:

  1. Cree una clave para el cifrado XOR mediante una marca de tiempo de 32 bits con la "clave de ofuscación" recibida anteriormente.
  2. Aplique el cifrado XOR a la carga útil del paquete UDP.
  3. Envíe el paquete UDP con la marca de tiempo en el encabezado más la carga útil confusa. De esta manera, el servidor puede desenfocarse usando la misma marca de tiempo.

Una cosa que espero lograr con esto es simplemente disuadir a los rastreadores de paquetes y "guiones de niños" que podrían intentar realizar una ingeniería inversa trivial del protocolo. Otra preocupación es la prevención de ataques de repetición de paquetes, que es la razón para incluir la marca de tiempo en el cifrado XOR. Finalmente, espero que agregar la "clave de ofuscación" en la mezcla evitará los ataques triviales de hombre en el medio.

Mi segunda pregunta: ¿existe una forma más sencilla y / o más efectiva de alcanzar estos objetivos?

Me doy cuenta de que estas son preguntas cargadas, así que gracias de antemano por tomarse el tiempo para leer esto.

    
pregunta Kai 03.12.2011 - 06:27
fuente

1 respuesta

5

En la medida en que entiendo lo que está proponiendo, me preocupa que este no sea un gran diseño. Parece que podría ser más complejo de lo necesario. Me preocupa cualquier diseño que tenga el servidor conociendo las claves privadas del cliente; Se siente como un riesgo innecesario. El uso de "claves de ofuscación", cifrados XOR y similares levanta banderas rojas. Por estas razones, me preocuparía su seguridad.

Me pregunto si hay una solución más simple. Mi recomendación sería: eche un vistazo a Seguridad de la capa de transporte de datagramas (DTLS) . DTLS es una variante de TLS diseñada especialmente para protocolos de datagramas, como UDP. Está diseñado para funcionar bien incluso en presencia de paquetes caídos y reordenados. DTLS está razonablemente bien investigado. Usar un esquema aceptado, publicado y bien evaluado es mucho más seguro (y mucho más barato) que diseñar el suyo propio. Por lo tanto, si DTLS satisface sus necesidades, parece que sería una gran solución.

Si no satisface sus necesidades, regrese y háganos saber qué requisitos no cumple, y podremos hacer otra sugerencia.

    
respondido por el D.W. 03.12.2011 - 06:47
fuente

Lea otras preguntas en las etiquetas