¿Cómo evitar que un servidor pirateado falsifique un servidor maestro?

Deseo configurar un modelo de juego multicapa basado en sala donde los jugadores puedan organizar partidos y servir como host (es decir, el servidor con poder autorizado). Deseo alojar un servidor maestro que rastrea los artículos, rango, efectivo, exp, etc. del jugador.

En dicho modelo, ¿cómo puedo evitar que alguien que aloja un juego (con un servidor modificado) falsifique el servidor maestro con resultados de partidos no válidos, obteniendo así experiencia, dinero o clasificaciones?

Gracias. -Cody

Se ha señalado que mi respuesta anterior puede haberse basado en un malentendido de lo que querías decir con "falsificación". (Si es así, hágamelo saber y lo eliminaré).

Si lo que desea evitar es que los servidores del juego envíen datos falsos al servidor maestro, entonces, como señala Jari Komppa, generalmente es imposible evitarlo por completo. De hecho, es simplemente una variante del clásico problema de prevención de trampas multijugador , excepto con los servidores intermedios en lugar de que los clientes sean los sospechosos de hacer trampa. Muchas de las mismas técnicas utilizadas para la prevención tradicional de trampas también podrían funcionar aquí, pero como de costumbre, ninguna de ellas es completamente infalible.

Dicho esto, no son algunas cosas que podría hacer que ayudarían específicamente contra los servidores de engaño. Una de ellas sería que cada jugador en un partido contacte por separado con el servidor maestro y confirme que está participando en ese partido. (Usted probablemente querrá hacer eso antes de que comience el partido, por lo que puede asegurarse de que todos están de acuerdo que los participantes son y para que nadie de la tentación de afirmar que no participaron en un partido que perdieron. Usted podría utilizar firmas digitales a aplazar eso, sin embargo; esencialmente, podría hacer que cada jugador en un partido firme un mensaje que diga " Soy el jugador X y estoy participando en el partido M en el servidor S en el momento T con los jugadores Y, Z y W."y enviarlo al servidor del juego, que luego puede retransmitirlo al servidor maestro.) De esa manera, al menos puedes asegurarte de que un servidor de trampa no pueda afectar la clasificación de ningún jugador que realmente no juegue en ese servidor .

Esto es particularmente útil si está utilizando algo como las clasificaciones de Elo, donde la clasificación de los jugadores depende principalmente de su rendimiento relativo . Claro, alguien que ejecuta un servidor falso aún podría crear un montón de cuentas falsas y enviar resultados diciendo que su propia cuenta venció a las falsas, pero con un sistema de clasificación relativo, todo lo que hará es hacer que la cuenta del tramposo se ubique ligeramente por encima de las falsas ( que a su vez tendrá calificaciones de fondo).

Otra cosa obvia para desalentar las trampas es permitir que los jugadores verifiquen los resultados de sus partidos directamente desde el servidor maestro. Si un jugador gana una partida en un nuevo servidor, pero los resultados enviados al servidor maestro dicen que perdieron (o si los resultados nunca se envían), eso les hará saber que está sucediendo algo sospechoso. Con suerte, en ese momento informarán al servidor por trampa, o al menos votarán con sus pies y nunca volverán a jugar en ese servidor.

De hecho, puede hacer que esto sea automático: después de cada juego, una vez que los resultados se hayan enviado al servidor maestro, haga que los clientes los recuperen del servidor maestro y los comparen con la forma en que el cliente cree que terminó el juego. Si hay una falta de coincidencia, infórmelo tanto al jugador (para que sepan que algo anda mal) como al servidor maestro (para que pueda detectar los servidores de trampa). Por supuesto, como operador del servidor maestro, deberá decidir quién está mintiendo, el servidor o el jugador, pero es de esperar que en la mayoría de los casos eso sea bastante obvio a partir del patrón de los informes.

Nota: Esta respuesta puede estar basada en un malentendido de la pregunta; vea los comentarios a continuación.

Respuesta genérica corta: use firmas digitales .

Específicamente, el servidor maestro debe tener una clave privada para un esquema de firma digital adecuado (RSA, DSA, ECDSA, etc.) y de alguna manera debe transmitir de manera segura su clave pública a todos los clientes. Luego, el servidor puede firmar cualquier dato que envíe a los clientes con la clave privada (o posiblemente usarlo para negociar un secreto compartido utilizable para cifrar y / o autenticar simétricamente las comunicaciones entre él y ese cliente en particular) y el cliente puede usar la clave pública para Verifique que la firma haya sido generada por el servidor.

Por supuesto, su próximo problema es distribuir la clave pública para que un servidor no autorizado pueda falsificar eso y sustituir su propia clave pública. Puede que no sea tan difícil si puede hacerlo por adelantado (por ejemplo, distribuir la clave junto con el ejecutable del juego), pero se vuelve complicado si tiene que hacerlo más tarde, por ejemplo, porque la identidad del servidor maestro no se conoce en avanzar. Una solución estándar es distribuir alguna otra clave pública (cuya clave privada correspondiente solo es conocida por usted) por adelantado a todos los clientes, y luego firmar el mensaje que contiene la clave pública del servidor maestro con esa otra clave antes de transmitirla.

De hecho, incluso podría extender aún más estas cadenas de firmas, por ejemplo, tener una clave privada maestra súper secreta, que se mantiene en una caja fuerte en algún lugar y cuya clave pública sea conocida por todos los clientes, y otra clave privada de "uso diario" que se usa para firmar realmente las claves del servidor, y cuya clave pública está firmada con la clave maestra súper secreta antes de encerrarse en la caja fuerte. Esto no es tan útil por sí mismo, pero se vuelve potencialmente muy útil si también incluye algún mecanismo para revocar las claves comprometidas, de modo que, por ejemplo, si se filtra su clave de uso diario, puede revocarla y generar otra.

Lo que describo anteriormente es un tipo rudimentario de infraestructura de clave pública . En realidad, implementar uno de forma segura puede ser bastante complicado, pero afortunadamente ya se ha hecho antes. De hecho, cada vez que se conecta a un sitio web (como Wikipedia ) usando HTTPS , esto es casi exactamente lo que hace su navegador: recibe un certificado de clave pública del servidor, verifica que el certificado coincida con el nombre del servidor en la URL, no aparece como revocado y ha sido firmado por una autoridad de certificación conocida y confiable , y luego lo usa para negociar una clave de cifrado simétrica temporalconocido solo para sí mismo y para el propietario de la clave privada correspondiente al certificado. Esta clave simétrica se utiliza para cifrar y autenticar todos los datos enviados entre el cliente y el servidor.

En particular, debería echar un vistazo a las bibliotecas SSL / TLS existentes (que generalmente vienen con una implementación PKI X.509 ), o posiblemente en SPKI . Estos todavía son algo complicados, pero probablemente más fáciles (y más seguros) que intentar rodar los tuyos.

Esto depende de la naturaleza del juego y de la razón por la que estás descargando el rol del servidor.

En ciertas circunstancias, es posible que pueda lograr esto principalmente con registros de auditoría criptográficos. Por ejemplo, si se trata de un juego por turnos para dos jugadores y puede hacer arreglos para que cada cliente tenga una clave asimétrica privada para fines de firma, puede tener un protocolo en la línea de

• El estado inicial S0 incluye un identificador único para el juego (para evitar ataques de repetición) y, por lo demás, se supone que es constante. Si hay un elemento aleatorio, ese debe ser producido por el servidor central y almacenado en caché para futuras comparaciones.
• P1 hace el movimiento m1; firma el estado resultante S1, produciendo la firma C1; y lo envía con su movimiento (S1, C1, m1) a P2.
• P2 hace mover m2; firma el estado resultante S2, produciendo la firma C2; y lo envía con su movimiento (S2, C2, m2) a P1.
• etc.

Al final, ambos clientes envían el resultado al servidor central y, si no están de acuerdo, envían las pistas de auditoría: (S1, C1, m1), (S2, C2, m2), etc. Como cada jugador ha firmado sus movimientos, Están comprometidos con ellos.

Todavía es vulnerable a que un jugador se DDOS al otro para evitar que envíen su resultado, pero realmente no hay mucho que pueda hacer al respecto.

Nota: este es solo un boceto rápido: estoy seguro de que si lo publica en crypto.stackexchange.com, alguien hará agujeros enormes en él, pero creo que el principio es sólido. Obtenga cualquier esquema que diseñe revisado por alguien que conozca sus cosas antes de comenzar a confiar en él.