¿Cómo protejo mi juego con la clave del CD / número de serie?

Así que decidí que quiero evitar que las copias pirateadas de mi juego XNA accedan a los servidores oficiales del juego (que son moderados, para que las personas que pagaron por el juego obtengan la mejor experiencia) desconectando a los clientes con un CD incorrecto o generado, duplicado o prohibido. teclas (o números de serie, ya que el juego es digital y no hay CD en absoluto).

¿Cómo consigo ese sistema de protección de número de serie en mi juego (tanto clientes como servidor de autenticación principal), para que no sea fácilmente pirateable?

Tenga en cuenta que no tengo experiencia en hacer una buena protección de ese tipo para el software.

Nunca he hecho esto antes, pero entiendo lo básico. Veo por qué no puedo hacer verificaciones de clave en el cliente, por lo que está bien para mí usar la autenticación de inicio de sesión / pase con entrada de clave única.

Actualmente, el objetivo de esta protección es mantener a los tramposos potenciales y a los jugadores que se comportan de manera disruptiva fuera de los servidores oficiales. Cualquiera puede jugar en servidores privados con o sin clave, pero la posibilidad de que obtengan una experiencia no deseada con otros jugadores es mayor. Supongo que es bastante fácil comprar jugadores, ya que tienen que estar en línea para jugar en los servidores oficiales.

Debido a que piratear el cliente es demasiado fácil, protegeré solo los procedimientos de registro inicial (y posiblemente de autenticación del lado del servidor), para que nadie pueda robar las claves mientras se transfieren.

Ver también:

¿Cómo deben manejar los juegos multijugador la autenticación?

Básicamente, tienes tres requisitos:

1. no debería ser fácil usar la misma clave para varias instancias de clientes,
2. no debería ser fácil generar nuevas claves válidas, y
3. No debería ser fácil robar la clave de un cliente legítimo.

La primera parte debería ser bastante sencilla: simplemente no permita que dos jugadores inicien sesión en el mismo servidor con la misma clave al mismo tiempo. También puede hacer que los servidores intercambien información sobre los usuarios registrados o que se comuniquen con un servidor de autenticación compartido, de modo que incluso al usar la misma clave para diferentes jugadores en diferentes servidores al mismo tiempo falle. Probablemente también desee buscar patrones sospechosos de uso de claves y, si determina que se ha filtrado una clave, agréguela a una lista de claves prohibidas.

Para la segunda parte, una forma es simplemente mantener una base de datos de todas las claves emitidas válidas. Mientras las claves sean lo suficientemente largas (digamos, 128 bits o más) y se elijan al azar (usando un RNG seguro), las probabilidades de que cualquiera logre adivinar una clave válida son esencialmente cero. (Incluso las claves mucho más cortas pueden ser seguras si usa algún tipo de limitación de velocidad en intentos fallidos de inicio de sesión para detener los intentos de encontrar claves válidas por fuerza bruta).

Alternativamente, puede generar claves tomando cualquier identificador único y agregando un código de autenticación de mensaje (como HMAC ), calculado utilizando una clave maestra secreta. Nuevamente, mientras el MAC sea lo suficientemente largo, las probabilidades de que cualquiera que no conozca la clave maestra pueda adivinar un MAC válido para cualquier ID es insignificante. Una ventaja de este método, además de eliminar la necesidad de una base de datos de claves, es que el identificador puede ser cualquier cadena única y puede codificar información sobre el cliente para el que se emitió la clave.

Un problema con el uso de MAC es que los servidores oficiales del juego (o al menos el servidor de autenticación) necesitan conocer la clave maestra para verificar la MAC, lo que significa que, si los servidores son pirateados, la clave maestra podría filtrarse. Una forma de mitigar este riesgo podría ser calcular varios MAC para cada ID, utilizando diferentes claves maestras, pero solo almacenar una de las claves maestras en los servidores del juego. De esa manera, si esa clave maestra alguna vez se filtra y se usa para generar ID falsas, puede revocarla y cambiar a otra clave maestra. Alternativamente, puede reemplazar los MAC con firmas digitales , que pueden verificarse utilizando solo la mitad pública de la clave maestra.

Para la tercera parte, un enfoque es asegurarse de que el cliente no envíe su clave a nadie sin verificar que el destinatario realmente sea un servidor oficial legítimo. Por ejemplo, podría usar SSL / TLS (o DTLS ) para el proceso de inicio de sesión, emitir certificados personalizados para sus servidores de juegos y solo tener los certificados de confianza del cliente emitidos por usted. Convenientemente, el uso de TLS también protegerá las claves del cliente (y cualquier otro dato de autenticación) de espías, por ejemplo, en WLAN públicas.

Desafortunadamente, este enfoque no permitirá que los servidores de terceros verifiquen las claves del cliente, incluso si así lo desean. Podría solucionar este problema configurando un servidor de autenticación oficial que los servidores de juegos de terceros puedan utilizar, por ejemplo, haciendo que el cliente inicie sesión en el servidor de autenticación y reciba un token aleatorio que pueden usar para iniciar sesión en el servidor de juego (que luego envía el token al servidor de autenticación para verificarlo).

Alternativamente, puede emitir certificados de cliente reales, o algo así, a sus clientes. Puede usar un protocolo existente (como TLS) que admita la autenticación de certificado de cliente (recomendado) o implementar el suyo propio, por ejemplo:

• El certificado del cliente consta de una cadena de identificación arbitraria, un par de claves pública / privada y una firma digital de la identificación y la clave pública utilizando la clave maestra.
• Para iniciar sesión, el cliente envía su ID, clave pública y firma. El servidor responde con una cadena de desafío única (preferiblemente que incluye una ID de servidor y una marca de tiempo, que el cliente debe verificar), que el cliente firma con la clave privada (para demostrar que conoce la clave) y envía la firma al servidor.
• El servidor verifica ambas firmas, lo que demuestra que la clave pública ID + forma una clave de cliente legítima (ya que fueron firmadas con la clave maestra) y que la clave del cliente realmente pertenece al cliente (ya que el cliente podría firmar el desafío del servidor con la clave privada llave).

(Este protocolo podría simplificarse aún más si el cliente genera el "desafío", que consiste en un ID de servidor y una marca de tiempo, y lo firma. Por supuesto, el servidor debe verificar que el ID y la marca de tiempo sean válidos. También tenga en cuenta que Este simple protocolo, por sí solo, no impedirá que un atacante intermediario pueda secuestrar la sesión del cliente, aunque evitará que obtenga la clave privada del cliente necesaria para futuros inicios de sesión).

No hay 100% de ahorro, pero podría comenzar con un enfoque bastante simple:

• Necesitará alguna forma de verificar las claves generadas, por ejemplo, las sumas de verificación incluidas. Por supuesto, esto no debe ser demasiado fácil de entender.

• Opcional (pero recomendado) habría una base de datos del lado del servidor que verifica las claves con una base de datos de todas las claves dadas para que no pueda generar claves, incluso si tiene el algoritmo (ignoremos la fuerza bruta).

A partir de ahí, puede tener dos enfoques diferentes, pero de cualquier manera algo es muy importante:

• No verifique la clave en el lado del cliente. Esto es muy importante, porque en realidad es bastante fácil descompilar cosas escritas en .net / XNA. Si tiene que pedir la clave o pasarla (inicio de sesión o registro), coloque la clave en hash (con una sal agregada, etc.) y envíela al servidor.

En cuanto a los caminos reales:

• Requerir que se envíe la clave hash (ver arriba) durante el procedimiento de autenticación / inicio de sesión.

• Como alternativa (la OMI es la mejor, aunque a muchos no les gusta este tipo de "DRM"): no utilice la clave en el cliente. En su lugar, solicite al usuario que inicie sesión en una cuenta y una clave de CD válida (esto requiere la base de datos mencionada anteriormente) para crear cuentas. Así es como los juegos modernos, por ejemplo, cualquier MMORPG de pago por juego maneja esto.

Personalmente, optaría por el enfoque de la cuenta debido a una razón simple: al final, no se puede evitar que las personas roben claves de CD (fuerza bruta, ingeniería inversa o estafa). Como tal, la gente podría crear una nueva clave para seguir jugando o bloquear a otros del juego. Con las claves vinculadas a la cuenta, nadie puede hacer nada con una clave que ya está en uso. En caso de que alguien haya comprado una clave generada por otra persona, aún podría transferir la propiedad de la cuenta suponiendo que haya pruebas suficientes de ello.

Pangea Software -creador de varios juegos para Mac- ha escrito un tema sobre la protección contra copia en su libro (ahora gratuito) de desarrollo de juegos. El libro también explica cómo lidiar con las llaves piratas y otros hacks que la gente usa. El libro se centra en el desarrollo de juegos para Mac, pero las ideas podrían ser útiles para otras plataformas. El libro incluye el código fuente de cada capítulo, parte de la descarga a continuación. También se incluye el código fuente (escrito en C) relacionado con la protección contra copia.

El libro se puede descargar aquí .